Design proposal: Embodied AI Evidence Profile for physical-action traces

[carloshvp]

Context

I would like to propose a focused design discussion for an Embodied AI Evidence Profile in cMCP/TRACE.

This builds on #301, where external_execution_evidence landed as an optional AuditEntry field for binding an independent issuer's signed assertion to a call. That first iteration established the right trust boundary: response_payload_hash remains "what the gateway forwarded", while external_execution_evidence is "what an independent authority attested".

The next question is whether cMCP/TRACE should define a small profile for embodied-agent workflows that composes that primitive with governance decision context, controller handoff metadata, and optional downstream receipts.

Why this matters

Embodied-agent workflows introduce a gap between:

• the governance decision that allows or denies a physical-action request,
• the tool or controller handoff that follows that decision, and
• any downstream receipt that claims what an external controller, monitor, or safety authority decided.

A governance layer can decide whether a physical-action request should be allowed, but it does not by itself prove what was sent to a controller, which policy/context was used, or how later receipts should be bound back to the original decision.

This proposal is intentionally scoped to evidence binding, not physical safety, hardware attestation, real-time control, or proof of physical completion.

Related work

• Bind independent safety-controller execution evidence into the audit chain (embodied agents, follow-up to #293) #301 added the first external_execution_evidence binding primitive for independent controller evidence.
• feat: add Nobulex — Ed25519 action receipts as external execution evidence integrations#6 demonstrated a concrete receipt-style integration using Nobulex.
• docs: add embodied action governance profile microsoft/agent-governance-toolkit#3181 frames the complementary decision-layer governance boundary for embodied action requests.

The distinction I am trying to preserve is:

• AGT / governance layer: decides whether a physical-action request should proceed under policy.
• cMCP / TRACE evidence layer: binds the request, decision context, handoff, and optional external receipts into an auditable chain.

Possible profile shape

A first profile could define how an embodied action trace binds fields such as:

• action_digest
• policy_version
• governance_decision
• approval_context
• controller_target
• handoff_timestamp
• external_execution_evidence
• receipt_digest
• receipt_type
• evidence_limitations

The goal would be to define the minimum useful evidence shape for verification without implying that cMCP observed physical execution or certified safety behavior.

Open questions

• Should this be a standalone TRACE profile, or an extension/profile of the existing external_execution_evidence field?
• What fields are minimally required for useful embodied-action verification?
• How should the profile represent missing, partial, stale, or untrusted downstream receipts?
• Should verifier behavior be specified here, or should this issue define only the evidence shape and leave verifier rules to a follow-up?
• Should controller/tool identity be linked through Agent Manifest identity binding when available?
• How should this profile avoid duplicating or overloading response_payload_hash?

Non-goals

• This does not make cMCP an actuation path.
• This does not claim functional-safety certification, IEC 61508 / ISO 13849 compliance, or physical outcome proof.
• This does not require every tool call to include a receipt.
• This does not replace Bind independent safety-controller execution evidence into the audit chain (embodied agents, follow-up to #293) #301; it would build on that landed primitive.

If maintainers think this direction fits the project, I am happy to draft a first profile sketch and keep it scoped to evidence semantics, verification boundaries, and compatibility with the existing audit model.

[carloshvp]

Opened a concrete draft profile PR for this discussion: #339.

The draft keeps v0.1 docs-only and builds on the existing external_execution_evidence envelope. It proposes:

• keeping linked_call_id tied to the cMCP audit call_id, not overloading it with controller-native IDs;
• carrying controller/native identifiers as action_ref inside the detached payload;
• using RFC3339 UTC string timestamps in the profile preimage to avoid timestamp type divergence;
• explicit verifier flow, receipt states, Agent Manifest identity checks, and non-goals around physical completion / safety certification.

I left it as a draft because this is intended to sharpen the design discussion, not declare the profile settled.