Inherited Capability — Luminity Digital
The Architecture of Capability  ·  Series 18  ·  Post 4 of 4  ·  June 2026
Agentic AI Governance

Inherited Capability

The enterprise inherits capability it did not create — open weights, derivatives, diffusion — and resilience is the residual control.

June 2026 Tom M. Gomez Luminity Digital 7 Min Read
Series 18 closes here — Post 4 of 4, the capstone. Dispatch 03, The Agent Identity Gap, governed the actor exercising the assembled capability. This dispatch reads the one part of the system the enterprise does not assemble — the inherited model — and closes the series on where the whole of it lands. It is the companion capstone to Series 17, Assurance as Architecture.

The Agent Identity Gap closed on the one part of the system the enterprise does not assemble. Identity reaches the actor inside the boundary; it does not reach the weights that actor runs on — weights the enterprise did not create, drawn from a release it cannot inspect. This dispatch reads that inheritance, and closes the series on where the whole of it lands.

An enterprise rarely deploys a model it trained. It inherits one: an open-weight release, a fine-tune of a fine-tune, a distillation of something larger, adapted and re-adapted along a chain that runs from a lab it has no relationship with to a deployment that lab never saw. Each step is a derivative, and each derivative is a step away from whatever safety case the original carried. Inherited capability is the capability that arrives this way — already made, already removed from its evaluation, carrying a residual that compounded at every hand-off before the enterprise received it.

The Architecture of Capability

The architecture that assembles the capability holds the assurance.

Inherited capability is Luminity vocabulary for that reading, and it is the fourth and last face of the transfer failure this series has read. The capability is assembled by the enterprise — but some of it was assembled before the enterprise ever touched it, by parties it cannot reach, in a population it cannot survey. The reading is grounded in the corpus this series reads, where a cluster of recent work follows the capability as it diffuses past the chokepoints the field’s instruments were built around.

The capability arrives already loose

The transfer failure has, until now, been about the distance between the lab’s evaluation and the enterprise’s assembly. Inheritance adds a distance the enterprise did not create and cannot audit: the one between the original release and the derivative it actually runs. A safety case, where one exists, is written about the model the lab released. By the time that model has been fine-tuned, merged, quantized, and distilled into the artifact an enterprise pulls down, the case describes an ancestor. The capability inherited the lineage; the assurance did not survive it.

This is the transfer failure read at the supply chain: you inherited weights whose safety case decayed across every derivative between the original release and your deployment. The decay is not anyone’s misconduct. It is what happens to a point-in-time evaluation when the artifact it described keeps being modified by parties under no obligation to re-run it. The enterprise holds the residual at the end of a chain it did not build, for a model whose provenance it can rarely reconstruct.

The chokepoints the instruments assumed are loosening

Model-level governance leans on a small number of physical facts: that frontier capability takes concentrated compute, that it is produced by a few developers, and that those concentration points are where capability can be seen and bounded. The corpus reads each of those facts loosening.

Advances in low-communication training let capable models be produced across distributed or community-contributed compute, which the corpus reads as eroding the detectability and shutdownability that compute-concentration governance relied on. Open-weight release moves capability into a population no developer can recall — and a reading of the open-weight question argues that the reflex to restrict can backfire: access restrictions, “without governed alternatives, may displace risks rather than reduce them,” pushing capability into settings with less oversight rather than less capability. Work on proliferation dynamics reaches the same structural point from the security side: as the technology that spreads capability outpaces the technology that detects it, detection alone stops being sufficient. The common thread is diffusion. The capability an enterprise inherits comes from a population that is getting larger, less concentrated, and less legible — not from a single governed source it can point back to.

Where governance goes when the model is loose

When capability can no longer be reliably governed at the model, governance moves to the layers that remain reachable — and, for the part that stays out of reach, to resilience. This is the centerpiece of the inheritance reading, and the corpus marks both moves.

Below the model sits infrastructure the enterprise and its providers still control. The same open-weight reading that warns against restriction-as-reflex points toward governed alternatives at the hardware and cloud layer — chip-level attestation, trusted execution, confidential computing — as a defense-in-depth that bounds what inherited weights can do at the point of execution rather than trying to control which weights exist. Above the model sits the ecosystem: institutional incentives and the mechanisms that govern how independent agents interact, including anti-collusion mechanisms adapted from human markets for multi-agent populations. And alongside both sit inherited risks that bypass the model’s own safeguards entirely — capability that discovers and exploits gaps in legal frameworks, and embodied capability that keeps honing itself from experience after it is deployed, accruing past whatever was evaluated. Each is a place governance can still attach when the model itself has diffused beyond reach.

What none of these reaches is the capability that has already escaped detection — the inherited, diffusing, self-modifying portion no layer below or beside the model fully contains. For that, the corpus reads a different kind of control. Resilience is the property of a deployment context — its vulnerability, its capacity to cope, its capacity to adapt — that determines how much harm a given capability can do when it arrives. The corpus makes it measurable: a societal-capacity framework that scores those three dimensions, a mapped portfolio of mitigations spanning governance, technical, operational, and transparency controls, and a risk-adjusted accounting that prices the residual exposure into the economics of deployment rather than leaving it unbooked. Resilience does not close the distance the way a control does. It is the honest residual control — what governs the harm of capability you could not detect, bound, or inspect.

It is worth saying plainly, in the series’ most assertive dispatch, what resilience is not. It is not a solved problem and it is not a product. Building a deployment context that is genuinely resilient to inherited capability is hard, incompletely specified, and ahead of where most organizations sit. The claim is not that resilience closes the gap. The claim is that for the inherited portion of the capability, resilience is the layer the work has to happen at — because it is the only layer still standing when the model has diffused past the rest.

What the series has read

Set the four dispatches side by side and they are one failure, read four times. The lab evaluated a model; the enterprise assembled a system, and the safety case did not transfer — the transfer failure. The evaluation measured that model at a fixed elicitation; the enterprise’s stack drew out capability the measurement never surfaced — the elicitation gap. The capability was exercised by a machine principal the enterprise’s identity systems were not built to govern — the agent identity gap. And the model itself was inherited, its assurance decayed across a chain of derivatives the enterprise did not make — inherited capability. Four readings, one residual, and in every reading the residual lands in the same place — with the enterprise that did the assembling.

It also closes in the same place. The transfer failure resolves, where it resolves at all, in the architecture: capability assembled in the scaffold and tool graph is governed in the scaffold and tool graph; authority that propagates at runtime is bounded at runtime; inherited weights are contained at the execution layer they run on and the context they run in. Each dispatch arrived at the architecture the enterprise built, because that is where the capability is — assembled, elicited, delegated, and inherited.

This is the premise Series 17 was missing. The Assurance Imperative read five instruments and found each one downstream of a property only the architecture could establish; it concluded that assurance has to be built into the agent, that the instruments mark the road and the architecture is how the distance gets closed. This series has read why the distance is there and why it cannot be closed anywhere else: the capability lives in the architecture too. The model marks the starting line. The architecture is where capability gets assembled — which leaves assurance nowhere else to live.

The Hard Claim

A model can be licensed; the assembled system, and the obligation it carries, cannot be licensed away.

Capability Is Assembled in the Architecture. So Is Assurance.

If you are reading where capability is assembled, elicited, delegated, and inherited — and asking where your organization sits relative to the obligation to assure it — the calendar is open.

Start the conversation
The Architecture of Capability  ·  Series 18  ·  4 Posts
Post 01  ·  Published The Transfer Failure
Post 02  ·  Published The Elicitation Gap
Post 03  ·  Published The Agent Identity Gap
Post 04  ·  Now Reading Inherited Capability
References & Sources
Series 17 — The Assurance Imperative

Evidence base: Series 18 rapid scoping review, corpus v1.1 — 46 papers, window July 2025–June 2026 (see series appendix).

Share this:

Like this:

Like Loading…