Home / The model / The delta

The delta

The delta is derived and never authored. Nobody writes a delta. It is only ever the output of a computation over the grant and the mandate, and it is stored along with the versions of both inputs and the time it was computed.

This page corrects something this site said this morning

The foundation document says, twice, that the delta is computed and never stored. The first half is right and the second half is wrong, and the correction was issued on the same day by the project lead. It is published here rather than applied quietly, because the method is to record the gap: the dev brief that makes the correction, and the foundation document as published, which otherwise stands in full.

Was	Is
The delta. Computed. Never stored, because the deployment changes.	The delta. Derived. Recomputed whenever the grant or the mandate changes, stored with the versions of both, and never edited by hand.
The delta is computed and never stored. A stored delta is a claim about somebody's environment on a day that has passed.	The delta is derived and never authored. Nobody writes a delta. It is only ever the output of a computation over the grant and the mandate, and it is stored along with the versions of both inputs and the time it was computed. What must never happen is that somebody edits a delta, because a hand edited delta is a fiction about an environment, and nothing downstream could tell.

What the old rule was protecting, and what survives

The sentence being corrected was guarding against three real things, and all three survive.

The fear	Does the correction still handle it
A delta becomes a stale claim about somebody's environment	Yes. A stored delta carries the versions of its inputs and the time it was computed, so its staleness is a fact rather than a surprise
A delta gets hand edited into a fiction	Yes, and more strongly. Never authored is a harder rule than never stored, because it forbids the act rather than the artefact
A delta is treated as authoritative after the inputs move	Yes. It reacts. A recompute is cheap because the inputs are graphs

So the correction loses nothing and gains the history. It is also the fourth instance of a pattern already in force across this network, which is why the corrected sentence is the one that fits and the old one was the odd one out: indexes are generated from the data they index, prose is derived from the graph and never hand edited, a bill of materials is generated from the dependency files, and the delta is derived from the grant and the mandate. In every case the artefact is stored. What is forbidden is writing it.

The word for this already exists

A stored result of a computation over other data, refreshed when its inputs change, never edited directly, is a materialised view. The vocabulary is decades old and it carries exactly the right properties: it exists for use, it has a refresh policy, its staleness is knowable, and writing to it directly is a category error rather than a permission question.

The grant and the mandate are the append only side: a history of what changed and when. The delta is the read model computed from them. The delta is a projection of the ABP graph, and so is the label, and so is the leaflet.

The stored record

Field	Why
`grant_version`	The input, pinned
`mandate_version`	The input, pinned
`pack_version`	The published vocabulary it was computed against
`computed_at`	When
`computed_by`	Which version of the computation, because the computation is code and code changes
`excess`	Capabilities in the grant and not in the mandate
`unbounded_excess`	Excess whose barrier is one of the first three kinds
`shortfall`	Capabilities in the mandate and not in the grant

No field in that record is writable by a person. The way to change a delta is to change a grant or a mandate. So the release gate does not take the stored records on trust: it recomputes every one of them from the profile and the mandate it names and fails on a single row of disagreement. That check is a few lines, because the computation is a set difference, and it is a set difference because the grant and the mandate are held as graphs with a schema rather than as prose. That is the underlying capability. All of this can be done by hand today and almost nobody does it.

9 stored deltas, one per deployment shape and mandate pair: /data/deltas/index.json.

Reality is the third input

The grant is a model of what the agent can do. The mandate is a statement of what somebody meant. Both are interpretations, and both improve. The customer says what they actually meant, and the mandate sharpens. Somebody discovers a capability nobody had listed, and the grant grows.

What is observed	What it tells you
Something happened that is not in the grant	The grant was incomplete. Add the capability
Something was blocked that the grant said was possible	A barrier was missed, or recorded at the wrong kind. Correct it
Something in the mandate never happens	Either the mandate is aspirational, or the capability is missing and the shortfall is real
Something happens repeatedly that is in the grant and not in the mandate	The mandate is wrong, or the deployment is. This is the only row where the observation does not say which

That last row is the one place a derived delta cannot resolve itself. An agent doing something outside its mandate, repeatedly, without anybody complaining, means either that the mandate was written too narrowly or that something is happening nobody authorised. This site publishes the observation. Which of the two it is belongs to the risk layer and to a person. Record, not verdict, again.

And the calibration loop is the answer to this site's honest weakness. 21 of 99 capability rows are measured and the rest derived from documentation. Every deployment that runs and reports back moves a row from derived to measured, and because the capability map is shared and public, it moves for everybody. That is the reason the map belongs in an open repository rather than inside a product.

And the collection problem it creates

A calibration loop needs observation, and the downloadable builds in this estate are ruled never to transmit anything. The resolution is that calibration happens inside the customer's own instance: their deployment observes, their grant improves, their delta recomputes, and none of it leaves. What comes back to the shared map is a contribution, not telemetry: a proposed correction to a capability row, carrying its evidence, submitted deliberately through the same mechanism as any other proposal, with a source, a timestamp and a hash. A person decides to send it. Nothing phones home. That is slower, and it is the only version that is honest.

It reacts, and the trigger has a standard

Because the delta is derived, a change in either input propagates without anybody touching the document. A template cannot do that and a rendered document cannot do that. Three cases:

What happens	What the ABP does
A weakness is disclosed in a tool the agent can call.	Nothing about the deployment changed, but a capability recorded at the fourth barrier is now at the first. The grant is the same and the unbounded excess jumps. The ABP changed because the world did
A credential is quietly widened.	Somebody adds a scope to a token to fix an unrelated problem. The grant grows, the mandate does not, and the excess grows by exactly the capabilities that scope carries. Nobody involved thought they were changing a policy
A control ships.	A gateway is deployed with default deny. A set of capabilities move from the second barrier to the fourth. Unbounded excess falls, and the number it falls by is what the project bought

The trigger for a recompute already has a standard, so it is a receiver rather than an invention. The continuous access evaluation profile, published on the standards track by the shared signals working group, defines event types an identity provider transmits and a receiver consumes so that access can be attenuated as things change.

Event type	What it means for the ABP
Credential Change	The grant may have moved. Recompute
Token Claims Change	The grant may have moved. Recompute
Assurance Level Change	A barrier may have moved
Device Compliance Change	A barrier may have moved
Risk Level Change	Not ours. That is the risk layer's input, not the ABP's
Session Revoked, Established, Presented	Session lifecycle, below the ABP's altitude

Nothing here is wired, and one caveat travels with the citation. The status of that specification could not be confirmed from its own page, which said standards track rather than final while sitting at a final address. It is named here because it is the right shape, and it should be checked before anybody cites it as settled.

What hooks to it, and the hazard

Behaviours can be hooked to a derived delta: actions, the granting of a licence to operate and the removal of one. That is where an ABP stops being a document. It is also hazardous in a specific way: a computation error would revoke a licence.

The delta crossing a threshold is a record. The consequence is a verdict. So this site publishes the crossing, with its inputs and its computation version, and the consequence is a policy the customer or the underwriter set in advance, never a judgement the ABP makes. That keeps the ABP consequence agnostic while the automation is real, and it means any automatic suspension is traceable to a threshold somebody chose and a computation anybody can rerun.

The history is the business case, read rather than constructed

Store the series and the business case stops being a document somebody writes. A control project has a date; the series has grants, mandates and deltas with dates; so the value of the project is a subtraction:

On 14 March the gateway was deployed. Unbounded excess fell from thirty one to six. Excess was unchanged, because the agent can still do the same things; what changed is that twenty five of them are now bounded by something it cannot reach.

That sentence contains no verdict, no score and no adjective, and both ends of it are stored records with their inputs pinned, so it is checkable.

Use of the series	How soon it pays
Justifying what was already bought	The easiest, and the one every security team needs and cannot produce today
Pricing what to buy next	The capabilities in unbounded excess, ordered by how many would move to the fourth barrier per control, is a list with an effect size on each row
Evidencing a condition over time	Asking whether a control was in place throughout a period is a question about a series, not a snapshot. A stored history answers it and a recomputed present cannot. This is the one the old wording made impossible

Three clocks, and the gap that is not ours

Clock	What it measures	Who controls it
The ABP's clock	When the grant was last measured or calibrated	Us, and it can run on events
The twin's clock	When the twin last synchronised with the real environment	The customer's integration
Reality's clock	Never stops	Nobody

So an ABP is exactly as fresh as the twin, and the twin is exactly as fresh as its connection. That is a parameter rather than a defect to hide, and it belongs on the label as part of the validity statement: as at this date, from a twin last synchronised at this date.

And the gap between the second clock and the third is a risk that the risk layer accounts for, which is the correct home for it, because how much that gap matters depends on the assets, and the ABP does not know the assets. The twin is the interface to the real environment.

Drift is a neighbouring measurement, and the difference is the mandate

The market has a word for a related phenomenon and it is drift. Products announced in September 2026 compare an agent's runtime behaviour against its authorised scope. That is validation, and it sharpens the distinction rather than blurring it.

	What it compares	When you learn
Behaviour drift	What the agent did against what it was allowed to do	After the action
Capability excess	What the agent can do against what it was authorised to do	Before any action

You can only detect drift once an agent has drifted. An ABP states that the drift is possible before it happens, which is a different thing and an earlier one in the sequence. Both want a mandate, and the mandate is the scarce input, which is the strongest reason to make eliciting it cheap and to publish the method.

No adjective is attached to any named product on this site, and none is here. Neither product was used or tested. One number from one of those announcements is worth keeping because it is somebody else's figure supporting this site's thesis: fifty seven per cent of enterprise identity is described as unseen and unmanaged. You do not know what it can do, said by somebody selling a different answer to it.

What is not settled

What the recompute policy is: on every event, on a schedule, on read, or a combination. It decides how much the receiver has to do.
Who sets the thresholds a consequence hooks to: the customer, the underwriter, or a default published here. All three have different shapes.
How a calibration contribution is submitted without revealing the deployment, since a correction to a capability row implies somebody runs that shape.
Whether the shortfall matters commercially. Capabilities in the mandate and not in the grant are a real finding and nobody has proposed anything against them.
What happens to a stored delta whose computation version is superseded: recomputed, marked, or left as the record of what was believed at the time. The third is the most honest and the least useful.

The full brief · The stored deltas · The four objects