How assurance works

AI System Assurance is Brutor’s answer to the question no request dashboard can answer: is this AI System still operating according to what we signed off? It is built for the failure modes that are quiet instead of loud, and it is keyed on the AI System — the agent, assistant or pipeline — not on individual requests.

The whole discipline fits in one picture:

Read it top to bottom:

1. Every run becomes evidence. Governed calls — every LLM, MCP, skill and A2A call — are grouped by task into the run ledger, each run with an honest terminal state. Baselines learn what normal looks like per system, and a version-hashed contract records what the system declared at sign-off.
2. Five signals score it continuously. Liveness (still running when it should be?), behaviour (has how it works moved?), reliability, cost per completed task, and conformance (what it declared vs what it actually called).
3. One verdict — worst-of, never an average. A system that is cheap, fast and dead is not 80% healthy. And unknown is a real verdict: too little evidence never reads as green. See health.
4. The verdict drives three outputs. The fleet board in Mission Control; findings and response — alerts, approval gates, or automatic tightening of autonomy; and the Assurance Report, which ends by stating what it does not cover.
5. Recorded runs are reusable. Replay rehearses a policy change against real recorded traffic offline — nothing dispatched upstream, no tokens spent — before the lifecycle gate lets the change promote.

The four guarantees

Deploy an AI System through Brutor and the platform commits to four things. Every assurance feature exists to make exactly one of them true.

G1 — Bounded

It operates within policy, and the policy is enforced in the request path, not advised. What it was allowed to do is provable after the fact, via contracts.

G2 — Non-drifting

It will not drift without you being told — and told why. Behavioural baselines, drift detection and cause attribution: behavioural drift.

G3 — Doing its job

You find out when it stops doing what it should. Recorded production traffic becomes an eval set, and changes are diffed against it before promotion: replay.

G4 — Alive

You find out when it stops working at all — including when it goes silent, the failure every request-driven metric misses: liveness.

What Brutor deliberately does not claim

Brutor detects behavioural change against a system’s own history — it does not detect wrong answers, because there is no ground truth at a proxy. It attributes the most likely cause of a change from data the gateway owns, and answers unexplained when nothing lines up rather than inventing a reason. It detects silence and stalls in traffic through the gateway — not end-to-end process uptime. And it produces continuous monitoring evidence; compliance itself remains yours. Over-claiming is how assurance products lose trust; the boundaries are stated in the product, on purpose.

One full lap

How the pieces cooperate across a system’s life:

1. Register — declare the system: owner, kind, intended use, risk tier. From this moment every call is attributed to it; traffic matching no system lands in an “Unattributed runs” funnel rather than being lost silently.
2. Contract — freeze the rules: a hash-pinned snapshot of everything the system may do, append-only, one active per system.
3. Gate — prove before promoting: promotion to active requires evidence, and a bound replay suite must pass — with the verdict being an outcome change, so tightening never blocks a release.
4. Run — enforce and record: every action policy-checked in-path and written to the run ledger with an honest terminal state.
5. Observe — watch it against itself: liveness fires on the absence of traffic; drift compares behaviour against the system’s own history and leads with the likely cause.
6. Respond — tighten automatically: an armed response policy can downgrade autonomy on findings — it can only tighten, never loosen, and restore is always human.
7. Report — show the evidence: five components, one worst-of health verdict, and an immutable Assurance Report the engineer opens at 09:00 and the auditor exports in December. The same document.

Then a change arrives — a new model, a new tool, a policy edit — a new contract is minted, the gate asks for evidence, and the loop repeats.

If you have run IT operations before

Every mechanism above has an ancestor you already trust:

Brutor concept	Old-world ancestor
The gateway	A reverse proxy + policy enforcement point
The run ledger	A flight recorder — sensor readings rolled up into “what happened on this flight”
Liveness	A dead-man’s switch
Baselines & drift	APM anomaly detection — but over behaviour, not CPU
Contracts & the gate	Change management, made executable and cryptographically pinned
Replay	A regression test set built from production traffic
The closed loop	A circuit breaker — tripping on behavioural evidence, turning a dial instead of cutting power
The Assurance Report	An audit evidence pack, generated continuously

Scope

Assurance applies to the programmatic surface: systems, agents and applications whose traffic points at the gateway. Brutor does not observe or govern consumer chat apps that talk directly to their vendors.

The detail pages

The run ledgerHow actions become runs: signed chains, the run-id header, terminal states, integrity, the Trajectory Explorer.

LivenessThe only signal that fires on the absence of traffic — expectations, detectors, learned cadences.

Behavioural driftRobust statistics, sustained-change detection, cause attribution, consequence-ranked severity.

ContractsHash-pinned snapshots of what a system may do — append-only versions and widened-vs-narrowed diffs.

Autonomy & responseHow much a system may do without a human, and the closed loop that tightens it automatically.

The gate & replayEvidence-gated lifecycle transitions, and rehearsing changes against recorded traffic.

Health & the Assurance ReportOne worst-of verdict from five components, conformance, and the immutable evidence artifact.

Assurance APIEvery endpoint: fleet, runs, liveness, drift, contracts, lifecycle, replay, health, reports.