3-Vendor Walkthrough

End-to-end worked scenario. One buyer composes agents from three vendors and asks an auditor to verify every cross-vendor action without trusting any of them unilaterally. This page is the flagship demo for the Swarms section: every wire artefact, every guard, every signature is shown.

Cast

• Buyer (Bee). Buyer Corp. Owns the workflow root, holds the audit obligation, signs the aggregate workflow receipt.
• Vendor A (Alpha). DataCo. Customer-record provider; tool customer_record.read.
• Vendor B (Bravo). LlamaWorks. LLM drafting provider; tool draft.support_response.
• Vendor C (Charlie). PaySwift. Payments provider; tool refund.execute.
• Auditor (Atlas). Buyer Corp Compliance. Verifies the trail under selective disclosure, without trusting any of A, B, C unilaterally.

Setup

Bee, Alpha, Bravo, and Charlie each operate a Chio kernel. Before the workflow runs, three bilateral handshakes occur (Bee with each vendor). Each handshake produces two artefacts that sit alongside the pinned FederationPeer record: a passport-pinned envelope, and a co-signed chio.chiodos-ladder-intersection.v1 manifest.

Handshake envelope

The handshake (Bee to Alpha; symmetric in reverse) exchanges PeerHandshakeEnvelope challenges as defined in chio-federation::trust_establishment. Each side pins the other’s declared passport key and seeds the rotation window (default 12h).

{
  "challenge": {
    "schema": "chio.federation-kernel-handshake.v1",
    "localKernelId": "did:chio:buyer-corp",
    "remoteKernelId": "did:chio:dataco",
    "nonce": "9c8a4f2e6d1b47a0b3e5f6c7d8e9f0a1",
    "timestamp": 1746360000
  },
  "declaredPublicKey": "ed25519:0xBUYER_CORP_PUB",
  "signature": "ed25519:0xBUYER_CORP_HANDSHAKE_SIG"
}

Ladder intersection (co-signed body)

Immediately after the envelope verifies, both kernels exchange chio.chiodos-ladder.v1 manifests and reconcile them per the rules in CHIODOS_LADDER section 6. The output is a pairwise chio.chiodos-ladder-intersection.v1 artefact, co-signed by both kernels and stored alongside the FederationPeer record.

{
  "schema": "chio.chiodos-ladder-intersection.v1",
  "intersection_id": "buyer-payswift.support-ops.2026-05-04",
  "treaty_scope": "treaty:buyer-payswift:support-ops",
  "left_manifest": {
    "manifest_id": "buyer.support-ops.ladder.2026-05-04",
    "participant_id": "did:chio:buyer-corp",
    "ladder_version": "1.0.0",
    "sha256": "1111aa..."
  },
  "right_manifest": {
    "manifest_id": "payswift.financial.ladder.2026-05-04",
    "participant_id": "did:chio:payswift",
    "ladder_version": "1.0.0",
    "sha256": "2222bb..."
  },
  "destructive_floor": "receipt_backed",
  "intersected_classes": [
    {
      "intersected_id": "payments.refund_execute",
      "left_id": "payments.refund_execute",
      "right_id": "payments.refund_execute",
      "mode": "receipt_backed",
      "co_sign": "bilateral_required",
      "consistency_model": "totally-ordered"
    }
  ],
  "produced_at": 1746360120,
  "co_signature": {
    "left":  { "signer_key": "ed25519:0xBUYER_CORP_PUB", "alg": "ed25519", "value": "ed25519:0xINT_LEFT_SIG" },
    "right": { "signer_key": "ed25519:0xPAYSWIFT_PUB",  "alg": "ed25519", "value": "ed25519:0xINT_RIGHT_SIG" }
  }
}

The Buyer to DataCo intersection covers data.customer_record_read; the Buyer to LlamaWorks intersection covers llm.draft_support_response. Three intersections, one per pair, each pinning a single action-class id with co_sign: bilateral_required.

Workflow grant

Bee’s WorkflowAuthority (in chio-workflow::authority) mints a workflow grant that binds the three open-market CapabilityToken ids from the AcceptedBids into one workflow root. The grant is scoped to skill buyer.support-ticket-refund-flow and budgets the entire run at 100 USD across the three steps. Authority for the grant is locally signed only (no intersection covers a workflow.grant_issue class today; see gap G2).

Walkthrough

Six steps from BidRequest to settlement. Each step shows the wire-format artefacts that cross the boundary, the guards each kernel runs, the consistency-model dispatch point, and where each artefact accumulates into the workflow receipt.

1. BidRequest, AskResponse, AcceptedBid

Bee posts one chio.marketplace.bid-request.v1 per vendor under the support-ticket-fulfillment namespace (handled by chio-open-market::bidding). Each vendor responds with a signed chio.marketplace.ask-response.v1 that carries an inline tokenOffer: a capability token whose subject is Bee’s agent passport key and whose scope names the exact tool. Bee returns one chio.marketplace.accepted-bid.v1 per vendor; the AcceptedBid is the binding event that materialises the token.

{
  "schema": "chio.marketplace.ask-response.v1",
  "listingId": "listing:payswift:refund.execute:v1",
  "agentId": "did:chio:buyer-corp:agent:support-orchestrator-1",
  "bidDigest": "sha256:bid-buyer-payswift-001",
  "quotedPrice": { "units": 30, "currency": "USD" },
  "tokenOffer": {
    "id": "cap:payswift:refund:wf-001:001",
    "subject": "ed25519:0xBUYER_AGENT_PUB",
    "scopes": ["tool:payswift:refund.execute:tier2-le-25000c"],
    "issuedAt": 1746360305,
    "expiresAt": 1746360905,
    "issuer": "ed25519:0xPAYSWIFT_PUB",
    "signature": "ed25519:0xPAYSWIFT_TOKEN_SIG"
  },
  "issuedAt": 1746360305,
  "expiresAt": 1746360905
}

Token attenuation is already cross-org at this point: the scope tool:payswift:refund.execute:tier2-le-25000c names Charlie’s tool, the KYC tier ceiling, and the amount cap in cents. The AcceptedBid receipt accumulates as the first entry under the workflow root in Bee’s receipt store.

2. Workflow plan and skill manifest

Bee’s WorkflowAuthority emits a chio.skill-manifest.v1 that declares the three steps in order, with input and output contracts and a budget envelope. The skill manifest is the authoritative declaration of the workflow shape; the workflow grant references it by id.

{
  "schema": "chio.skill-manifest.v1",
  "skill_id": "buyer.support-ticket-refund-flow",
  "version": "1.0.0",
  "name": "Support ticket triage with refund",
  "steps": [
    { "step_index": 0, "server_id": "dataco.crm-server", "tool_name": "customer_record.read",
      "input_contract": { "required_fields": ["ticket_id"] },
      "output_contract": { "produced_fields": ["customer_record"] } },
    { "step_index": 1, "server_id": "llamaworks.draft-server", "tool_name": "draft.support_response",
      "input_contract": { "required_fields": ["customer_record", "ticket_id"] },
      "output_contract": { "produced_fields": ["draft_response", "anomaly_signal"] } },
    { "step_index": 2, "server_id": "payswift.refund-server", "tool_name": "refund.execute",
      "input_contract": { "required_fields": ["customer_record", "draft_response"] },
      "output_contract": { "produced_fields": ["refund_id"] } }
  ],
  "budget_envelope": { "units": 100, "currency": "USD" },
  "max_duration_secs": 120
}

Per the buyer-side ladder, every step inherits a consistency_model declaration: steps 0 and 1 are totally-ordered with a hash-chain anchor; step 2 is totally-ordered with a chio-anchor anchor (the destructive class is held to a stricter consistency floor). The consistency model is read out at every cross-org boundary to decide which kind of value lands in parent_receipt_sha256 on the child step.

3. Step 0: customer_record.read at Alpha

Bee’s agent invokes dataco.crm-server.customer_record.read. Alpha’s kernel runs its guard pipeline against the inbound request: capability chain validation (token issuer recognised, not expired, scope matches), ladder intersection lookup (yes, data.customer_record_read is in the Buyer to DataCo intersection), revocation freshness (no entry pinned against the lease), and source-diversity caps. Alpha signs first, then asks Bee’s kernel to co-sign. The result body is signed by Alpha only; the dual-signed wrapper binds both kernels to the invocation event.

{
  "schema": "chio.receipt.v1",
  "id": "rcpt:dataco:wf-001:step0",
  "issued_at": 1746360315,
  "agent_id": "did:chio:buyer-corp:agent:support-orchestrator-1",
  "tool_invocation": {
    "server_id": "dataco.crm-server",
    "tool_name": "customer_record.read",
    "args_hash": "sha256:7a1d...",
    "result_hash": "sha256:b9e0..."
  },
  "capability_id": "cap:dataco:customer_record:wf-001:001",
  "workflow_grant_id": "wfg:buyer:wf-001",
  "parent_receipt_id": null,
  "consistency_anchor": { "kind": "hash-chain", "value": null },
  "kernel_key": "ed25519:0xDATACO_PUB",
  "signature": "ed25519:0xDATACO_RECEIPT_SIG"
}

parent_receipt_id is null because step 0 is the first step in the workflow; the hash-chain accumulator opens here. The dual-signed wrapper is what the workflow receipt actually points at:

{
  "schema": "chio.federation-dual-signed-receipt.v1",
  "body": { "...": "the ChioReceipt above..." },
  "orgAKernelId": "did:chio:buyer-corp",
  "orgBKernelId": "did:chio:dataco",
  "orgASignature": "ed25519:0xBUYER_COSIGN_SIG_S0",
  "orgBSignature": "ed25519:0xDATACO_COSIGN_SIG_S0"
}

Both signatures are over the canonical bytes of the CoSigningBody defined in chio-federation::bilateral. Either side can independently verify with DualSignedReceipt::verify; because the intersected class names co_sign: bilateral_required, the wrapper is the load-bearing artefact and the inner receipt alone is insufficient. The workflow receipt accumulates the wrapper’s SHA-256 in its steps[0].dual_signed_receipt_ref field.

4. Step 1: draft.support_response at Bravo

Bravo consumes the customer_record field produced by step 0. Bravo’s kernel runs the same guard pipeline (capability chain, ladder intersection for llm.draft_support_response, revocation freshness, plus the prompt-safety guard family). The critical new wire field is the hash-chain anchor: parent_receipt_sha256 carries the SHA-256 of the step 0 dual-signed wrapper, and consistency_anchor.value repeats it under the hash-chain kind. The consistency-model dispatch happens here: because the class is declared totally-ordered with anchor hash-chain, Bravo’s kernel refuses to sign until the parent SHA matches the step 0 wrapper Bravo independently fetched from Bee’s store.

{
  "schema": "chio.receipt.v1",
  "id": "rcpt:llamaworks:wf-001:step1",
  "issued_at": 1746360355,
  "agent_id": "did:chio:buyer-corp:agent:support-orchestrator-1",
  "tool_invocation": {
    "server_id": "llamaworks.draft-server",
    "tool_name": "draft.support_response",
    "args_hash": "sha256:c4f1...",
    "result_hash": "sha256:d23e..."
  },
  "capability_id": "cap:llamaworks:draft:wf-001:001",
  "workflow_grant_id": "wfg:buyer:wf-001",
  "parent_receipt_id": "rcpt:dataco:wf-001:step0",
  "parent_receipt_sha256": "sha256:88e0...",
  "consistency_anchor": { "kind": "hash-chain", "value": "sha256:88e0..." },
  "lineage_step_index": 1,
  "kernel_key": "ed25519:0xLLAMAWORKS_PUB",
  "signature": "ed25519:0xLLAMAWORKS_RECEIPT_SIG"
}

The dual-signed wrapper has the same shape as step 0’s with orgBKernelId: did:chio:llamaworks and the corresponding step-1 signatures. The wrapper’s SHA-256 lands in the workflow receipt under steps[1].dual_signed_receipt_ref; Bravo simultaneously emits a pheromone deposit if it detects prompt-injection patterns in the customer ticket text (covered in step 6).

5. Step 2: refund.execute at Charlie

Charlie’s tool is destructive. The intersected class is payments.refund_execute with mode receipt_backed, destructive: true, and consistency_anchor: chio-anchor. Three artefacts mesh together at this boundary: a capability lease that narrows the minted token to this single call, a governance receipt from Bee’s kernel authorising the destructive action, and the bilateral dual-signed invocation receipt.

5a. Capability lease

The lease pins the amount, currency, and customer-id hash to this single call. It is the artefact backing the ladder’s partition_fallback.lease_kind: narrow_destructive knob.

{
  "schema": "chio.capability-lease.v1",
  "lease_id": "lease:payswift:refund:wf-001:c-001",
  "token_id": "cap:payswift:refund:wf-001:001",
  "agent_id": "did:chio:buyer-corp:agent:support-orchestrator-1",
  "narrowed_scopes": [
    "tool:payswift:refund.execute:amount_minor=24999:currency=USD:customer_id_hash=sha256:abc..."
  ],
  "issued_at": 1746360390,
  "expires_at": 1746360510,
  "kernel_key": "ed25519:0xBUYER_CORP_PUB",
  "signature": "ed25519:0xBUYER_LEASE_SIG"
}

5b. Governance receipt

The intersected class declares evidence_required: [trust_activation, workflow_receipt, anchor_epoch, passport_presentation]. Bee’s chio-governance kernel materialises one governance receipt that bundles all four evidence kinds. Charlie’s kernel refuses the call without it.

{
  "schema": "chio.governance-receipt.v1",
  "id": "gov:buyer:refund-authz:wf-001:c-001",
  "case_kind": "destructive_authorization",
  "subject": {
    "kernel_id": "did:chio:payswift",
    "tool": "refund.execute",
    "amount_minor": 24999,
    "currency": "USD"
  },
  "evidence": [
    { "kind": "trust_activation",       "ref": "trust:buyer:dataco:tier2-confirmed:1746360320" },
    { "kind": "passport_presentation",  "ref": "pp:buyer:agent-1:tier2:1746360318" },
    { "kind": "workflow_receipt",       "ref": "wfr:buyer:wf-001:partial:step1" },
    { "kind": "anchor_epoch",           "ref": "anchor:buyer:epoch-2026-05-04T00:00Z:#7341" }
  ],
  "issued_at": 1746360395,
  "kernel_key": "ed25519:0xBUYER_CORP_PUB",
  "signature": "ed25519:0xBUYER_GOV_SIG"
}

5c. Settlement receipt and FROST-aggregated quorum signature

Charlie’s kernel runs the destructive-tool guard pipeline (egress allowlist, blast-radius caps, the lease-narrowness check, and the destructive-floor check that mode == receipt_backed is satisfied by the inbound governance receipt). For quorum-required consistency the ladder demands a FROST-aggregated quorum signature inside Charlie’s organisation; even though this fixture keeps the class at bilateral_required for legibility, the field shape below shows how the FROST signers appear when co_sign: n_of_m is in effect on a destructive class.

{
  "schema": "chio.receipt.v1",
  "id": "rcpt:payswift:wf-001:step2",
  "issued_at": 1746360400,
  "agent_id": "did:chio:buyer-corp:agent:support-orchestrator-1",
  "tool_invocation": {
    "server_id": "payswift.refund-server",
    "tool_name": "refund.execute",
    "args_hash": "sha256:e9a4...",
    "result_hash": "sha256:f2c1..."
  },
  "capability_id": "cap:payswift:refund:wf-001:001",
  "lease_id": "lease:payswift:refund:wf-001:c-001",
  "governance_receipt_id": "gov:buyer:refund-authz:wf-001:c-001",
  "workflow_grant_id": "wfg:buyer:wf-001",
  "parent_receipt_id": "rcpt:llamaworks:wf-001:step1",
  "parent_receipt_sha256": "sha256:c1d4...",
  "consistency_anchor": { "kind": "chio-anchor", "value": "anchor:buyer:epoch-2026-05-04T00:00Z:#7341" },
  "lineage_step_index": 2,
  "destructive": true,
  "outcome": {
    "refund_id": "refund:payswift:R-2026-05-04-89421",
    "amount_minor": 24999,
    "currency": "USD",
    "kyc_tier_at_time": "tier2"
  },
  "kernel_key": "ed25519:0xPAYSWIFT_PUB",
  "signature": "ed25519:0xPAYSWIFT_RECEIPT_SIG",
  "quorum_signature": {
    "scheme": "frost-ed25519",
    "threshold": "2-of-3",
    "group_pub": "ed25519:0xPAYSWIFT_QUORUM_GROUP_PUB",
    "aggregated_signature": "ed25519:0xPAYSWIFT_QUORUM_AGG_SIG",
    "signer_set_digest": "sha256:fa00..."
  }
}

The aggregated FROST signature verifies under the single group public key; downstream verifiers do not see which subset of the signer set produced it, only that the threshold was met. The consistency_anchor.value is now an anchor-epoch id rather than a parent SHA: the destructive class crosses into Bee’s anchored epoch, so Atlas can re-derive the epoch root independently and pin step 2 against it.

6. Workflow finalisation and aggregate receipt

Bee’s WorkflowAuthority builds the final chio.workflow-receipt.v1 and signs it with the buyer kernel key. Each step record points at its dual-signed wrapper, carries the parent SHA, and (for step 2) carries the governance receipt id, the lease id, the destructive flag, the amount, currency, and KYC tier at time of action.

{
  "id": "wfr:buyer:wf-001",
  "schema": "chio.workflow-receipt.v1",
  "started_at": 1746360300,
  "completed_at": 1746360410,
  "skill_id": "buyer.support-ticket-refund-flow",
  "skill_version": "1.0.0",
  "agent_id": "did:chio:buyer-corp:agent:support-orchestrator-1",
  "session_id": "sess:buyer:support-2026-05-04-001",
  "capability_id": "wfg:buyer:wf-001",
  "outcome": { "status": "completed" },
  "steps": [
    {
      "step_index": 0, "server_id": "dataco.crm-server", "tool_name": "customer_record.read",
      "allowed": true, "tool_receipt_id": "rcpt:dataco:wf-001:step0", "outcome": "success",
      "duration_ms": 240, "cost": { "units": 5, "currency": "USD" }, "output_hash": "sha256:b9e0...",
      "dual_signed_receipt_ref": "dsr:buyer-dataco:wf-001:step0",
      "parent_receipt_sha256": null,
      "consistency_anchor": { "kind": "hash-chain", "value": null }
    },
    {
      "step_index": 1, "server_id": "llamaworks.draft-server", "tool_name": "draft.support_response",
      "allowed": true, "tool_receipt_id": "rcpt:llamaworks:wf-001:step1", "outcome": "success",
      "duration_ms": 1820, "cost": { "units": 18, "currency": "USD" }, "output_hash": "sha256:d23e...",
      "dual_signed_receipt_ref": "dsr:buyer-llamaworks:wf-001:step1",
      "parent_receipt_sha256": "sha256:88e0...",
      "consistency_anchor": { "kind": "hash-chain", "value": "sha256:88e0..." }
    },
    {
      "step_index": 2, "server_id": "payswift.refund-server", "tool_name": "refund.execute",
      "allowed": true, "tool_receipt_id": "rcpt:payswift:wf-001:step2", "outcome": "success",
      "duration_ms": 940, "cost": { "units": 30, "currency": "USD" }, "output_hash": "sha256:f2c1...",
      "dual_signed_receipt_ref": "dsr:buyer-payswift:wf-001:step2",
      "governance_receipt_ref": "gov:buyer:refund-authz:wf-001:c-001",
      "parent_receipt_sha256": "sha256:c1d4...",
      "consistency_anchor": { "kind": "chio-anchor", "value": "anchor:buyer:epoch-2026-05-04T00:00Z:#7341" },
      "destructive": true, "amount_minor": 24999, "currency": "USD", "kyc_tier_at_time": "tier2"
    }
  ],
  "total_cost": { "units": 53, "currency": "USD" },
  "duration_ms": 110000,
  "kernel_key": "ed25519:0xBUYER_CORP_PUB",
  "signature": "ed25519:0xBUYER_WF_SIG"
}

The aggregate is signed by Bee’s kernel only. Per-step bilateral receipts have joint authorship, but the aggregate does not (gap G5). The aggregate receipt is the joint cognition unit that Atlas walks during the audit, and the unit that BBS+ projects over in step 7.

Workflow receipt structure

The workflow receipt is a tree: the buyer-signed root at the top, three step records as children, each step record pointing sideways at its dual-signed wrapper (which itself sits in each peer kernel’s store). Step 2 also points at the governance receipt and the capability lease.

Two structural invariants the diagram exercises: vertical lineage (each child step pins the parent step’s SHA, so any reordering breaks the chain), and horizontal redundancy (each dual-signed wrapper exists in both kernels’ stores; Atlas can pull from either side and the canonical bytes match).

Audit by Atlas

Atlas (Buyer Corp Compliance) needs to verify a single end-to-end claim: refund <= $250 was issued to a verified KYC-tier-2 customer. Customer PII stays withheld. The procedure below walks the workflow without trusting any of A, B, C unilaterally and ends with a BBS+ disclosure that exposes only the predicate proof.

Eight-step verification procedure

1. Pull the aggregate. Atlas fetches wfr:buyer:wf-001 from Bee’s receipt store and verifies its Ed25519 signature against the pinned buyer-kernel public key.
2. Verify each dual-signed wrapper. For each step, Atlas dereferences dual_signed_receipt_ref, fetches the wrapper from either Bee’s store or the peer’s, and runs DualSignedReceipt::verify against both pinned FederationPeer records.
3. Recompute the hash chain. For step 1 and step 2, Atlas recomputes parent_receipt_sha256 from the parent dual-signed wrapper’s canonical bytes and asserts the value matches the field in the inner receipt and the workflow-receipt step record.
4. Resolve the chio-anchor. For step 2, Atlas resolves the consistency_anchor.value (an anchor-epoch id) against Bee’s checkpoint manifest and confirms the inner receipt’s SHA-256 sits in the anchored Merkle root.
5. Walk the governance bundle. Atlas verifies the governance receipt named by steps[2].governance_receipt_ref and confirms its evidence array contains all four kinds named in the intersected class: trust_activation, passport_presentation, workflow_receipt, anchor_epoch.
6. Verify ladder intersections. Atlas pulls all three chio.chiodos-ladder-intersection.v1 artefacts, verifies the co-signatures, and confirms each step’s action-class id sits in the right intersection’s intersected_classes list.
7. Cross-check the FROST quorum. For step 2, Atlas verifies the FROST-aggregated quorum_signature under the named group public key. The verification is a single Ed25519 check over the aggregated signature; the signer-set digest is recorded but the participating subset stays opaque.
8. Request a BBS+ disclosure. To prove the amount-cap predicate without revealing PII or the draft body, Atlas issues a disclosure request against the buyer’s BBS+ signer. The shape is below.

BBS+ disclosure request

Atlas asks for the workflow receipt projected through a BBS+ secondary signature, with the settlement-amount-cap predicate proven and everything else withheld.

{
  "schema": "chio.workflow-receipt-bbs-disclosure-request.v1",
  "subject_workflow_receipt_id": "wfr:buyer:wf-001",
  "requested_disclosed_fields": [
    "schema",
    "skill_id",
    "outcome.status",
    "steps[2].server_id",
    "steps[2].tool_name",
    "steps[2].destructive",
    "steps[2].currency",
    "steps[2].kyc_tier_at_time"
  ],
  "requested_predicate_proofs": [
    {
      "predicate": "RangeStatement",
      "field": "steps[2].amount_minor",
      "operator": "<=",
      "value": 25000
    }
  ],
  "requestor": "did:chio:buyer-corp-compliance",
  "issued_at": 1746360500
}

BBS+ disclosure response

Bee returns the projected envelope. The Ed25519 signature on the aggregate workflow receipt remains authoritative; the BBS+ proof is a secondary commitment that lets the disclosure envelope stand alone for verifiers who never see the workflow receipt body.

{
  "schema": "chio.workflow-receipt-bbs-disclosure.v1",
  "subject_workflow_receipt_id": "wfr:buyer:wf-001",
  "subject_workflow_receipt_sha256": "sha256:9ce4...",
  "issuer_kernel_id": "did:chio:buyer-corp",
  "bbs_messages_projection_version": 1,
  "disclosed_fields": {
    "schema": "chio.workflow-receipt.v1",
    "skill_id": "buyer.support-ticket-refund-flow",
    "outcome.status": "completed",
    "steps[2].server_id": "payswift.refund-server",
    "steps[2].tool_name": "refund.execute",
    "steps[2].destructive": true,
    "steps[2].currency": "USD",
    "steps[2].kyc_tier_at_time": "tier2"
  },
  "predicate_proofs": [
    {
      "predicate": "RangeStatement",
      "field": "steps[2].amount_minor",
      "operator": "<=",
      "value": 25000
    }
  ],
  "withheld_fields": [
    "agent_id",
    "session_id",
    "steps[0].*",
    "steps[1].*",
    "steps[2].tool_invocation.args_hash",
    "steps[2].tool_invocation.result_hash",
    "steps[2].outcome.refund_id",
    "steps[2].output_hash"
  ],
  "anchor_epoch": "anchor:buyer:epoch-2026-05-04T00:00Z:#7341",
  "bbs_secondary_signature": {
    "issuer_bbs_pub": "bls12-381:0xBUYER_BBS_PUB",
    "proof": "bbs-proof:0xPROOF_BLOB"
  },
  "ed25519_authoritative_signature_ref": "ed25519:0xBUYER_WF_SIG"
}

The KYC tier is disclosed verbatim (categorical equality, no predicate machinery needed). The amount cap is a RangeStatement predicate proof: Atlas learns that amount_minor <= 25000 without learning the exact amount. The customer record from step 0 and the draft body from step 1 are withheld in their entirety.

Gap analysis: G1 through G11

Running the fixture against today’s crate set surfaces eleven concrete gaps. Each is a wire- or schema-level mesh failure where an artefact required by the worked walkthrough has no canonical home. The load-bearing column flags whether the gap blocks an end-to-end verification (yes) or merely weakens the audit story (no).

What this fixture validates

The walkthrough exercises six protocol invariants that together define the cross-vendor agent action attestation surface:

• Capability attenuation across orgs. The token offered by Charlie is scoped to a single tool, a single tier, a single amount cap; the lease narrows it further to one customer-id hash. No widening occurs across the chain.
• Ladder intersection at handshake. Three pairwise intersections are computed before the workflow runs; every cross-org action references the intersection that authorised it.
• Bilateral co-sign at action time. Every cross-org boundary produces a chio.federation-dual-signed-receipt.v1; the inner receipt alone is insufficient when the intersected class names co_sign: bilateral_required.
• Consistency-model dispatch. Each step reads its consistency_model declaration and writes the matching anchor value: hash-chain SHA for steps 0 and 1, chio-anchor epoch id for step 2.
• Workflow receipt as joint cognition unit. The aggregate receipt is the artefact a third party replays end-to-end; per-step bilateral receipts are the atoms of joint authorship.
• BBS+ projection over destination receipts. The auditor proves a predicate on a nested step field (steps[2].amount_minor) without revealing the body, and without materialising PII from the upstream steps.