containment.ai — Brief 01: reading a decision record. Status of record: www.containment.ai/trust.html
BRIEF 01 — FOR A CONTRACTING OFFICER OR PROGRAM SECURITY LEAD

What a decision record proves — and what it does not.

Every governed action produces a decision record. This brief states the fields, shows you how to verify a real one yourself in a browser, and marks exactly where the claim stops. It is written to be forwarded.

The fields

eventThe action that was proposed, in canonical form — normalised so that equivalent inputs produce one comparable representation. policy versionThe exact versioned bundle that was evaluated. Pinned at decision time, not resolved later. contextThe identity, classification, target and parameters the policy saw when it decided. rulingOne of ALLOW, DENY, MODIFY, STEP_UP, DEFER. Ambiguity resolves to DENY; the path fails closed. Two layers, two names: that five-verb set is the export vocabulary this brief describes. On the wire, a Gateway receipt carries the enforcement field verdict with values like permit / deny — so the receipt you verify on the verifier page will read "verdict": "permit", not "ruling": "ALLOW". Both are correct at their own layer; neither is a rename of the other. sealIntegrity protection over the record. The scheme differs by product — see the limits below.

Verify one yourself, without talking to us

A real Gateway staging receipt is pre-loaded in the browser verifier, signed under published key staging-2026-07-06. You can recompute its decision hash, check the signature against the published key, and then alter one byte and watch verification fail. It runs entirely in your browser — nothing is sent to us.

Open the verifier →

WHAT THE VERIFIER CHECKS
Record integrity · signer key · continuity of the chain segment you supply.
WHAT IT DOES NOT DO
It does not re-run policy. It confirms the record is authentic and unaltered — not that the ruling was the correct one.

Where the claim stops

A record evidences the decision, not the downstream effect. It states the ruling, the policy metadata, and the response the enforcement point issued. It is not independent proof that a downstream system executed, or refused to execute, anything.

Signing and chaining differ by product. Ed25519 signatures with per-organization hash chaining are the Mission Authorization Gateway staging build. Connected-tier proxy rulings use HMAC receipts; the Chat Firewall writes tamper-evident audit records. The per-product scheme is stated in the Trust status matrix.

Re-evaluation has preconditions. A ruling can be re-evaluated only where the exact recorded input, the context, and the retained policy bundle are all still available. Retention is a deployment decision.

Three questions worth asking us

1   For our deployment, which product writes the record, and under which signing scheme?
2   What is the retention window, and who can export the trail?
3   Which paths in our environment are mediated, and which are deliberately left direct?
Containment.ai is pre-ATO and holds no completed certification or authorization. No independent audit report exists. Current product and assurance status is stated in full on the Trust record — versioned, dated, and it outranks this brief.
Print this page or save it as PDF to forward it — the site chrome drops out and it sets as a document.