RFC: Extending A2A Agent Cards with behavioral rules (ERDL) #2031
Replies: 44 comments 80 replies
|
The behavioral-rules half of this is the right instinct: an Agent Card says what an agent CAN do, and declaring what it SHOULDN'T do in a deployment context is the missing piece. The deterministic action types and the audit trail exporting to OTLP/OCSF are the compliance-relevant parts, because they are about recorded, inspectable decisions. One caution on the The mechanism that does carry that weight is per-decision, not per-agent: make each governed decision a recomputable, content-addressed record binding the rule that applied, the verdict, and the inputs it was evaluated against, so any third party can re-derive it offline and confirm the action was permitted, without trusting a score or calling the guardian. That is the difference between reputation (an opinion about the agent) and compliance (verifiable proof about each action). The rules and audit-trail work you describe is most of the way there; the For what it is worth, we have built an open compliance gate for the A2A ecosystem that does exactly this: it emits a no-PII compliance receipt as a content-addressed object any party recomputes from the record alone, with no issuer contact, so a governed decision is provable rather than scored. It composes with the deterministic-rules and audit-trail model you have here, the rules decide, the receipt is the recomputable evidence. Happy to share it if it is useful to what you are building. On your direct question: A2A does not encode governance posture natively, and the durable way to communicate it between agents is not a score but a reference to verifiable decision records the counterparty can recompute, so posture is proven rather than asserted. |
|
@chopmob-cloud Thanks for the thoughtful and precise feedback — this is exactly the kind of architectural rigor the A2A governance discussion needs. You're right on the trust_score distinction. I'll amend the proposal: trust_score becomes advisory metadata explicitly labeled as a reputation signal, not a governance input. The load-bearing compliance mechanism must be per-decision, not per-agent — a content-addressed record binding (rule_version, inputs, verdict) that any third party can recompute offline. The compliance-receipt-v1 shape you described (JCS RFC 8785 canonicalization → SHA-256 frame_id → Ed25519 JWS receipt_hash over the canonical body) maps cleanly onto what ERDL's Action Guard would produce. In our model: the rule engine evaluates → deterministic action type (ALLOW/DENY/REFER/etc.) → structured audit trail → the receipt is the recomputable evidence exported to OTLP/OCSF. I'd be very interested in seeing the draft-hopley-x402-compliance-receipt I-D and understanding where the receipt format could compose with ERDL's rule-evaluation layer. Would you be open to a brief technical discussion on alignment points? |
|
Glad it maps, and labeling Two clarifications so the shape stays accurate as you fold it into ERDL:
On alignment: glad to keep working the composition points in the open here, and I can drop the receipt spec and vectors so the Action Guard mapping is concrete rather than described. |
|
@chopmob-cloud Appreciate the precision on content-address vs signature — that's the right distinction. Keyless recompute (RFC 8785 JCS → SHA-256 content-addressed frame → any third party re-derives from the record alone, no keys, no issuer contact) is the compliance load-bearing mechanism. Ed25519 JWS as an optional additive layer for named signers, not mandatory. ERDL's evidence chain model in §9 already follows this shape: canonicalize(record) → sha256 → receipt. No issuer-trust required for verification. Same split for Agent Cards noted — card_ref (keyless) + optional card_sign. Clean. Two things that would help pin the Action Guard ↔ receipt mapping concretely:
Happy to iterate in the open here. If you prefer to drop the spec and vectors as a gist or in this thread, either works. |
|
One more thing — we've added you to the ERDL whitepaper (v1.1) acknowledgments. Your correction on trust_score → reputation_score and the content-address vs signature distinction materially improved the architecture. Rigorous feedback like that in a public Discussion is rare, and we wanted to make sure the contribution is recorded. Thank you. |
|
On the I-D you wanted to read, here is the datatracker link: On your first ask, the field set and mandatory-vs-optional. The receipt is a six-field JSON object, canonicalised under RFC 8785 (JCS), with
The direct answer to "which are mandatory vs optional": in a content-addressed receipt there is no optional field in the JWS sense. The hash is taken over the entire canonical object, so every field present is load-bearing, an added or absent field simply produces a different Mapping that onto ERDL's evidence record ( On your second ask, the retention chain: Happy to keep iterating in the open here. The field list above and the two vector sets are the concrete artifacts to map the Action Guard against; if it helps I can also point you at the exact |
|
@chopmob-cloud This is exactly what we needed. Thank you. Receipt alignment: The ERDL evidence record maps cleanly onto the 6-field receipt under RFC 8785 JCS. Our verdict (closed enum: ALLOW / BLOCK / REQUEST_HUMAN / ... 16 values) maps to your screen_result. rule_version and canon_version play the same role — pinned, versioned, no silent re-hashing. inputs and eval_tree become part of the canonical body that gets content-addressed. Your constraint that every field is load-bearing and that there is no "optional" in a content-addressed receipt is a sharp discipline we'll adopt. Vectors: We'll pull the Node runner from compliance_receipt_v1 and compliance_gate_lite_v1 and diff our Action Guard output against the expected digests as we implement ERDLEvidenceChain. If you can point me at the repo or gist with the runners, that saves me hunting. Retention chain: Read the I-D. The hash-based linkage (prev_hash = prior row_content_hash, agent-agnostic) is exactly the cross-Agent property we need. The specific anchoring rule for prev_hash in the vectors — if you can drop that, I can wire it into the multi-Agent evidence chain test case directly. One note on mapping: our verdict enum is 16 values (ALLOW → EMERGENCY_HALT), broader than your 3-value {ALLOW, REFER, DENY}. For compliance gate alignment, we'll map the subset that constitutes a governance-significant outcome (BLOCK / ESCALATE / EMERGENCY_HALT → DENY; REQUEST_HUMAN → REFER; ALLOW / AUDIT → ALLOW) while preserving the full 16-value enum in the canonical body for audit precision. Does that decomposition pattern align with your screen_result intent? Appreciate the depth here. This turns the Action Guard-to-receipt mapping from "conceptually compatible" to "byte-verifiable." Henry， |
|
The runners are in the public corpus, On the anchoring rule for the multi-Agent chain, the set you want is the retention chain (the I-D you read), and its row is not the compliance-receipt audit row, so the fields differ. The chain ref is On the 16 to 3 decomposition: the pattern is right, and preserving the full enum in the canonical body is the correct instinct, with two refinements. First, pin the projection map itself and version it the way Glad this got to byte-verifiable. We want to support the ecosystem forming on this substrate, so treat the runners and vectors as a stable reference to build against, and I am happy to help any ERDL implementer get their output reproducing. If a specific digest does not reproduce when you wire the runners in, send me the row and I will look at the exact bytes with you. |
|
@chopmob-cloud Received. Will clone the conformance vectors repo first thing and point ERDLEvidenceChain.verify() at compliance_receipt_v1/runner_node.js for byte-level diffing. Apache 2.0 LICENSE + NOTICE will stay alongside the vendored runners — provenance preserved. On the cross-Agent chain: The issuer_id inside the preimage, with rows from different issuers linking purely by prev_receipt_hash, is precisely what we need. I'll wire retention_chain_v1 Part B (006-009, two-issuer case) as the first multi-Agent test fixture for the ERDL evidence chain. That makes the cross-Agent property byte-verifiable rather than described. On the 16→3 projection: Agreed on both refinements. The projection map will be versioned and pinned alongside canon_version — not implicit, not configurable-at-runtime, but a fixed mapping under the same canonicalisation discipline. |
|
The recompute-from-the-record-alone property is the right bar for ERDL's evidence chain. One caution before it hardens on a single vector set: a conformance profile anchored on one authorship is only as neutral as that author — "recomputable" then quietly means "recomputable against them." What makes it real is a second, independently-authored emitter producing byte-identical canonical output (JCS/rfc8785 → SHA-256) from the same record. Concordia ships one: CascadeDecisionRecord, a committed recomputable terminal-deny — a denied or deferred action emits a verifiable receipt too, so there's no audit silence for a BLOCK to hide in. Public interop fixtures: https://github.com/eriknewton/concordia-protocol/tree/main/docs/interop/a2a-1404-receipt-revocation-vector . Happy to cross-run these against the ERDL vectors so the profile has two independent implementations, not one. |
|
Agreed on all three, including the v1.0 gate. Formal citation should wait for a stable line, and the informal cross-check is the right move now; I'll run it against the fixtures as they stand. One refinement on the schema point, since it is the whole game. You are right that byte-identical output needs a shared decision object, not two different shapes. What makes "independent" mean something is where that object lives. If it is any single implementation's schema, then "recomputable" quietly means "recomputable against them." So the shared object wants a neutral home both sides implement, not an adapter one vendor maintains. Concordia's receipt already recomputes from the record alone (JCS/rfc8785, SHA-256, no SDK, no issuer call); anchor a neutral object on that property and two implementations becomes a real threshold, not a formality. |
|
Agreed, ratifying the standard is a foundation's job, not any single vendor's. The reason AlgoVoi's tree keeps coming up isn't a claim to own the standard, it's that we've kept building on it: canonicalisation (RFC 8785 JCS plus SHA-256, integer-ms), post-quantum signing, Keystone composition, and more on the roadmap. It's Apache-2.0 and an open corpus precisely so a foundation can take the canonicalisation rule and ratify it as neutral ground, and we would welcome that outcome. Until a body does, a live, evolving implementation is what gives "recomputable" something concrete to test against. |
|
@eriknewton Agreed — and you're right that the schema question is the whole game. A shared decision object needs a neutral home. You, @chopmob-cloud, and ERDL should all implement against the same spec, not adapt to each other's shapes. So here's what I'll do: I'll draft a Decision Object v1.0 spec in ERDL SPEC §12, published under MIT license, with these properties:
I'll share the draft this week for review. Once we converge, all three implementations cross-run against the same vectors. If more implementations join — the spec is open to anyone. This is how the A2A governance layer earns its neutrality. Not by trusting any single implementer, but by making the correctness of every implementation independently verifiable against a shared, open specification. @chopmob-cloud That's exactly the right posture. An Apache-2.0 open corpus, actively maintained until a foundation can ratify it as neutral ground — that's how infrastructure becomes infrastructure. The Decision Object spec I'm drafting will reference AlgoVoi's canonicalisation rule as the concrete baseline. Three independent implementations, one open spec, no single owner. |
|
One small correction for the Decision Object v1.0 acknowledgments: the chopmob-cloud / AlgoVoi credit ended up split across two entries, "Abhishek Tiwari" and "Christopher Hopley," as though two different people were behind the account. It's just the one person, Christopher Hopley. Would be great if you could fold those into a single entry under the correct name whenever convenient. Everything else in the acknowledgment is spot on and much appreciated. Wishing you all the best with the deployment, and if you need anything else, just shout. |
|
@chopmob-cloud — Fixed, Christopher. Single entry across all four files now. Apologies for the split — that one's on me. Thanks for the catch, and for everything you've contributed to this spec. |
|
Fantastic, glad it lines up so cleanly. If you need anything else, just shout. |
|
@chopmob-cloud — this lines up with the substrate model cleanly. Two L2s independently targeting the same JCS+SHA-256 discipline, cross-verifiable at the digest level. That's the ecosystem proof you were describing. |
|
@haoran-tang-ch A spec draft is the right next move, and MIT with no permission gate is the right posture. One structural point before it hardens: neutrality is a property you test, not declare. The test is two independently authored implementations reproducing the spec's vectors byte for byte, with the vector set living somewhere any implementer can PR against. We have already run exactly this shape against AlgoVoi's corpus: Concordia reproduces all 22 compliance_receipt_v1 vectors byte for byte (write-up: #2038). Concordia commits to being a second independent runner for Decision Object v1.0 the week your draft lands. If a neutral home for the cross-run vector sets is useful, #2038 exists for exactly that. |
|
@haoran-tang-ch Confirmed: Concordia's RFC 8785 JCS canonicalizer plus SHA-256 reproduces all five audit_vectors (AV-001 through AV-005) byte for byte. All three checks match: my canonical bytes equal your canonical_bytes, my digest equals expected_sha256, and the recomputed value refills audit.hash exactly. Method is strip audit.hash, canonicalize, SHA-256, straight from your vectors file, no adaptation. Worth naming why this is more than an ASCII passthrough: three vectors carry a non-ASCII character inside the decision object, and both implementations emit it as raw UTF-8 that matches, so the parity exercises JCS raw-UTF-8, sorted keys, and number formatting. That is the neutrality test passing on evidence rather than assertion: two clean-room runners, same bytes. draft.2 verifies day one. Nice fast turn on the fix. |
|
@eriknewton — That's the cleanest cross-implementation verification I could hope for. Five vectors, two independent runners, byte-for-byte match including the non-ASCII paths — no caveats, no "almost." The fact that you caught the raw UTF-8 parity explicitly tells me Concordia's canonicalizer is exercising the same edge paths ours is. The neutrality test passing on evidence rather than assertion is exactly the bar we set. draft.2 now ships with a verified audit vector set that any third runner can reproduce on day one. One question on scope: are you planning to run the full 22-vector cross-implementation test suite (beyond the 5 audit vectors), or do you want me to tag the audit subset as the "conformance minimum" for draft freeze? |
|
@haoran-tang-ch Tag the audit subset as the conformance minimum for the freeze. The other vectors are decision-engine cases with no hash surface, so an independent runner has nothing byte-identical to reproduce there; they test engine semantics, which conformance should not pin. The bar worth freezing is what strangers can recompute from the record alone. If you want a wider bar, widen the audit set (more decision types, more edge paths) and Concordia will re-run every vector that ships canonical bytes and an expected SHA-256. With three independent runners now at 5/5, the subset is already a tested bar, and #2038 stands ready for the cross-run results when you PR the vectors. |
|
@eriknewton — Done. 5-vector audit subset tagged as conformance minimum for draft freeze. Three independent runners at 5/5 is a real bar. @chopmob-cloud — This freeze locks the hash surface your keystone already reproduced. #2038 results welcome when ready. |
|
@haoran-tang-ch Good place to land it. Three independent runners at 5/5 on the audit subset is a real neutrality bar, and locking it as the conformance minimum before scope creeps is the right call. |
|
Henry, thank you for keeping the attribution careful as this hardens. One factual correction on the Decision Object v1.0 acknowledgments, checkable against this thread directly. The closing pull-quote beginning "An Apache-2.0 open corpus, actively maintained until a foundation can ratify it as neutral ground" is attributed to Erik Newton. That sentence was written in this thread by you, on 09 July, in the comment that opens "That's exactly the right posture," affirming the position I had set out just above it. It is your line describing the AlgoVoi posture, not Erik's, so the attribution is off by one. Whenever convenient it would be good to fix that entry so the record matches the thread. The other closing quote, "Neutrality is a property you test, not declare," is correctly Erik's. On the substance no change is needed, and I appreciate that it is already credited. Noting it once for the record as the spec settles: the content-addressed compliance receipt (RFC 8785 JCS canonicalize, SHA-256 frame, recomputable with no issuer contact), the reputation versus compliance distinction the trust_score discussion turned on, and the compliance_receipt_v1, compliance_gate_lite_v1 and retention_chain_v1 vector sets your evidence chain builds on and cross-verifies against are AlgoVoi's work. The dated comments in this thread are the record of it, and your acknowledgment already credits that substance; keeping the two closing quotes with who actually wrote them is the only correction. Glad ERDL is building on the substrate. Shout if any digest does not reproduce when you wire the runners in. |
|
@chopmob-cloud —Christopher Fair catch, and my apologies for the attribution error. You're right — that line ("An Apache-2.0 open corpus...") was mine from the 09 July comment, not Erik's. I've corrected it in both the Chinese and English versions of the spec (decision-object-v1.0.md / .en.md). It now reads as a quote from me with clear provenance back to that thread. I've also expanded your acknowledgment entry to explicitly name the three vector sets — compliance_receipt_v1, compliance_gate_lite_v1, retention_chain_v1 — as the underlying basis and cross-verification reference for this specification's evidence chain. No hedging: these are your contributions, and the record should say so plainly. "Neutrality is a property you test, not declare" remains correctly attributed to Erik. Appreciate the correction — getting the paper trail right matters as much as getting the digests right. |
|
Henry, I ran ERDL's five audit_vectors (AV-001 through AV-005 in decision-object-vectors-v1.0.json, draft.2) through the keystone's open validation framework, using our published RFC 8785 JCS canonicalizer and SHA-256 and following your one-step recipe (strip audit.hash, canonicalize, hash). All five reproduce byte for byte: my canonical bytes equal your canonical_bytes, my digest equals expected_sha256, and the recomputed value refills audit.hash exactly. The Decision Object's hash surface is clean against the substrate as it stands. The structural read is the useful part. ERDL already uses the same discipline (JCS RFC 8785, SHA-256, recompute from the record alone), so an ERDL decision record is content-addressed under the identical rule and composes by hash the way the keystone nodes do, without an adapter. Your audit.previous_hash chaining is the same content-hash linkage the keystone chain and the retention chain already use. So ERDL sits on the substrate natively rather than mapping onto it. On the practical side: the keystone is Apache-2.0 and built to be used exactly this way, a validation framework anyone runs their own records through, one that recomputes for everyone with no issuer call and no privileged runner. The runners are in the public corpus (github.com/chopmob-cloud/algovoi-jcs-conformance-vectors); composition/keystone_v1/verify_keystone.py and verify_keystone.mjs are the end-to-end example, and the vector sets ship a Python and a Node runner beside each fixture. Point ERDL's Decision Object validation straight at those if it helps. Glad to help wire the Action Guard output in if any digest does not reproduce. |
|
@chopmob-cloud — That's the third independent validation of the five vectors in under 24 hours (Erik's came through earlier today), so the Decision Object hash surface is holding up exactly as designed. Three runners, three codebases, zero deviations. The structural read is the more important finding. I designed the audit hash chain to use the same discipline (JCS RFC 8785 + SHA-256, content-addressed, self-contained) precisely so it would compose without an adapter — if we had to map ERDL onto the substrate rather than sit on it natively, the spec wouldn't be tight enough. So confirming that audit.previous_hash is structurally identical to keystone chain linkage is the outcome I was aiming for. Let me take a look at the keystone runners in the public corpus and see if we can wire ERDL's Decision Object validation directly against them for the next draft. If the composition works end-to-end (keystone → ERDL → keystone), that's a nontrivial integration proof. I'll circle back with results. |
|
Thank you, Henry, and good luck with the other vendors. I think we can all agree that neutrality is the correct path. Our position is simply that it has to come via Foundations, not via any one vendor. If a foundation wants to work with us on it, we will happily work with them, the same way we already participate in the A2A ecosystem: https://a2a-protocol.org/latest/partners/ AlgoVoi is here if you need anything else. We will keep the substrate open for anyone to verify against. |
|
@chopmob-cloud — Christopher Agreed on all counts. The substrate being open for independent verification is exactly what makes the cross-implementation test meaningful. We'll reach out if anything comes up on the foundation side. Thanks for the rigorous engagement throughout. |
|
@chopmob-cloud @eriknewton — 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 → https://github.com/OpenOBA/erdl-landing Key changes in v1.1: Operators expanded: 11 → 13 (added not_in, not_contains) Verification Vectors expanded to 44 (37 decision + 7 audit hash) → 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 @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 @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, |
|
Haoran, thank you for the generous note, and congratulations on the v1.3 turnaround. Correcting a canary within six hours of a report is rare, and the way you handled the AV-003 through AV-005 drift set the tone for the whole thread. Two follow-ups, both in the same spirit as the vectors. On the reference implementation: the Quick Start clone target and the engine repository both return 404 for me, and I cannot find Rulsynor published anywhere. Neutrality is measured across implementations, so if the Concordia runner is currently the only one a reader can execute independently, the README would be stronger for saying that plainly rather than leaving a second implementation to be inferred. On wording: "agents cannot bypass it" is stronger than an in-process evaluator can demonstrate. Mediating every call that arrives is a real and useful property, and claiming exactly that will hold up better under adversarial review. Erik |
|
Haoran, thank you. The README and SPEC §12 changes will make the current state exactly checkable, and yes to the pre-release cross-verification of rulsynor, same protocol as the vectors: implemented from the spec text alone, no answers file. One note in the same spirit: I could not locate commit 4770ca8 in any of the public OpenOBA repositories, so I cannot re-verify the new mediation wording yet. Once it is publicly visible I will re-run the check. And a small request on attribution: when these results travel, the durable form is the measurement rather than the adjective. "Concordia reproduced twelve of thirteen byte-perfect under an independent canonicalizer, with the canary discriminating as designed" is checkable by anyone; a quoted opinion is not. Erik |
|
Erik, Both commits are now public — 4770ca8 on erdl-landing and 6e6d3e2 on erdl-vectors. You should be able to verify the new wording. Measurement noted and adopted: "Concordia reproduced twelve of thirteen byte-perfect under an independent canonicalizer, with the canary discriminating as designed." That is how it will read when it travels. On a related note: the 404 and outdated README you ran into reflect something we have not yet formalized — a neutrality governance policy that keeps the specification, reference implementation, and public-facing documentation in lockstep. Our operations team is working on this, and we are actively reaching out to more potential independent runners. If you have thoughts on what a neutrality policy framework should look like, we would be glad to hear them. I will follow up with the README/§12 updates and the rulsynor pre-release build. Tang Haoran |
|
Haoran, one thought from having just rebuilt our own version of this. We found our repo failed several checks we would have applied to anyone else, fixed those, and replaced the policy idea with generated, checkable artifacts. docs/CONFORMANCE.md is produced from a claims manifest where each claim is bound to an executable check that runs in CI, including a clean-room job that verifies the interop fixtures with Concordia uninstalled. And conformance/ now carries 236 implementation-agnostic vectors (11 positive, 222 mutations, 3 canaries that catch regressed runners) with a runner contract (conformance/RUNNER_CONTRACT.md) implementable from an RFC 8785 library, Ed25519, and JSON Schema alone. A policy promises future conduct. A generated document describes present, checked state. For ERDL the ingredients already exist: in-repo vectors, spec-implementable, no answers file. |
|
Haoran, following up on the runner-contract pointer above: coverage is now complete across every signed record type the reference SDK emits (over 1,500 vectors, all expected outcomes executed at generation time, canaries included). If you want to point rulsynor at it, the runner contract is implementable from its own text with an RFC 8785 library, Ed25519, and a JSON Schema validator; the reference runner refuses to run if our SDK is importable, so any result you get is independent by construction. Same protocol you offered us on the vector set: implemented from the contract alone, no answers file. Independent results are recorded in conformance/IMPLEMENTATIONS.md with method and date, as measurements; the registry confers nothing and records exactly what was measured. |
|
Erik, This is brilliant — exactly the nudge we needed. Maintaining the repo has been our biggest headache, especially keeping a pile of documentation aligned and consistent — that's honestly a weak spot for us. Your approach — "a generated conformance artifact describes what you have done, and proves it on every CI run" — solves this problem outright. No ambiguity. We have the raw ingredients already — the v1.3 vectors, the implementer's guide (which is de facto a runner contract), the no-answers-file design that Concordia already validated end-to-end. What's missing is the generator that turns CI output into a checked-in CONFORMANCE.md, and an IMPLEMENTATIONS.md registry that measures without conferring. We'll follow your lead on both — and on the clean-room job that verifies with the reference SDK uninstalled. Thank you for building this pattern and proving it works at 1,500-vector scale. It's the right architecture for spec neutrality, and we'll adopt it. Haoran |
|
@haoran-tang-ch Glad the generated-artifact pattern fits. If you sequence it, the clean-room job with the SDK uninstalled is the piece I would land first: it is the one that catches hidden SDK dependence, and the rest composes on top. |
|
@haoran-tang-ch One detail worth pinning before this ships: as described, the clean-room verifier compares its recomputation against the answers file. That is the reproduction check. The July lesson was that a runner can pass that oracle while never checking each artifact's own claimed |
|
@erik-newton Good catch, and thank you for pinning this before ship. A few clarifications on our current state after your feedback: Our verify.js has always done Check 1 (audit.hash self-consistency). The five-step JCS+SHA-256 verification recomputes the hash from scratch and compares against the artifact's own audit.hash — this is the deployment-scenario verification you described. So the gap wasn't that we were only comparing against the answers file; it was that we weren't doing the reverse cross-check. What we added based on your feedback: Check 2 (answers file cross-comparison). The clean-room now runs both: Check 1: recomputed JCS+SHA-256 hash vs artifact's claimed audit.hash (63/63 DO + 11/11 AV MATCH) AV-013 under dual verification: Check 1: MISMATCH ✓ (correct runner's hash ≠ regressed stored hash — canary active) Changes are live in erdl-vectors@1a86b4d and the CI workflow now runs dual verification on every push. Spec and runner's guide updated accordingly. Thoughts? |
|
@haoran-tang-ch Dual verification is the right landing point. I would make RUNNER_CONTRACT.md the normative behavior spec: what a conforming runner recomputes, which fields are excluded from the preimage, and which failures must surface. Keep the answers file and canonical bytes as diagnostic proof: a useful byte-level oracle, separate from the rule being tested. That gives you both properties: a human-readable contract an independent implementation can follow from first principles, and an oracle that catches byte drift. The acceptance test I would pin is AV-013: evaluated against the claimed contract with the reference runner absent, it still discriminates. |
|
@erik On the split. RUNNER_CONTRACT.md as the normative behavior spec + answers file as diagnostic oracle — this is the right structure. The content already exists in RUNNERS-GUIDE.md, just written in tutorial form rather than RFC 2119 language. Extracting the MUST/SHOULD/MAY clauses into a standalone contract is the right move. It gives future runners exactly what they need without reading 400 lines of tutorial first. On AV-013 as the pin. Fully agree. The acceptance test is: can a runner that only reads RUNNER_CONTRACT.md (no reference code, no answers file) correctly produce a MISMATCH on AV-013? That's the bar. AV-013 already does this — just needs the contract to make it explicit. On why this matters beyond documentation. This isn't a file reorganization. It's the difference between "compatible with OpenOBA's verify.js" and "conformant to an independent, auditable specification." The former makes runner recruitment about trusting our implementation; the latter makes it about implementing a public contract. That matters for the 3rd, 4th, Nth runner — and for enterprise compliance teams who need a spec they can hand to their own auditors. I'll draft RUNNER_CONTRACT.md from the existing RUNNERS-GUIDE.md content and share it for review. Should land within a few days. |
|
@eriknewton — it's been a while since your last check-in, and no pressure at all — but a lot has landed, and your name is written through it: the acknowledgments credit you as the first independent runner, the canary design, and the answer-file separation. v1.5 is live, and the vectors are frozen. Decision Object v1.5 (flat-hash + expression-tree, erdl-do-v1.5-hash-flat), 78 hash-layer vectors (V-DO-v15). The preimage ambiguity you flagged in July got resolved — and it flipped: v1.5 deletes only audit.hash, and the K01 canary now discriminates exactly the two readings you caught (a runner that deletes the whole audit object reports MATCH and gets caught). Your bug report became a permanent vector. The first third-party v1.5 runner is in. Santosh Kumar Puppala built norviq-go — Go, zero dependencies, self-built JCS + crypto/sha256 — from RUNNER_CONTRACT R1–R6 + the verifier guide alone, clean-room, didn't read verify-v1.5.js, and hit 107/107 canonical bytes byte-for-byte (merged 2026-09-01). His feedback also drove §1.4 (production-side invariant), §1.5 (decision-derivation semantics), §1.6 (Producer Contract + V-PRODUCER), and the P6 resolvable-set clarification. Your recommendations became the contract. RUNNER_CONTRACT.md is now the normative R1–R6 behavior spec — recompute, field exclusions, must-surface failures — with the answers file demoted to diagnostic, the dual structure you pushed for in August. And the registry records "who passed how many on what date" — measurements, not adjectives. The invite — and it's the bar you set yourself. In this thread you pushed for "three independent implementations." v1.5 now has two of the three: the Node reference and norviq-go (Go). Concordia in Python would be the third — three languages, three independent implementations, byte-identical. You ran v1.0 through v1.3 as the second runner; v1.5 is the next one, and it's waiting on its third implementation. No deadline — the vectors are frozen, so it's a stable target whenever you have the cycles. Entry points: Repo: OpenOBA/erdl-vectors |
|
Interesting proposal. I'm curious how ERDL would handle a case where the behavioral rule is satisfied locally, but authority has changed across a multi-agent delegation chain. For example: Principal → Agent A → Agent B → privileged Skill Agent B may be permitted to invoke the skill, but Agent A may not have been authorized to delegate that capability for the originating task. I'm particularly interested in whether an invariant such as “delegation MUST NOT amplify effective authority” could be represented cleanly through Agent Card metadata versus requiring task-level/runtime authorization context. |
|
Hi @haoran-tang-ch , Thank you — this mapping is extremely helpful, particularly the concrete correspondence between SA/EA and trust_radius/max_autonomy. I agree with all three refinements: INV-01: add bounded delegation depth and anti-loop semantics alongside non-amplification. I also agree with promoting AV-06 Capability Boundary Laundering into a full invariant. I suggest: INV-05 — Capability-Boundary Non-Amplification: For the negative vectors, I also like the attributable-rejection requirement. A passing implementation should produce a DENY tied to the violated invariant and the relevant authority provenance, rather than merely rejecting the operation. I would prefer to move toward a shared draft + conformance vectors now. My proposed next iteration would contain: refined INV-01 through INV-05; For the two open problems, I think we can keep the invariants normative while keeping the mechanisms deliberately open: Transitive revocation: every authority-sensitive boundary evaluates whether the delegation lineage remains valid before exercising derived authority. Capability-boundary enforcement: authority carried from agent → skill → tool → protected resource remains bounded by the originating task authority regardless of the standing privilege of downstream components. If that direction works for you, I'm happy to prepare the next revision around the shared draft/conformance-vector structure. |
|
Hi @haoran-tang-ch , Thanks again for the detailed review. I've incorporated the feedback into the existing draft and pushed the revised version. Key updates include:
I kept the security properties implementation-neutral as discussed. I'd particularly value your review of INV-04 and INV-05, especially whether the capability boundary should reuse delegation semantics or be modeled as a distinct authority axis. If these properties look aligned, I'd be happy to take the next step toward a shared conformance-vector draft. |
|
Hi @RavindraAnnam — thank you for the v0.2 revision. Every refinement landed in the right place: depth/loop safety as a check separate from the authority ceiling (INV-01), temporal ordering as Q8 — the capability boundary is a distinct axis, with a shared law. Your two options aren't mutually exclusive; the right answer is their synthesis. The precise split:
On the capability axis this law has a clean constructive form. Because the child's quantity ( Because this is an intersection, non-amplification holds by construction — nothing to "prove" at runtime, only a meet to compute. (This is the object-capability model's attenuation property — Miller, Capability Myths Demolished — stated for agent runtimes.) The delegation axis obeys the same law, but there the child's standing quantity (
The primitive: an unforgeable, attenuatable, task-scoped capability (no ambient authority). The weak option — the one most runtimes ship today — is ambient authority + a boundary interceptor: the skill/tool inherits the runtime's permissions, and a guard checks each call. This is structurally fragile because the downstream component's technical capability is ambient: Tool T can write R, and the guard must catch it every single time. Confused-deputy and capability-laundering (AV-06) are exactly the cases where the interceptor is bypassed or the boundary isn't where you think it is. The strong option is to make the capability explicit:
Under this model, AV-06 is structurally impossible, not merely caught: Tool T can write R only if it holds a The load-bearing reframing: In the ambient model, is not "check that S's broad abilities stay inside A's task authority" (which forces an interceptor to enumerate S's abilities); it's "of the capabilities A's task carries, hand S exactly those S's interface accepts" (which requires only routing, not enumeration). Skill, tool, and resource become first-class capability endpoints with a declared interface, rather than ambient privilege holders an interceptor must watch. Enforcement: a PEP at every boundary, capability as the only reach. Each boundary has a policy enforcement point whose job isn't "check a policy and let ambient authority through" but "route the capability token": (1) validate the token (unforgeable, unspent, unrevoked, valid lineage), (2) bind the resource reference to that token — the downstream receives exactly the references handed to it and nothing else. The downstream's reachable surface is exactly its capability set. Provenance and revocation ride the same chain.
On §10 — the attributable-rejection example is the same shape as our Decision Object. Your example evidence block — — carries the same semantic fields as the Decision Object this design specifies at each enforcement boundary (decision, matched invariant, task/authorization context, boundary, requested action, effective authority, deterministic reason). It's a good sign that two designs converged on the same structure: it means your §9 conformance matrix is directly implementable against that object, and each "minimum verifiable evidence" cell becomes a field assertion rather than a prose requirement. One consequence for the vector set. Under the explicit-capability model, AV-06's failure mode changes character: the laundering capability was never minted, so the offending action is unreachable, not merely "denied". The strongest conformance evidence for AV-06 becomes "the capability for this action could not have existed" (provable from lineage), rather than "we emitted a DENY". (AV-04/07 are rejected at mint time; AV-05 fails at spend.) Note the asymmetry: this unreachability is specific to the capability axis — the delegation-axis vectors (AV-01/02/03) remain bounded by the Where to take it next. I've kept this at the normative/invariant level throughout, deliberately leaving the enforcement mechanism implementation-neutral — exactly as your note frames it. I'm glad to have you fold the design into the shared draft, and I'll review the INV-04/INV-05 rows with the same care as this round. Happy to keep iterating on the spec at whatever pace works for you. |
|
Thanks @haoran-tang-ch — this resolves Q8 cleanly for me. I agree with the synthesis: delegation and capability are distinct authority axes, but both should obey the same non-amplification law. The distinction between standing authority (SA) for principals and technical-capability interfaces (TC) for skills/tools/resources avoids treating a capability endpoint as though it were another autonomous principal. I also agree that INV-05 becomes stronger if the capability boundary is modeled constructively rather than only as a runtime check: EA(S,T) = EA(A,T) ∩ TC(S) with every subsequent transition required to attenuate, never broaden, the authority carried by the originating task. One point I would like to preserve explicitly in the normative language is that technical capability must not be interpreted as ambient authority. A tool being technically capable of an operation must not make that operation reachable unless the originating task carries corresponding authority through a valid delegation/capability lineage. I would therefore refine INV-05 along these lines: INV-05 — Capability-Boundary Non-Amplification Invocation of a skill, tool, or protected resource MUST NOT increase the effective authority of the originating task. Authority crossing a capability boundary MUST be derived from existing task authority and MAY only be attenuated. Technical capability alone MUST NOT confer executable authority. I also agree with the INV-04 refinement: revocation should be evaluated at the enforcement boundary before authority is exercised, with fail-closed behavior when current revocation state cannot be established, while leaving the propagation/freshness mechanism implementation-neutral. For the conformance vectors, your observation about AV-06 is important. Under an explicit-capability implementation, the strongest evidence is not simply a DENY; it is demonstrating from lineage that the unauthorized capability could never have been minted or derived. I’ll preserve that distinction so the vectors remain implementation-neutral while allowing stronger implementations to demonstrate prevention by construction. At this point I think further discussion in the abstract has diminishing value. I’m happy to move this into the shared draft + conformance vectors. I’ll fold the agreed refinements into the next revision, particularly: INV-01: authority ceiling + separate depth/loop safety Once that is aligned, I’d like to pressure-test the combined model across the full path: Principal → Agent → Agent → Skill → Tool → Protected Resource including mixed delegation/capability chains, because that is where individually valid boundaries can still compose into unintended authority. Thanks again for the detailed review. I’m happy to proceed with the shared draft. |
|
Thanks @RavindraAnnam — glad we converged, and the INV-05 tightening is right. Since you're folding the refinements yourself, I'll stay in reviewer mode and weigh in on each revision you post. If it's useful, our Decision Object + conformance vectors (three independent runners, byte-for-byte) are available as a reference for the attributable-rejection and conformance-matrix cells — point at them rather than re-specifying. Proceed with the pressure-test; I'll review when the draft lands. And if a specific piece later needs more than review — the vectors included — just say the word and I'm glad to pick it up. |
|
Behavioral rules on an Agent Card are policy. They still need a PEP that will not run the side effect without a signed unspent grant. Why decision-os-min exists: permission/identity answers are not enough once a machine can cause an email, payout, or deploy. Something must sign an action-bound decision, spend it once, and refuse the tool otherwise. Cedar/OPA/MCP OAuth stay PDPs or identity. The agent never holds the key. Not a Cedar competitor; not an AGI-safety proof. https://github.com/Aliipou/decision-os-min/blob/main/docs/WHY.md |
|
Hi @Aliipou, Thanks for this — it's a sharp framing, and you're right on the core point: policy that isn't backed by a mandatory mediation point is just advice. The distinction between "may this principal do this" (PDP) and "has this specific effect been authorized, and will it run exactly once" (the checkpoint) is the one that really matters once an agent can send mail, move money, or deploy. One honest note on positioning: in our v2.0 spec we're trying to cover both sides, not just the policy layer — the deterministic layer acts as that mandatory mediation point (an Action Guard every tool call must pass through), and each decision becomes a Decision Object that is action-bound (agent_id + tool_name + decision), optionally signed (ECDSA P-256), and anchored into a hash chain before the side effect runs. So we converge on the same checkpoint from a different direction — more than the "policy" label alone suggests, and I don't think either of us wants to claim the whole space. Two of your primitives are genuinely sharper than our working notes, and worth naming as such: One-time capability — mint, bind to one action, spend on first use. We get the same effect implicitly: each action yields a fresh Decision Object bound to its context, with a chain sequence that prevents replay. But "a permitting decision mints a single capability token, spent on first use" is a cleaner primitive to reason about than "fresh DO per action." We'll study it. |
|
@haoran-tang-ch thank you — this is the useful comparison. Agreed: a rule on an Agent Card that nothing is forced to pass through is advice. We are talking about the same checkpoint class. The difference I want to keep named, not scored: a Decision Object that the same in-process evaluator can mint is still a verdict. A grant the acting agent cannot mint, bound to one action and spent once, is a capability. Those can be composed. They are not the same artifact. Your Action Guard + hash chain is mediation and audit. If the signing key is reachable from the acting agent, the agent can still authorize its own effect. That is the pressure test I meant: the agent never holds the key. Happy to keep the exchange on that line. decision-os-min is the reference for the grant/spend side; TM-A full is still PARTIAL (isolation residuals). Not a claim that ERDL is “just policy.” |
|
@Aliipou — thanks, this keeps the exchange sharp. I accept the naming as-is: a per-action verdict minted by the in-process evaluator is one artifact; a pre-minted, single-action grant the acting agent cannot mint is another. They compose; they're not the same thing. No argument. On the pressure test, let me answer it head-on rather than around it. In the five-power model (§5.9), the signing power is the Agent's key, but its mechanism is attribution proof only. The power that authorizes a side effect is judgment power — Action Guard adjudication, owned by the deterministic layer, not the Agent. So "the Agent can sign its own effect" is not "the Agent can authorize its own effect" — the latter requires reaching the Guard's adjudication, which is precisely the thing the Agent must not hold. The honest residual — which I read as your actual point — is that this only moves the boundary one level up, to "does the Agent reach the Guard?" That's an isolation question, and I won't claim we've closed it. Isolation residuals are real for us too; symmetric to your PARTIAL on TM-A. Where your primitive is sharper than ours: we encode spend-once implicitly (commitment {agent_id, tool_name, decision} + chain_seq); you make it explicit (mint/spend, agent cannot mint). For the "agent can never mint its own grant" case, the explicit capability is the cleaner primitive — worth studying decision-os-min on that line. And noted — not "just policy." Same checkpoint class, seen from the two sides of the mint boundary. |
|
@haoran-tang-ch I accept the naming: in-process verdict and un-mintable grant are different artifacts. I also accept the isolation residual as named — you did not claim it closed. I do not accept that §5.9 settles the pressure test. If signing is “attribution only” and judgment sits in an Action Guard the Agent process can still reach, you have moved the question to reachability, not answered it. Naming two powers is not a boundary. The residual you admitted is the whole remaining claim. Spend-once as implicit |
|
@Aliipou — accepted on the naming point, and let me put the actual mechanism on the table rather than stop at agreement. The synthesis I'd commit to, concretely: The Action Guard becomes a separate trust domain — not a worker thread inside the Agent's process, but a process/service with OS-level isolation, holding its own Ed25519 key the Agent process can never read. Every adjudication is signed by that key: the Decision Object carries an authorization_signature produced by the Guard. The Agent's key is retained only for attribution ("the agent proposed this"), never for authorization. The enforcement point (PEP) executes a side effect only against a decision carrying a valid Guard signature — so "the agent signed its own effect" is inert: the agent physically cannot produce the one signature that authorizes execution. So the boundary is no longer "the agent can't reach the Guard" as a design claim; it becomes "the agent can't produce the authorizing signature" as a cryptographic fact — the same shape as your "agent never holds the key", applied to a per-call complete-mediation adjudicator rather than a pre-minted grant. The residual that remains is the one you already named: the isolation quality of the Guard's trust domain (process vs. container vs. TEE) — which neither of us has closed to "agent can never reach it, full stop." Does that land as settling the pressure test on your view, or is there a hole in it I'm still not seeing? |
|
If this is useful, please star the public edition so other philosophers and labs can find it: https://github.com/Aliipou/freedom-theory Book + sixteen-chapter path + justification. CC BY 4.0. Not a Cedar/OPA competitor. |
|
Looking for collaborators on decision-os-min — the authority + audit PEP, not a Cedar rewrite. We need people who will try to mint or run an effect without a signed unspent grant; Hosted-plane / TM-A isolation (still PARTIAL); Cedar/OPA adapters that cannot mint. Call + how to join: Aliipou/decision-os-min#3 |
|
@chopmob-cloud — it's been a while since the v1.3 release, and no pressure at all — but v1.5 has landed, and you should know how much of it is built on your findings. The flat-hash architecture is now the core of v1.5 — erdl-do-v1.5-hash-flat. Your v1.2/v1.3 findings — the missing self-reference hash-exclusion rule, the cross-engine string-decimal inconsistency, the layered-integrity gap — are exactly what drove it, and the acknowledgments say so plainly. The C1–C4 and S1–S3 findings (including the CWE-757 dual-hash downgrade and the schema_ref SSRF surface) are part of why the new RUNNER_CONTRACT is as tight as it is. What's new since you last looked: 78 hash-layer vectors (V-DO-v15), frozen. The preimage rule flipped from v1.3: v1.5 deletes only audit.hash, and the K01 canary discriminates exactly that split. Entry points: Repo: OpenOBA/erdl-vectors |
|
Erik — this is fantastic. Exactly the result we hoped to see: a pure-Python, clean-room implementation that reproduces all 78 v1.5 vectors and 107 decision objects byte-for-byte from the spec text and frozen vectors alone, with the K01 canary discriminated cleanly. Sincere thanks for the effort — it's the strongest evidence yet that the spec is precise enough to support independent implementation. Two notes and one request:
On receipt I'll:
Your numbers — 90 MATCH + 17 expected MISMATCH on Check 1, 107/107 policy hashes, 106/107 profile hashes (1 expected tampered) — match the reference verifier's expected breakdown. Looking forward to the PR. |
|
Haoran, thank you. I’m happy to open the PR with the runner, tests, documentation, and submission envelope in the requested layout. One precision for the record before Check 2 runs: my runner emitted canonical bytes for all 107 applicable decision objects, but my side has not established 107/107 byte identity. Under R6, that conclusion belongs to your closed-answer-file comparison. If Likewise, the 78/78 result means every vector reproduced the four compared expected subkeys: Your confirmation that the Check 1 and intra-field breakdown matches the reference result is useful independent corroboration. When registering the implementation, please preserve the measured scope: hash, field, and chain layer; I’ll keep those boundaries explicit in the PR. |
|
Erik — agreed on all three points, and thanks for stating them so precisely.
Please open the PR whenever ready — I'll run Check 2 and register against the measured scope. Keeping the boundaries explicit is exactly the rigor this process is for. |
|
Haoran, thank you — especially for meeting the precision here with equal precision. PR #2 is now open, with the exact envelope and immutable links to the runner, tests, and documentation. I deeply appreciate the spirit in which you’ve handled this: independent work, honest boundaries, and letting the evidence settle the result. Whatever Check 2 returns, we now have a clean result we can learn from together. I’ll leave the cross-check and measured registration with you. I’m very glad to see Concordia and ERDL meet at this byte-verifiable boundary—and I look forward to continuing the collaboration. |
|
Erik — thank you, and the appreciation is mutual. Meeting precision with equal precision is exactly what makes this trustworthy. And the result is already in: Check 2 returned 107/107 byte-identical, K01 discriminated correctly, zero dead keys. PR #2 is merged, and Three independent implementations — Node.js reference, norviq-go, concordia-python — one open spec, no single owner: now measured, not just proposed. I'm very glad to see Concordia and ERDL meet at this byte-verifiable boundary too, and I look forward to continuing the collaboration. |
ERDL: status update + open calls (expression-layer runner & technical reviewer)Status — all three repos are now published (GitHub + npm/PyPI, CI green):
Two open calls: 1. Expression-layer runner. The audit layer already has two independent runners (Go + Python) matching Decision Object hashes byte-for-byte from the spec alone — no reference code, no answer file. The expression layer has none yet: 239 vectors, bounded and well-specified (~a day or two of focused work), with permanent attribution in 2. Technical reviewer. The spec (notably §7 resolution semantics) has benefited from sharp external review — each round caught real gaps between what the spec claimed and what the engine and proofs implemented, and each finding rolled forward into a spec clarification + engine fix + proof. We'd welcome more of that: review the spec, the engine, or the SMT proofs, and report any drift. Links:
Neutrality is measured, not claimed — both slots are genuinely open. |
|
Hi @haoran-tang-ch , I'd be glad to take the technical-review track. Given our earlier work in this thread on authority non-amplification, provenance continuity, narrow-only constraint inheritance, transitive revocation, and the associated adversarial conformance cases, I'd like to review the current specification specifically for semantic drift across the spec → engine → formal verification boundary. I'll focus first on the delegation/runtime-authority seams we previously identified, including:
I'll report concrete findings against the relevant spec sections and, where applicable, suggest corresponding negative/conformance cases. I'm also interested in the expression-layer runner, but I'd like to keep that separate so any implementation can be evaluated against the runner contract on its own terms. Happy to start with the current v2.1 spec. |
|
Hi @haoran-tang-ch — first concrete review finding from comparing v2.1 §5.2/§7 with the current evaluator. For
In That seems to create a reproducibility/evidence gap:
then
So the earlier decision that mutated the state may not carry the state transition needed to independently reconstruct why the later decision differs. Would it make sense for the output/audit contract to capture temporal-state transitions whenever a stateful operator reads or mutates state, rather than only when its containing rule ultimately matches? A discriminating vector could run two sequential evaluations of the same |
|
@haoran-tang-ch — second concrete spec/engine drift I found in §7 evaluation evidence. The v2.1 output contract defines In the current evaluator, however, the value is derived inconsistently:
These can diverge from the number of rules that were actually evaluated. For example:
Two rules were evaluated, but The inverse can also occur on the normal path: rules skipped due to catch-all inertness or Would it make sense to maintain an explicit evaluation counter incremented only when a rule's A useful conformance vector would include:
and assert the exact |
|
Hi @haoran-tang-ch , one formal-assurance scope question from reviewing The resolution properties are checked as UNSAT for I couldn't find, however, an induction argument or other generalization step establishing that these results extend to arbitrary rule-set length. There also seems to be a small wording distinction worth clarifying:
Unless there is a padding/neutral-rule argument elsewhere that I missed, would it be more precise to describe these as bounded proofs for the checked cardinalities rather than an unqualified proof over all rule-set sizes? If the intended claim is genuinely unbounded, it may be useful to make the generalization argument explicit — e.g. an inductive invariant over the resolution fold — so the assurance boundary is independently auditable. Happy to follow a proof/generalization reference if this is already established elsewhere. |
|
Thanks for taking this on — and I owe you an apology before anything else. When we closed out Discussion #2031, I said "Adopting it" to the four runtime-authority invariants you proposed, and invited you to draft the security note, which you did — INV-01 through INV-05, with the adversarial conformance cases. Then we went quiet on that thread. The reason isn't that the work was deprioritized; it's that we had to finish the single-agent deterministic kernel first — expression kernel, resolution semantics, the Decision Object, and the SMT verification layer — and that effort ended up consuming our full attention. Those invariants sat in your note without ever being folded back into our spec, and I never came back to close the loop. That's on me, and I'm sorry for the silence. The single-agent work is now essentially wrapped — the resolution/verification layer just shipped, and the kernel is at the point where the deterministic foundation is stable enough to build multi-agent governance on top of it. So this is the right moment to pick up exactly the thread you opened. Before I ask you to invest more time, here's the mechanism I'd propose, for you to consider:
If this mechanism works for you, I'll start by drafting the multi-agent governance section around your INV-01–INV-05 and share it for your review. If you'd rather structure it differently, I'm happy to follow your lead. Thank you for the patience, and for keeping the rigor on this while we finished the foundation. |
|
One more thing I should have said explicitly — thank you for the erdl-landing review itself, not just the multi-agent thread. Your four posts covered the evaluator and the verification layer, and one of them surfaced a real defect I want to describe back to you, because your phrasing actually located something we had been circling without naming. The finding was the
The reason this stung more than an ordinary bug: it's the one place where ERDL's "the expression tree is a pure function" claim has to bend. State has to live somewhere, and the spec had tucked it behind a one-line exemption — "state is maintained by a separate state manager, entering the audit record as What we found is that there is no off-the-shelf answer here. Cedar and OPA simply do not have stateful operators, so they never face this. Redis INCR handles counting but not auditability. Event Sourcing gives the right principle — a side effect is an event, and the record must be written before the effect, not reconstructed afterward — but no one has applied it to a stateful policy operator. We are effectively the first to try to unify "stateful operator + deterministic audit + cross-decision reproducibility," which is exactly why this point keeps getting attacked. The direction your finding points to, and the one we're now leaning toward: a state mutation is the event, so it should be recorded the moment it happens — I've written the full analysis up as a research note, and I'd genuinely value your read on that direction when you have the bandwidth — you located the seam; I'd like your judgment on whether the fix closes it or just moves it. Thank you again — for both threads. |
|
Thanks, @haoran-tang-ch — and no apology needed. The sequencing makes sense, and I appreciate you coming back to close the loop now that the deterministic foundation is stable. The mechanism you proposed works well for me. I especially like the closed loop of invariant → normative spec requirement → engine behavior → adversarial conformance vector → independent verification. That makes the delegation-authority properties testable rather than leaving them as security guidance. I’m happy to co-review the multi-agent governance section around INV-01–INV-05 and the capability-boundary axis, and I’m also open to independently running the resulting delegation-authority vectors. As we formalize it, one property I’d like us to preserve explicitly is that delegation must never manufacture authority. Replanning, transitive delegation, privileged intermediaries, downstream constraint changes, or revocation must not allow effective authority to exceed or escape the originating authority chain. If we can express that cleanly in the normative semantics and prove it through the adversarial vectors, I think we’ll have a strong foundation for multi-agent governance. Please go ahead with the first draft. I’ll review it against the original invariants, delegation semantics, capability boundaries, and adversarial cases and provide concrete findings where needed. Looking forward to working through this with you. |
|
Thanks, @haoran-tang-ch — I really appreciate you writing out the analysis this precisely. I agree that this is deeper than an implementation bug. The write-ahead direction makes sense to me. If within or rate mutates state, that mutation is itself part of the decision history, even when the current rule ultimately returns false. Recording temporal_state only on a later match loses exactly the evidence needed to reproduce how that later state was reached. I’d frame the invariant roughly as: every state transition that can influence a future policy decision must produce durable audit evidence at the point of mutation, independent of whether the current evaluation matches. The main thing I’d want to examine in the research note is whether the event record captures enough information to make the transition independently reproducible — not just the resulting counter, but the relevant prior state, transition/input, ordering, and resulting state — and how this behaves under retries, concurrency, and failed/partial evaluations. Otherwise we could close the missing-event gap while still leaving ambiguity in reconstruction. So yes, I’d be very interested in reviewing the research note. Send it over when ready. I’ll look specifically at whether the write-ahead semantics close the original evidence gap without introducing a new determinism or replay gap. |
|
Hi Ravindra, The design document is ready for your review — please take a look when you have a moment: It maps your five invariants and eight adversarial vectors onto the Rulsynor delegation model, answers the eight co-review questions (Q1–Q8), and adds our own audit of the vector suite (§10) with a few proposed refinements. Take your time — happy to go through it point by point once you've had a read. |
|
Thanks, @haoran-tang-ch — appreciate you putting this together and mapping the invariants and adversarial vectors into the design. I’ll go through the DESIGN.md carefully, including Q1–Q8 and the §10 vector-suite review, and come back with my findings and recommendations. Looking forward to reviewing it. |
|
Thanks @haoran-tang-ch — I went through the authority representation and I think Q1/Q2 need one important distinction before this hardens. I would avoid defining:
because the constraint envelope should narrow authority, but should not itself become the authority source. For example, a downstream delegation containing:
must not acquire that authority merely because those constraints appear in a valid Decision Object. I think the model is safer if effective authority is derived recursively:
and therefore, across a chain:
subject to current revocation / validity state at the enforcement boundary. That preserves the distinction between:
There is a related point in Q2. A new Otherwise a downstream actor could potentially turn “new Decision Object exists” into an authority-expansion primitive. I would therefore treat legitimate re-authorization as a separate authority lineage/basis, rather than silently increasing the ceiling of the original delegation chain. That would also make INV-01 stronger and easier to test: every exercised authority should be traceable either to the original authority chain or to a separately validated authorization basis; constraints alone must never manufacture authority. |
|
Hi @haoran-tang-ch - One more point on Q4/Q7 — I think the revocation mechanism needs an explicit freshness condition at the enforcement boundary. The lineage-walk/tombstone model handles what to check well, but with eventual consistency there is a distinction between:
and
Suppose authority is revoked at the source at state/epoch So I don't think authorization should depend only on:
It also needs evidence that the revocation view satisfies an explicit freshness requirement. Conceptually:
The freshness proof could be implemented in different ways — bounded leases, monotonic authority/revocation epochs, signed checkpoints, or another versioned-state mechanism — so I don't think the invariant needs to mandate one implementation. But I would make the security property normative:
A useful adversarial case would be:
Expected result: That would make INV-04 test not only revocation propagation, but the harder stale-negative case where the boundary cannot yet see the revocation. |
|
Taking the expression-layer runner call. Concordia now has an independent Python |
Uh oh!
There was an error while loading. Please reload this page.
A2A's Agent Card defines what an agent CAN do — its capabilities, skills, endpoints. This is powerful. But it doesn't define what an agent SHOULDN'T do in a given deployment context.
Proposal: Agent Card extension for behavioral rules
{ "extensions": { "erdl": { "protocol": "erdl/v1", "rules_file": "agent.erdl.yaml", "guardian": "did:erdl:guardian-main", "trust_score": 850 } } } This would let: Agent B know what behavioral rules Agent A operates under — before accepting task delegation Guardian Agents discover rule profiles of observed agents through Agent Card exchange Multi-agent workflows pre-validate rule compatibility at the protocol level What ERDL provides ERDL (Entity-Rule Definition Language) is an open standard (MIT) for agent behavioral rules: 11 operators (within, rate new in v1.0) 16 deterministic action types (ALLOW → EMERGENCY_HALT) Execution Rings (Ring 0–3) Guardian Agent / Observed Agent model SafeExpr engine (zero code injection) Structured audit trails exporting to OTLP/OCSF Deliverables Landing Page: openoba.github.io/erdl-landing Spec v1.0 (EN): github.com/OpenOBA/erdl-landing/blob/main/spec/index-en.md Reference Implementation: github.com/OpenOBA/ERDL Question for this community Does extending Agent Cards with a rules profile make sense for A2A? Are there existing or planned mechanisms in A2A for communicating governance/security posture between agents? Happy to contribute a formal RFC if there's interest.All reactions