Skip to content

A Pattern Language for Production LLM Platforms: Governed Routing, Agent Orchestration, and AI-Native Delivery

Aug 2026 · Open MIND · 8 citations · 1 references

Abstract

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, fewer tests run. 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. This specification is built on one invariant: a boundary is a clause the optimizer may not cross, and everything else is optimization. The contribution is a cross-layer architectural method for separating non-negotiable constraints from adaptive optimization and binding both to reconstructable evidence, applied identically across model routing, agent orchestration and AI-native delivery. The seventeen patterns are instances of that method rather than the contribution itself. Each pattern is specified in the classical pattern form and carries three architectural declarations: the boundary it fixes, the optimizer it frees, and the evidence proving the boundary held. Every boundary is assigned to one of five classes covering data, authority, decision, resource and process constraints. Section 3 states the derivation method by which candidates were admitted or rejected, and publishes the rejections alongside the admissions so that the criterion can be examined rather than trusted. Three mechanisms make the language operate as a language rather than a list. A pattern relationship graph names which pattern supplies the artifact, evidence or authority another depends on, including the single cycle by which a workflow improves from its own structural record and the economic chain running the full height of the stack. A normative event identity, with rules for causal parentage, retries, provider boundaries and retention, turns the requirement that evidence be joinable into something an implementation can satisfy or fail. And per-pattern applicability conditions replace categorical requirements, so that a pattern governing a mechanism an institution does not operate is out of scope rather than a gap. Conformance is self-declared and published as a profile carrying the environment, the applicable set, per-pattern status, an evidence date and documented gaps. It is not a certification scheme, and no conformity assessment body operates against it. The contribution is architectural rather than empirical. Every pattern carries an evidence level, and no pattern reaches the highest level, because no implementation unconnected to the author has been evaluated. Nothing has been measured. The specification separates what would falsify the invariant from what would falsify an individual pattern and from what would falsify the composition and adoption sequence, poses six research questions, and records the absence of a real implementation profile as a known deficiency of version 1.0. An appendix reconciles the pattern identifiers with the names used across the author's papers and companion book series, including the acronyms PEVG and PARA, so that the two bodies of work can be cited as one. Version 1.1 names two constructs the specification already contained. The central proposition is named the Boundary Invariant, and the three architectural declarations required of every pattern are together named the BOE Declaration. Neither carries a trademark, both are offered for use with attribution under this document's licence, and neither changes any requirement: the proposition, its wording and its priority date are those of version 1.0. Section 11 gains the two-family naming convention and a precedence rule fixing which document governs where this specification and the Defensible AI Framework Registry describe the same relationship.

View source

Similar papers

#computer vision Open access Jun 2016

Software Development in Startup Companies: The Greenfield Startup Model

The results are packaged in the Greenfield Startup Model (GSM), which explains the priority of startups to release the product as quickly as possible, and the need to shorten time-to-market, by speeding up the development through low-precision engineering activities.

Carmine Giardino, Nicolò Paternoster, M. Unterkalmsteiner et al. · 178 citations · ⚡14
#computer vision Open access Oct 2016

Software Startups - A Research Agenda

Software startup companies develop innovative, software-intensive products within limited timeframes and with few resources, searching for sustainable and scalable business models.

M. Unterkalmsteiner, P. Abrahamsson, Xiaofeng Wang et al. · 157 citations · ⚡17
#machine learning Review Open access Oct 2016

“Failures” to be celebrated: an analysis of major pivots of software startups

This study conducts a case survey study based on the secondary data of the major pivots happened in 49 software startups, and demonstrates that customer need pivot is the most common among all pivot types.

Sohaib Shahid Bajwa, Xiaofeng Wang, Anh Nguyen-Duc et al. · 127 citations · ⚡15
#computer vision Review Open access May 2015

A survey study on major technical barriers affecting the decision to adopt cloud services

The comparison of adopter and non-adopter sample reveals three potential adoption inhibitor, security, data privacy, and portability, which underlines the importance of the technical and security perspectives for research investigating the adoption of technology.

Nattakarn Phaphoom, Xiaofeng Wang, S. Samuel et al. · 111 citations · ⚡8
#computer vision Conference Open access Dec 2013

Affordable and Energy-Efficient Cloud Computing Clusters: The Bolzano Raspberry Pi Cloud Cluster Experiment

The ongoing work building a Raspberry Pi cluster consisting of 300 nodes is presented, with potential use cases being an inexpensive and green test bed for cloud computing research and a robust and mobile data center for operating in adverse environments.

P. Abrahamsson, S. Helmer, Nattakarn Phaphoom et al. · 110 citations · ⚡7
#computer vision Book Open access Mar 2017

On the Unhappiness of Software Developers

The results indicate that software developers are a slightly happy population, but the need for limiting the unhappiness of developers remains, and 219 factors representing causes of unhappiness while developing software are identified.

D. Graziotin, Fabian Fagerholm, Xiaofeng Wang et al. · 84 citations · ⚡6

Related blog posts

MIT News · Artificial Intelligence Sep 14, 2026

New method enables AI for safety-critical situations

The “HardFlow” algorithm could help generative AI models produce high-quality outputs that obey strict requirements when “pretty close” doesn’t cut it.

GPT-Lab Sep 10, 2026

Responsible AI Must Consider Its Afterlife

AI may appear weightless, but every model depends on physical infrastructure. To understand responsible AI, we need to look beyond algorithms and consider the entire lifecycle of the hardware behind them. The post Responsible AI Must Consider Its Afterlife appeared first on GPT-Lab.

We use cookies to run the site and, with your consent, for analytics and to show ads. See our Cookie Policy.