The gate & replay

Assurance is cheapest before a change ships. Two mechanisms make promotion an evidence question rather than a dropdown: the lifecycle gate, which demands proof at each stage transition, and replay, which rehearses a candidate configuration against real recorded traffic — offline.

The lifecycle gate

lifecycle_stage moves proposed → approved → active → deprecated → retired. Each transition carries an evidence requirement:

Transition	Requires
proposed → approved	A contract minted for the current config; an owner; intended use
approved → active	An approver recorded on the contract; a liveness decision
active → active (config change)	No unapproved widening of permissions
active → deprecated	A successor named, or “no successor” stated explicitly
deprecated → retired	No runs for the quiet period (30 days)

Moving backwards needs no evidence — that is how an operator corrects a mistake, and a gate that traps a system in active is a gate people route around. Skipping a stage is refused outright.

The Lifecycle tab on a system draws this as a live rail: the current stage is marked, the gate in front of it lists every requirement as met or unmet, and each unmet requirement with one fix carries the button that performs it — mint the contract, set the owner or intended use inline, approve the contract, jump to liveness, attach the impact assessment, run replay. The rail is deliberately a different diagram from the assurance loop: this is the governance lifecycle, a stage the system sits in; that is the evidence loop that runs at every stage.

Every transition is recorded — from and to stage, the accountable approver and the admin who recorded it, and when — and the Lifecycle tab lists them. The admin performing the move is the named approver by default; naming someone else records an approval on their behalf beside the recorder, never instead of it.

Systems with eu_ai_act_risk_tier: "high" additionally require a named human approver on every transition, and an unexpired impact assessment (an EU AI Act Article 27 FRIA, a DPIA — attached as evidence) for proposed → approved. Both are floors, not defaults: a tenant policy can tighten the other requirements or relax them, but cannot remove these. The assessment is demanded only at the approval step — approval is the review where the document is actually read, and a document does not get truer by being checked twice.

External evidence

Some evidence the platform cannot generate: an impact assessment, an evaluation report, a red-team or penetration-test report. These attach to the AI System as evidence artifacts — pointers with fingerprints, not copies. The document stays in your document system; the platform records where it lives (uri), how to verify it (sha256), who produced it, whether that party was independent of the team that built the system, and how long the assessor’s claim holds (valid_until). An expired impact assessment does not satisfy the gate — evidence that has aged out is a different fact from evidence that exists, and the refusal names which document needs renewing.

One kind is about a single dependency, not the whole system: supplier_information (EU AI Act Art 25(4)) — the written agreement the system relies on from the legal entity that supplies one of its dependencies (every external agent, and a shared service owned by another legal entity, named on the edge as supplier_legal_entity). It names the edge (dependency_id, one of this system’s dependencies) and must carry its sha256; no other kind names an edge. The obligation registry counts it per edge (dependencies.supplier_information_on_file). Removing the edge keeps the pointer, detached.

Attached artifacts appear in the Assurance Report, which also states plainly when everything attached is self-produced — independent evidence matters more as the stakes rise, so its absence is a named gap, never a silent one.

There is no ungated path

lifecycle_stage cannot be set through PATCH /v1/admin/resource-groups/{id} on an AI System — that request is refused with a 409 pointing at the lifecycle endpoint. A governed field with an ungated writer is worse than no gate, because the fleet board would still report the system as approved. On every other group type the field is documentation and stays freely editable.

The checklist is visible before you click

GET /v1/admin/ai-systems/{id}/lifecycle returns every reachable stage with its full requirement list, each item marked satisfied or not. The UI shows an operator what is missing rather than a red toast after the fact, and a refusal names every missing requirement at once rather than the first one.

Replay

Your audit log is an eval dataset: Brutor collects production traces as a byproduct of enforcement, so a suite costs nothing to gather. If a replay suite is bound to a system, promotion through the gate requires a passing replay run.

Replay diffs authorization, not behaviour

Replay re-evaluates every recorded step’s authorization decision under the candidate contract and diffs the verdicts. It does not re-run your agent: the loop that decides “call a model, read the answer, call a tool” lives in your process, not the gateway, so re-issuing the first request would replay one step and stop.

That means replay answers “would this change govern my traffic differently?” — which is the release question — and not “would my agent have behaved differently?”, which is what drift detection answers on real traffic afterwards. Content guardrails are not re-evaluated either; whether a PII check would trip depends on running it.

Because nothing is dispatched, replay cannot call a tool, spend a token or move money — that is structural, not a setting. It is also deterministic, so a failing gate is reproducible rather than a coin flip against a live provider.

Sampling is stratified, rarest-first across terminal state, step-count decile and tool signature — plus an explicit outlier bucket for runs that brush the iteration cap. “The last 50 runs” is the obvious suite and it gates nothing: it encodes the happy path and misses the exhausted runs, the rare tool and the long trajectories, which are exactly the cases a config change breaks. Each case records which stratum it was picked for, so a suite that is thirty variations on one happy path is visible as such.

The diff classifies each case:

Verdict	Means	Passes?
matched	Every step decided the same way	✅
policy_changed	A step now needs approval that did not	❌
outcome_changed	A step that used to succeed is now denied — the task would not have completed	❌
failed	The case could not be evaluated (its actions aged out)	❌
skipped	Excluded from the pass rate entirely	—

A new approval requirement is stricter, not broken, so it is reported separately from an outright denial — blocking a release for tightening would teach people to route around the gate.

Nothing that evaluated nothing reports a pass. An empty suite, an unreplayable suite, a case whose actions have aged out of retention: each fails with a reason. A suite where every case was skipped reports no pass rate at all rather than a confident 100%.

Related

• Contracts — the thing being promoted, and the diff an approver reads
• The run ledger — where the recorded traffic comes from
• Behavioural drift — the after-the-fact counterpart to replay