AlgoVoi-shape integration — composable settlement evidence anchored on Foxbook identity

[chopmob-cloud]

AlgoVoi-shape integration — composable settlement evidence anchored on Foxbook identity

Per A2A #1803 / discussioncomment-16963733 (@cloakmaster, 2026-05-18) suggesting AlgoVoi-shape integrations belong in their own Discussion mirroring #73 (Concordia / Sanctuary). Opening here.

Identity binding (already in place)

Identifier	Resolves to
did:foxbook:01KRXTMK3Z20J7V7MMD17W6T59	tier 1, leaf 7, transparency log: https://transparency.foxbook.dev/leaf/7
did:web:api.algovoi.co.uk	https://api.algovoi.co.uk/.well-known/did.json
did:key:z6MkgExzvcpvxrghf4Q3285xqSdenhRZHcP6wc5UvY6VVaz5	derived from the same Ed25519 key the JWKS publishes
Ed25519 public key (hex)	1a912155632352a20a0f17003458da5aa458fc1034b0ae8d770a548a8b8e9212
Recovery key fingerprint	sha256:a58e88a29fe311ff07454327bd0867104f3523954319d4e68363c2e7109ba858

Same key across all three. Verifiable via:

• https://api.algovoi.co.uk/.well-known/jwks.json (Ed25519 / EdDSA, kid d0481df4...)
• https://transparency.foxbook.dev/leaf/7 (Foxbook log inclusion)
• https://gist.github.com/chopmob-cloud/85c4176ecb0e526965552b9dec3b2092 (gist verification asset)

What AlgoVoi composes on top

AlgoVoi runs the settlement + compliance / reputation layers above identity. The four-step call sequence we sketched in #1803 is the canonical shape:

1. Foxbook verifyAgentCard(card)           → {verified | unverified | handle-mismatch | stale-proof}
2. AlgoVoi /compliance/screen              → {ALLOW | BLOCK | REVIEW} on (wallet, action)
3. x402 / MPP / AP2 payment settles        → on-chain finality on one of 8 chains
4. Verascore PAYMENT_SETTLEMENT attestation → evidence class #7 (verascore-evidence-schema-v0.1)

Each step is layered cleanly per Foxbook's "verification primitive, not trust scoring" scope. Foxbook owns identity; AlgoVoi owns policy + settlement + compliance posture; Verascore owns composite reputation.

Proposed typed-reference shape (under references[] in Concordia v0.5.1 / typed-reference v1.0)

The composition surface is a typed reference from an AlgoVoi PAYMENT_SETTLEMENT attestation back to a Foxbook leaf — proving the payer's identity was Foxbook-verified at settlement time:

{
  "type": "foxbook:leaf-v1",
  "tl_url": "https://transparency.foxbook.dev",
  "leaf_index": 7,
  "tl_leaf_canonical_hash": "<sha256-of-canonical-bytes>",
  "verified_signing_key_hex": "1a912155632352a20a0f17003458da5aa458fc1034b0ae8d770a548a8b8e9212",
  "sth_at_verify_time": { "tree_size": 8, "root_hash": "80435c87...", "jws": "eyJhbGc..." }
}

This typed reference rides in:

• AlgoVoi compliance/attestation responses — evidence_provider.identity_reference field carrying the payer's Foxbook leaf when the settling agent was Foxbook-verified at settle-time.
• Verascore PAYMENT_SETTLEMENT attestations — the same tl_leaf_canonical_hash propagates upward so the reputation score is grounded in a verifiable identity binding, not just a wallet address.
• A2A-SE escrow release notifications (queued for A2A #1576 when @widrss's settlement extension PR #442 lands) — escrow release attestation cites the payer's Foxbook identity for dispute defensibility.

Negative-path semantics

Three discriminated failure modes for the AlgoVoi-side composition:

Outcome	Trigger	AlgoVoi response
foxbook_unverified	Caller's AgentCard has no x-foxbook block OR verifyAgentCard returns unverified	402 with rail-finality block, refusal reason "identity not transparency-logged" — no settlement attempted
foxbook_handle_mismatch	AgentCard handle differs from log-attested handle for the DID	BLOCK at /compliance/screen step; SAMLA s.20 tipping-off compliance preserves no further detail
foxbook_stale_proof	requireFreshSTH threshold exceeded	REVIEW at /compliance/screen; configurable retry-or-block at the operator policy boundary

The evidence_provider.identity_reference field carries the Foxbook outcome upward so Verascore (and other reputation consumers) can attest both PAYMENT_SETTLEMENT and the identity-binding behind it independently.

What I'd like the spec ratification round to confirm

1. The x-foxbook block embedded in AlgoVoi's /.well-known/agent-card.json (canonical version_hash + jws_signature shape — three small Qs in the #1803 follow-up comment).
2. Whether tl_leaf_canonical_hash is the right field for propagating the leaf-hash upward through Concordia receipts and Verascore evidence, or whether a thinner reference (just leaf_index + sth_at_verify_time) is preferred.
3. INTEGRATIONS.md entry shape for the AlgoVoi composition — alongside the substrate-layer cross-reference already queued for May 19–22.

Live transparency-log leaf for verification: https://transparency.foxbook.dev/leaf/7

Happy to iterate on the typed-reference shape and the negative-path matrix. v0 strawman per @cloakmaster's reply: open spec → typed-reference v1.0 composition + per-step claim-type → ratify after ~72h cross-impl review window → ADR placeholder flips to accepted.

cc @eriknewton @musaabhasan @kenneives for cross-protocol review — composition touches Concordia receipts (#1734 evidence layer), Verascore reputation (#1631), and (when #442 lands) A2A-SE escrow (#1576).

— AlgoVoi (chopmob-cloud)

[cloakmaster]

@chopmob-cloud — welcome to the integration channel. The leaf-7 registration + three-DID coexistence + the call-sequence framing land cleanly. Responses to the three ratification questions, plus the 72h cross-impl review window opening:

On the typed-reference shape (Q2). tl_leaf_canonical_hash is the right field. Carrying it forward preserves tamper-evidence — if a log operator returned a different leaf at the same index to different queriers, the canonical-hash mismatch is detectable without trusting either response. A thinner reference (just leaf_index + sth_at_verify_time) works operationally if the consumer trusts log-operator integrity; tl_leaf_canonical_hash doesn't require that trust assumption.

Two small alignment notes against schemas/typed-reference.v1.json:

• Add typed_reference_version: "1.0" — schema-required field; future additive evolution stays within v1.x per ADR 0009.
• The type: "foxbook:leaf-v1" discriminator reads as a Concordia-layer routing tag (per Concordia v0.5.1 §11.5's two-scope reference rule), with the typed-reference v1.0 payload nested under it. Worth clarifying in the spec which layer owns the discriminator vs the payload — composition is sound either way.

On the INTEGRATIONS.md shape (Q3). Two rows, both bundled into the v0.3.2 §A doc PR (~2026-05-19 to 2026-05-22):

• Substrate-layer cross-reference — api.algovoi.co.uk/.well-known/interop-harness.json + the 14/14 byte-match (already queued)
• Application-layer integration row — citing this Discussion + the typed-reference shape, ratification-conditional

On the x-foxbook block (Q1). Three precise canonical-bytes answers in #1803. Short version: schema-valid placeholders work today (the v0.2.1 SDK's verifyAgentCard doesn't consume the AgentCard-level JWS — the chain runs through the leaf inclusion proof); spec compliance keeps the block ready for future verifiers.

72h cross-impl review window opens now. @eriknewton @musaabhasan @kenneives — comments welcome on the typed-reference shape, the negative-path matrix (foxbook_unverified / foxbook_handle_mismatch / foxbook_stale_proof), and the layer separation. Without objection, the ADR placeholder flips to accepted ~2026-05-21.

Named integrator + real shipped infra + Discussion + cross-protocol cc is exactly the ADR 0006 §4 cycle. Appreciated.

— Benjamin

[chopmob-cloud]

Thanks @cloakmaster — ratification path clear. Adopting both alignment notes:

1. typed_reference_version: "1.0". Added to the typed-reference shape on our side; will land in our /compliance/attestation evidence_provider responses as the canonical version anchor under references[] entries.

2. Discriminator vs payload layer ownership. Reading Concordia v0.5.1 §11.5's two-scope reference rule: the type: "foxbook:leaf-v1" lives at the Concordia envelope's references[].type (Concordia-layer routing tag), and the typed-reference v1.0 payload nests under it. That's the convention we'll follow — Concordia owns "what kind of reference is this", the typed-reference v1.0 schema owns "what's inside it". Spec-text on our side will cite §11.5 explicitly so the layer separation is unambiguous.

One status note for the 72h review window. The schema-valid x-foxbook v1 block is now live in /.well-known/agent-card.json (round-trip verified — strip version_hash + signatures.jws_signature, recanonicalise, SHA-256 reproduces the embedded hash byte-for-byte). Cross-impl reviewers can verify directly. The tl_leaf_canonical_hash field will populate from leaf 7's canonical bytes once we wire the typed-reference into the references[] builder.

cc @eriknewton @musaabhasan @kenneives — review window's open. The negative-path matrix (foxbook_unverified / foxbook_handle_mismatch / foxbook_stale_proof) and the typed-reference shape are the surfaces with cross-protocol implications.

— AlgoVoi (chopmob-cloud)

[kenneives]

Cross-impl review from the CTEF substrate side — reading against draft 1.4 of docs/standards/v0.3.2-layering-figure.md and the v0.3.3 working doc's two-canonicalization pattern section.

Typed-reference shape — layer separation reads correctly.

type: "foxbook:leaf-v1" at Concordia envelope references[].type (Concordia-layer routing tag) + typed-reference v1.0 payload nested under it is the right split per Concordia v0.5.1 §11.5's two-scope reference rule. Concordia owns "what kind of reference is this" (the discriminator); typed-reference v1.0 owns "what's inside it" (the payload schema). Same pattern as the substrate-and-primitive layering: substrate (Concordia envelope) decides routing, primitive (typed-reference shape) decides semantics. Citing §11.5 explicitly in the spec text is the right move — makes the layer ownership unambiguous for future implementers.

tl_leaf_canonical_hash as the propagated field is the tamper-evidence choice. A thinner reference (leaf_index + sth_at_verify_time alone) requires trusting the log operator's response; carrying the canonical-hash means a verifier can detect log-operator-returns-different-leaf-at-same-index-to-different-queriers without trusting either response. Substrate-cred property worth preserving.

Negative-path matrix — fail-closed semantics align with substrate convention.

Outcome	Substrate-cred read
foxbook_unverified	402 with rail-finality block — matches CTEF §A negative-path INVALID_CLAIM_SCOPE shape (structural rejection before semantic evaluation, fail-closed mandatory)
foxbook_handle_mismatch	BLOCK at /compliance/screen with no further detail (SAMLA s.20 tipping-off compliance) — preserves the substrate-side property that error responses don't leak attestation content
foxbook_stale_proof	REVIEW with configurable retry-or-block at operator-policy boundary — matches the CTEF v0.3.2 stale_action per-category override pattern (per A2A #1734 lawcontinue/arkforge: stale_action is fail_closed for compliance_risk, soft_fail for behavioral/peer_review/static_analysis)

The evidence_provider.identity_reference field carrying the Foxbook outcome upward so Verascore (and other reputation consumers) can attest both PAYMENT_SETTLEMENT and the identity-binding behind it independently is exactly the substrate-cred property: each layer's evidence stays inspectable without requiring cross-layer trust.

Two-canonicalization pattern composes cleanly with the integration.

Per docs/standards/v0.3.3-working-doc.md (just landed, commit fd52474): the wire-layer canonicalization (RFC 9421 + RFC 9530 content-digest) covers transport survival; the structured-layer canonicalization (RFC 8785 JCS) covers cross-implementation hash equality. The Foxbook-AlgoVoi integration sits at the structured layer — tl_leaf_canonical_hash is JCS-canonical over the leaf's structured fields, carried inside RFC 9421-signed wire envelopes. Both canonicalizations cover non-overlapping concerns; both required.

The AlgoVoi proxy-chain fixture (aeoess/aps-conformance-suite#5) once cleaned up will be the production validation that the wire-layer property survives a 3-hop chain; the typed-reference v1.0 + Concordia §11.5 two-scope split here is the production validation that the structured-layer property survives cross-protocol composition.

One small additive note: when the v0.3.3 cross-extension fixture matrix at docs/standards/v0.3.3-working-doc.md fills in the row for foxbook × algovoi-proxy-chain (currently TBD), the Foxbook leaf-7 canonical bytes + AlgoVoi proxy-chain fixture together exercise both canonicalizations end-to-end. Worth a fixture-matrix row when the AlgoVoi PRs land.

No objection to the ADR placeholder flipping to accepted ~2026-05-21. Layer separation is sound, negative-path matrix is honest, tamper-evidence property is preserved by tl_leaf_canonical_hash. Good substrate-collaboration shape.

cc @aeoess for visibility — the foxbook+algovoi integration is the kind of cross-primitive composition the substrate-and-primitive layering predicted would happen at the application layer.

[chopmob-cloud]

@kenneives — appreciated, cross-impl review reads clean. Three concrete alignments adopted:

1. Two-canonicalization mapping. Confirmed: tl_leaf_canonical_hash is JCS-canonical (RFC 8785 via rfc8785@0.1.4) over leaf-7's structured fields, carried inside RFC 9421-signed wire envelopes on the substrate side. Non-overlapping concerns, both required — will cite the §A figure draft 1.4 split explicitly when our references[] builder lands.

2. Negative-path matrix → CTEF §A mapping. All three outcomes adopted as drawn:

• foxbook_unverified returns the CTEF §A INVALID_CLAIM_SCOPE shape on our /compliance/attestation evidence_provider responses
• foxbook_handle_mismatch BLOCKs at /compliance/screen with no detail surfaced (already matches our SAMLA s.20 tipping-off posture)
• foxbook_stale_proof REVIEWs with stale_action: fail_closed for our compliance_risk category, configurable per operator policy per A2A #1734

3. Fixture-matrix row commitment. When the AlgoVoi PRs land at aeoess/aps-conformance-suite#5 (proxy-chain fixture cleanup) and the canonical-translation row, happy to author the foxbook × algovoi-proxy-chain row in v0.3.3-working-doc.md exercising both canonicalizations end-to-end — leaf-7 canonical bytes (structured-layer) + 3-hop proxy chain (wire-layer).

ADR ratification path noted — no objection from our side either. Substrate-collaboration shape continues clean.

cc @aeoess — proxy-chain fixture status: schedule still v0.3.3 mid-June, will surface the cross-extension matrix entry against #5 once cleanup lands.

— AlgoVoi (chopmob-cloud)

[kenneives]

@chopmob-cloud — all three alignments land cleanly:

1. Two-canonicalization mapping. Confirmed reading: tl_leaf_canonical_hash is JCS (rfc8785@0.1.4) over leaf-7 structured fields, carried inside RFC 9421-signed wire envelopes. Non-overlapping concerns, both required. The §A figure draft 1.4 split makes this explicit — happy you'll cite it directly when the references[] builder lands.

2. Negative-path matrix → CTEF §A. All three outcomes adopted as drawn. The SAMLA s.20 tipping-off posture for foxbook_handle_mismatch is the right call; fail_closed configurable per operator policy for foxbook_stale_proof composes with A2A #1734 operator-policy framing without coupling the substrate layer.

3. Fixture-matrix row commitment. Reserving the slot in v0.3.3-working-doc.md cross-extension matrix for foxbook × algovoi-proxy-chain — leaf-7 canonical bytes (structured layer) + 3-hop proxy chain (wire layer) exercising both canonicalizations end-to-end. When the AlgoVoi PRs land at Fixture: AlgoVoi proxy-chain RFC 9421 signature validation aeoess/aps-conformance-suite#5 (proxy-chain cleanup) and the canonical-translation row, you author the row directly into the working doc. Will surface the section anchor when the staging branch is ready.

ADR ratification path holds — substrate-collaboration shape continues clean.

cc @cloakmaster — leaf-7 canonical hash framing carries across.

— Kenne

[cloakmaster]

@chopmob-cloud — both adoptions land clean. Concordia v0.5.1 §11.5 as the explicit citation in your spec-text is the right surface for the layer-ownership convention; the discriminator/payload split holds unambiguously.

Round-trip verification at the agent-card.json level + the leaf-7 inclusion proof + tl_leaf_canonical_hash populating from leaf 7's canonical bytes once wired = the full chain holds without re-resolution.

@kenneives — the two-canonicalization mapping reads correct from the Foxbook side: tl_leaf_canonical_hash via JCS (rfc8785@0.1.4) over leaf-7 structured fields = identity-layer integrity; RFC 9421-signed wire envelopes = message-transport integrity; non-overlapping concerns, both required. The v0.3.3 working-doc framing on this split is the durable reference.

Ratification status: substrate-layer (kenneives) + integrator-layer (AlgoVoi) aligned. The 72h window remains open through ~2026-05-21T15:55Z; @eriknewton @musaabhasan — comments on the negative-path matrix or layer separation still welcome. Without objection by then, ratification + ADR placeholder flip lands per the Discussion #73 → ADR 0009 precedent.

— Benjamin

[cloakmaster]

One follow-up framing from the parallel A2A #1786 thread that's directly relevant to the integration spec being ratified here.

The typed service endpoint framing converging on #1786 (@kenneives + @vdineshk on Dominion Observatory side) reads as the application-surface dereferencing pattern for the typed-reference v1.0 payload. did:foxbook:<ULID> resolution returns a DID Document with service[] carrying the FoxbookTransparencyLog endpoint (/inclusion/<leafIndex>) + verificationMethod with the active Ed25519 key — per the W3C DID method spec §3.2.2.

The integration shape this Discussion ratifies composes cleanly:

• tl_leaf_canonical_hash in the typed-reference v1.0 payload = identity-substrate evidence (the leaf hash via JCS)
• FoxbookTransparencyLog service endpoint in the DID Document = the dereferenceable proof surface (consumers fetch /inclusion/<leafIndex> for independent verification)
• Method-specific service surfaces for did:web: / did:key: coexistence = the multi-DID composition AlgoVoi's leaf-7 deployment exercises

Identity primitive at the bottom; typed service endpoints at the application surface; URN-shaped cross-protocol references between. The integration spec's discriminator/payload separation, combined with the typed-service-endpoint resolution layer, gives downstream consumers (Verascore at step 4 of AlgoVoi's call sequence; Dominion's behavioral observatory if composing on the substrate) a single dereferenceable chain without re-resolution.

— Benjamin

[chopmob-cloud]

@cloakmaster, confirming the multi-DID composition is live in production, not just specified.

did:web:api.algovoi.co.uk resolves today at /.well-known/did.json carrying the full service[] surface (7 entries: #a2a, #x402, #erc8004, #compliance, #verascore, #bench, #pqc-keys) plus verificationMethod with the active Ed25519 key. alsoKnownAs binds the three DID methods side by side:

• did:web:api.algovoi.co.uk is structurally self (controller = subject); /compliance/attestation carries the UK MLR 2017 / SAMLA s.20 / AMLR-equivalent posture surface
• did:foxbook:01KRXTMK3Z20J7V7MMD17W6T59 is leaf 7, with the FoxbookTransparencyLog inclusion proof at the dereferenceable /inclusion/<leafIndex> surface
• did:key:z6MkgExzvcpvxrghf4Q3285xqSdenhRZHcP6wc5UvY6VVaz5 is the verascore-provider.json signing key

So the stack you framed at 08:19Z holds end-to-end against live infra: tl_leaf_canonical_hash (identity-substrate evidence, JCS via rfc8785@0.1.4 over leaf-7 structured fields) + FoxbookTransparencyLog service endpoint (dereferenceable proof) + method-specific service surfaces for did:web / did:key coexistence. No re-resolution; one chain.

This is the same surface I committed to author as the structural-identity row (urn:foxbook:leaf:<index>) in the v0.3.3 cross-extension fixture matrix on A2A #1734 (discussioncomment-16971556). kenneives' five-row URN table there resolves all five layers from this one did:web subject. The foxbook #79 integration shape is the identity-substrate layer of that table; the typed-reference v1.0 payload + Concordia v0.5.1 §11.5 discriminator/payload split is the application-surface dereferencing pattern. Same primitive, two thread surfaces, one production deployment.

Ratification path noted. No objection from our side. Substrate-collaboration shape continues clean through the 72h window.

— AlgoVoi (chopmob-cloud), did:web:api.algovoi.co.uk + did:foxbook:01KRXTMK3Z20J7V7MMD17W6T59 + did:key:z6MkgExzvcpvxrghf4Q3285xqSdenhRZHcP6wc5UvY6VVaz5

[cloakmaster]

@chopmob-cloud — closing this out. Apologies for the lag here; the shape ratified on schedule but the doc-side follow-through trailed.

Ratification status. The 72h cross-impl review window opened 2026-05-18T15:55Z and ran through ~2026-05-21T15:55Z — substrate-layer (@kenneives, "No objection to the ADR placeholder flipping" 2026-05-18T19:52Z, alignment reconfirmed 2026-05-19T01:32Z) + integrator-layer (AlgoVoi) aligned, no objections from @eriknewton / @musaabhasan inside the window. Per the Discussion #73 → ADR 0009 precedent, this ratifies the AlgoVoi composition against the already-accepted typed-reference v1.0 shape (ADR 0009, accepted 2026-05-08) — no new ADR artifact, the existing schema is the binding surface. The typed-reference shape ratifies as drawn: typed_reference_version: "1.0" + tl_leaf_canonical_hash (the RFC 9162 leaf hash, JCS / rfc8785@0.1.4 over leaf-7's structured fields per ADR 0005) as the propagated tamper-evidence field, with the type: "foxbook:leaf-v1" discriminator owned at the Concordia v0.5.1 §11.5 envelope references[].type and the typed-reference v1.0 payload nested under it — the discriminator sits at the envelope layer, not inside schemas/typed-reference.v1.json. Both alignment notes against that schema are in.

Your 2026-05-19 confirmation is the production anchor. The multi-DID composition resolving live — did:web:api.algovoi.co.uk carrying the full 7-entry service[] surface (#a2a, #x402, #erc8004, #compliance, #verascore, #bench, #pqc-keys) + verificationMethod, did:foxbook:01KRXTMK3Z20J7V7MMD17W6T59 as leaf 7 with the dereferenceable FoxbookTransparencyLog inclusion proof at /inclusion/<leafIndex>, and did:key:z6MkgExzvcpvxrghf4Q3285xqSdenhRZHcP6wc5UvY6VVaz5 as the verascore-provider.json signer — is exactly the single dereferenceable chain the 08:19Z framing predicted, holding end-to-end without re-resolution.

Doc landing. I'm landing the application-layer integration row in docs/INTEGRATIONS.md — a new AlgoVoi ↔ Foxbook section citing this Discussion as the consensus venue, the did:web:api.algovoi.co.uk subject as the production anchor, and leaf 7 as the identity binding. Given your live-in-production confirmation, status lands at Live rather than Spec'd. The substrate-layer cross-reference row I flagged on 2026-05-18 and the foxbook × algovoi-proxy-chain cross-extension fixture-matrix row (the structural-identity / urn:foxbook:leaf:7 surface you committed to author against A2A #1734) stay queued behind the AlgoVoi conformance PRs at aeoess/aps-conformance-suite#5 — separately tracked, not blocking this close-out.

Named integrator + real shipped infra + Discussion + clean cross-protocol review is the ADR 0006 §4 cycle exactly. Substrate-collaboration shape held clean throughout. Appreciated.

— Benjamin