For architects and engineers

Build: the three joins, on the stack you already run

Existing products cover much of the control plane, and much of it already runs in the firm. What a firm has to show is that its business mandate, the basis an act relies on, the execution, and the evidence are connected, and three joins, built on the stack it already runs, connect them: a versioned mandate the check can query, a record keyed to the mandate version and the release, and a return path from the record to the mandate. With the engine that commits each act once, which is written as well, they let the control plane refuse an act before it runs. For each part there is a contract, the invariant it keeps, and a test that breaks it: the properties a firm’s own binding has to demonstrate on its stack.

The reference model sets what a firm must be able to show at each level of autonomy. An architect and an engineer build to it with the contracts that follow, on whatever stack you run.

1The control plane as softwareAgent, check, engine, and system of record, with the joins beside them
2The two rules, as invariantsWhat refuses when each one is broken
3One contract per essentialThe call, its key, the invariant, and the test
4The three joinsThe mandate, the record keyed to it, and the return path
5The record line as a schemaSettlement 4471 as JSON, the version keys, and the replay
6The permit, from proposal to receiptFrom declaration to reconciliation, with a revocation in flight and a timeout
7The stacksWhat each stack provides, essential by essential
8The kill pathOne revocation on every platform, and the quarterly test
9The referenceThe contracts running, with what they prove and what they do not
10From hereThe path from the workshop, and every box of the map

1The control plane as software

Built · the mandate, the record, the loop, and the lines between them, which are the joins, and the engine
Part built · the check: the decision point is bought, and the assembly around it is written
Bought or in place · everything in a thin line
The colour of a thin edge is the box’s row on the map: enterprise, workflow, or platform.

The act runs on one line. The agent declares the act, one operation with an effect outside the agent, and its basis: the claims it relies on, each with its version. A plan of many tool calls is as many acts as it has such operations, each declared and checked; a sub-agent acts under a sub-mandate of its own, never wider than its parent’s, with its parent’s entitlements and never more; and what an agent remembers from earlier runs enters a basis only once it is resolved to the owner’s record. The check reads its six inputs and permits the act, blocks it, or refers it to a named person. A permit is the authorisation for that one act; it is bound to the mandate version, the release, the basis, and the exact act, and it expires. The engine, which holds the only credential, re-reads the permit against what is in force at that second and commits the act once into the system of record, under one operation id, and the system of record checks what the permit is bound to again when it books. An agent’s act has no other route: the system of record’s own permissions refuse every agent identity and take an agent’s act only from the engine, and the test is under the check. Handlers, batch runs, reconciliation, and break-glass keep their own routes under their own controls, and the binding names each one.

Beside the line are the mandate, which the check reads as at the second of the act; the record, to which the check appends its decision before the act runs and the engine appends the receipt, what the receiving system returned, after it, each a line of its own, linked by the act’s operation id, and none written over; and the register, which lists every agent, release, mandate, source, and rule with its version, and decides nothing. As-at, on every call here, means what the firm’s systems knew at that second. The time a fact applies to, the date of the loss in a settlement, is a field of the act read beside it: resolve() returns the wording in force on the date of the loss, as the firm knew it at the second of the act. What was true then and was learned later is analysis, and never evidence of the decision.

The loop goes back from the record to the mandate. A rule with an owner narrows the mandate as soon as its condition is met, and a widening needs evidence at the level it asks for and the owner’s signature: a signature over the digest of the new version, made with a key the owner controls and the firm’s identity provider vouches for, and written to the record with the version it creates. A sign-in alone binds nothing to the version signed. The agent’s identity can never sign, and a deputy signs only inside the owner’s recorded absence.

The three joins are drawn in orange: the mandate, the record, the loop, and the lines between them. No product we reviewed in September 2026 ships them whole, so we expect a firm to write them as small services on the stack it already runs. The engine is in orange too, and the check is dashed: a policy engine or a decision service is bought as the check’s decision point, while the assembly of its inputs, the permit, the reservation against the limit, and the write to the record before it answers are written, as the engine is. In the vendor documentation we reviewed, no gateway or policy engine holds a permit until the run, sums the permits in flight, or reconciles an unknown outcome. All of this is read from documents, a prediction to test on each stack, and the contracts below are the test: run a join’s tests against the managed capability, and what passes is bought, while what fails is what the firm writes. The reference has run them on the open-source baseline only. Everything in a thin line we expect to be bought or already in place, and the same tests settle that too.

2The two rules, as invariants

Standing, in both rules, is what the check reads about each claim of a basis, on two axes: how far the evidence supports relying on it, and who asserted it under what mandate. It belongs to the claim in the firm’s knowledge, and it is neither the agent’s confidence in its own output nor standing in the regulatory sense.

Autonomy may not rise above evidence. Each level of autonomy needs a level of evidence. Both ladders are defined by what can be observed, so that an assessor who did not run the agent can say which level it is at.

A.0: A tool that recommends. It sits outside the ladder.
A.1: One task is automated, and a person does the rest.
A.2: The agent does part of the work on its own, with a person ready to take control.
A.3: The agent does most tasks alone, and a person decides the critical ones, where “critical” is a written rule.
A.4: The agent does all tasks in stated circumstances.
A.5: No oversight. No evidence condition allows it.

K0: Acts appear in application logs, and none is attributed to an agent identity.
K1: Every act is recorded, append-only, with the agent’s own identity, the principal, the time, the mandate version, and the check’s decision; the agent has a named owner in the register, and its outcomes are measured against a test set owned outside the team that built it.
K2: Someone who did not run the agent rebuilds a period of its acts from the record alone, in a set time, and reports what could not be recovered; every decision carries a reason code.
K3: Every act is classed into a consequence tier, carries the standing of its basis and a named authority in scope, and is bound to a signed manifest; the check refuses below the tier’s bar with no person in the path.

In the Hub’s proposal, under review for the reference model, A.1 and A.2 need K1, A.3 needs K2, and A.4 needs K3. It is a discipline proposed for firms to adopt, and not yet shown to predict acceptable risk: a rebuild shows what was decided and on what basis, and not that the decision was right. An act that cannot be undone needs one level more. The return path can correct the next act, and never this one. There is no level above K3, so an agent at A.4 takes an act that cannot be undone only under a signed override. A widening of the mandate needs evidence at the level it asks for and the owner’s signature, and an override needs an executive’s signature, a scope, a date, and an expiry. The register holds, for each agent, the level it is operated at, the evidence it can show, and every unmet condition with its owner, an assessor who did not run the agent, and whether it blocks: a condition that no override can cover, such as a shared identity or a release without validation, blocks the level outright. So it refuses a level of autonomy without the evidence that licenses it, or a signed override in its place.

a_level_above_its_evidence_is_refused
  claims-agent-01 at A.3 on K2 evidence
  set to A.4, with no K3 evidence and no
  override → refused; the row stays at A.3

Standing scales with consequence. A claim, in this rule and on these pages, is the smallest statement the agent relies on, with one condition under which it holds: the excess on policy 88-1201 is €250. In the motor-insurance examples the insurance claim is called by its settlement, settlement 4471, so the word keeps one meaning. Every act is classed into a consequence tier, by a taxonomy that has its own version, and the tier sets the bar the basis must clear on both axes: evidential warrant, how far the evidence supports each claim, and authority, who asserted the claim under what mandate. The claims an act of each type needs are set by the rule set, outside the agent, and the check reads each of them, with its version and its standing at the second of the act, whether the agent declared it or not: a required claim the agent left out refers the act. The standing of the whole basis is the standing of the weakest claim the act needs. Below the bar the check refuses: it blocks the act or refers it to a person with the authority to decide, and records the refusal before anything runs.

the_weakest_claim_sets_the_bar
  settlement 4476 declares wording v13;
  the policy record says v14 applies
  → refer, BASIS-01, recorded before
    anything runs

missing_required_basis_is_referred
  a settle on case 4476 declares the
  estimate alone; RS-MC-05 r14 requires
  the excess clause for every settle
  → refer, BASIS-MISSING, recorded
    before anything runs

The harder half. The check reads the standing of each claim at the second of the act, and the set fixes that condition. Producing standing a firm can trust is the harder problem: who verifies an extracted clause, how a missing premise is found, what happens when two authorised sources disagree, and how a derived claim inherits the uncertainty of what it rests on. That is a research question, answered by implementation, at as many clients and on as many estates as the Hub can work with, and not by one reference: the research agenda.

3One contract per essential

Each essential, and the register beside them, has one contract: the call it answers, what the call is keyed on, the invariant, and one test that breaks the invariant, written as given and expected on the motor-insurance case of the use cases, whose identifiers and figures are invented. Independence from any platform is a property of these contracts. Then each stack you run is a binding to them, its own services wired to answer the calls and pass the tests, and a product that ships one natively becomes a binding too. The calls, their keys, the invariants, and the tests are what to build to, and they change only with a new version of this page that lists the change. The thresholds of the two ladders, the evidence conditions of K1 to K3 and the levels each licenses, are the Hub’s proposal under review in the reference model, and a binding reads them from configuration.

1The agent itselfwhoami() 2Its knowledgeresolve(question, case, as_at) 3Its mandatemandate(agent, as_at) 4The checkdecide(act, as_at) 5The recordappend(event) · query(…) 6The looprule(stream) · review() RThe registerlist(kind, as_at)

The agent itself

Is it fit to run?

w1 · p1

The contract.

whoami() → agent, principal, release
release.manifest
  models by version and hash · routing
  instructions · tools and their scopes
  sources and their index builds
  policies · identity
  surface: model · vendor · region
           · data-handling terms
keyed on: agent id · release version

The invariant. The agent holds no credential for a system that moves money.

The test that breaks it.

agent_holds_no_payment_credential
  claims-agent-01 calls the payment service
  with its own token → refused

A change of model, vendor, region, or data-handling terms is a change of release: model risk validates it with the rest of the release before the agent runs on it, and the record line shows, for every act, which model, vendor, and region processed it. A failover is not a change: the release names its regions, the primary and the one it fails over to, and the line records which one served the act.

Its knowledge

Does what it relies on apply, and is it current?

w2 · p2

The contract.

resolve(question, case, as_at)
  → source, version, owner
keyed on: source · version · as-at

The invariant. Every source has an owner and answers as-at.

The test that breaks it.

resolve_reads_the_owner_not_the_index
  the index rebuilt on 10.09 serves v13 text
  resolve("excess", case 4476,
          2026-09-11T08:31)
  → wording v14 §4.2 · the policy data team

Its mandate

Is it allowed to decide?

The contract.

mandate(agent, as_at)
  → version, level, limits,
    conditions, owner
keyed on: mandate id · version

The invariant. A rule may narrow the mandate; only the owner’s signature widens it.

The test that breaks it.

a_rule_cannot_widen
  R-02 writes level decide over MC-05.3
  (recommend) → refused

The check

May this exact act go ahead, now?

w4 · p4

The contract.

decide(act, as_at)
  → permit | block | refer, reasons
reads: identity · release · basis
       mandate · the exact act
       current state, with permits in flight
keyed on: act id · payload hash · as-at

The invariant. Nothing consequential runs before its decision is recorded.

The engine is where the decision is enforced. It holds the only credential the system of record accepts, re-reads the permit at the second of the act, and executes each operation id once. Of the tests below, commit_without_recorded_decision_is_refused and engine_killed_between_payment_and_receipt are its own, and bypass_attempt_is_refused and revocation_between_reread_and_commit are the binding’s, at the system of record.

The tests that break it.

commit_without_recorded_decision_is_refused
  the engine receives an act with no
  decision line in the record → refuses

bypass_attempt_is_refused
  a call to the payment service from the
  agent’s network, under an agent
  identity → refused by the payment
  service itself, with the gateway out
  of the path

engine_killed_between_payment_and_receipt
  the payment service accepts P-4471 and
  the engine dies before the receipt is
  written → on restart the outcome is
  unknown, reconciled with the payment
  ledger by C4471-S1 before any retry;
  the ledger shows one payment

concurrent_permits_cannot_overbook
  €1,496,000 committed against the
  €1.5m daily limit; two €3,000 acts
  declared in the same second → one
  permit, and the other refers: the check
  reads the state, decides, and reserves
  the amount as one step

acts_split_on_one_case_count_together
  settlement 4483, €9,000, declared as
  two acts of €4,500 under the €5,000
  limit per settlement → the first is
  permitted; the second refers, LIMIT-CASE

revocation_between_reread_and_commit
  PR-4471-1 re-read at 10:00:41 under
  MC-05.2; the mandate narrows before the
  booking → the payment service checks
  the mandate version, the agent, and the
  release the permit is bound to, and
  refuses; a booking made before the
  narrowing stands

Inside the three outcomes, the check computes finer ones and writes each as a reason code on the record line: a pass with caveat is a permit with the uncertainty logged, an evidence request or an escalation is a referral, and a partial pass splits into one decision for each act. Among the codes are OK; BASIS-01, a declared version that is not the one that applies; BASIS-MISSING, a claim the rule set requires that the agent did not declare; and LIMIT-CASE, acts on one case that together pass the case’s limit.

The record

What happened, under which authority?

The contract.

append(event)
query(agent, release, mandate,
      case, from, to)
keyed on: mandate version · release version

The invariant. The record is append-only, and the agent’s identity cannot write to it.

The tests that break it.

update_in_place_is_refused
  a write over the record line of
  settlement 4471 → refused; a correction
  is a new entry, linked to it

record_unavailable_blocks_the_act
  the record does not answer at 10:00
  → decide() cannot write its decision,
  so no permit is issued; the act waits
  or is referred, and never runs
  unrecorded

record_unavailable_after_permit_issue
  PR-4471-1 issued, then the record stops
  answering before the 10:00 run → the
  engine refuses before it pays, and the
  act waits for the record

The loop

Should its authority narrow or widen?

The contract.

rule(stream) → narrow(mandate)
review() → widen(signed)
keyed on: rule id · review id

The invariant. Narrowing is automatic, by a rule with a named owner; every widening is signed.

The test that breaks it.

rule_without_an_owner_is_not_armed
  R-02 deployed with no owner on record
  → the loop does not arm it

The register

What runs, in which version?

beside the essentials

The contract.

list(kind, as_at)
  → objects, owners, versions
keyed on: object id · version

The invariant. The register records configuration and decides nothing.

The test that breaks it.

a_register_row_grants_nothing
  claims-agent-02 listed at release v1.0,
  no mandate in force → decide() blocks
  its first act

An agent with no row at all, the shadow AI a firm worries about, is refused at the check, and the find goes to the executive sponsor for AI.

4The three joins

1A versioned mandate the check can querymandate(agent, as_at) 2A record keyed to the mandate version and the releaseappend · query · verify · rebuild 3A return path from the record to the mandaterule(stream) · review() · widen(signed)

A versioned mandate the check can query

Who granted this authority, and how far does it go?

w3 · built

Ask a firm what one of its agents was permitted to do at 10:02 on 17 September, who owns that answer, and which version was in force. Today the answer is spread across a role assignment, a policy file, an access review, and a system prompt, and nobody owns the whole.

The mandate gathers it into one object with an owner, a version, and an expiry, and the check reads it as at the second of the act.

The gap to test. Policy engines evaluate rules over data. The mandate is the data: who granted what to which agent, up to what amount, under which conditions, until when, and who may change it. OPA and Cedar read it. In the vendor documentation of the September 2026 review, none of them owns it, versions it, or signs its widening, so we expect the mandate to be a small service the firm writes on every stack. That is mapped from documents and not yet tested on a managed stack.

The object. Mandate MC-05, version 05.2, from the motor case:

{
  "mandate_id": "MC-05",
  "version": "05.2",
  "in_force_from": "2026-06-15",
  "owner": "Head of Motor Claims",
  "deputy": "Head of Claims Operations",
  "challenger": "Chief Risk Officer",
  "agent": "claims-agent-01",
  "acting_for": "Motor Claims",
  "action": "decide routine motor settlements within the limits; request execution through the payment service",
  "level": "decide",
  "limits": { "per_settlement_eur": 5000, "per_day_eur": 1500000 },
  "conditions": {
    "checked_by": "RS-MC-05 r14",
    "rules": ["wording_applies", "estimate_verified", "no_prior_payment"]
  },
  "review_triggers": [
    { "rule": "R-02", "when": "three referrals for one reason in seven days", "effect": "narrow to recommend" },
    { "rule": "R-SD", "when": "a referral finds a settlement paid on the wrong wording", "effect": "narrow at once" }
  ],
  "restore": "20 clean proposals from a test chosen for the cause, approved by model risk and run by a team that did not build the agent, on the owner's signature; after a serious defect the CRO signs as well",
  "expiry": "2026-12-31 or the next release of the agent, whichever first",
  "signature": { "by": "Head of Motor Claims", "on": "2026-06-15", "sig": "…" }
}

Every figure is invented. Each condition is a rule of the rule set, by its id, which the check runs; the words for each are in the rule set beside its code.

The contract.

mandate(agent, as_at) → version, level, limits,
    conditions, owner
narrow(mandate_id, rule_id, reason) → new version
  # automatic, by a rule with a named owner
widen(mandate_id, proposal, signature) → new version
  # refused without the owner's signature
history(mandate_id) → every version, with who
    moved it and why
keyed on: mandate id · version

The invariant. A rule may narrow it; only the owner’s signature widens it.

The tests that break it.

as_at_returns_the_version_in_force
  mandate("claims-agent-01",
          2026-09-16T15:39) → 05.2;
  at 15:41 → 05.3 (recommend)

a_rule_can_narrow_without_a_person
  third referral for BASIS-01 inside seven
  days → version 05.3, level recommend,
  R-02 recorded as mover

widening_without_the_owner_signature_is_refused
  widen(MC-05, level=decide,
        signature=none) → refused;
  signature by the deputy outside the
  owner’s absence → refused

a_challenge_holds_a_widening
  widen signed by the owner; challenge
  open from the CRO → version in force
  stays 05.3 until the challenge closes

the_check_reads_the_mandate_not_a_cache
  mandate narrowed at 15:40; a permit
  issued at 15:38 → void at 16:00

What the firm writes. A versioned document store with signed writes, four operations, and a read keyed on agent and as-at. In the reference the mandate service is 187 lines of Python, with no role model, identity provider, or production store behind it: a measure of the contract, and not a delivery estimate. The governance around it is the work: who the owner is, who the challenger is, what a rule may do without a person, and when the mandate expires and is reviewed again.

On Microsoft, AWS, open source, and ServiceNow. Added on every stack. The binding is where the object lives and who may sign it: a store with an audit trail the firm already trusts, the enterprise identity provider for the key behind the signature, the policy engine as the reader. The ceilings at e3 above it are a table the board sets, and the entitlements at p3 beneath it are bought; the mandate between them is written.

Run against the managed capability on a stack, this join’s tests settle the binding: what passes is bought, and what fails is what the firm writes.

Who owns it at the client. The business owner of the workflow; the CRO challenges. The platform team runs the service and may not write to it.

All three joins meet at the mandate: join 2 keys every line of the record to the version this join issues, and join 3 is how that version narrows and widens.

A record keyed to the mandate version and the release

What happened, under which authority?

w5 · built

Which acts of an agent last month ran under a mandate version that has since been narrowed, and on which release? Today the answer takes weeks, assembled from traces that show the calls, a case system that shows the outcomes, and a mandate, where one exists, that nobody versioned.

The record holds an act as several lines linked by its operation id: the check’s decision before the act, the engine’s receipt after it, and a void or an unknown outcome when one happens. Each is appended, none is written over, and each is keyed to the mandate version and the release. So with those two keys an act can be queried by the authority it ran under, and rebuilt as at its second by someone who did not run the agent.

The gap to test. Tracing and observability products record what was called, with timings, tokens, and errors, and the closest of them link a trace to a runtime version. In the vendor documentation of the September 2026 review, none keys a record to the mandate version; the nearest, one governance platform, records the active policy version, in research preview. And the reason is join 1: a mandate version exists only once the firm writes the mandate.

The object. The lines of section 5: settlement 4471, keyed on MC-05.2 and release v2.4, with the chain that links each line to the one before it and to the head of the event log.

The contract.

append(event) → line id
  # by the control plane’s own services only
query(agent, release, mandate,
      case, from, to) → lines
verify(from, to) → intact | first broken entry
rebuild(day) → decisions recomputed,
    differences, what could not be recovered
keyed on: mandate version · release version

The invariant. The record is append-only, and the agent’s identity cannot write to it.

The tests that break it.

write_by_agent_identity_is_refused
  claims-agent-01 calls append() with its
  own token → refused; only the control
  plane’s own services write to it

a_corrected_fact_is_a_new_linked_entry
  on 17.09 review MR-117 adds the cause of
  the referral of case 4476 → a new entry,
  linked to the line of 11.09; that line is
  unchanged, and a query as at 11.09
  returns it without the cause

chain_breaks_where_the_log_was_altered
  the event of 10.09 that recorded the
  index rebuild is edited after the fact
  → verify() fails at that event and lists
  the lines that point past it

Two tests elsewhere on this page break it as well: rebuild_of_a_day_matches_field_for_field, in section 5, and engine_killed_between_payment_and_receipt, under the check in section 3.

What the firm writes. The writer at the check and at the engine, with the hash chain; the query by the two keys; verify; and the rebuild, which recomputes every decision of a day from the record alone. In the reference the record is 129 lines of Python and its rebuild 87, on one file and no production store: a measure of the contract, and not a delivery estimate. The storage beneath it is bought, and the work is deciding what a line must hold, for how long, and who may read it.

On Microsoft, AWS, open source, and ServiceNow. Added on every stack. The traces beside the record are bought: Azure Monitor and Foundry tracing, AgentCore Observability and CloudWatch, OpenTelemetry into Langfuse or Phoenix, AI Control Tower and the platform audit. The check and the engine write to a transactional store the firm already runs, which acknowledges each line before the act goes on, with insert-only grants; the lines are copied from it to write-once object storage, which each cloud sells, and that copy is the archive. The record is on the path of every payment run, so it has an on-call team and a recovery time set with the payment service’s, and while it does not answer no permit is issued and the acts wait or are referred. Each trace is tagged with the act id of its line.

Run against the managed capability on a stack, this join’s tests settle the binding: what passes is bought, and what fails is what the firm writes.

Who owns it at the client. The business owner, under the firm’s records policy. The platform team runs the store with no write path to it outside the control plane’s own services, and the agent’s team has none at all.

It meets the other two at the mandate: each line holds the version join 1 issued, and join 3 reads the lines to decide whether that version changes.

A return path from the record to the mandate

Should its authority narrow or widen?

w6 · built

After an agent’s third referral for the same reason in one week, what changed in its authority, who decided it, and on what evidence was it given back? Today the referrals sit in a review queue, the decision in a mail thread, and the mandate, where there is one, is left as it was.

The return path reads the record as it is written. It narrows the mandate when a rule’s condition is met, with no person in the path, and it widens the mandate only on a review that brings evidence at the level asked for and the owner’s signature, which the second line can challenge.

The gap to test. Evaluation and monitoring products measure an agent in production and raise alerts, and the return path is what happens after the alert. But in the vendor documentation of the September 2026 review none writes back to a mandate, since none holds one, and none tells a rule that may narrow without a person from a widening that needs a signature and can be challenged.

The object. The rule and the review that changed MC-05 in September, from the motor case:

{
  "rule": {
    "rule_id": "R-02",
    "owner": "Head of Motor Claims",
    "mandate": "MC-05",
    "reads": "REFER lines of claims-agent-01 in the record",
    "when": "three referrals for one reason in seven days",
    "effect": "narrow to recommend",
    "fired": {
      "at": "2026-09-16T15:40+02:00",
      "on": ["case 4476", "case 4482", "case 4490"],
      "reason_code": "BASIS-01",
      "new_version": "05.3"
    }
  },
  "review": {
    "review_id": "MR-117",
    "opened": "2026-09-17",
    "cause": "source data: an index rebuilt on 10.09 restored v13 text for policies renewed in August",
    "fixed_at_source_by": "the policy data team, 12 correct lookups verified",
    "evidence": {
      "test": "20 clean proposals from a test chosen for the cause",
      "run_by": "model risk",
      "result": "20 of 20 clean"
    },
    "widening": { "from": "05.3", "to": "05.4", "level": "decide" },
    "challenger": "Chief Risk Officer",
    "signature": { "by": "Head of Motor Claims", "on": "2026-09-21", "sig": "…" },
    "re_armed": ["R-02"]
  }
}

Every figure is invented.

The contract.

rule(stream) → narrow(mandate)
  # automatic; the rule has an owner
review(mandate, evidence) → proposal
widen(mandate_id, proposal, signature)
  → new version   # join 1’s call
challenge(proposal, by) → held while open
override(kind, scope, by, until)
  → a signed exception, recorded
keyed on: rule id · review id

The override. When the check would refuse and the firm must act anyway, the path is an override: signed by a person other than the agent, scoped to the classes of act written into it, dated, expiring, and reported to the body that can refuse. No override reaches a ceiling, the law, a confirmed sanctions match, a release without validation, or a shared identity.

Emergency: Signed by the accountable owner, never by the agent, for one class of act on a basis below the bar. It ends by itself at its expiry, a review of the acts follows, and a second one for the same class goes up a level.
Scope: Signed by the owner of the domain, so that sources from outside the usual scope may count. The standing of each claim stays as it was, and the scope returns to its default at the expiry.
Standing: Signed by the claim’s steward and an evidence authority together, raising a claim’s standing on evidence the computation has not yet read. The override is itself a claim, with its source, and it lasts until standing is next computed.
Breaker: Signed by the risk or compliance authority, with one person accepting the liability by name, for a single high-consequence act the check would block. It ends with that act and is never delegated to an automated process.

Every override expires, none is signed by the actor it frees, and the rate of overrides is watched: a rising rate means a bar set in the wrong place, or governance wearing thin.

In operation. A narrowing pages the mandate’s owner and the workflow’s on-call team at once, and the acts it sends back reach people the same hour. A challenge names a deputy and an expiry, and one still open at its expiry goes to the risk committee to close, so an unanswered challenge never becomes a narrowing for good. An override has its expiry from the moment it is signed, and the review of the acts under it has a date as well. The test that restores a mandate is approved by model risk and run by a team that did not build the agent, model risk itself or another, so restoring tests do not queue behind one team. And an edit that makes a rule fire less often, a higher threshold or a narrower condition, is a widening: it waits for the owner’s signature, and the CRO can challenge it.

The invariant. Narrowing is automatic, by a rule with a named owner; every widening is signed.

The tests that break it.

third_referral_narrows_without_a_person
  REFER BASIS-01 on 11.09 and on 13.09
  → MC-05 unchanged; the third, case 4490
  on 16.09 → narrow(MC-05, R-02) at
  15:40, called by the loop, with no
  person in the path

the_agents_own_traces_are_not_evidence
  a review to widen MC-05.3 offers only
  claims-agent-01’s own traces → refused;
  the evidence comes from a test owned
  outside the team that built the agent

irreversible_act_needs_one_level_more
  a widening to decide payments that can
  no longer be recalled, on K2 evidence
  → refused; it needs K3, or an override

override_lapses_at_its_expiry
  an emergency override for storm-day
  settlements, signed by the owner, until
  18:00 → the act at 18:01 is checked
  against MC-05.3, and the review of the
  acts under it is open

a_rule_edit_that_fires_less_is_a_widening
  R-02 edited to fire on five referrals
  in seven days, where it fired on three
  → not armed until the owner signs it
  as a widening of MC-05, with the CRO’s
  challenge open; R-02 fires on three
  until then

Two tests under join 1 break it as well: widening_without_the_owner_signature_is_refused and a_challenge_holds_a_widening.

What the firm writes. The rule runner over the record stream, the review with its evidence and signature, the hold while a challenge is open, and the register of overrides. In the reference the loop is 134 lines of Python, with one rule file per mandate: a measure of the contract, and not a delivery estimate. The work is in the rules: writing them, giving each an owner, and choosing, for each cause, the test that restores the mandate.

On Microsoft, AWS, open source, and ServiceNow. Added on every stack. The signals are bought: Foundry evaluations and Azure Monitor alerts, AgentCore Evaluations, evaluations in Langfuse or Phoenix, the runtime agent evaluations of AI Control Tower. The rule runner reads the record of join 2 and calls narrow on join 1, and the key behind the review’s signature comes from the enterprise identity provider, as join 1’s does.

Run against the managed capability on a stack, this join’s tests settle the binding: what passes is bought, and what fails is what the firm writes.

Who owns it at the client. The business owner, with risk. The owner holds the rules and signs every widening, each rule has an owner of its own, the CRO challenges, and model risk approves the test that restores the mandate, which a team that did not build the agent runs.

It meets the other two at the mandate: it reads the record of join 2 and writes only to join 1, narrowing on a rule and widening on a signature.

5The record line as a schema

In the record line of settlement 4471, the keys are the site’s field names in the site’s order, grouped as the case page groups them: before the act, what the check read; at the act, what the check decided; after the act, what came back. The values are the case page’s, figure for figure. Two keys are versions, the mandate version and the release, and with them the line can be rebuilt as at its second. The fields the site did not have and an engineer needs come from The Knowledge Layer Manifest Specification. In the record the act is several lines linked by C4471-S1, the check’s decision at 08:14:06 and the engine’s receipt at 10:00:41, and the JSON below is what a query by that id returns, as one object. The schema of one line is published beside this page as record_line.schema.json, held to every line of September by the reference’s tests, and scripts/replay_motor_claim.py --jsonl in the reference writes the complete example, every line of the motor case.

{
  "before_the_act": {
    "when": {
      "decided": "2026-09-11T08:14:06+02:00",
      "committed": "2026-09-11T10:00:41+02:00",
      "committed_in": "the 10:00 payment run",
      "clock_source": {
        "clock": "time service TS-1",
        "protocol": "NTP",
        "stratum": 2,
        "offset_ms": 0.8,
        "last_sync": "2026-09-11T08:14:00+02:00"
      }
    },
    "agent_and_identity": {
      "agent": "claims-agent-01",
      "acting_for": "Motor Claims",
      "identity": "its own",
      "token_issued": "2026-09-11T08:12:50+02:00",
      "token_valid_for": "PT15M"
    },
    "release": {
      "id": "v2.4",
      "models": [
        {
          "tier": "tier-1",
          "version": "2026.06.1",
          "hash": "7c41e0",
          "vendor": "V-1",
          "region": "EU-1",
          "data_handling_terms": {
            "retention": "zero data retention",
            "residency": "EU",
            "training_use": "excluded"
          }
        },
        {
          "tier": "tier-2",
          "version": "2026.05.2",
          "hash": "e9a3b7",
          "vendor": "V-2",
          "region": "EU-1",
          "data_handling_terms": {
            "retention": "zero data retention",
            "residency": "EU",
            "training_use": "excluded"
          }
        }
      ],
      "prompt_set": "claims-settle 2.4",
      "validated": {
        "by": "model risk",
        "report": "MRV-031",
        "on": "2026-09-01"
      }
    },
    "basis": [
      {
        "claim": "The excess on policy 88-1201 is €250",
        "source": "wording",
        "version": "v14 §4.2",
        "valid_from": "2026-08-12",
        "standing": {
          "evidential_warrant": [
            "validated", "current", "uncontradicted"
          ],
          "authority": {
            "source": "the signed wording",
            "owner": "the policy data team"
          }
        }
      },
      {
        "claim": "Policy 88-1201 covers accidental damage",
        "source": "wording",
        "version": "v14 §2.1",
        "valid_from": "2026-08-12",
        "standing": {
          "evidential_warrant": [
            "validated", "current", "uncontradicted"
          ],
          "authority": {
            "source": "the signed wording",
            "owner": "the policy data team"
          }
        }
      },
      {
        "claim": "The repair estimate for settlement 4471 is €3,650",
        "source": "the case file",
        "recorded": "2026-09-11T08:13+02:00",
        "standing": {
          "evidential_warrant": [
            "validated against the repairer network"
          ],
          "authority": {
            "owner": "claims operations"
          }
        }
      }
    ],
    "mandate_version": {
      "id": "MC-05.2",
      "since": "2026-06-15",
      "level": "decide",
      "limit_per_settlement_eur": 5000,
      "limit_per_day_eur": 1500000,
      "limit_per_day_scope": "the deployment"
    },
    "control_standard": {
      "id": "CS-3",
      "version": "v2026.2",
      "rule_set": "RS-MC-05 r14"
    },
    "consequence_tier": {
      "tier": "routine",
      "taxonomy": "CT-2026.1",
      "classified_on": [
        "to €5,000",
        "one policyholder",
        "recoverable inside the recall window",
        "inside the firm"
      ]
    }
  },
  "at_the_act": {
    "check_decision": {
      "outcome": "PERMIT",
      "inputs_held": 6,
      "inputs_read": 6,
      "reason_code": "OK"
    },
    "exact_act": {
      "act": "settle",
      "settlement": "4471",
      "amount_eur": 3400,
      "beneficiary": "B-082",
      "operation_id": "C4471-S1",
      "once": true,
      "payloads": {
        "prompt": {
          "hash": "sha256:3f9a1c0e7b52",
          "pointer": "payloads/sha256/3f9a1c0e7b52"
        },
        "tool_call": {
          "hash": "sha256:b07e44d2a9c1",
          "pointer": "payloads/sha256/b07e44d2a9c1"
        }
      }
    },
    "permit": {
      "id": "PR-4471-1",
      "bound_to": {
        "mandate_version": "MC-05.2",
        "release": "v2.4",
        "basis": ["wording v14 §4.2", "estimate E-4471-1"],
        "act": {"amount_eur": 3400, "beneficiary": "B-082"}
      },
      "valid_for": "the next payment run"
    }
  },
  "after_the_act": {
    "receipt": {
      "payment": "P-4471",
      "amount_eur": 3400,
      "run": "10:00",
      "acknowledged_by": "the payment service",
      "acknowledged": "2026-09-11T10:00:41+02:00",
      "reconciled_against": "the payment ledger",
      "reconciliation": {
        "permits": 1, "payments": 1, "receipts": 1
      }
    },
    "human_decision": {"needed": false},
    "cost": {"tokens_eur": 0.34, "reviewer_time_eur": 0},
    "retention": {
      "covers": ["the record", "the manifest", "the permits"],
      "period": "P10Y",
      "from": "the act",
      "set_by": "the insurer, for settlement decisions of this tier",
      "illustrative": true,
      "personal_data": "by purpose and retention rule",
      "corrections": "a corrected fact is a new, linked entry",
      "holds": [],
      "disposal": {
        "removes": "the payloads",
        "keeps": "the line and its hashes",
        "recorded_as": "an event, with who authorised it"
      }
    }
  },
  "chain": {
    "prior_manifest_hash": "sha256:9d2e6b10c4f7",
    "event_log_head_hash": "sha256:51c8a3f0e2d9"
  }
}

Version key · the mandate version and the release
From the specification · not on the case page
Times are the insurer’s local time, with its offset, and hashes are shortened. Every identifier, hash, and figure is invented, as on the case page.

From the specification.

The chain: Each line holds the hash of the line before it, prior_manifest_hash, and the hash of the head of the event log at its second, event_log_head_hash. The event log is the record’s own history: every change to a claim, an authority, or a mandate, in the order it happened. If a line or an event is altered, the chain breaks at the altered entry. Whoever can write a chain can rewrite it end to end, so the chain is kept per writer, and the head of each is copied at set intervals to a store its writer cannot reach: the write-once archive, or a log the second line keeps.
The clock: clock_source records which clock stamped the second, how it was synchronised, its offset, and when it last synchronised. Without it, a second in the record cannot be compared with a second in the payment ledger.
Payloads by reference: The prompt and the call to the payment service are kept in a content-addressed store, and the line holds a hash and a pointer, never the content. Payloads are large, and they hold personal data with retention rules of its own.
Retention as an object: The period, what it covers, and who set it are fields of their own, beside any hold that freezes the line past its period and the terms of disposal. At disposal the payloads are removed and the line and its hashes are kept, so the chain is intact afterwards.
The release surface: For each model the release gives the vendor, the region, and the data-handling terms in force, and a change in any of them is a new release. So every act’s line records where it was processed and on what terms.

Standing. Each claim in the basis is read on two axes: evidential warrant, how far the evidence supports relying on the claim, and authority, who asserted it, under what mandate, within what scope. The values are the site’s labels, a warrant validated, current, and uncontradicted, and the authority by name. They are bands of a warrant that the reference architecture computes on several dimensions, in The Knowledge Layer. From that paper the Build pages take the claim as the unit of the basis, the two axes of standing, the consequence tier that sets the bar, and the manifest whose groups the table below maps; they take no dimension, scale, or threshold from it.

The specification’s groups

Site field	Group	In the specification
when	A, G	`action_timestampclock_source`
the agent and its identity	A, F	`agent_idiam_entitlement_chain`
the release	F	`model_versionsexecution_surfacedata_handling_terms`
the basis	B, C, D	`claim_idclaim_versionevidential_warrantauthority_idcontradiction_state`
the mandate version	C	`authority_designation_event_idrevocation_status`
the control standard	A	`policy_version`
the consequence tier	E	`consequence_classconsequence_class_rule_idconsequence_class_rule_version`
the check’s decision	E	`gate_decisionrefusal_reason_code`
the exact act	A, F	`action_idaction_typeprompt_payload_reftool_call_payload_ref`
the permit	E	`gate_decision`In the specification the act commits with the decision. The site holds a permit between them, as section 6 shows, and adds it to the line.
the receipt	none	The specification records the basis, not what came back.
the human decision	C, G	`authority_idsignature_chain`
the cost	none	Not in the specification.
retention	G	`retention_class`

A, action identity and context · B, the basis · C, authority · D, contradiction state · E, consequence class and the gate decision · F, execution surface · G, integrity and lifecycle. The chain, prior_manifest_hash and event_log_head_hash, is group G.

Rebuilt by someone who did not run it

Someone who did not run the agent takes the record of 11.09.2026, folds every event the firm’s systems had recorded by 08:14:06, and recomputes the check for settlement 4471 from what that fold returns: the basis with its standing, the mandate as at that second, and the tier under its taxonomy version. Then the rebuilt line is compared with the recorded one field for field, exactly on identifiers, versions, reason codes, and hashes, while the release surface, captured at the act and never computed, is taken as recorded. When the two disagree there are three causes, and each is a different finding: the log was altered, and its chain breaks at the altered event; the record was altered, and the line no longer matches a log whose chain still holds; or both chains hold and the lines still differ. That last is a finding to investigate, in the inputs, the versions, the order of events, and the rebuild itself, before anyone calls it a defect of the check. In the reference the first such difference came from the rebuild, which read the mandate in force by the clock and not in the order of the record, around the narrowing of 16 September.

Replay as at the second, with only what was known then, is the evidence, and replay with what is known today is analysis. But replay proves the record is faithful and says nothing about whether the basis was right: whether each standing was well judged, and each authority the right one, is a question for model risk. This is K2 of section 2, demonstrated.

rebuild_of_a_day_matches_field_for_field
  11.09.2026 and the record alone, in the
  hands of someone who did not run the agent
  → every decision recomputed equal, field
    for field, and a list of what could not
    be recovered

6The permit, from proposal to receipt

Between the second the check decides and the second the engine commits, a permit is all that holds the act. For settlement 4471 those seconds are 08:14:06 and 10:00:41 on 11.09.2026, and at 10:00:41 the engine reads again everything that may have changed in between.

Built · the mandate, the record, and the engine
Part built · the check: a bought decision point, with its assembly written
Bought or in place · the agent and the payment service
navy the act on its way · orange a write to the record · dashed what comes back

The agent declares the act and its basis (1). The check reads the mandate as at that second, MC-05.2 (2), writes its decision to the record before it answers (3), and issues permit PR-4471-1, bound to the mandate version, the release, the basis, and the exact act, and valid for the next payment run (4). Until it is used or void, the permit counts against the €1.5m daily limit, so acts that each sit inside the mandate cannot together breach it. The check reads the state, decides, and reserves the amount as one step, so two acts in the same second cannot both take the last of the limit; and acts on one case count together against the limit per settlement, so a settlement split in two refers, LIMIT-CASE.

At the 10:00 run the engine re-reads the permit against what is in force at that second (5). It commits the act once, under operation id C4471-S1 (6), takes receipt P-4471 from the payment service (7), and writes it to the record (8). Then it reconciles with the payment ledger: one permit, one payment, one receipt (9).

A revocation while a permit is in flight. On 16.09 a permit for another settlement is issued at 15:38 under MC-05.2. At 15:40 R-02 narrows the mandate to 05.3, recommend. At the 16:00 run the engine re-reads, finds 05.3 in force, and refuses: the permit is void, the refusal is recorded, and the act goes back to a person. Join 1’s test the_check_reads_the_mandate_not_a_cache is written for this interval. A narrowing that lands after the re-read and before the booking is caught at the system of record, which checks the mandate version, the agent, and the release the permit is bound to when it books: revocation_between_reread_and_commit, under the check. Without that check at booking, the re-read leaves an interval open.

A timeout, with the outcome unknown. At the 16:00 run on 11.09 the engine sends the payment of case 4476 under C4476-S2, and the payment service does not answer in time. Before any retry the engine queries the payment ledger by the operation id. It finds nothing booked and retries under the same id, so the payment service can book it only once, and receipt P-4476 records one retry and one payment. Had the ledger shown the payment, the engine would have written the receipt and sent nothing. engine_killed_between_payment_and_receipt, under the check in section 3, tests the same rule after a crash.

When the system of record cannot take part. Many platforms in a firm cannot check a permit when they book. The engine, which holds the only credential, still closes every other path, and one interval stays open: a narrowing that lands after the engine’s re-read and before the booking. The binding states it as a residual risk, with how long the interval lasts on that system, how the daily reconciliation of permits, bookings, and receipts finds an act that went through in it, and who reverses that act. Transaction boundaries, consistency through an outage, and latency are the binding’s to demonstrate on the client’s stack. These are the properties required; the reference shows them on one file and a simulated ledger, and says nothing about the effort on a real system.

7The stacks

The essentials of the map down the left, each as the components that do its work, and what each stack provides. The mandate, the return path, the check’s assembly, and the engine are added on every stack. On the record row the stacks provide the traces, and the record keyed to the mandate version beside them is join 2.

Component	All Microsoft	All AWS	Open source, the baseline	ServiceNow-centred
1the agent itself
Agent identitywho is acting	Entra Agent ID, with Conditional Access at sign-in	AgentCore Identity · IAM	SPIFFE and SPIRE, or the enterprise IdP	the enterprise IdP
Content guardrailswhat goes into and out of the model	Azure AI Content Safety	Bedrock Guardrails	NeMo Guardrails · Guardrails AI	Now Assist Guardian
2its knowledge
Knowledge and retrievalwhat the agent reads	Azure AI Search over Purview-labelled sourceslabel enforcement in preview	Bedrock Knowledge Bases	a governed catalogue · a vector store	knowledge in the platform
3its mandate
The mandate objectversioned, owned, queryable at run time	added on every stack · built once, and kept
4the check
Policy decisionmay this exact action proceed?	a decision service or OPA	AgentCore Policy, in Cedar	Open Policy Agent, or Cedar	rules held in ServiceNow
Enforcement at the actionwhere the decision is applied	API Management in front of the toolits MCP gateway in preview	AgentCore Gateway	Envoy, or the target service itself	a gateway, or the target service itself
The check’s assemblysix inputs as at the second, the permit, the reservation, the write first	added on every stack · built once, and kept
The engineholds the credential and the permit, commits once, reconciles	added on every stack · built once, and kept
5the record
Record and traceswhat happened, keyed to versions	Azure Monitor · Foundry tracing	AgentCore Observability · CloudWatch	OpenTelemetry into Langfuse or Phoenix	AI Control Tower · platform audit
6the loop
Evaluation and monitoringhow well it works, in production	Foundry evaluations · Azure Monitor alerts	AgentCore Evaluations, online and on demand	evaluations in Langfuse or Phoenix	AI Control Tower runtime agent evaluations
The return pathrecord → rule → review → mandate	added on every stack · built once, and kept
Rthe register
Registerwhat runs, in which version	Agent 365 registryin preview	AWS Agent Registry	a catalogue with an API · MLflow	AI Control Tower

Vendor documentation, checked 23 and 24 September 2026. The Agent 365 registry, the MCP gateway in API Management, and label enforcement in Azure AI Search are in preview; the rest is generally available or open source. The review did not establish where each of these runs: it recorded no region limit, which is not the same as there being none, so each placement is checked in phase 1 against the regions the client has approved, on the client’s own estate. A part in preview stays out of a payment path until it is generally available in those regions.

8The kill path

One agent can span several platforms, each with its own kill switch. So the agent’s identity is issued once, at the firm, and federated to every platform, and one revocation stops it everywhere.

Revoke. The CISO revokes the agent’s identity once, at the firm: revoke(agent).
The check and the engine. Both read the revocation themselves, so the agent stops at once at the act: the check refuses its next declaration and voids every permit issued to it, and the engine refuses each one at its re-read.
Tokens. Tokens already issued are, as a rule, not revoked in place; continuous access evaluation, where a platform has it, cuts some short. Each platform stops accepting them at expiry at the latest, fifteen minutes in the motor case, and that is the backstop for anything the agent reaches outside the check.
The queue. Acts already waiting go back to people, through the check.
The record. The record shows the revocation and every refusal after it.

The quarterly test. Every quarter, on every platform, a test tries to act after revocation, and the record shows that it failed.

revoked_agent_cannot_act_on_any_platform
  claims-agent-01 revoked at 10:00 → an
  act attempted at 10:01 on each platform
  is refused at the check, and the record
  shows every refusal

What is in flight. Nothing in flight escapes the re-check. A permit is void once the identity is revoked or the mandate narrows. Queued acts go back through the check. An act already past the commit is reconciled from its receipt, and an act whose outcome is unknown is reconciled with the receiving system before anyone retries, as section 6 shows.

9The reference

The contracts of section 3 run as small Python services, wired together for the motor case, in the folder 11-reference of the Hub’s control-plane repository; ask the Hub for access. Every test the Build pages name is there under the same name, the motor case runs through it from 11 to 21 September, and no model is called anywhere. It is a reference and it is not hardened: it shows that the joins can be built and tested, and it must not be copied into production as it is.

cd 11-reference
python -m pip install -e ".[dev]"
pytest
python scripts/replay_motor_claim.py --record record.sqlite
python scripts/replay_motor_claim.py --jsonl
python scripts/rebuild.py record.sqlite 2026-09-11

What it proves. The contracts can be implemented, and the implementations are small; each invariant can be tested, and the tests are short. A permit dies with its mandate: the permit issued at 15:38 on 16 September is refused at 16:00, after R-02 narrowed MC-05 at 15:40. A retry acts once, and an act whose outcome is unknown is reconciled with the ledger before anything is sent again. Two orderings first failed there: two acts in the same second both took a permit, and a narrowing between the engine’s re-read and the booking let the payment through. The check now decides and reserves in one step, and the payment service checks the permit again when it books. A day is rebuilt from the record file alone, and every decision of 11 September comes out equal, which is K2 of section 2 on invented data. The rules run in Python and in Open Policy Agent, and a test holds the two to the same answers.

What it does not prove. Whether the check keeps pace with payments or trading. Whether the mandate object survives a real firm’s role model, identity provider, and system of record. Anything about security: its tokens and signatures stand in for the firm’s identity provider, and its record is one file. And whether evidence at level K predicts controllable behaviour at level A, which only deployments can settle.

10From here

From the workshop to the first governed agent

Phase by phase, from the half day on one workflow to a second workflow on the same joins: what is decided, who takes part, and what is handed over.

See the path →

Every box, as something to build

For every box of the map, the question, the owner, who builds it, what exists and what is written, the contract it implements, the invariant, and its tests.

See every box →

Every product on the Build pages is a placement from public documentation of September 2026: an example to check against the version a firm runs, and no assessment or recommendation of it.