Conformance Profile

Version 1.0, published 2026-07-06. This is the stable release of the profile at its canonical URL, https://www.asqav.com/docs/conformance-profile.

This profile defines what "verifiable" means for a governance receipt: the evidence an auditor needs to re-derive, on their own, that an agent action was authorized, policy-evaluated, and bound to the authority that signed it. It is a public standard. Anyone who emits governance receipts can conform to it, and anyone who receives one can check it.

The profile is stated as five principles. Each is testable, and each is pinned by machine-checked fixtures published alongside this page. A receipt either survives all five or it does not. Documentation by itself asserts nothing.

How to cite this profile

The profile is versioned and stable at its canonical URL. Cite it as:

citation

Conformance Profile for AI-Agent Governance Receipts. Version 1.0.
Asqav, published 2026-07-06.
https://www.asqav.com/docs/conformance-profile
Conformance fixtures: https://www.asqav.com/docs/conformance-profile#fixtures

The six boundary fixtures that pin the profile are listed in the fixtures section and downloadable from the fixture directory at https://www.asqav.com/docs/conformance-profile#fixtures.

Principle 1. Decision differs from outcome

What it means. A pre-dispatch authorization decision and the post-dispatch execution outcome are separate things, and a receipt must keep them separate. The decision payload carries allow or deny plus a policy_ref that says which policy evaluated. The outcome evidence, such as an applied attestation or a result digest, is what the tool actually did. The two live in different receipt types and must not be folded into one.

Why it matters. The attack is a decision receipt that quietly carries an outcome field. A reader who sees decision: allow next to result_digest: ... reads the authorization as if execution had already happened and produced that result. That is a forged causal chain. The authorization ran before the tool, so it cannot know the result. Keeping decision and outcome on separate receipt types closes the gap.

Principle 2. Required supports are a subset of the supports retained

What it means. For every tool-call transition, the verifier can name the supports the profile requires (a mandate, a policy, an approval) and prove each one is backed by retained evidence that recomputes at verify time. Required is a subset of Supported. A receipt that claims a support it cannot reproduce is out of profile.

Why it matters. The attack is a receipt that asserts "this ran under mandate M" or "policy P evaluated" with nothing behind the assertion. Without a join to retained evidence the assertion is decorative. The subset rule turns each claim into something the verifier can check or reject.

Principle 3. Identity differs from authority differs from evidence

What it means. Three things move at different speeds and must not be conflated. Agent identity is stable, it is who the agent is. Execution authority narrows, expires, and re-establishes; it is what the agent is allowed to do right now, under a mandate with a validity window. Evidence is appended and never rewritten; once an action is recorded it stays recorded. A receipt that treats identity as authority, or authority as permanent, blurs all three.

Why it matters. The attack is a receipt signed long after the mandate that authorized it expired. If authority is read as permanent, because the identity is stable, a lapsed mandate keeps authorizing forever. Treating the three independently lets the verifier say "the agent is who it claims, the receipt is well-formed, but the authority for this action had lapsed" and downgrade accordingly.

Principle 4. Recompute, never trust a copied digest

What it means. Every digest binding in a receipt is recomputed from canonical fields at verify time. The verifier never compares two stored strings; it regenerates the digest from the source bytes and checks equality. action_ref recomputes from the canonical request. policy_digest recomputes from the retained policy artefact. scope_digest recomputes from the mandate scope.

Why it matters. The attack is a receipt that claims a policy_digest pointing at a policy that never evaluated, or an action_ref claiming a request the receipt was not signed over. If the verifier trusts the copied value, the mismatch is invisible. Recomputing turns each digest into a proof rather than a label.

Principle 5. Conformance is fixture-driven

What it means. The boundary is proven by test vectors, not asserted by documentation. Each principle has a fixture that exercises it in both directions: a positive vector that passes, and a negative vector that rejects or downgrades. The fixtures are the contract. If a code change breaks one, an implementation has drifted off profile.

Why it matters. A profile described in prose alone drifts. The fixture set is the machine-checkable form of the standard, and it runs in continuous integration on every change, so the profile is enforced against the code rather than against a document someone forgot to update.

The six profile fixtures

The boundary is proven by test vectors, not asserted by prose. Each fixture is a JSON document you can download and run against any implementation that claims to conform. A verdict is one of PASS, REJECT, or INCOMPLETE. REJECT is a forged or out-of-bound receipt. INCOMPLETE is a freshness downgrade where authority may have lapsed but nothing was forged.

vector-029-decision-outcome-boundary, principle 1, expected REJECT. A decision receipt carrying an outcome key.
vector-030-request-digest-recomputed, principle 4, expected REJECT. An action_ref that does not match the canonical request bytes.
vector-031-policy-digest-recomputed, principle 4, expected REJECT. A policy_digest that does not match the retained policy artefact.
vector-032-mandate-scope-coverage, principle 2, expected REJECT. A mandate that does not authorize the receipt tool.
vector-033-all-supports-present, principle 5, expected PASS. Every support present and recomputable, the positive path.
vector-034-mandate-freshness-window, principle 3, expected INCOMPLETE. A receipt whose timestamp is outside the mandate validity window.

The full fixture directory is at https://www.asqav.com/docs/conformance-profile#fixtures. Download a vector, feed it to the implementation under review, and compare the verdict to the expectation above.

How Asqav implements this profile

Asqav's cloud enforces all five principles server-side and runs the six fixtures in its continuous integration on every change, so the profile is checked against the running code rather than against a document. The receipt vocabulary splits decision from observation, the profile layer recomputes every digest binding and joins each claimed support to the retained evidence, and a stale mandate downgrades a receipt to INCOMPLETE rather than rejecting it. For the regime-by-regime view of the evidence Asqav produces, see the conformance mapping. The receipt format itself is specified in the IETF Internet-Draft, and any receipt can be checked with the independent verifier.