R5 makes tamper-evident receipts a Core MUST but leaves the receipt format entirely to each builder. That's the right call for flexibility, but it means two AARM-conformant systems can produce receipts no common verifier can check, and each builder re-solves canonicalization, digest binding, and third-party verifiability from scratch.
Suggestion: add non-normative guidance that R5 can be satisfied by existing verifiable-record work — e.g., anchoring receipts to a SCITT transparency service (RFC 9943) and/or using an established record profile such as draft-mih-scitt-agent-action-capsule, which already binds action, disposition, and outcome with frozen conformance vectors and two verifier implementations.
This keeps AARM defining the what while pointing builders at an interoperable how, and it gives the conformance evidence package something checkable. Happy to draft the paragraph if the TWG wants it.
R5 makes tamper-evident receipts a Core MUST but leaves the receipt format entirely to each builder. That's the right call for flexibility, but it means two AARM-conformant systems can produce receipts no common verifier can check, and each builder re-solves canonicalization, digest binding, and third-party verifiability from scratch.
Suggestion: add non-normative guidance that R5 can be satisfied by existing verifiable-record work — e.g., anchoring receipts to a SCITT transparency service (RFC 9943) and/or using an established record profile such as draft-mih-scitt-agent-action-capsule, which already binds action, disposition, and outcome with frozen conformance vectors and two verifier implementations.
This keeps AARM defining the what while pointing builders at an interoperable how, and it gives the conformance evidence package something checkable. Happy to draft the paragraph if the TWG wants it.