Tiny A2A task-lifecycle evidence sample from an external consumer

[Rul1an]

Hi all — we put together a very small sample on our side to test one honest external-evidence seam from A2A, and I wanted to share that rather than open with a broader protocol pitch.

The sample is here:
https://github.com/Rul1an/assay/tree/main/examples/a2a-task-evidence

It stays deliberately narrow. We start with task.requested and task.updated, keep route_ref only as a bounded observed reference when it is already naturally present, and freeze one success artifact, one failure artifact, and one malformed case. Those map into Assay-shaped placeholder evidence without treating A2A task outcomes, delegation correctness, or trust/accountability semantics as Assay truth.

We are not asking Assay to inherit protocol semantics, trust semantics, or runtime judgments as truth. The goal here is just to keep the seam small and see whether there is a clean external-consumer handoff at all.

If this is roughly the right direction, the main thing I’d love to understand is which A2A artifact or packet surface you would most want an external evidence consumer to align to as the smallest stable seam.

Happy to keep this small and follow your lead on the right boundary.

[aeoess]

@Rul1an — the smallest stable seam for an external evidence consumer is the authorization receipt.

Every evaluated action in APS produces a signed receipt:

{
  "action_ref": "sha256:abc...",
  "agent_id": "did:key:z6Mk...",
  "action_type": "task.execute",
  "scope": ["data:read"],
  "decision": "permit",
  "constraint_vector": { "max_spend": 100, "ttl": 3600 },
  "timestamp": "2026-04-07T12:00:00Z",
  "signature": "ed25519:..."
}

This maps to your Assay model: task.requested → the action_ref (content hash of the task input). task.updated → the receipt (signed evaluation outcome). The route_ref you mention as "bounded observed reference" maps to our delegation_hash — the chain that authorized this action.

The seam contract: if your evidence consumer can parse a JWS-signed JSON object with those fields, you can consume APS receipts without understanding delegation semantics, trust scoring, or enforcement internals. The receipt is the external-facing artifact. Everything behind it (delegation chains, scope narrowing, constraint evaluation) is internal.

For your three cases:

• Success artifact → receipt with decision: "permit", action completed
• Failure artifact → receipt with decision: "deny" + denial reason code
• Malformed case → receipt fails JWS signature verification (tampered payload)

The governance evidence export (createGovernanceEvidenceExport() in SDK v1.36.4) bundles receipts into a signed 9-section artifact for bulk consumption.

Happy to produce a test fixture mapping your three Assay cases to APS receipts — would confirm the seam works end-to-end.

SDK: npm install agent-passport-system (v1.36.4, 2,502 tests).