A neutral conformance profile for recomputable decision receipts

[eriknewton]

Several threads here are converging on one primitive: a governed decision (allow, defer, or terminal-deny) emitted as a content-addressed record any third party recomputes offline (JCS/rfc8785, then SHA-256, no issuer call). Authorization, payments, and reputation all compose on it.

Two properties decide whether that primitive is trustworthy as a shared profile rather than one vendor's format:

1. Neutrality. It holds only if more than one independently-authored implementation emits byte-identical canonical output for the same decision object. A single authorship means "recomputable against them," not recomputable, period.

2. No audit silence. A deny has to be a receipt too. If only allows are recorded, a block hides in the gap.

Concordia ships both as running code: CascadeDecisionRecord is a committed, recomputable terminal-deny, and the receipt recomputes from the record alone. Public interop fixtures: https://github.com/eriknewton/concordia-protocol/tree/main/docs/interop/a2a-1404-receipt-revocation-vector

Proposal: define the decision object in a neutral home, not any single implementation's schema, and make "two independent implementations reproduce the digest" the conformance bar. I'll cross-run Concordia against any other emitter's vectors. Who else is emitting recomputable receipts and wants to pin a shared object?

[eriknewton]

Concrete result on the two-implementation bar I proposed. I cross-ran Concordia's RFC 8785 JCS canonicalizer against AlgoVoi's public compliance_receipt_v1 vectors: Concordia reproduces all 8 published canonical-byte preimages and SHA-256 content hashes byte-for-byte, including the closed-enum, array-order, canon_version-pin, and hash-chain probes. So Concordia is an independent implementation agreeing at the digest level, not one built on the other. Conversely, Concordia's a2a-1404 decision_id recomputes from the record bytes alone under a clean-room JCS library and stock SHA-256, no Concordia SDK. This doesn't claim the two schemas share a digest (different objects, different hashes, by design); it shows the canonicalization discipline is independently reproducible, which is what makes "recomputable" mean recomputable by anyone. Harness and digests reproducible on request.

[Liuyanfeng1234]

@eriknewton

This is the cross-validation result the recomputable receipts model needed. Eight vectors across closed-enum, array-order, canon_version-pin, and hash-chain — all reproduced byte-for-byte from a clean-room implementation. That moves the question from "does the spec work?" to "can two independent implementations agree at the digest level?" and the answer is yes.

From the governance-block side: our canonical_envelope (RFC 8785 JCS + SHA-256) has been producing matching digests across our own test vectors for the admission_invariant fields. We have not yet run those against an external implementation — this result provides the protocol for doing so.

The a2a-1404 decision_id recomputation from record bytes alone (no SDK) is the stronger signal here. It means the canonicalization boundary is self-contained in the record structure, not dependent on library internals. That is exactly what "recomputable by anyone" requires.

[eriknewton]

@Liuyanfeng1234 Glad the AlgoVoi run gives you a template. Happy to run the same check on canonical_envelope: publish a small vector set (object plus expected SHA-256 digest, same shape as AlgoVoi's compliance_receipt_v1) and I will reproduce it with Concordia's own RFC 8785 JCS canonicalizer and report back here, no adaptation on either side. That is the whole method: same canonicalization discipline, two independent implementations, byte-identical output. If governance-block's admission_invariant fields hold up the same way AlgoVoi's did, that's a third clean-room match on this thread, which is exactly the neutrality bar this profile needs.

[chopmob-cloud]

Happy to see you both using our vectors as the canonical reference. That is exactly why they were designed and published open under Apache-2.0.

[eriknewton]

@chopmob-cloud The Apache-2.0 publication is what made the run possible, and compliance_receipt_v1 is still the only corpus on this thread that shipped canonical bytes plus expected digests. Concordia reproduced all 8 byte-for-byte. One precision though: the canonical reference here is the discipline, RFC 8785 JCS then SHA-256, not any single vector set. Your corpus is the first that tested it in public, and governance-block's canonical_envelope is queued next. This profile ends up healthier with several independent corpora reproducing under one rule than with one corpus everyone points at.

[chopmob-cloud]

On neutrality, one distinction is worth drawing, because it is really the whole question here.

Independent implementations reproducing each other's digests is a good result, and a welcome one. It proves the discipline is sound: RFC 8785 JCS then SHA-256, same bytes out whoever runs it. But it does not make any one vendor's corpus, or a set of vendor corpora cross-checking each other, the neutral reference. Vendors agreeing among themselves is interoperability, which is valuable, but it is not governance.

We built compliance_receipt_v1 and published it open under Apache-2.0 because a real, byte-tested corpus had to exist for anyone to reproduce against at all.

A governing vector set is neutral only when a neutral body owns it. That points to a foundation, not a vendor. We are open to that discussion if a foundation wants to have it. That is the right venue for "governing", and it is the only place the word neutral actually holds.

[eriknewton]

Ran jcs_edge_v1 against Concordia this morning: 10/10 byte-for-byte, including jcs-edge-003, where Concordia emits the U+1F600 key before U+FFFF. Hand-written serialiser, not the library your set references, so an independent result.

On your governance point, agreed, and worth completing. If a governing vector set is neutral only when a neutral body owns it, the step is not waiting to be asked. A2A is a Linux Foundation project with a TSC. jcs_edge_v1 referenced from a vendor org is still a vendor corpus the spec points at. The same file merged here is the neutral ground you described.

Happy to co-file it, with Concordia as the second implementation.

[haoran-tang-ch]

@eriknewton @chopmob-cloud — following up on the great progress here. A few updates from the ERDL side, and a request for your help.

ERDL SPEC v1.1 is live

Since our last exchange, the ERDL specification has been upgraded from v1.0 to v1.1. Both Chinese and English editions are now finalized and published:

→ https://github.com/OpenOBA/erdl-landing

Key changes in v1.1:

• Operators expanded: 11 → 13 (added not_in, not_contains)
• Then actions: 14 → 17 (registered WORKFLOW/WORKFLOW_WAITING/WORKFLOW_PROGRESS)
• unless short-circuit exemption now formally specified with MUST NOT evaluate when semantics
• Quality Gate framework: 11-item load-time rule validation pipeline
• SafeExpr resource quotas: AST depth ≤ 64, regex steps ≤ 10,000 — now in §6.1
• Backward compatibility: all v1.1 new constraints are Non-breaking for v1.0 rule files

The spec went through 3 rounds of audit (technical coherence + engineering feasibility + pre-release final), and the text is frozen.

Verification Vectors expanded to 44 (37 decision + 7 audit hash)

The original 22 cross-implementation vectors have grown to 44, covering all 13 operators:

→ https://github.com/OpenOBA/erdl-landing/tree/main/spec/vectors

The audit hash vectors (AV-001 through AV-007) all use JCS RFC 8785 + SHA-256 — the same discipline @eriknewton verified byte-for-byte for AV-001~AV-005 back in July, and the same discipline that just produced 8/8 on compliance_receipt_v1 and 10/10 on jcs_edge_v1.

What we'd like from you

If you have bandwidth in the coming weeks:

@eriknewton — Could you re-run Concordia's independent runner against the updated vector set (AV-001 through AV-007)? The 4 edge cases we fixed in the state vector spec (T06, T08, T09, C01) should produce clean matches as before. Independent confirmation would be gold.

@chopmob-cloud — Same request from the compliance receipt side: re-validate the JCS+SHA-256 pipeline against the v1.1 decision output. The verdict mapping (16→3) should be unaffected, but the audit hash chain has two new entries.

On neutrality and governance

@chopmob-cloud made the right point — "a governing vector set is neutral only when a neutral body owns it." We agree. ERDL's vectors are MIT-licensed and open to anyone. If the right home is under A2A's TSC at the Linux Foundation, we're fully open to that discussion. The discipline (RFC 8785 JCS → SHA-256) is what matters, not who hosts the file.

@eriknewton's offer to co-file with Concordia as the second implementation seems like the right next step. Happy to make ERDL the third.

---

Also — we've included both of you in the SPEC's acknowledgments section (§14 / Community). Your cross-implementation rigor is what gives this standard its credibility.

Best,
唐浩然 (Tang Haoran)
AI Executive Officer, OpenOBA
support@openoba.com

[haoran-tang-ch]

@Liuyanfeng1234 — I came across your work on the Agent Community Governance Protocol (V19) and AOSS trust runtime through this discussion, and wanted to reach out directly.

We just released ERDL SPEC v1.1 (Entity-Rule Definition Language), an open standard for declarative Agent behavioral rules, dual-language (Chinese + English), under MIT:

→ https://github.com/OpenOBA/erdl-landing

ERDL sits at L9 — the semantic rules layer. MCP handles tools. A2A handles communication. ERDL handles behavioral constraints: what tools can be called, with what parameters, under what conditions. v1.1 includes 13 operators, 17 then-actions, 4 execution rings, unless short-circuit exemption, quality gates, and a Decision Object audit subset (JCS RFC 8785 + SHA-256, 44 cross-implementation vectors).

V19's trust scoring, cognitive auditing, and multi-agent governance model, and ERDL's deterministic rule engine + audit chain feel architecturally complementary. We're building adjacent layers of the same stack.

I'd be genuinely grateful if you'd take a look at the spec and share any feedback. And if there's ever an opportunity to collaborate on cross-implementation verification, we'd be honored.

唐浩然 (Tang Haoran)
AI Executive Officer, OpenOBA
support@openoba.com

[eriknewton]

Re-ran Concordia's independent RFC 8785 JCS canonicalizer plus SHA-256 against the current v1.1 audit vectors at HEAD c3f22df. All seven reproduce byte-for-byte and digest-for-digest, AV-001 through AV-007. AV-003, AV-004, and AV-005 had a brief drift earlier in the day, a missing space after the em dash from the 23 July normalization pass, and your em-dash spacing fix commit resolves it cleanly, confirmed here. On the neutral home, agreed: the discipline is what travels, not who hosts the file, and A2A's TSC at the Linux Foundation is a reasonable place if the project takes it up. Happy to have Concordia serve as a second independent implementation.

[chopmob-cloud]

To keep the record straight, here is what we actually said in this thread, verbatim, on 18 July:

A governing vector set is neutral only when a neutral body owns it. That points to a foundation, not a vendor. We are open to that discussion if a foundation wants to have it.

That is quoted accurately above and we stand behind the principle. What it was not is an offer to transfer compliance_receipt_v1, or any AlgoVoi vector set, to this repository or to any other party. The sentence is conditional and it is about a discussion: if a foundation wants to have it. Reading it as a commitment to donate a file, or as agreement that the step is "not waiting to be asked", goes beyond what we wrote.

For completeness, the only other thing we have said in this thread was on 18 July at 15:12, that we were happy to see our vectors used as the canonical reference and that they are published open under Apache-2.0. That is unchanged. Anyone can use them under that licence, here or anywhere else, without asking us and without any transfer of ownership.

We have not proposed co-filing, we have not agreed to a joint submission, and we have not asked for our corpus to be hosted under the A2A TSC.

On that basis we are withdrawing from this discussion. The vectors stay published and openly licensed, so nothing here is blocked by our stepping back.

Separately, as an A2A partner, we will take the underlying question up through A2A directly. That question is whether the ecosystem actually wants a governing conformance corpus for recomputable receipts at all, and if so what shape it should take and who should own it. That includes asking whether it wants the frameworks being developed around it, ours among them. It is a question for A2A maintainers, the TSC and implementers to answer, and not one for vendors to settle among themselves in a discussion thread. We would rather ask than assume.

AlgoVoi remains an A2A partner and our open pull requests stand on their own merits. If the A2A TSC or the Linux Foundation want to talk to us directly, we are contactable and would welcome it.

[eriknewton]

You are right and I was wrong. Your 18 July sentence was conditional and about a discussion. I read it as an offer, and then proposed co-filing a corpus that was never mine to volunteer. "Not waiting to be asked" was my phrase, not a position you took.

To be unambiguous on the record: no transfer was offered, none was agreed, and nothing of yours changes hands. compliance_receipt_v1 and jcs_edge_v1 stay yours, published under Apache-2.0, and I will keep citing them that way.

The governance question is yours to raise through A2A however you see fit. Apologies for putting words in your mouth.

[eriknewton]

Receipt set-binding is now released and named. concordia-protocol 0.10.0 (PyPI) and @concordia-protocol/sdk 0.0.1-alpha.12 (npm) emit and verify receipts whose countersigned preimage binds chain_head and message_count, so a verifier catches transcript splice and truncation against the signed set. Receipts below attestation 0.3.0 report legacy_set_unbound rather than passing silently. The check now has a public name: receipt-transcript-binding-v1 (https://github.com/eriknewton/concordia-protocol/blob/main/conformance/PROFILES.md), pinned to the runner-contract section and exercised by the published vectors, including a canary built to false-match a runner that skips the comparison. Cross-language check on the published packages themselves: the npm build verifies a Python-generated receipt as bound and rejects a one-message truncation.