FrameworkA Pattern Language for Production LLM PlatformsSheet 60

A boundary is a clause the optimizer may not cross.

Governed routing, agent orchestration, and AI-native delivery, unified by one rule.

← Defensible AI

§ 01Status

What this is.

A Pattern Language for Production LLM Platforms

Specification · Deposited. 10.5281/zenodo.22109864, version 1.1, CC BY 4.0. This is the concept DOI and it always resolves to the latest version.

The boundary, optimizer and evidence model Three stacked blocks. At the top a governed boundary states what may not happen and moves only by governance, never by optimization. Beneath it the optimization space, where cost, latency, quality, throughput and autonomy are free to move but cannot exit the boundary. At the base, evidence records what happened and why, proving the boundary held. An arrow on the left shows that widening autonomy widens the optimization space rather than relaxing the boundary. An arrow on the right shows evidence returning to governance as the only route by which a boundary may move. The boundary, optimizer and evidence model Nabeel Khan 2026 https://doi.org/10.5281/zenodo.22109864 https://doi.org/10.5281/zenodo.22109864 Copyright 2026 Nabeel A. Khan. Licensed CC BY 4.0. Nabeel Khan https://nabeelkhan.com/frameworks/pattern-language A BOUNDARY IS A CLAUSE THE OPTIMIZER MAY NOT CROSS Governed Boundary what may not happen moves only by governance, never by optimization constrains Optimization Space cost · latency · quality · throughput · autonomy free to move within the boundary, and unable to exit it produces Evidence what happened, and why proves the boundary held autonomy is raised by widening this space, never by relaxing the boundary above evidence is the only route by which a boundary moves Every pattern in Section 4 is an instance of this figure, declaring its boundary, its optimizer and its evidence in that order. A Pattern Language for Production LLM Platforms v1.1 · Nabeel Khan · nabeelkhan.com/frameworks/pattern-language · CC BY 4.0 · DOI 10.5281/zenodo.22109864
Figure 1. The Boundary Invariant.
§ 02Two kinds of decision

Two kinds of decision.

A production platform built on large language models makes two kinds of decision, and most of its trouble comes from writing both into one clause. An optimization decision improves an objective: lower latency, lower cost, higher quality. A boundary decision fixes a constraint that may not be relaxed for any gain: a residency rule, a least-privilege scope, a human-review threshold. When the two share a clause, improving one silently erodes the other, which is why efficiency and accountability are so often reported as a trade.

The pattern language: three layers, one control path, one evidence plane Governance sits at the top and holds a Boundary Registry governing promotion, review and reversal. Boundaries descend from it into three layers: Infrastructure carrying patterns IP-1 to IP-5 for routing, Application carrying AP-1 to AP-5 for agents, and Operations carrying OP-1 to OP-7 for delivery. Each layer emits an evidence artifact into a single evidence plane below: Routing Evidence, Execution Evidence and Delivery Evidence. All three are joined by one event identity at the base. Boundaries descend, evidence ascends. The pattern language: three layers, one control path, one evidence plane Nabeel Khan 2026 https://doi.org/10.5281/zenodo.22109864 https://doi.org/10.5281/zenodo.22109864 Copyright 2026 Nabeel A. Khan. Licensed CC BY 4.0. Nabeel Khan https://nabeelkhan.com/frameworks/pattern-language GOVERNANCE Boundary Registry promotion, review, reversal boundaries descend LAYER 1 Infrastructure Routing. Which model may serve, under what budget and record IP-1 · IP-2 · IP-3 · IP-4 · IP-5 LAYER 2 Application Agents. How workflows stay inspectable and reviewed AP-1 · AP-2 · AP-3 · AP-4 · AP-5 LAYER 3 Operations Delivery. How authority is granted, earned and revoked OP-1 … OP-7 evidence ascends EVIDENCE PLANE Routing Evidence decision, policy version, basis Execution Evidence plan, calls, checks, outcome Delivery Evidence authority, guardrail, action Event Identity the join key, specified in 5.2 One control path observed at three altitudes. An artifact without the event identity cannot join, and a layer that writes no artifact is not conformant however well its boundary is drawn. A Pattern Language for Production LLM Platforms v1.1 · Nabeel Khan · nabeelkhan.com/frameworks/pattern-language · CC BY 4.0 · DOI 10.5281/zenodo.22109864
Figure 2. Seventeen patterns in three layers.
§ 03The derivation filter

The derivation filter.

The catalogue states the method by which candidates were admitted or rejected, which is the property that lets its size and membership be examined rather than assumed. A pattern catalogue with no stated admission criterion is a list of things its author found interesting.

The four-stage pattern derivation filter A left to right pipeline in four stages. Stage one, a force or failure drawn from four sources: recurring production failure modes, architectural control requirements, governance constraints, and optimization mechanisms needing an explicit boundary. Stage two, a candidate mechanism. Stage three, boundary and optimizer decomposition. Stage four, pattern admission. A candidate that decomposes into an optimizer with no boundary is rejected at stage three and falls out of the pipeline, catalogued inside whichever pattern bounds it. Rejected examples include prompt caching, retrieval augmentation, template versioning, continuous batching, reasoning profile and rate limiting. The four-stage pattern derivation filter Nabeel Khan 2026 https://doi.org/10.5281/zenodo.22109864 https://doi.org/10.5281/zenodo.22109864 Copyright 2026 Nabeel A. Khan. Licensed CC BY 4.0. Nabeel Khan https://nabeelkhan.com/frameworks/pattern-language PATTERN DERIVATION STAGE 1 Force or failure production failure modes control requirements governance constraints unbounded optimizers STAGE 2 Candidate mechanism the thing a team would actually build STAGE 3 Decomposition can it be stated as a boundary the optimizer may not cross, or as what makes one enforceable? yes STAGE 4 Pattern admission enters the catalogue with an identifier, a boundary class and an evidence level no Rejected as optimization An optimizer with no boundary of its own is not a pattern. It is catalogued inside whichever pattern bounds it, so the catalogue does not grow with every new technique. Worked rejections: prompt caching · retrieval augmentation · template versioning · continuous batching · reasoning profile · rate limiting. The full table is at 3.4. The criterion is stated so that it can be examined, which is why the rejections are published alongside the admissions. Seventeen is the count that survives this filter at version 1.0. It is defended as a criterion, not as a number. A Pattern Language for Production LLM Platforms v1.1 · Nabeel Khan · nabeelkhan.com/frameworks/pattern-language · CC BY 4.0 · DOI 10.5281/zenodo.22109864
Figure 3. The derivation filter: how candidates were admitted or rejected.
§ 04Deliberately unmarked

Deliberately unmarked.

No trademark is claimed on PEVG, PARA, the Boundary Invariant, the BOE Declaration, or on any of their constituent names. A mark on a design pattern suppresses the citation the pattern needs in order to spread. Their defensibility rests on a dated, citable priority record rather than on a symbol.

The pattern relationship graph A directed graph of the seventeen patterns in three bands. Infrastructure band: IP-5 gates promotion of IP-1; IP-1 selects from IP-2 and emits IP-4; IP-3 stands apart, bounded by a declared objective. Application band: AP-5 bounds the executor of AP-1; AP-1 is composed as vertices in AP-2; AP-2 is logged as structure by AP-3; AP-3 trains the planner of AP-1, closing the only cycle in the language; AP-4 attaches to nodes of AP-2. Operations band: OP-1 is the route bounded by OP-2; OP-2 and OP-4 are mutually dependent; OP-3 runs inside OP-1; OP-2 bounds the faculties of OP-5; OP-6 supplies evidence for OP-7. Cross-layer edges: AP-5 informs OP-2, and IP-4 with AP-3 are reused as the metering path by OP-6. The economic chain runs IP-1 to IP-4 to OP-6 to OP-7 across the full height of the stack. The pattern relationship graph Nabeel Khan 2026 https://doi.org/10.5281/zenodo.22109864 https://doi.org/10.5281/zenodo.22109864 Copyright 2026 Nabeel A. Khan. Licensed CC BY 4.0. Nabeel Khan https://nabeelkhan.com/frameworks/pattern-language PATTERN RELATIONSHIP GRAPH INFRASTRUCTURE IP-5 Lifecycle security IP-1 Routing policy IP-2 Tiered pool IP-4 Observability IP-3 Latency-bounded gates selects emits bounded by a declared objective APPLICATION AP-5 Capability contract AP-1 PEVG AP-2 AOV graph AP-3 Trajectory logging AP-4 Tiered HITL bounds composed in logged by trains the planner of · THE ONLY CYCLE IN THE LANGUAGE attaches to nodes of OPERATIONS OP-1 Golden path OP-2 Bounded delivery OP-4 Benchmark gate OP-3 Test selection OP-5 PARA OP-6 Cost attribution OP-7 Budget boundary bounded by bounds evidences runs inside mutually dependent AP-5 informs OP-2 IP-4 + AP-3 metering path for OP-6 Shaded nodes carry the economic chain IP-1 → IP-4 → OP-6 → OP-7, which runs the full height of the stack and is the strongest evidence that the three layers are one control path rather than three. Dashed edges cross layers. An institution implementing a pattern shall implement its dependencies here, or record the omission as a documented gap (8.4). A Pattern Language for Production LLM Platforms v1.1 · Nabeel Khan · nabeelkhan.com/frameworks/pattern-language · CC BY 4.0 · DOI 10.5281/zenodo.22109864
Figure 4. How the patterns compose.
§ 05Figures

The rest of the picture.

Event identity propagation across the control path A single event identity is assigned at the platform boundary when a request arrives and is propagated through eight stages: request, routing, workflow, agent actions, verification, human review, deployment and cost attribution. Below the chain, three evidence artifacts attach to it: Routing Evidence at the routing stage, Execution Evidence across workflow through human review, and Delivery Evidence across deployment and cost attribution. Four rules are noted: every artifact carries the identity, asynchronous delegation carries the immediate parent identity, a retry keeps the identity and adds an attempt ordinal, and where a provider does not propagate the identity the platform records the correlation on its own side. Event identity propagation across the control path Nabeel Khan 2026 https://doi.org/10.5281/zenodo.22109864 https://doi.org/10.5281/zenodo.22109864 Copyright 2026 Nabeel A. Khan. Licensed CC BY 4.0. Nabeel Khan https://nabeelkhan.com/frameworks/pattern-language EVENT IDENTITY assigned at the platform boundary request routing workflow agent actions verification human review deployment cost attribution Routing Evidence Execution Evidence plan, tool calls, verifier corrections, review tier and reviewer Delivery Evidence authority, guardrail, spend Four rules make the join hold in practice, and each addresses a way a nominally complete evidence set fails to answer a causal question: 1. Every evidence artifact shall carry the event identity. An artifact written without it cannot join, and therefore does not satisfy 2.3.2. 2. Asynchronous delegation, including agent to agent, shall carry the identity of the immediate parent event, so a fan-out is distinguishable from a sequence. 3. A retry shall keep the identity of the attempt it repeats and be distinguished by an attempt ordinal, because retries cluster where the join is most needed. 4. Where a provider does not propagate the identity, the platform shall record the correlation on its own side. The obligation relocates; it does not lapse. Retention periods shall be consistent across the three artifacts. The shortest member sets the reconstruction horizon for the whole set. A Pattern Language for Production LLM Platforms v1.1 · Nabeel Khan · nabeelkhan.com/frameworks/pattern-language · CC BY 4.0 · DOI 10.5281/zenodo.22109864
Figure 5. Event identity, which makes three evidence artifacts joinable in fact rather than in aspiration.
§ 06Honest limits

What this does not claim.

Nothing here has been measured. The contribution is architectural rather than empirical.

§ 07Cite

Citation.

Cite this work. Version 1.1. 10.5281/zenodo.22109864. Concept DOI, always the latest version. CC BY 4.0.

§ 08Where this sits

In the practice.

§ 10Ask an assistantLive, no key

Ask your AI assistant instead.

This page is a snapshot, accurate at the release it cites. The same corpus is callable, publicly and without a key, so an assistant can query it live and return an answer carrying the source it came from. For this page that is explain_this_setup and search_knowledge, which do what this page describes rather than describe it again: the first returns how this site's machine layer is actually built, component by component, and the second queries the corpus behind this page and returns matches with the URL each came from. The page states the practice; the tools are the practice.

01 · Connect
claude mcp add --transport http concylium https://mcp.nabeelkhan.com/api/mcp

Claude Desktop, ChatGPT, Cursor, VS Code and Gemini CLI take the endpoint on its own: https://mcp.nabeelkhan.com/api/mcp. No key, no account, nothing to sign. Setup for every client.

02 · Ask

“Using Concylium, call explain_this_setup and tell me whether this site actually implements what its machine-accessible-ai-expertise page claims.”

A category page that survives being audited by the reader's own assistant is doing something a brochure cannot.

Fin · Machine-Accessible Expertise
Point your assistant at the endpoint →