3-Vendor Walkthrough

# Print the buyer-auditor proof package JSON to stdout:
cargo run --bin generate-chio-proof-package --quiet

# Write the full fixture corpus to a directory:
cargo run --bin generate-chio-proof-package --quiet -- --out-dir ./out

# Print the verifier report instead of the package:
cargo run --bin generate-chio-proof-package --quiet -- --report

# Regenerate the committed three-vendor fixtures:
cargo run --bin generate-chio-three-vendor-fixtures

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.federation.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.federation.governance-ladder-manifest.v1 manifests and reconcile them per the rules in the ladder spec (CHIO_LADDER.md section 6). The output is a pairwise chio.federation.ladder-intersection.v1 intersection record, co-signed by both kernels and stored alongside the FederationPeer record.

{
  "schema": "chio.federation.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: none of the three pairwise intersections in this fixture reference the verifier-owned workflow.grant_issue class the ladder spec defines (CHIO_LADDER.md section 5.2), so no cross-org co-signature covers it here (see gap G2).

Walkthrough

Six steps from BidRequest to settlement. Each step shows the wire-format records that cross the boundary, the guards each kernel runs, the consistency-model dispatch point, and where each record is added to 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 required for this class and the inner receipt alone is insufficient. The workflow receipt accumulates the wrapper’s SHA-256 in its steps[0].bilateral_dsse_sha256 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].bilateral_dsse_sha256; 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 into a single scope digest for this one call. It is the record backing the ladder’s partition_fallback.lease_kind: narrow_destructive knob, and its actionClass is narrow_destructive. The body below matches the CapabilityLeaseArtifact (camelCase wire fields); it is carried inside a signed export envelope (SignedCapabilityLease) that supplies the issuer key and signature.

{
  "schema": "chio.capability-lease.v1",
  "leaseId": "lease:payswift:refund:wf-001:c-001",
  "issuer": "did:chio:buyer-corp",
  "subject": "did:chio:buyer-corp:agent:support-orchestrator-1",
  "scopeDigest": "b2c58e91a0d4c7f3e6a9b1d8c2f5a0e3d7b4c1f8a5e2d9c6b3a0f7e4d1c8b5a2",
  "actionClass": "narrow_destructive",
  "issuedAtUnixMs": 1746360390000,
  "expiresAtUnixMs": 1746360510000
}

5b. Governance receipt

The intersected class declares evidence_required: [trust_activation, workflow_receipt, anchor_epoch, passport_presentation] — the evidence kinds a verifier must check against the workflow’s other artefacts. The governance receipt itself is a compact destructive-authorization artifact: Bee’s chio-governance kernel emits one GovernanceReceiptArtifact whose caseKind is destructive_authorization and which names the authorised capability lease, the workflow, and the exact step hash it authorises. Charlie’s kernel refuses the destructive call without it. The body below is carried inside a signed export envelope (SignedGovernanceReceipt).

{
  "schema": "chio.governance-receipt.v1",
  "receiptId": "gov:buyer:refund-authz:wf-001:c-001",
  "authorizingKernel": "did:chio:buyer-corp",
  "caseKind": "destructive_authorization",
  "authorizedLeaseId": "lease:payswift:refund:wf-001:c-001",
  "workflowId": "wfr:buyer:wf-001",
  "stepSha256": "c104a8b2d5e9f1c3a7b0e4d8f2a5c9e1b4d7f0a3c6e9b2d5f8a1c4e7b0d3f6a9",
  "issuedAtUnixMs": 1746360395000,
  "expiresAtUnixMs": 1746360515000
}

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 organization; this fixture uses the class bilateral_required for clarity. The fields below show the FROST signers 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. The quorum_signature block is illustrative: FROST-aggregated quorum signing is defined at the spec layer (CHIO_LADDER.md, CHIO_BILATERAL_COSIGN_INVOCATION.md) but has no implementation in any current Chio crate, so nothing emits this shape yet.

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...",
      "bilateral_dsse_sha256": "sha256:3f9a1c...",
      "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...",
      "bilateral_dsse_sha256": "sha256:7c2e4b...",
      "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...",
      "bilateral_dsse_sha256": "sha256:e1b8f0...",
      "governance_receipt_id": "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 in this fixture. The real WorkflowReceipt carries an optional vendor_signatures array for detached vendor co-signatures over the canonical body, but this walkthrough leaves it empty; per-step bilateral receipts hold the joint authorship (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.

The step records above match the real StepRecord shape in chio-workflow::receipt on step_index, server_id, tool_name, allowed, tool_receipt_id, outcome, duration_ms, cost, output_hash, bilateral_dsse_sha256, governance_receipt_id, parent_receipt_sha256, consistency_anchor, and destructive. Two details are illustrative extensions: on the real type consistency_anchor is an opaque string rather than the structured kind/value object shown here, and the trailing amount_minor, currency, and kyc_tier_at_time fields are walkthrough-only annotations.

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 bilateral_dsse_sha256, 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 authorization. Atlas verifies the governance receipt named by steps[2].governance_receipt_id: it confirms caseKind is destructive_authorization, that authorizedLeaseId matches the step’s capability lease, that stepSha256 matches the step-2 receipt hash, and that it has not expired. The intersected class’s evidence_required kinds (trust_activation, passport_presentation, workflow_receipt, anchor_epoch) are checked separately against the workflow’s other artefacts.
6. Verify ladder intersections. Atlas pulls all three chio.federation.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. This step is spec-only: no Chio crate implements FROST aggregation yet.
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 because categorical equality needs no predicate proof. 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

Re-audited against today’s crate set, the eleven gaps this fixture originally surfaced split three ways. Four are closed in code (G3, G4, G9, G10): the schemas and receipt fields the walkthrough needs now ship. One is closed at the spec layer but still code-partial (G6). The remaining six are soft gaps that weaken the audit record without blocking an end-to-end verification. The status column records which is which.

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. A third party can replay the aggregate receipt; per-step bilateral receipts record the signatures for each step.
• 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.