design: correction-aware supersession for delegated authority and pending action evidence

[moneyparking]

Problem

cA2A can establish that a delegation chain was structurally valid, attenuated, within its validity window, rooted in a trusted issuer, and authorized for a requested capability at an evaluation time. The ACTION fixtures tracked in #36 then distinguish provenance-invalid evidence, authorization-invalid evidence, and valid negative outcomes.

A different lifecycle boundary is not currently represented: an authoritative human/principal correction can make previously valid downstream authority, derived state, or a still-pending action no longer applicable without making the original evidence cryptographically invalid.

Example:

principal intent I0
  -> delegation D1
    -> delegation D2
      -> derived state S1
        -> pending action A1

later: authoritative correction C1 supersedes I0 -> I1

At the time D1/D2/A1 were authorized, their signatures, scope attenuation, timestamps, and policy checks may all have been correct. After C1, replaying only that historical evidence can still verify cleanly while answering the wrong present-tense question: whether A1 is still authorized/applicable under the principal's corrected intent.

This is not a request to make historical records mutable. A verifier should continue to be able to prove that a decision was valid under the evidence available at the time, while separately reporting that its authority or dependencies have since been superseded.

Why this appears distinct from current work

I reviewed current cA2A main at 52141e84e6bf8bd26f08d8e27e73ae707a9f95a3 and TRACE main at dba52b321359f21059f359bc6a8e219d6f5ef43e, including:

• test(conformance): add delegation-link action evidence fixtures #36: delegation-linked action evidence and the provenance / authorization / valid-negative-outcome split;
• cA2A delegation validity windows: time-bound use of a credential, not principal-driven semantic supersession;
• trace-spec#179: binding separately authorized pre-execution intent to runtime execution evidence;
• trace-spec#191: attributable human approval outcomes for step_up / defer;
• trace-spec#67 and Agent Manifest revocation work: revocation of keys/manifests/credentials, not dependency-aware invalidation after a correction to intent;
• agent-manifest#298: behavioral assessment of evolving memory checkpoints, which is a retrieval/memory boundary rather than delegated-authority applicability.

The missing question appears to be:

Given an authentic correction from the authority that established or approved an intent, which downstream evidence remains applicable, which is superseded, and which cannot be decided without reappraisal?

Requirements for a useful solution

I would start with requirements rather than a normative schema:

1. Corrections are new evidence, not edits. Historical delegation/action records remain verifiable as emitted.
2. Authority is explicit. A correction is signed by, or verifiably authorized by, the principal/authority allowed to supersede the referenced intent/decision.
3. The corrected object is cryptographically identified. Bind to a prior intent/decision/delegation-root digest or another stable evidence identifier, not a free-text description.
4. Dependency scope is explicit where known. A correction may identify affected delegation roots, action IDs, or state references. The verifier must not invent semantic dependencies that are absent from evidence.
5. Applicability is a separate axis from provenance. A record can remain provenance-valid while its current applicability becomes superseded or reappraisal_required.
6. Unknown impact fails visibly. If a correction is relevant but the evidence bundle does not establish whether a downstream artifact depends on the corrected object, report reappraisal_required / unverifiable, not valid by default.
7. Ordering is tamper-evident when available. For offline bundles, prefer a receipt/log/chain position already protected by the evidence system over relying solely on a producer-controlled wall clock.
8. No retroactive outcome claims. A correction after irreversible commit does not rewrite the historical execution result. It can affect future authority and can be evidence for remediation/compensation, which is outside this first profile.

Candidate detached artifact (informative only)

One possible shape for discussion:

{
  "type": "CorrectionReceipt/0.1",
  "correction_id": "corr-123",
  "principal_id": "spiffe://example.org/principal/alice",
  "supersedes": {
    "kind": "intent",
    "digest": "sha256:<64 hex>"
  },
  "replacement_digest": "sha256:<64 hex>",
  "scope": {
    "delegation_roots": ["sha256:<64 hex>"],
    "action_ids": ["action-42"],
    "state_refs": []
  },
  "effect": "invalidate_authority",
  "reason_digest": "sha256:<64 hex>",
  "ordering_ref": {
    "kind": "record_hash",
    "value": "sha256:<64 hex>"
  },
  "signature": "<detached signature>"
}

I do not propose these exact field names as settled vocabulary. A detached object may fit the existing PIC/TRACE bridge pattern better than adding fields to cA2A credentials, because credentials should remain immutable statements of what was delegated when issued.

Candidate verifier outcomes

On an independent correction/applicability axis:

not_applicable
superseded
reappraisal_required
post_commit_correction

These would compose with, rather than replace, #36's provenance / authorization / outcome classifications.

Initial conformance vectors

• CORR-001 — no applicable correction: previously valid pending action remains applicable.
• CORR-002 — authentic correction references an unrelated intent/root: action remains applicable.
• CORR-003 — authentic correction directly supersedes the intent bound to a pending action: superseded.
• CORR-004 — authentic correction references an ancestor delegation root explicitly listed as a dependency: descendant pending action is superseded.
• CORR-005 — relevant correction exists but dependency from corrected object to the pending action cannot be proven from the bundle: reappraisal_required, never silent valid.
• CORR-006 — correction signature or authority binding invalid: correction evidence is provenance-invalid and must not silently supersede valid historical authority.
• CORR-007 — correction is ordered after an irreversible committed action: historical execution remains valid evidence; applicability result is post_commit_correction for that action and future consequences are out of scope.
• CORR-008 — tampering with the referenced prior digest, scope, effect, or ordering reference invalidates the correction signature.

Placement question

I see three plausible homes:

1. cA2A owns a small correction/supersession companion profile because the primary effect is on delegated authority;
2. TRACE owns a detached correction/applicability artifact and cA2A consumes its verdict;
3. the PIC/TRACE intent bridge owns the correction event, while cA2A only defines how delegated descendants consume it.

My preference is to keep cA2A credentials unchanged and put correction evidence in a detached, separately versioned artifact, then make the applicability algorithm composable with cA2A action evidence. I would like maintainer guidance on the repository/container before proposing a normative diff.

If this direction fits, I can contribute the reference verifier and deterministic CORR vectors first, without changing cA2A's credential wire format.

Security / compatibility boundary

• No existing credential or TRACE record is reinterpreted as having been invalid at issuance.
• No semantic dependency is inferred from model reasoning or free-form text.
• An unverified correction cannot revoke authority.
• Absence of correction evidence means only "no correction was established from this evidence bundle," not "no correction exists anywhere."
• This profile would not prove that a human correction was wise/correct, only that an authorized correction was issued and how declared dependencies are evaluated against it.

AI assistance disclosure

OpenAI assisted with repository inspection, gap comparison, and draft wording. The finding was checked against the current public main commits and issues listed above before filing.

[moneyparking]

I published an executable reference prototype for this design boundary and kept it intentionally outside the installable EvidenceBound runtime while awaiting maintainer guidance on normative placement:

• merged research PR: research: prototype correction-aware delegated authority moneyparking/evidencebound-core#27
• design note: https://github.com/moneyparking/evidencebound-core/blob/main/docs/research/AGENTRUST_CORRECTION_EVIDENCE.md
• verifier: https://github.com/moneyparking/evidencebound-core/blob/main/tools/agentrust_correction_evidence.py
• vectors: https://github.com/moneyparking/evidencebound-core/blob/main/tests/test_agentrust_correction_evidence.py
• candidate schema: https://github.com/moneyparking/evidencebound-core/blob/main/docs/research/correction-receipt.schema.json

The prototype exercises 10 positive/adversarial cases, including direct correction, declared descendant scope, forged correction evidence, incomplete dependency evidence, post-commit correction, signed-body tampering, and unprovable relative ordering. Its final PR gate passed the repository CI matrix (Python 3.10-3.13 tests; on 3.13: golden acceptance, compileall, selective-recovery benchmark, Ruff, strict mypy, build/wheel import), plus clean-room, security, supply-chain, and Google ADK compatibility jobs.

I am still treating the wire vocabulary as informative. The open design question is unchanged: should the authoritative correction artifact live in cA2A, TRACE/PIC, or another companion profile, with cA2A defining only the descendant-applicability consumption rule? I will not propose a normative schema diff until that ownership boundary is clear.