[pre-v1.0] Action receipt conformance cases for embodied-action evidence #95

Context

TRACE issue #66 defines verification.action_receipts as part of the pre-v1.0 verification-depth model. cMCP issue #337 and PR #392 explore an embodied-action evidence profile with static ROS 2-derived fixtures and verifier behavior.

The next useful step is to define conformance cases for action receipts, especially where the verifier must distinguish evidence integrity from physical-world completion or safety claims.

Proposal

Define a small conformance matrix for embodied-action receipt evidence.

Candidate cases:

• valid request receipt + valid controller outcome receipt
• missing request receipt
• missing outcome receipt
• mismatched action_ref / goal UUID / goal preimage hash
• signature/key mismatch
• stale or out-of-order receipt
• same-party self-report, reported with an issuer-independence warning
• valid negative controller outcome, such as rejected or aborted
• unsupported physical-completion claim

Non-goals

• no claim that TRACE proves physical completion
• no claim that controller success proves safety
• no live ROS 2 dependency in TRACE CI
• no new TRACE schema change unless maintainers think one is needed
• no product or vendor-specific positioning

Open Questions

• Should these conformance fixtures live in TRACE, cMCP, or both?
• What is the minimum pre-v1.0 set for action_receipts: required?
• Should ROS 2 remain fixture provenance, or become a named profile?
• Should issuer independence be reported as a separate verifier output from evidence proximity?