Intent to author Extension URI: A2A Procurement Profile (UBL / Peppol / OCDS / eForms aligned)

[brainspacer]

Intent to Author — A2A "Procurement Profile" Extension URI

• To: A2A Project TSC / a2aproject/A2A GitHub Discussions
• CC: Mazin Gilbert (Executive Director, AAIF); SAP Joule / Ariba product leads
• From: Brian P., BidAngel
• Subject: Intent to author an A2A Extension URI for procurement (RFx, supplier capability claims, buyer scope) — UBL / Peppol / OCDS / eForms aligned
• Date: 2026-05-10
• Public spec repository: github.com/bidangel/a2a-procurement-spec

---

Dear A2A maintainers,

We intend to author an A2A Extension URI scoped to B2B procurement — specifically the solicitation, supplier-capability, and evaluation segments of the source-to-award lifecycle. This note is to surface the work early, invite collaboration before we publish a draft URI, and ask whether anything materially overlapping is already in flight that we should join rather than parallel.

Why this profile, why now

A2A's Extensions mechanism explicitly invites vertical work, and procurement is a domain where (a) buyer and supplier agents need to exchange evidence-backed assertions across organizational boundaries, (b) document formats are heterogeneous (CAIQ, SIG, Ariba DDQ, SAM.gov solicitations, OASIS UBL 2.3, Peppol BIS Pre-Award 1.0, OCDS 1.1.5, EU eForms per Implementing Regulation 2019/1780), and (c) no public extension or working group has yet staked a profile.

With SAP Ariba's Bid Analysis Agent reaching GA this quarter and Coupa's "A2A collaboration" entering product vocabulary, the ground is shifting from product-level toolkits toward a need for shared semantics. We would rather contribute one than ship a private dialect.

What we propose to contribute

Four concrete artifacts from BidAngel's open architecture (durable ADRs in our repository), each procurement-neutral once tenant-scoping is removed:

1. Capability-claim noun. A typed, evidence-linked supplier assertion with kind discriminator (certification, past-performance, capability-statement, jurisdiction-coverage, other), supersession-not-edit, and freshness composed at read time from calendar validity, evidence freshness, review age, and approval state. Reference: BidAngel ADR-0025, Slice 68 (shipped).

2. Buyer-scope filter algebra. A declarative scope shape an agent can advertise on its AgentCard and a counterparty can narrow within: kind allowlist, AND-across-families / OR-within categoryFilters, jurisdictionFilters, freshnessFloor, supplier-veto denylist, and a three-tier evidence-dereferencing mode (redact_all / redact_asset_id_only / reveal_metadata). Reference: BidAngel ADR-0031, Slice 85 (shipped).

3. Structured RFx adapter contract. A format-agnostic orchestrator producing three canonical fragment kinds — opportunity, evaluation_criterion, requirement — with per-row provenance and per-row subtype discrimination (the requirement fragment carries narrative vs questionnaire as a typed subType, replacing an earlier separate questionnaire_row kind that was retired as duplicative). Each fragment ships as a typed TypeScript shape with documented round-trip semantics; the orchestrator pattern composes naturally with both A2A AgentCard advertisement and an MCP server pattern. Reference: BidAngel ADR-0026, packages/structured-rfx-adapters/, with Slice 70 (CAIQ / SIG DDQ rows → CanonicalRequirementFragment) and Slice 71 (SAM.gov structured opportunities → CanonicalOpportunityFragment) shipped to production; Slice 73 (SAP Ariba sourcing events → all three fragment kinds) is in flight under ADR-0032 Phase A.

4. UBL / Peppol / OCDS / eForms field-by-field crosswalks under a layered-on-UBL discipline. Six durable artifacts (ADR-0034) covering evaluation_criterion, opportunity, buyer, requirement, plus supporting cross-maps for criterion-type codelist (EU-COM-GROW CriteriaTypeCode) and opportunity status lifecycle. Each fragment is bucketed exact / partial / novel; the four shipped sit at ≈92% UBL-aligned with novel-share comfortably below the 20% ceiling we set ourselves (ADR-0034 §1). Pinned to UBL 2.3 / Peppol BIS ESPD 1.0 / OCDS 1.1.5 / current eForms codelists, with documented event-driven re-pin commitment when UBL 2.4 / Peppol BIS Pre-Award 4.0 / OCDS 1.2 land. This is the work that absorbs OpenPeppol Pre-Award and OASIS UBL TC review surface; we'd rather contribute it to AAIF as part of the Extension URI proposal than have it discovered as a duplicative-ontology objection during review.

We are willing to host the draft Extension URI on a domain we control for v1 and migrate it to an AAIF-blessed namespace later if the foundation prefers that pattern. The public spec repository at github.com/bidangel/a2a-procurement-spec already contains the four ADRs above, the six crosswalks, and a v0.1 JSON-LD @context for the requirement fragment, dual-licensed under Apache 2.0 (code, schemas, contexts) and CC BY 4.0 (prose). Provenance is source-SHA-pinned to our upstream repository.

Explicit invitation to SAP as co-author

SAP is an A2A founding member, and the Joule + next-gen Ariba roadmap is the most credible enterprise procurement-agent surface in market. We would rather co-author with SAP than publish a parallel profile that drifts from how the largest existing buyer-side workflow is being built.

Our specific ask: review of the typed canonical fragment shapes (CanonicalEvaluationCriterionFragment, CanonicalOpportunityFragment, CanonicalRequirementFragment — full TypeScript declarations available in the spec repo, with two of three already in production via Slice 70 [tenant-uploaded DDQ] and Slice 71 [public-structured government opportunity]) against Ariba's sourcing-event payload, to identify field-level divergences before slice 73 implementation lands. Co-listing as authors on the resulting Extension specification is on the table from our side. We are happy to begin from a Joule-side draft if one already exists internally.

What we are not asking for

No changes to A2A's core protocol, AgentCard schema, or task model. No new SEP. We are submitting under the public Extensions mechanism precisely because vertical work belongs there — and because the layered-on-UBL discipline above means our canonical shapes round-trip to UBL / Peppol / OCDS / eForms without modifying any horizontal A2A primitive.

What we are asking the TSC for

1. Confirmation that vertical procurement profiles are in scope for the Extensions mechanism today.
2. Pointers to any in-flight overlapping proposals (procurement, B2B vendor assertions, RFx ingestion, UBL / Peppol mapping work) we should join rather than parallel.
3. A preferred forum for ongoing discussion — GitHub Discussion thread, an Interest Group convening, or another channel.

Timeline

We aim to publish a v0.1 Extension URI with reference schemas (markdown specification, JSON-LD @context for all canonical fragments, JSON Schema files, at least one round-trip CI test against a real EU eForms F02 fixture) within 90 days of TSC acknowledgement. The spec repository linked above is the publishing surface; product-side implementation continues in our private codebase and is referenced rather than included.

Thank you for the work on A2A and on the AAIF. We are glad the shared substrate exists, and we want to contribute to it rather than around it.

— Brian P., BidAngel

[cmagorr1]

Hi @brainspacer, your repo link leads to a 404 error from my side, and the bidangel org has no public repositories. Can you double check so we can read your spec? Thanks

[brainspacer]

Silly me. Sorted.
Now Public again.

[brainspacer]

Addendum — three-way coordination with A2CN and Concordia (status update, no new ask)

Since posting on 2026-05-10, the answer to ask #2 in the original note ("pointers to in-flight overlapping proposals we should join rather than parallel") has materialised organically in #1725 and #1737. Posting the resolution here so the TSC sees it on the same thread as the intent-to-author.

The substrate split that has emerged in #1737: @eriknewton (Concordia) has publicly endorsed it; @cmagorr1 (A2CN) is co-scoping the broader composition with Erik, with explicit endorsement expected on bidangel/a2a-procurement-spec#4 once the worked example lands.

• A2CN owns session establishment + authority/mandate verification.
• Concordia owns the negotiation envelope, receipt format, and the cross-protocol references[] mechanism.
• A2A Procurement Profile (this letter) owns procurement payload semantics — the four canonical fragments (opportunity, requirement, evaluation_criterion, buyer) and their UBL / Peppol BIS Pre-Award / OCDS / eForms crosswalks. Nothing else.

This is formalised on our side as ADR 0035 (merged 2026-05-12). Practically, it strengthens the original letter's "no changes to A2A core" commitment: the wire envelope, session state machine, and receipt signing format that an earlier sketch had this profile owning now live in adjacent protocols. The Extension URI surface is correspondingly narrower than the original letter suggested.

One emerging cross-protocol surface to flag for TSC awareness. A small relationship-verb starter set — fulfills / approves / enforces / rejects / satisfies — is being scoped jointly for references[] entries that bind across protocol boundaries (Concordia receipts citing A2CN sessions, procurement payloads citing OCDS opportunity IDs, etc.). Erik's working name for it in #1737, 16907463 is "A2A Registered Vocabulary Profile" (working name on the thread; TSC welcome to rename). Two equally good homes for that vocabulary: (a) Concordia-side schema with the other composing protocols referencing it, or (b) a thin horizontal A2A vocabulary registry separate from this procurement Extension URI. Happy to follow the TSC's preference; not asking for a decision in this addendum, just declaring the surface exists.

SAP co-author invitation remains open and is materially easier to accept under the narrowed surface — the review ask is now strictly fragment-shape alignment against Ariba sourcing-event payload, with no envelope, session, or signing-format dependency on SAP's side.

The original three asks still stand unchanged. No response expected on this addendum specifically; it exists so the substrate split is on the record alongside the intent-to-author when the TSC reaches the thread.

— Brian P. / BidAngel

[eriknewton]

Three-protocol substrate split captured correctly. ADR 0035 reads clean from my side, and the narrowed Extension URI surface (procurement payload semantics only) is what makes SAP co-authorship materially easier to land.

Parallel URN shape works. urn:bidangel:registry:procurement-rejection-clauses:v1 mirrors urn:concordia:registry:rejection-clauses:v1 cleanly. Folding into the URI ratification round with @cmagorr1; if anything converges differently I'll surface here before it lands.

Joint procurement-patterns repo location: not picked yet. Weighing concordia-a2cn (existing joint org) vs a fresh narrow-scoped org. Will post the answer here within a week. Your fixtures plus the BAFO worked example can wait on that pick.
A2A Registered Vocabulary Profile working name stays open for TSC rename. Two homes (Concordia-side schema vs thin horizontal A2A vocabulary registry). My lean is the horizontal A2A registry if the TSC will host it, since the verbs are protocol-neutral by design; Concordia-side is the fallback if TSC declines.

[nlozkina19-crypto]

Hey everyone! I just released vector-zero-compute (a high-performance C++/Python crypto core). I'm looking for any feedback on the code or architecture. Drop your repo link in the replies, and I will check out your project and leave a star in return! ⭐ https://github.com/nlozkina19-crypto/vector-zero-compute

[eriknewton]

Repo location confirmed: concordia-a2cn/procurement-patterns (https://github.com/concordia-a2cn/procurement-patterns). Repo provisioning in flight with Christian; live within the week. Scope stays narrow to procurement patterns; org structure can revisit later if co-author set expands beyond the current Erik + Christian + brainspacer trio.

Substrate split as ratified on 2026-05-13 holds: A2CN session + Concordia envelope + A2A Procurement Profile payload, three protocols composing cleanly without cross-imports. Parallel URN urn:bidangel:registry:procurement-rejection-clauses:v1 mirrors urn:concordia:registry:rejection-clauses:v1. Christian's ratification on the three §8 open questions from the scoping doc landed off-thread today; URI convergence summary posting separately on this thread.

[eriknewton]

Convergence update for the TSC record on the three §8 open questions from the joint extension scoping doc. @cmagorr1 has co-signed off-thread; posting the outcome here so the addendum thread carries it alongside the intent-to-author.

Three ratifications.

Umbrella profile, single registration. Single A2A Registered Vocabulary Profile carrying ApprovalReceipt, RejectionRecord, and FulfillmentAttestation as registered entries, rather than three independent extension filings. Reads to the TSC as one coordinated cross-protocol effort, not three protocols filing in parallel.

URI shape, resolvable https://. Option (a) from the scoping doc, consistent with A2A's extension-discoverability guidance. URN-style and w3id permanent identifiers stay available as alternates if the TSC governance process prefers them later.

satisfies stays distinct from fulfills. A BidAngel procurement payload can satisfy a sourcing-event condition while the A2CN session is still live and the procurement obligation is not yet fulfilled. Starter relationship set stays {fulfills, approves, enforces, rejects, satisfies}.

Two HITL sub-questions also resolved. ApprovalReceipt expiry re-enters AWAITING_HUMAN_APPROVAL rather than terminating (procurement timelines where approval takes hours need re-entry, not termination). requires_human_approval_above is a global scalar in v0.3 with a per-counterparty tiers map as a v0.4 extension point.

Three-protocol substrate split (ratified 2026-05-13 on the parent #1737 thread + brainspacer's ADR 0035) is unchanged: A2CN session + Concordia envelope + A2A Procurement Profile payload, no cross-imports. The A2A Registered Vocabulary Profile sits horizontally over the three protocols as the registered-vocabulary surface that A2A transport activates.

Repo location for the joint procurement-patterns work is concordia-a2cn/procurement-patterns (provisioning in flight; URL https://github.com/concordia-a2cn/procurement-patterns). The horizontal-A2A-registry-vs-Concordia-side-schema question (raised in my 2026-05-13 reply on this thread) is the next decision for the TSC; the §8 ratifications above hold regardless of which home the TSC picks.

Formal A2A extension PR filing window: next one to two weeks. Christian is on the co-signature path before the PR opens publicly.

[brainspacer]

Re: §8 convergence + umbrella registration — co-sign, with one boundary to clarify before filing

Thanks @eriknewton — and confirming concordia-a2cn/procurement-patterns as the joint home works on my side. Co-signing the three §8 ratifications for the public record so the thread carries all three of us, not just the off-thread sign-off:

• Umbrella profile, single registration for the cross-protocol vocabulary — agreed. One coordinated filing reads to the TSC far better than three parallel ones.
• Resolvable https:// URI (option a) — agreed; consistent with A2A's extension-discoverability guidance, alternates available if governance later prefers them.
• satisfies distinct from fulfills — agreed; the live-session-vs-fulfilled-obligation distinction is exactly the procurement case. Starter set {fulfills, approves, enforces, rejects, satisfies} is right.

The two HITL resolutions also land correctly for procurement: ApprovalReceipt expiry re-entering AWAITING_HUMAN_APPROVAL (approval-takes-hours is the norm, not the exception), and requires_human_approval_above as a v0.3 global scalar with the per-counterparty tiers map as a clean v0.4 extension point.

One boundary I'd like to pin before filing. The umbrella as described carries ApprovalReceipt / RejectionRecord / FulfillmentAttestation — cross-protocol receipt/relationship types, which clearly belong in the single registration. Where I want to make sure we're aligned: does "single registration" also fold in the procurement payload semantics — the four canonical fragments (opportunity, requirement, evaluation_criterion, buyer) and their UBL / Peppol BIS Pre-Award / OCDS / eForms crosswalks — or does the A2A Procurement Profile stay a distinct Extension URI that the umbrella references? My instinct is the latter: the umbrella's relationship verbs bind to the fragments (a procurement payload satisfies a sourcing-event condition) without reclassifying the domain semantics as umbrella entries, which keeps the original letter's "narrow surface, no A2A-core changes" commitment intact and the crosswalks independently citable. Happy to be guided by what you and @cmagorr1 settled off-thread — could we make the boundary explicit before the PR opens so the filed structure reflects it either way?

On the vocabulary's home (horizontal A2A registry vs Concordia-side schema): no preference from me, same as my 2026-05-13 note — happy to follow the TSC's call. The procurement crosswalks bind cleanly either way, so I don't think this gates anything on the procurement side.

SAP co-author invitation stays open and is unchanged by the above — the ask remains strictly fragment-shape alignment against the Ariba sourcing-event payload, no envelope/session/signing dependency.

— Brian P. / BidAngel

[brainspacer]

Quick follow-up, @eriknewton / @cmagorr1 — and congrats on the momentum: saw concordia-a2cn/procurement-patterns is live and concordia-protocol==0.7.0a1 is on PyPI with RejectionRecord anchored. Good to see it moving.

Two small things before the extension PR opens:

1. The boundary question from my note above — does "single registration" fold in the procurement payload fragments, or does the Procurement Profile stay a distinct Extension URI the umbrella references? Slight preference still for the latter, for two reasons: it keeps the original letter's narrow-surface / no-A2A-core-changes commitment clean, and it keeps the procurement crosswalks (UBL / Peppol BIS Pre-Award / OCDS / eForms) independently citable for the SAP/Ariba alignment work — easier to point a partner at as its own URI than as one entry inside a multi-protocol umbrella. Not a blocker either way; I'd just rather it be a deliberate call than fall out of the filed structure. With RejectionRecord now anchoring Concordia-side in 0.7.0a1, a quick confirm on which way the procurement payload goes would let me line our crosswalk artifacts up to match.

2. CODEOWNERS on the joint repo. Since the README names "BidAngel payload semantics per ADR 0035" and the procurement fragments + crosswalks (opportunity / requirement / evaluation_criterion / buyer and their UBL / Peppol BIS Pre-Award / OCDS / eForms mappings) are the part I author, could you add me (brainspacer) as a CODEOWNER for those paths? Happy to scope it narrowly to the procurement-fragment files / crosswalk dirs so review stays with the right owner as fixtures land — the HITL pause-resume fixture looks like a good first one to route that way.

Thanks both — not trying to slow the cut, just making sure the procurement surface has an accountable owner before the fixtures and PR land.

— Brian P. / BidAngel

[cmagorr1]

Confirming from the A2CN side: the substrate split Brian describes is accurate and matches how we've been coordinating across the three projects. ADR 0035 and the addendum Brian filed on #1737 are the canonical record.

To give the TSC visibility into the three-protocol composition from the A2CN perspective: A2CN's session establishment and mandate verification sit upstream of the BidAngel procurement payload semantics. A procurement session in BidAngel terms would initiate with an A2CN session carrying a urn:a2cn:session:v0.2 DataPart, the mandate credential verified at session init, and the BidAngel CanonicalRequirementFragment carried inside the A2CN offer DataPart. The two protocols compose without either needing to absorb the other's semantics.

The SAP co-authorship angle Brian raises would narrow the A2CN integration surface too - if SAP Ariba sourcing events are the upstream trigger, the BidAngel procurement payload semantics are what translate Ariba events into A2CN-compatible offer shapes. That's a clean seam.

—Christian Magorrian
A2CN Protocol / github.com/A2CN-protocol/A2CN

[eriknewton]

@brainspacer, confirming on both points.

1. Boundary: the A2A Procurement Profile stays a distinct Extension URI that the umbrella references. The umbrella registration carries the cross-protocol receipt and relationship types (ApprovalReceipt, RejectionRecord, FulfillmentAttestation, plus the relationship verb starter set). The procurement payload semantics, the four canonical fragments (opportunity, requirement, evaluation_criterion, buyer) and their UBL / Peppol BIS Pre-Award / OCDS / eForms crosswalks, stay independently citable under their own Extension URI. The umbrella's relationship verbs bind to the fragments (a procurement payload satisfies a sourcing-event condition) without reclassifying the domain semantics as umbrella entries. This preserves the original letter's narrow-surface commitment and keeps the crosswalks independently citable for SAP/Ariba alignment.

2. CODEOWNERS: adding brainspacer scoped to the procurement-fragment files and crosswalk directories. Will land as part of the next PR against concordia-a2cn/procurement-patterns.

@cmagorr1, confirmed from the A2CN side as well, per your 2026-05-23 note on the three-protocol composition.

The formal A2A extension PR filing window remains on track. v2 of the scoping doc ships by Wed May 27 with §3.4 + §11 folded in; formal PR follows for co-signature before June 1.

Erik

[chopmob-cloud]

Following this from the #1737 thread. The ApprovalReceipt / RejectionRecord / FulfillmentAttestation shapes you are converging on overlap with territory we have already mapped in a set of IETF Internet-Drafts (settlement-attestation, refund-receipt, cancellation-receipt, composite-trust-query) -- all Independent Submission, Informational, cross-implementation validated across 8 language implementations.

Not proposing to redirect anything -- you have the right people on the procurement-specific semantics. Just flagging the overlap in case the receipt substrate work is useful as a reference point or saves rework on the canonicalisation and signing side.

Happy to share the I-D links or the conformance vector corpus if useful. -- AlgoVoi

[brainspacer]

Thanks @chopmob-cloud — that's a useful pointer. The receipt shapes (ApprovalReceipt / RejectionRecord / FulfillmentAttestation) live on the umbrella/Concordia side of the substrate split rather than in the procurement payload itself, so the canonicalisation + signing overlap you're describing is most relevant there — cc @eriknewton @cmagorr1. We'd happily take the I-D links and the conformance-vector corpus as a reference point on that side; saving rework on canonicalisation is exactly the kind of thing worth aligning early. The procurement fragments and their UBL/Peppol/OCDS/eForms crosswalks stay our surface and are unaffected, but anywhere the receipt substrate touches signing we'd rather converge than diverge.

[brainspacer]

Thanks @eriknewton — both confirmations work for us. Keeping the Procurement Profile as a distinct Extension URI the umbrella references (fragments + crosswalks independently citable) is exactly the narrow surface we wanted, and it keeps the SAP/Ariba crosswalk story clean. Saw the CODEOWNERS PR (procurement-patterns#1) — appreciate it.

One thing to pin down so we don't lose the filing window: since the Procurement Profile sits under its own Extension URI, I'd assume I open that registration PR (fragments + crosswalks) for you and @cmagorr1 to co-sign, while the umbrella registration (receipts + relationship verbs) sits with you two. Is that the split you have in mind, or were you planning to bundle them? Happy to have my PR up within a day or two once we agree on which repo/path it targets.

[eriknewton]

@brainspacer, yes, that is exactly the split, and not a bundle.

You author the Procurement Profile (the four canonical fragments plus the UBL / Peppol BIS Pre-Award / OCDS / eForms crosswalks) under its own Extension URI, and Christian and I co-sign it. The umbrella Registered Vocabulary Profile (the cross-protocol receipt types and the relationship verbs) stays with Christian and me, and references your profile rather than absorbing it, so the procurement surface stays independently citable for the SAP/Ariba alignment.

On where things land: your fragments, crosswalks, and fixtures go in the concordia-a2cn/procurement-patterns joint repo, which is the pattern and fixture library we already agreed is the joint home. The Procurement Profile's Extension URI itself is yours to host under a BidAngel-owned resolvable identifier, and the A2A-side registration follows A2A's extension governance: an a2aproject issue with the abstract and technical approach, sponsored into an experimental extension if a maintainer picks it up. That registration sequences behind the umbrella by design, land the umbrella profile first so it has something concrete to reference, then register the Procurement Profile as a distinct URI. So you are not blocked: put the fragments and the first fixture up against procurement-patterns now, and we line the A2A registrations up once the umbrella is filed.

Open it whenever it suits you.

Erik

[chopmob-cloud]

Thanks @brainspacer. Per the split, this sits on the umbrella / Concordia receipt side, so cc @eriknewton @cmagorr1.

For reference, the substrate runs in production today. It is a gated implementation; these are the public endpoints:

• Agent card: https://api.algovoi.co.uk/.well-known/agent.json (advertises the scoped-authorization-receipts/v1 extension, the ApprovalReceipt analogue)
• ALLOW / REFER / DENY admission screen: POST https://api.algovoi.co.uk/compliance/screen
• Composite-trust-query verdict: POST https://api.algovoi.co.uk/compliance/trust-query
• Compliance / framework attestation: https://api.algovoi.co.uk/compliance/attestation
• action_ref verifier: POST https://api.algovoi.co.uk/verify/action-ref
• RFC 9421 signature verifier: POST https://api.algovoi.co.uk/verify/rfc9421
• Receipt verifier: POST https://api.algovoi.co.uk/v1/receipt/verify
• Health: https://api.algovoi.co.uk/health
• Full public API surface: https://api.algovoi.co.uk/openapi.json

All live now. Linking here so it is on the record alongside the umbrella work.

AlgoVoi (chopmob-cloud) -- docs.algovoi.co.uk/substrate-2

[widrss]

The lifecycle here stops at award. Settlement is the leg after that, and it's the part I run — A2A-SE (#1576) does escrow, release/refund, and dispute resolution on a live rail, so escrow outcome attestations originate at the exchange, not at a composite layer above it.

@chopmob-cloud saw the settlement-attestation I-D mention. I'm publishing typed escrow attestation shapes (release, refund, dispute-resolution) over the next week or so. Since the exchange holds the underlying outcomes, can we align the I-D shape with those instead of running two parallel definitions? Same spirit as the vector work in #1576. Also if the umbrella's relationship verbs grow a settled-by edge from award to settlement receipt, the rail can back that today.

[widrss]

@chopmob-cloud the typed escrow attestation shapes I mentioned are published: https://github.com/a2a-settlement/a2a-settlement/tree/main/schemas, doc with the cross-extension field mapping here: attestation-schemas.md. The settlement core carries escrow_id / settlement_kind / amount / currency / rail as-is from your layer registry. mandate_hash is the one field that doesn't map directly — v1 binds evidence through the Merkle proof instead; doc explains the reasoning. Happy to walk through it against the settlement-attestation I-D whenever you want to compare.

[brainspacer]

@eriknewton — friendly nudge on the PR-ownership question from last week (dc-17201813), just to keep the filing window from slipping further.

My working assumption: I open the Procurement Profile registration PR (the four canonical fragments + their UBL / Peppol BIS Pre-Award / OCDS / eForms crosswalks) under its own Extension URI for you and @cmagorr1 to co-sign, while the umbrella registration (cross-protocol receipts + relationship verbs) stays with you two. If that's the split you have in mind, just point me at the repo/path you want it to target and I can have the PR up within a day or two.

If you'd rather bundle them, happy to align on that instead — main thing is unblocking the filing. (Also still see CODEOWNERS procurement-patterns#1 open on your side whenever you get a chance.)

[eriknewton]

@brainspacer, confirming the split again so it is unambiguous on the record: you open the Procurement Profile registration PR (the four canonical fragments plus the UBL / Peppol BIS Pre-Award / OCDS / eForms crosswalks) under its own Extension URI, Christian and I co-sign it, and the umbrella registration (cross-protocol receipts and relationship verbs) stays with the two of us and references your profile rather than absorbing it. Not a bundle.

On the two things holding you up: target concordia-a2cn/procurement-patterns for the fragments, crosswalks, and first fixture, and I will get the CODEOWNERS PR (#1) landed on my side this week so your path ownership is in place before your PR arrives. I will confirm the exact sub-path with Christian and point you at it. Open it whenever suits you; once it is up, Christian and I line the A2A registrations behind the umbrella filing.

Erik

[eriknewton]

@brainspacer , the two follow-ups from my last note are done. Sub-path is confirmed with Christian: your fragments, crosswalks, and first fixture go under procurement-profile/ at the top level of concordia-a2cn/procurement-patterns. CODEOWNERS PR #1 is merged, so your path ownership is in place. You are clear to open the Procurement Profile PR whenever it suits you, and Christian and I line the A2A registration up behind the umbrella once it files.

Erik

[chopmob-cloud]

@widrss ran your cross extension conformance fixture on our side. All five AlgoVoi signed artefacts verify: 5/5 JWS valid against our production JWKS (kid d0481df4) over the same rfc8785 canonical form your fixture declares. Your escrow-double-release and refund-replay vectors map to BLOCK on the exchange, matching your conformance results. On the three you marked N/A: dispute_amplification is now a live bench category (three profiles), so there is a reference behaviour to map against when the concurrent dispute gate lands. Glad to keep the settlement leg wired to the receipt substrate as the profile fills in.

[widrss]

Nice — thanks for actually running it rather than taking my word for it. 5/5 against your own JWKS carries a lot more weight coming from you than from me.

Want to put it in settlement-conformance? You've got maintainer access, so a results/algovoi/ entry next to a2a-se would get the 5/5 and the two BLOCK mappings on the record in the same format. I'll review whatever you open.

On dispute_amplification: once your three profiles settle, I'll land the concurrent-dispute gate on the exchange and we can move it off N/A. That one's still on me.

[brainspacer]

@cmagorr1 — looping you in here since you co-own concordia-a2cn/procurement-patterns and have been quick on the A2CN-side confirmations.

We're down to one small open decision before the Procurement Profile registration can be filed. The working split (dc-17201813, restated dc-17287236):

• I open the Procurement Profile registration PR — the four canonical fragments (opportunity, requirement, evaluation_criterion, buyer) plus their UBL 2.3 / Peppol BIS Pre-Award 1.0 / OCDS 1.1.5 / EU eForms crosswalks — under its own Extension URI, for you and @eriknewton to co-sign.
• The umbrella registration (cross-protocol receipts + relationship verbs) stays with you two.

The only thing blocking me from having that PR up within a day or two is confirmation of the target repo/path. My default assumption is concordia-a2cn/procurement-patterns (where CODEOWNERS #1 already scopes me to the fragment + crosswalk paths) — if that's right I'll open against it; if you'd rather it land elsewhere or be bundled with the umbrella registration, just say and I'll align.

No urgency beyond keeping the filing from drifting — happy to move whichever way you two prefer.

[cmagorr1]

Confirmed, concordia-a2cn/procurement-patterns is the right repo, and procurement-profile/ at the top level is the path. Erik merged CODEOWNERS #1 already so you’re scoped in. Open against it whenever you’re ready.

Christian

[chopmob-cloud]

@widrss — heads-up on the settled-by edge from award to settlement receipt you floated: more will be revealed soon, hope the vector validation helps and anything else, please just shout