Runtime Assurance Loop

The Runtime Assurance Loop turns what Mandaitor authorized at runtime into evidence that someone else can check afterwards. Core records the evidence as it acts. Ops validates what it publishes and refuses to publish what fails validation. The dashboard's Trust Operations page shows the result to operators. None of it changes how Mandaitor decides.

Definition: Runtime Assurance is the evidence loop after a decision. It shows that a write Mandaitor performed rested on an active mandate and a Proof-of-Mandate signed for it, and that its outcome was read back and signed.

Changed in October 2026

The loop's first source was POST /mcp/authorize, which answered each decision with an mcp-runtime-trace/v2 trace: Proof-of-Mandate binding, a Verifiable Intent L3 claim, and advisory drift scores. That route has been removed (see MCP Authorization Server), and its trace went with it. Runtime evidence now comes from executions. Ops does not read execution receipts yet, so the runtime-authorization snapshot in the published trust data is still the committed sample of the retired trace, from May 2026, and it is marked stale.

End-to-End Flow

Stage	Component	Evidence Produced	Failure Semantics
Execution	`mandaitor-core` execution path	A Proof-of-Mandate signed before the write is dispatched, the dispatch event that carries it, and a signed receipt of the outcome that names it	Nothing is dispatched without a signed Proof-of-Mandate and a recorded dispatch event.
Evidence export	`mandaitor-core` evidence-pack handler	Evidence-pack schema `1.2.0`, `export_manifest`, recomputable section digests, RBAC requester attribution, and `EVIDENCE_PACK_EXPORTED` audit event	Evidence exports fail if the pack or export audit event cannot be produced.
Evidence ingestion	`mandaitor-ops` runtime evidence generator	Runtime-authorization snapshots in `trust-data.json`. Today the only one is the May 2026 sample of the retired trace	Evidence validation is fail-closed when required fields are missing or malformed.
Trust publication	Public docs generated assets	`/generated/trust-data.json`, `/generated/assurance-pack.md`, and compliance report outputs	Trust publication should only use validated generated artifacts.
Operator review	`mandaitor-dashboard`	The Executions page for each execution's evidence; the Trust Operations cockpit for the published snapshots and evidence-pack export status	The cockpit falls back to documented sample data only when live trust data is unavailable.

What an Execution Leaves Behind

Every write an execution dispatches rests on three records, and the last names the first:

A Proof-of-Mandate, signed before the write is dispatched. It names the mandate the final check relied on, with the action and resource. It is bound to this one request by its request digest, or by its approval digest when a person approved it. If it cannot be signed, nothing is dispatched: the execution waits, and Mandaitor takes it up again.
The dispatch event on the mandate's audit trail, which carries the Proof-of-Mandate. If it cannot be recorded, nothing is written.
A receipt, signed once a read-back establishes the outcome. Its authorization claim holds event_id, mandate_id and pom_digest: the dispatch event, the mandate, and the SHA-256 of the Proof-of-Mandate. A reviewer can match a receipt to the authorization it rests on without trusting anything the agent says.

The agent receives the receipt and never the Proof-of-Mandate. Both go on the mandate's audit trail, and its evidence pack lists them in proof_tokens. Receipts describes the receipt's claims and how to verify one.

A denial has no Proof-of-Mandate and no receipt. Its record is the decision event on the audit trail. Executions compute no drift score and issue no Verifiable Intent L3 claim. Both belonged to the retired trace.

Evidence Export Integrity

Core evidence-pack exports include a manifest that binds the exported mandate snapshot, event chain, proof tokens, and manifest metadata to recomputable digests. This gives auditors a stable integrity envelope around the export itself, separate from the already chained audit events.

Integrity field	Operational meaning
`export_manifest.export_id`	Stable identifier for one evidence-pack export operation.
`export_manifest.generated_by`	Normalized requester attribution derived from Core RBAC context, including tenant and role/permission material when present.
`export_manifest.coverage`	Scope of the export, including tenant, mandate, schema version, event count, and optional event filter.
`export_manifest.digests`	Recomputable digests for the mandate snapshot, event chain, proof tokens, and manifest hash.
`EVIDENCE_PACK_EXPORTED` audit event	Append-only ledger proof that the export occurred, including export ID, manifest hash, case-log hash, event count, and schema version.

The standalone evidence-pack verifier checks the export manifest in addition to chain integrity and proof-token digest coverage, which allows offline reviewers to detect tampering in the export envelope before relying on the evidence pack. The verifier is part of the Core pull-request path through a golden evidence-pack fixture, so the integrity contract is tested before evidence-export changes can merge.

Trust Data Projection

Ops publishes runtime-authorization evidence into trust-data.json under runtime_authorization, and the dashboard derives its runtime summary from the first snapshot. The only snapshot today is the sample of the retired trace. It is published as it was collected, and marked stale, rather than re-dated:

{
  "runtime_authorization": [
    {
      "evidence_id": "2026-W19-runtime-authorization",
      "source": "runtime-authorization",
      "collected_at": "2026-05-08T15:15:10.303Z",
      "freshness_status": "stale",
      "contract_version": "mcp-runtime-trace/v2",
      "control_refs": ["OP-005", "AA-001", "AA-002"],
      "claim_refs": ["TC-020", "TC-036"],
      "obligation_refs": ["OBL-001", "OBL-020", "OBL-040"],
      "event_count": 1,
      "allowed_events": 1,
      "latest_verification_event_id": "evt_runtime_authorization_fixture"
    }
  ]
}

A second publication surface, evidence_pack_exports, lets the Trust Operations cockpit show whether recent evidence-pack export manifests were verified, which schema version they used, which manifest digest was recomputed, and which export audit event anchors the handoff. It stays compact, because a full evidence pack may be customer- or incident-specific: the published trust data carries the integrity envelope and its status rather than the pack's contents.

{
  "evidence_pack_exports": [
    {
      "export_id": "exp_wave4_fixture",
      "source": "evidence-pack-export",
      "generated_at": "2026-05-20T09:28:00.000Z",
      "schema_version": "1.2.0",
      "manifest_version": "1.0",
      "manifest_digest": "sha256:96bfe1e6b3d7d9bb9e0c03f31e16b66bdf65de6f7f2d7f63cc35b59d94fb8f66",
      "event_count": 3,
      "file_count": 1,
      "verifier": "offline-evidence-pack-verifier",
      "status": "verified",
      "latest_event_id": "evt_evidence_pack_exported_wave4",
      "artifact": "mandaitor-core/lambdas/test/fixtures/golden-evidence-pack.json"
    }
  ]
}

Projection Field	Review Purpose
`export_id`	Identifies the exact evidence-pack export operation being reviewed.
`manifest_digest`	Gives reviewers the recomputed manifest hash that should match the offline verifier result.
`schema_version` and `manifest_version`	Show whether the export used the current evidence-pack contract and manifest format.
`event_count` and `file_count`	Summarize the coverage of the exported evidence envelope without publishing sensitive pack contents.
`verifier` and `status`	State which verifier evaluated the export and whether it passed, warned, failed, or is missing.
`latest_event_id`	Links the visible manifest card back to the immutable `EVIDENCE_PACK_EXPORTED` audit event.

Compliance Closure

Runtime Assurance supports the public trust claims that require proof that autonomous actions are authorized, traceable, and mapped to operational controls.

Public Claim or Obligation	Runtime-Assurance Evidence
`TC-020` — mandate verification uses W3C Verifiable Credentials	The Proof-of-Mandate an execution's write rests on is an SD-JWT Verifiable Credential signed by Mandaitor.
`TC-036` — every write an execution dispatches is authorized by a Proof-of-Mandate signed before dispatch, and the signed receipt of its outcome names it	Core's execution path and its tests; an execution's evidence pack carries both in `proof_tokens`.
`TC-039` — evidence-pack export manifests are verified offline and surfaced in Trust Operations	Trust data includes `evidence_pack_exports` with manifest digest, verifier status, schema version, event count, and latest export audit event.
`OBL-001` — security questionnaire readiness	An execution's evidence pack shows a write, the Proof-of-Mandate it rested on, and its receipt. The published runtime-authorization snapshot is a sample.
`OBL-020` — API uptime commitment	Runtime evidence references operational controls and published freshness status.
`OBL-040` — SOC 2 Type I readiness preparation	Compliance mapping links runtime authorization to access, evidence, operations, and incident-response controls.

Adjacent compliance-evidence closures make the published Trust Operations view coherent. These controls are generated into the public compliance report even when they are not part of the runtime evidence itself.

Control or Obligation	Evidence Closure
`DP-006` / `OBL-011`	Data-subject request routing is represented as privacy-evidence closure so DSAR handling is no longer left as an unmapped privacy obligation.
`DP-007` / `OBL-012`	Subprocessor transparency is represented as a privacy/transparency evidence closure and mapped into generated compliance outputs.
`OP-008` / `OBL-001`, `OBL-020`, `OBL-040`	Runtime-authorization evidence ingestion validates each event fail-closed and publishes freshness-aware trust data. Its source, Core's MCP authorization responses, was retired in October 2026. Until it reads execution receipts, it publishes the May 2026 sample, marked `stale`.
`OP-009` / `OBL-031`	Beta feedback intake and SLA routing are documented as operational evidence for pilot transparency and feedback processing.

Dashboard Review Procedure

An execution's own evidence is on the dashboard's Executions page. An execution's page shows what the agent asked, what Mandaitor read, the decision and the mandate it rested on, the approval when one was needed, the write with the digest of its Proof-of-Mandate, and the receipt, which you can copy and verify with the SDK.

The tenant Trust Operations page shows what Ops published. Its Runtime Authorization card shows the stale May 2026 sample of the retired trace, badged as stale, until Ops reads execution receipts. Its Evidence-Pack Export Integrity section shows the latest evidence_pack_exports entry, with verifier status, manifest digest, schema version, event count, and the export audit event anchor.

Check	Expected Result
Execution evidence	A `SUCCEEDED` execution shows its mandate, the digest of the Proof-of-Mandate it was dispatched on, and a receipt. The receipt verifies with `verifyReceiptForExecution` and names the same digest in `authorization.pom_digest`.
Evidence pack	The mandate's evidence pack lists the execution's Proof-of-Mandate and receipt in `proof_tokens`.
Trust data load	The page reads `/generated/trust-data.json`. The runtime-authorization snapshot shows `freshness_status: stale`. At least one verified `evidence_pack_exports` entry appears when export evidence has been published.
Compliance coverage	Runtime-related obligations appear with their mapped controls instead of stale gap text.
Export integrity	The evidence-pack export card shows verifier status, manifest digest, schema/manifest versions, event count, and latest `EVIDENCE_PACK_EXPORTED` event ID.

Testing Checklist

Test Area	Command or Manual Path	Expected Result
Core execution evidence	Run `vitest run test/executions-handler.test.ts test/execution-receipt.test.ts test/execution-receipt-sdk.test.ts` in `mandaitor-core/lambdas`.	A write is dispatched only with a Proof-of-Mandate signed for its request or approval, the agent never receives it, and the receipt verifies and names it by digest.
Core evidence-pack export	Run `vitest run test/evidence-pack.test.ts test/evidence-verifier.test.ts` and `pnpm --filter @mandaitor/lambdas verify:evidence-pack:golden` in `mandaitor-core/lambdas` or through pull-request CI.	Evidence packs include schema `1.2.0`, a valid export manifest, RBAC requester attribution, offline-verifier coverage, and an `EVIDENCE_PACK_EXPORTED` audit event.
Ops runtime ingestion	Run the runtime-evidence and trust-data generator tests in `mandaitor-ops`.	Events normalize into validated runtime evidence and trust data, the same events are never filed under a second week, and evidence-pack export manifests are summarized.
Public generated artifacts	Sync `mandaitor-ops/generated/` into `mandaitor-public/static/generated/`.	Public trust data and compliance reports match what Ops validated.
Dashboard	Run the Executions and Trust Operations page tests in `mandaitor-dashboard`.	An execution's page renders its authorization and receipt. The cockpit renders live trust-data snapshots, evidence-pack export manifest status, and deterministic fallback data.

Boundary Conditions

Runtime Assurance records what Mandaitor did; it does not decide. Evidence validation is stricter than the runtime path it describes: Ops does not publish a runtime-authorization snapshot unless every required field is present, and it does not file the same events again under a newer week to make them look fresh. A snapshot collected more than 60 days ago is published as stale, not re-dated.

End-to-End Flow​

What an Execution Leaves Behind​

Evidence Export Integrity​

Trust Data Projection​

Compliance Closure​

Dashboard Review Procedure​

Testing Checklist​

Boundary Conditions​