Widen the per-call decision enum under a new profile version, not in 1.0

[imran-siddique]

Decision recorded so this is not re-derived: widen under a new profile version, leave 1.0 untouched.

Background

agentrust-io/cmcp now records the five AARM R4 decision types (ALLOW, DENY, MODIFY, STEP_UP, DEFER) in its audit chain. The TRACE Claim cannot carry two of them. schemas/trace-claim.schema.json in cmcp pins the per-call decision enum to:

["allow", "deny", "redact", "advisory_deny", "fault", "n/a"]

So step_up and defer are currently narrowed to deny at the claim boundary, in cmcp PR #442. That is sound and tested: the call was blocked in every case, which is the part a claim asserts, and unrecognised values also narrow to deny so a future value cannot emit a claim that fails validation. The cost is that the specific decision is invisible to anyone who only reads claims.

Why not widen 1.0 in place

A verifier pinned to the current 1.0 enum would reject a claim carrying step_up. Compatibility is the entire reason a version is pinned, so widening in place spends it. Rejected for that reason.

What to do instead

Add the values under a new profile version, so adopters opt in and existing verifiers keep working.

Coordination, which is why this is an issue rather than a patch:

Repo	Change
trace-spec	New profile URI, tag:agentrust-io.com,2026:trace-v0.3 or a 1.1 claim version. Document the widened enum and that 1.0 is unchanged
trace-tests	Conformance cases for the new values; existing 1.0 cases must keep passing unmodified
trace-registry	Accept and index the new profile
cmcp	Emit the new profile, and drop claim_value()'s narrowing when the profile in use supports the values. Keep narrowing for 1.0

Semantics worth settling in the spec rather than per implementation:

• STEP_UP means the call was blocked and a named human authority can authorize it. A relying party must not read it as allowed.
• DEFER in cmcp today is classified but not asynchronously enforced: there is no callback registry, so a defer entry is a blocked call, not a pending one. If the spec permits defer, it should say whether it may ever mean "pending", because a verifier that assumes pending when the implementation means blocked would be wrong in the permissive direction. See cmcp's LIMITATIONS.md.

That second point is the one I would not leave to implementations to decide.

[lywinged]

We run the widened verb set in production (allow / deny / redact-modify / step-up / defer), so the narrowing this issue describes — step_up and defer collapsing to deny at the claim boundary — is losing exactly the events auditors ask about first. Two semantic positions from operating them, offered since the issue asks that implementations not decide these unilaterally:

STEP_UP: the escalation and its resolution are different receipts, and the resolution is three claims, not one. When the named authority authorizes, the record needs (a) approver identity resolved and frozen at emit time — we once shipped approval records carrying only an internal UUID; by audit time, answering "who is this?" required a live lookup against a mutable directory, i.e. the receipt's answer decayed; (b) the assurance tier of the approval (session token vs. platform biometric vs. hardware-backed with display attestation) — these carry different evidentiary weight and conflating them reproduces, at the human hand-off, the same category error the two-axis model in #66 fixes on the supply chain; (c) what the approver was shown, where display-integrity evidence exists. Each tier should claim only what it can support.

DEFER: must terminally resolve, and the resolution must be receipted. In our implementation defer = pause with a hard timeout, and every terminal state (resumed / expired / killed) emits its own receipt. Without a required terminal state, defer becomes a laundering verb — blocked actions recorded as eternally pending.

One more enum candidate while the profile is open: an observed-only marker for actions the governance layer saw but had no enforcement wire on. Real deployments have those surfaces; without the marker they either vanish from the record or masquerade as governed. "We saw it and could not have blocked it" is itself compliance evidence — and it is a different claim from n/a.