Series 17 closed on a claim it earned across five instruments: assurance is not a layer laid over a finished system but a property built into the agent at the architecture. Assurance as Architecture read the certificate, the audit, the standard, and the convergence, and found each one downstream of a property only the architecture could establish. The instruments mark the road; the architecture is how the distance gets closed.
That series read the problem from the assurance side — from the instruments an enterprise reaches for and the boundary each one stops at. This series reads it from the other side: not what the instruments can attest, but where the capability they are trying to govern actually comes from. The two readings arrive at the same architecture. Series 17 found that assurance has to live there. Series 18 supplies the premise that leaves it nowhere else to go — the capability does too.
The transfer failure is Luminity vocabulary for the recurring object of this series. It extends the residual logic The Certification Boundary named — conformance transfers, sufficiency does not, and the residual stays with whoever operates the agent — to the capability side of the same line. Stated once, to recur through every dispatch that follows:
The lab evaluated the model. You assembled the system. The safety case does not transfer. The residual is yours.
The shape of the failure
A frontier lab evaluates a model. It runs the dangerous-capability tests, documents the elicitation, files the safety case, and ships. That work is real, and the safety case is a true statement — about the model the lab evaluated. The enterprise does not deploy that model. It deploys the model inside a scaffold, wired to tools, retrieving over proprietary data, delegating to and from other agents, run at inference settings the lab never exercised. The object the enterprise puts in front of its customers is not the object the lab examined. It is a system the enterprise assembled, and the lab’s safety case was never written about it.
This is the transfer failure, and the word failure is doing careful work. Nothing failed in the ordinary sense. The lab’s evaluation did not fall short; it answered the question it was scoped to answer, about the artifact it was scoped to examine. The failure is one of transfer — the safety case is sound and does not extend, the way a load rating on a beam is sound and says nothing about a structure someone else assembled from the same stock. The lab made a true statement about a model. The enterprise needs a true statement about a system. The distance between those two statements is the residual, and it does not travel with the weights.
It is worth being precise that this is not a charge against the lab or against model-level governance. Evaluating the model is the rational thing to do, and the safety case is a real and valuable finding within its scope. The transfer failure is not the failure of that choice. It is the honest accounting of it — the obligation the model-level safety case leaves unmet for the system the enterprise actually runs, because that system did not exist when the evaluation was performed.
Where the capability comes from
The reason the system outruns the model has a name in the research literature. A 2026 position paper from a frontier lab’s own governance researchers — the anchor this series reads against — argues that model-level governance weakens as capability is increasingly driven by what it calls non-model gains: improvements independent of advances in the base model. It sorts them into three. Inference gain is the capability unlocked by spending more compute at the moment of use. Systems gain is the capability added by the scaffolds, tools, and multi-agent structure built around the model. Asset gain is the capability that arrives when the model is given access to restricted data or assets it never trained on. Embodiment, continual learning, and the diffusion of capability across a deployed population sit behind these as the sources the paper expects next.
Read from the policy seat, that taxonomy is an argument about where governance has to reach. Read from the enterprise architect’s seat, it is a description of an ordinary deployment. An enterprise running an agent over its own documents is manufacturing asset gain. An enterprise wrapping a model in a tool-calling scaffold is manufacturing systems gain. An enterprise turning reasoning effort up to clear a hard task is manufacturing inference gain. The gains the paper identifies as the thing that erodes model-level governance are not exotic capabilities held by a few labs. They are the standard moves of putting a model to work — which means the enterprise is not a bystander to the transfer failure. It is the party that assembles the capability the lab never saw.
The three vectors are scaffolding for this reading, not its spine. They organize where the capability comes from; the transfer failure is what that assembled capability does to the assurance the enterprise inherited. The vectors recur through the series as the furniture. The transfer failure is the room.
Why a better evaluation cannot reach it
The natural response is to ask the lab to evaluate harder — to test the scaffolded, tool-wired, asset-fed system the enterprise will actually run. That helps, and it meets a limit that is structural rather than practical. The system the enterprise assembles is configured at deployment, by the enterprise, in combinations no upstream evaluator can enumerate in advance. Evaluating the model more thoroughly does not reach a system that does not exist until the enterprise composes it.
The deeper reason sits one layer down, in how governance attaches to a system at all. A 2026 result in the corpus this series reads — McCann’s The Two Boundaries: Why Behavioral AI Governance Fails Structurally — frames it exactly. When governance is laid over a system behaviorally, after the fact, the boundary of what the system can do and the boundary of what the governance covers are drawn independently, creating “three regions: governed capabilities (the only useful region), ungoverned capabilities (risk), and governance policies that address non-existent capabilities (theater).” Two of the three regions are failure modes, and for a system that can compose arbitrary actions, deciding from the outside whether its behavior complies is, in the general case, undecidable.
The consequence for the transfer failure is direct. Capability that is assembled in the architecture — in the scaffold, the tool graph, the delegation chain, the retrieval surface — can be governed only in the architecture, because that is the single place the two boundaries can be made to coincide. A safety case written about the model is written about one region; the enterprise’s assembled system spans all three. The governance surface is not the model. It is the architecture the enterprise built — which is the same architecture Series 17 found that assurance has to be built into. Two readings, one surface.
The residual lands on the assembler
If the capability is assembled by the enterprise, and the governance has to attach where the capability lives, then the residual — the distance between what the lab evaluated and what the enterprise runs — is the enterprise’s to hold. It cannot be handed back up the supply chain, because the party upstream never assembled the system and could not have evaluated it.
The corpus reads this asymmetry from a second angle. Work on governance under capability asymmetry finds that oversight degrades as the gap between the system and its overseer widens, and that disclosure-based remedies lose their grip exactly where the capability is most assembled and least legible — and that the checks an organization relies on, which look independent under a modest gap, begin to fail together once the gap grows, because each draws on the same oversight capacity. The enterprise inherits not only capability it did not create but the obligation to govern a system whose consequential behavior it can observe only at runtime. This is the same residual The Certification Boundary located on the assurance side — conformance transfers, sufficiency stays with the operator — arriving now from the capability side. A certificate can change hands; the residual does not. A model can be licensed; the assembled system, and the obligation it carries, cannot be licensed away.
That is the inversion this series is built on. The policy literature frames non-model gains as a problem for the governance of frontier labs. From the enterprise seat, the same fact reads as an allocation: the assurance obligation follows the assembly, and the assembler is, increasingly, the enterprise.
The assurance obligation follows the assembly — and the assembler is, increasingly, the enterprise.
What this series reads
None of this argues against model-level governance. The lab’s evaluation is the floor — a true, examined statement about the model — and most of the field does not yet read even that boundary accurately. The argument is narrower and harder: the floor is a statement about the model, and the enterprise deploys a system. The work this series reads is the work of governing the distance between them — where the capability is assembled, who holds the residual, and what has to be true of the architecture for an assured agent to be the thing actually deployed.
The transfer failure is the object. The dispatches that follow read it where it does the most damage: in the evaluation that measured a model your stack has already outrun, in the machine principals exercising capability your identity systems were never designed to govern, and in the weights you inherited whose safety case decayed before they reached you. Each is the same failure, read once more, one layer further into the system the enterprise assembled.
It begins with the evaluation. If capability is assembled after the model is evaluated, the first question is the plainest one: what, exactly, did the evaluation measure?
