Proposal: an independent dispute-handoff profile for AEP (§§2.7, 2.8, 4.3, 6, and 6.5)

[shunhe-wang]

Hi A-Comm team,

I’m writing from People’s Court (peoplescourt.ai), where we are working on a consent-based process for resolving disputes using structured evidence.

AEP is unusually thoughtful about preserving the history of an agent-mediated transaction.
We would like to explore adjudicating disputes from AEP DisputeBundles.

We think a natural next step would be to define what must happen when a DisputeBundle leaves the merchant, platform, or evidence custodian and goes to an independent decision-maker.
This would be especially useful for the stablecoin and x402 transactions recognized in §§3.6 and 3.9.10, which may have no card-network dispute process.

An independent reviewer needs to know who created each important assertion, what may be missing, and whether the affected parties had a fair opportunity to respond.

For that reason, we suggest adding an independent dispute-handoff profile under §6.
At minimum, it should provide:

• one canonical hash and signature covering the complete §6.1 export, including the applicable AEP version and fields computed at export;
• the identity of the exporter or custodian, the time of export, and the §5 verification checks it performed;
• a manifest stating which expected artifacts were included, omitted, unavailable, or redacted;
• the per-field signal classes already required by §2.8, connected to any §4.3 signature or external anchor;
• a way for each affected party to receive the frozen bundle and attach a signed response, correction, or authenticity challenge under §6.5 without rewriting the original evidence chain;
• amendment history, so a later export cannot silently replace an earlier one; and
• a place for an independent disposition to reference the exact bundle hash it considered.

The complete-bundle signature is already implied by the draft.
Sections 2.7 and 4.1 say the chain-level fields are protected by a bundle signature under §4.3, but §4.3 defines only per-artifact signatures.
Section 6.1 has no bundle-signature field, even though §6.3(c) promises a signed DisputeBundle test vector.
Defining that signature would give an independent forum a stable record to adjudicate.

We would also keep consent to a dispute forum separate from transaction authorization.
Section 3.9 records forms of commerce authority, not agreement to arbitration or to any particular decision-maker.
Forum consent should be its own record, matched to the parties, transaction, rules, and terms in effect.

For this profile, the platform safe harbor in §6.5 should become a non-attribution rule rather than a blanket evidence exclusion.
The preceding sentence in §6.5 and the signal classes in §2.8 already protect platforms from having unverified third-party statements attributed to them.
Platform-authored evidence should remain available to an independent decision-maker, with notice and an opportunity for the platform to explain or rebut it.

A public test vector under §6.3 would make the profile easier to implement.
It could include a valid bundle, a partially disclosed bundle, a modified export, conflicting party annotations, and a final disposition that references the accepted bundle hash.

Would A-Comm consider an independent dispute-handoff profile for v1.0.4 or v1.1?
People’s Court would be interested in adjudicating a synthetic dispute from an AEP bundle and returning a signed test disposition tied to that bundle.

Shunhe
People’s Court

[jyothi-acomm-ai]

Hi Shunhe,

Thank you for a detailed proposal with specific section citations; it is straightforward to evaluate on the merits.

Bundle signature (§§2.7, 4.1, 3.10, 4.3, 6.1)

Your analysis is correct. Sections 2.7, 4.1 and 3.10 each state that the chain-level fields are integrity-protected by a bundle signature under §4.3, but §4.3 defines only a per-artifact server_signature over that artifact's current_hash. Section 6.1 provides no field for a bundle signature, and the anchoring provisions in §4.3 refer to an "exported bundle hash" that the draft does not define.

For the record, this gap is already tracked: vectors/v1.0.3-rc.2/README.md lists vector (c) as blocked on this definition (file).

Your proposal contributes the scope that we had not resolved. It establishes that signing sealedBundleHash would be insufficient: §2.5 defines sealing as recording the authorization artifact's current_hash, so the seal is a single artifact hash rather than a digest over the bundle. The verification, evidenceTier and customerHistory members, together with all post-seal appends, fall outside it. A signature intended for an independent recipient must therefore cover the export rather than the seal.

Related findings

Your comment prompted a review of the hash rules against the published vectors. That review identified two defects that we consider prerequisite to the export signature, since a signature computed over an under-determined artifact hash would provide limited assurance.

Detail: two defects in the hash rules

**(a) Sections 2.7 and 4.1 are inconsistent with the conformance vector.** Both state that the chain-level fields are not part of the per-artifact hash input. Vectors (a) and (b) include `merchant_id` and `spec_version` within `metadata`, which is one of the eight hash-input fields enumerated in §4.1. Section 6.3 establishes vector (a) as the conformance gate, so an implementation that follows the normative prose does not reproduce the gating vector. A single artifact therefore admits three defensible hash values depending on which provision is followed.

Two related observations. The metadata example in §4.1 still reads {protocol, sdk_version, merchant_id, session_id_hash, ...}, notwithstanding the statement in Appendix D that the example was corrected and that §§2.7, 4.1 and Appendix B now present a single account. Vector (b) contains no chain_id or session_id_hash at either artifact or bundle level, although §2.7 requires them in one location or the other.

(b) The canonical key-sort rule is ambiguous for member names outside the BMP. Section 4.1 states that member names sort by Unicode code point. RFC 8785, which the same paragraph incorporates normatively, sorts by UTF-16 code unit, as do vectors/README.md and vector (h). The two orderings diverge for non-BMP member names, and the key-order case in vector (h) uses only ASCII, which does not distinguish them.

Common cause. These defects, the bundle signature, and the export-record gaps below share a single origin: rc.2 introduced normative requirements in prose without extending the schemas or vectors that would carry them. Two further instances are §6.2, which requires a verified_at value for which the §5 result schema provides no field, and §5, which requires that use of witnessed rather than live keys be recorded without defining where. We are treating this as one schema and vector audit against the rc.2 additions rather than as separate corrections.

## Process

Your items raise materially different questions, so we will separate them into individual issues in accordance with the one-topic-per-issue convention. Links will follow in this thread. Our preference is to file those issues and invite comment from other actor classes before settling scope, rather than fix it bilaterally here.

Detail: preliminary direction per item

The following is the editors' current reading and not a settled position.

Item	Direction	Likely target
Bundle-level signature over the §6.1 export	agreed in principle	v1.0.3-final
Exporter identity and verification-mode fields	agreed in principle	v1.0.3-final
Disclosure manifest	agreed, scoped to the §2.2 expected counts and §8.2.1 withholding rather than free-form	v1.0.4
Amendment history (supersedes)	agreed, as detectable rather than prevented	v1.0.4
Independent dispute-handoff profile	candidate, with a named editor	v1.0.4
Party response and authenticity challenge	granted in principle by §6.5; schema is open question 5 in COMMENT-ROUND.md	v1.1.0
Disposition referencing the bundle hash	follows from the export hash; see open question 4	v1.0.4
Forum consent as an AEP artifact	likely declined on the §9.3 and §9.4 boundary; available as a generic signed consent-event record carrying no representation as to enforceability	—
Narrowing the §6.5 safe harbour	dedicated governance issue with agent-platform comment solicited; not declined	—

On the final two items. Your reading of §3.9 is correct that it records purchase authority rather than agreement to arbitrate, but determining what constitutes valid consent to a forum is outside what this specification should decide. On the safe harbour, your argument is specific rather than rhetorical; however, platform emission is voluntary, and the actor class whose adoption depends on that term is not represented in this thread.

## Two items already open

Two of your requests correspond to questions we have already published for comment. The annotation and rebuttal payload schema is granted in principle by §6.5, and its schema is open question 5. A signed disposition referencing a bundle hash overlaps open question 4, concerning a compact verification attestation that a rail can verify without ingesting the chain; we would prefer a single primitive for signed statements about a bundle hash to two closely related objects. Comments against both questions would be welcome.

Interoperability exercise

We are interested in principle. We would want the export record defined first, so that your implementation is not built against a specification still under revision, and we would propose framing the exercise as forum-agnostic, open to any participant, and limited to synthetic data.

Detail: proposed terms

1. **Forum-agnostic and open.** Published as an independent-handoff interoperability exercise rather than a bilateral engagement. We would seek a second participant, principally because two independent reviewers reaching different conclusions on the same bundle would be the most informative outcome available. 2. **Synthetic data only, and marked as such.** No production transaction data and no raw-plane identifiers per §8.2.1. Signing would use the published test keypair in [`keys.json`](https://github.com/A-Comm-Tech/a-comm-evidence-protocol/blob/main/vectors/v1.0.3-rc.2/keys.json). Because that seed is published, every artifact produced must carry a test-only marker. 3. **Findings on evidentiary sufficiency rather than outcome.** Section 9.3 states that AEP is not a dispute manager, and we take no position on the correctness of any reviewer's determination. The useful output is what could not be determined from the bundle, what had to be assumed, and where the §2.8 signal classes affected the reading. 4. **DCO and Apache 2.0** for any material intended for publication as a conformance vector. 5. **No endorsement.** We would publish the artifacts and findings, and would not present any participant as validating AEP. The convention in CONTRIBUTING.md for listing independent implementations without endorsement ranking would apply.

## Settlement rails

You note that the stablecoin and x402 transactions recognised in §§3.6 and 3.9.10 may have no card-network dispute process. That is correct, and Appendix C and the §6.4 renderers are card-network specific. We would ask you to address one consequence: x402 settlement is final, so a disposition concerning such a transaction has no settlement-layer remedy unless funds were escrowed or the remedy is prospective. A profile designed for irreversible rails may differ materially from one bound to representment, and we would prefer to establish which is being specified before drafting.

Request

Separately from the technical discussion and for our records rather than for the thread: please provide the legal entity operating People's Court and the ruleset under which it conducts proceedings, including whether dispositions are intended to be binding or expressly non-binding.

Issue links to follow. Where we have characterised your proposal more narrowly than you intended, particularly on the manifest scope and the single-primitive suggestion, please say so.

[jyothi-acomm-ai]

Thanks @shunhe-wang — the entity and ruleset details are noted for the record; I won't take a position here on the binding character of your dispositions. On the exercise boundary: your restatement matches our proposed terms, and the two elements it adds — no funds movement, and an expressly non-binding test disposition — raise no objections from our side. We'll write the terms up once the export record (#3, #16) is defined.

Manifest scope

Understood that #16's count-based manifest is narrower than you intended; your item-level counter-proposal is on #16 and we'll respond there. Short read: what the count-based shape genuinely can't express is the computed export members (customerHistory, verification) and the applicability rules; the cost of the item-level shape is the expected-item registry it presupposes — who defines applicability, and what a verifier checks an entry against. That's where I'd focus #16.

Signed-statement envelope

A single envelope with typed payloads for verification attestations and dispositions is a concrete answer to the single-primitive question, and my current read is favorable. One point to state either way when you file: §6.5's annotation/rebuttal payloads (open question 5) are chain-appended artifacts rather than statements about an export hash — same envelope or separate shape? Please file against the open questions per COMMENT-ROUND.md so this gets a formal disposition rather than a thread read.

Settlement postures

Your two-posture split is the answer we asked for, and the escrowed posture is closer to the existing text than you may expect: §3.9.10 already projects scheme: 'exact' | 'upto' | 'auth-capture' | 'batch-settlement' and a settlement_finalized boolean, so a held-pending payment is representable at capture time. What rc.2 lacks: the x402 verification rule (§3.9.11 rule 7) is written for scheme = 'exact' on eip155, there is no export-time record that funds remain held pending a dispute, and no artifact type records the eventual capture or void — the closest precedent is the post-seal refund artifact (§3.10).

One boundary before drafting: mapping a disposition to capture-or-void is rail behavior; AEP records settlement facts rather than gating them (§9 — a line this round has held twice, in the Discussion #4 and Issue #40 dispositions). So my read of the escrowed profile is three records, no directives: an export-time hold status, the signed disposition referencing the export hash, and a post-seal settlement-outcome artifact parallel to §3.10. Whether the rail executes the disposition is outside this specification.

Per the round's ground rules on external protocols, can you cite the primary x402r specification? It appears nowhere in rc.2, and we'd want to know whether its auth-capture flow is the mechanism §3.9.10's 'auth-capture' scheme value already denotes or a distinct extension.

Questions:

1. Scope: should the profile specify both postures (declaratory/prospective relief only on finalized rails), or scope v1 to the escrowed posture where a disposition has a settlement-layer counterpart?
2. Recording: is a post-seal rail-outcome artifact (the §3.10 pattern) sufficient, or does adjudication require the hold itself to be evidenced by a facilitator signature at export time?
3. The x402r primary source, per above.

[shunhe-wang]

Thanks Jyothi, on your three questions:

1. On scope, we'd favor specifying both postures in v1. The common profile should support dispositions concerning finalized payments, even where any resulting refund or other performance occurs separately, as well as escrowed payments where a disposition may have a later settlement-layer counterpart. In neither posture would AEP direct or gate execution.
2. On recording, we'd prefer that the hold itself be evidenced at export time, but it doesn't have to be through a facilitator signature. On a publicly verifiable on-chain rail, a contract-state proof at an identified block, together with the relevant authorization event, should be sufficient. On an opaque rail, the equivalent should be signed by the facilitator or settlement operator. The export should include rail-authenticated evidence of the scheme, network, payment identifier, payer, receiver, asset, authorized amount, currently capturable and refundable amounts, captureAuthorizer, capture and refund deadlines, current state, and observation block, hash, and time. A subsequent post-seal outcome artifact would record any capture, void, reclaim, or refund, but would not substitute for proving the hold at export.
3. The primary sources are the x402 Foundation’s auth-capture scheme specification and its EVM profile. Those specifications define the two-phase authorize → capture | void flow, reclaim and post-capture refund, and the autoCapture posture. The x402r implementation registers under that same scheme. So we treat it as an implementation/profile of x402 auth-capture. AEP rc.2 already has the correct scheme value. The remaining gap is preserving and verifying the export-time hold and subsequent capture, void, reclaim, or refund events, together with any optional x402r dispute artifacts.

[jyothi-acomm-ai]

Thanks @shunhe-wang — that closes out all three, and the scoping question row 15 carried into v1.0.4 is now answered from your side. Two process notes before the substance: the dispositions for this thread are recorded in COMMENT-ROUND.md (row 15 defers the profile to v1.0.4 as a candidate, conditional on a named editor and sequenced behind #3/#16; row 16 records the forum-consent decline), and the comment window closes 14 August. So rather than open another round of questions here, below is what I think changes what you file, and where each piece belongs.

1. Scope — both postures

No objection to one profile covering both, and "in neither posture would AEP direct or gate execution" matches where this round has landed twice already (rows 2 and 14).

What makes the two-posture version harder than it looks: rc.2 has no rail-independent way to say which posture a chain is in. The only field that states it explicitly is settlement_finalized, and it sits inside the x402 wrapper on the delegation artifact (§3.9.10) — so it exists only when x402 is in play. On a §3.6 settlement_rail = 'stablecoin' chain that didn't come through x402, the stablecoin object carries {chain, asset, transaction_hash, amount_atomic} and nothing else, and result is 'approved' | 'declined' | 'review'. The only posture signal left is a null transaction_hash, which is ambiguous in exactly the way that matters to a reviewer: it cannot distinguish funds held pending from a settlement the exporter simply didn't record. If the profile covers both postures, that discriminator is the first thing it needs.

2. Recording — where hold evidence can actually live

Agreed that a post-seal outcome artifact doesn't substitute for evidence of the hold at export. Three structural consequences, which I think are more useful to you now than a field-by-field response:

Your two mechanisms don't carry the same signal class. A contract-state proof at an identified block is re-derivable by any verifier with chain access, which reads as Deterministic on the §2.8 table; a facilitator or settlement-operator signature is verifiable against that signer's published key, which is Attested. Adjacent, but not equivalent — and §2.8 requires the class to be preserved on export, so the profile should record which mechanism produced the hold evidence rather than treating the opaque-rail form as a drop-in for the on-chain one. §4.3 pushes the same way at bundle level: a bundle that is not externally anchored and was verified only by the exporting party carries the Asserted class as a whole.

Worth knowing that you are not the first to hit this: #43 makes the general form of the argument — that a DisputeBundle cannot distinguish a self-reported fact from an independently observed one — and points at issuer_relationship ∈ {independent, psp} (#27) as the existing precedent for upgrading Asserted to Attested. The fit isn't exact, since #43 asks for the classification on chain artifacts and yours would sit on a computed export member, but it is the same missing distinction and a convergent filing there would be stronger than a separate one.

Six of your sixteen fields already exist, but not as observations. §3.9.10 projects scheme, network, payer, pay_to, asset and amount_atomic today (plus facilitator_signer, which you didn't list but the profile probably wants). The delegation artifact is pre-seal, bound into the chain at position 4 (§2.5), so those are capture-time values fixed by the hash chain rather than statements about current state.

Your seventh is the interesting miss. The only identifier §3.9.10 carries for an x402 payment is transaction_hash — the on-chain settlement hash, present "if finalized" — which in the posture you care about is by definition absent. So inside the x402 wrapper a held payment has nothing that names it. The chain isn't identifier-less, since §3.6 requires charge_id and payment_intent_id at the authorization artifact, but those are PSP-shaped fields on a rail that may have no PSP.

The remaining nine are the part that changes after capture: capturable and refundable amounts, captureAuthorizer, capture and refund deadlines, current state, and the observation block, hash and time. None of those terms appear anywhere in rc.2 — "capturable", "captureAuthorizer", "reclaim" and "deadline" have zero occurrences.

So my read is that hold evidence is a computed export member, not an artifact. rc.2 already has that shape: customerHistory and verification are §6.1 bundle members computed at export time, explicitly not chain artifacts and not hash-chained. An observation of external state at export time is the same kind of object. Two consequences worth stating in whatever you file: computed members sit outside the hash chain, so a hold record is only integrity-protected once the export signature (#3) is defined — it depends on that work rather than being separable from it; and §6.2's two disciplines don't cover this case. Full re-verification is required for representment-bound exports and the cached seal-time index serves inquiry-speed channels; a handoff export is neither, and an export-time observation rules out the cached path outright, since a seal-time index cannot carry a block observed later.

On the outcome artifact itself: §2.5's post-seal append list is closed — fulfillment, refund (§3.10), and §6.5 annotation/rebuttal are the only types permitted after the seal. A capture/void/reclaim/refund artifact is therefore a §2.5 amendment plus an expected-count exclusion (the §3.10 precedent in §2.2), not only a new schema.

One schema question for #16 rather than here: if a reader can't tell whether your observation block was read before or after the export was cut, "held at export" isn't checkable. Whatever relationship the profile needs between that observation and exportedAt should be stated there.

3. One consequence you'll want to know about before drafting

The escrowed posture is tier-disadvantaged, permanently, and the tier reaches your reader specifically. §3.9.12's S-tier has three routes; the only one naming x402 requires AP2-Direct plus a session_binding_* plus "on-chain x402.transaction_hash (finalized)". Two things make that worse than a timing inconvenience:

• It can't resolve later. The tier is computed from the delegation artifact, which is pre-seal (§2.5) and immutable — §8.1 requires append-only enforcement at the storage layer. A payment authorized but not captured at position 4 fails that row at capture time and cannot be upgraded afterwards: there is no path to amend a sealed artifact, and no capture artifact to carry the eventual hash. That last point is the same gap as your post-seal outcome artifact, arriving from a different direction.
• It's scheme-asymmetric. An otherwise identical AP2-Direct chain settled under scheme = 'exact' reaches S-tier; the same transaction held under auth-capture does not, and never will.

§6.1 echoes evidenceTier into the bundle and §3.9.12 says exports SHOULD surface the tier to reviewers — so your adjudicator reads a tier that encodes settlement mechanics rather than evidence quality, on the transactions your profile exists to serve.

§3.9.12's disclaimer does cover this — a lower tier "implies nothing about a transaction's legitimacy and MUST NOT be presented as adverse evidence" — but it constrains how the tier may be presented, not how it is computed, and the number still travels in the bundle to a reader §3.9.12 itself describes as the audience it is "Informative for Adjudication" to. I'd rather have this raised in the round than discovered by a forum reading a tier it has no way to interpret.

4. auth-capture and x402r

Sources noted; we'll read them against the primary text rather than work from the summary, so nothing below assumes what they contain. Your conclusion may well be right that the scheme value is the correct hook, but it's worth being precise about what "rc.2 already has the correct scheme value" gets you: 'auth-capture' occurs exactly once in rc.2, in the §3.9.10 scheme enum. There is no verification rule behind it — §3.9.11 rule 7 is written for scheme === 'exact' on eip155 — no field set for a two-phase flow, and no conformance vector; §6.3's x402 vector (g) is an EIP-3009 settlement example. The enum value is a slot, not an implementation of the posture.

Anything that lands would be written against the scheme rather than any implementation of it, which I think matches how you framed it.

Where this leaves it

Rows 15 and 16 are this thread's disposition; what remains is component work that needs issue numbers to receive one of its own. #3 and #16 already carry your export-record comments, and the posture discriminator plus the hold member's shape and its relationship to exportedAt all belong on #16. The escrowed-posture material — the §3.9.10 and §3.6 field gaps, and separately the §3.9.12 tier consequence, which no open issue reaches — would be new filings.

One debt on our side: I said on 7 August we would respond to your item-level manifest counter-proposal on #16, and haven't. That response is coming there rather than here.

[shunhe-wang]

Thanks, though I don't think I see this thread in Rows 15/16/in the comment-round.md (could be looking at the wrong doc)

[jyothi-acomm-ai]

You're looking at the right doc — the error is mine, and thank you for saying so rather than assuming you'd missed it.

Those two dispositions were drafted but not pushed, so they weren't in COMMENT-ROUND.md when you looked; I cited them from an unpushed working copy. As published, rows 15–17 are Issues #46, #47 and #56.

They are now recorded as row 18 — the independent dispute-handoff profile, deferred to v1.0.4 as a candidate, conditional on a named editor and sequenced behind the export-record work (#3, #16) — and row 19, forum consent declined as an AEP artifact type on the §9.3/§9.4 boundary, with the note that your reading of §3.9 is correct and that the record remains available as a generic signed consent-event carrying no representation as to enforceability.

The substance of both is as I described it; only the row numbers were wrong. Rows 2 and 14, cited further up for the never-gating line, are correct as published — you can check my reading of those against the log.

Separately: #58 and #59 are both in and will receive their own disposition rows; I'll respond on the issues rather than here. One you may not have seen — #60, filed the same day by @saishav7 — reaches §3.9.11 from a different direction: the general signature-verification MUST against rule 7's narrowing to scheme === 'exact' on eip155:. I haven't evaluated it, but it turns on the same rule 7 predicate as the verification half of #58, so it's worth watching alongside yours.

[jyothi-acomm-ai]

Issues now filed. The first was already open before this discussion, and it
precedes the export signature because it determines what a verifier hashes:

• [bug] spec_version and the chain-level fields have no defined integrity mechanism #3 — spec_version and the chain-level fields have no defined integrity
  mechanism (pre-existing, opened 14 July)
• [bug] §4.1 states code-point key ordering; RFC 8785 and vector (h) use UTF-16 code units #17 — §4.1 states code-point key ordering; RFC 8785 and vector (h) use
  UTF-16 code units
• [bug] §6.2 and §5 require values the §5 Verification Result Schema defines no fields for #15 — §6.2 and §5 require values the §5 Verification Result Schema defines
  no fields for
• [§6.1] Export record: exporter identity, disclosure manifest, and supersession #16 — [§6.1] Export record: exporter identity, disclosure manifest, and
  supersession
• [§6.5] Safe harbour: non-attribution rule or evidence exclusion? #18 — [§6.5] Safe harbour: non-attribution rule or evidence exclusion?

#16 and #18 are where your proposal is most directly under discussion. The
bundle-signature definition you propose is tracked in #3, since the two cannot
be resolved independently.

[timaxorum]

Additional consumers of the evidence export

Building on this proposal and the direction in #12: the adjudicator is one member of a larger set of consumers for the export @shunhe-wang describes: auditor, insurer, tax authority, and regulator.

• When agent transactions become revenue, someone must rely on this record for financial reporting, tax, and attestation, and that reader needs the same properties this proposal asks for on the dispute side: a signature over the complete exported record, the exporter's identity, a manifest of what was omitted or redacted, an amendment history so a later export cannot silently replace an earlier one, and a disposition that references the exact record it judged. Swap "disposition" for "journal entry" and the list is unchanged. Doubly so if one party's acting on behalf of another party (say in an AP company that is moving client's funds. They hold those in an FBO account).
• Insuring parties and claims adjusters/adjudicators need essentially the same thing. Amex's Agent Purchase Protection (April 2026) conditions coverage on registered agents transmitting authenticated intent, which makes the claims adjuster a relying party on exactly this class of record.
• A tax authority or regulating entity are another.

None of these readers produce the export or can re-derive it, yet each must decide something binding from it. So the dispute-handoff profile is the same profile any independent reader will use who has to trust an export they did not produce. Thus, I believe the export layer should be shared, with reader-specific fields living in profiles on top (e.g. forum consent and response windows for disputes, period and reporting basis for audit, policy identifiers for claims).

This is the core-and-profiles shape from #12, and I think #14 is reinforces that. Bespoke export formats per reader would force every producer to implement the same integrity machinery independently, allowing the records drift apart. But that drift cannot be tolerated by those same readers: a dispute decided on one record that differs from the record that was booked, insured, or examined is a compliance nightmare.

Tying this to organization identifier proposal

The spec identifies agents but has no concept of the organization an agent acted for. For the adjudicator, that compounds the problem this thread already raised: authority to transact is not consent to arbitrate, and consent must come from a party with capacity to give it, which for commercial disputes means a legal entity, not an agent identifier.

Who has standing to respond to the bundle? Which entity does the award bind? For the auditor, the same missing field decides whose books the transaction lands on and which jurisdiction's tax attaches. For the insurer and the examiner it decides who the policyholder is and whether the counterparty is one you are permitted to transact with at all. An award that cannot name the entity it binds cannot be confirmed against anyone; an entry that cannot name the entity it belongs to cannot be audited; a claim that cannot name the insured cannot be paid. Same missing field, three dead ends.

Concrete suggestion for v1.1.0: agent-to-legal-entity resolution

Concrete suggestion: agent-to-legal-entity resolution (entity identifier, jurisdiction, and the authority chain from entity to agent) belongs in the core evidence record rather than in a profile, because every downstream reader needs it and no one can reconstruct it after the fact.

The editors' diagnosis above cuts against proposing that as prose alone: rc.2's defects share the pattern of normative requirements without schema fields or vectors to carry them, so I'll frame my comments on #16 as proposed schema fields plus a conformance vector rather than a requirement statement. #16 and #18 are where these readers overlap most directly, and #3 determines what any export signature actually covers.

I’m happy to coordinate language so the adjudicator-reader and relying-party arguments land as one position instead of two.

[jyothi-acomm-ai]

Thank you @timaxorum!

The editor reply on #12 noted that #14 points at the same architecture from another vertical; your comment makes that connection concrete on the export side.

The multi-reader argument

Your core observation holds up against the text. rc.2 already recognizes these readers below the export layer: §8.5 requires retention "long enough to support dispute resolution, audit, and regulatory review," and §8.2.1 lists "regulatory or audit response" among the only permitted uses of raw-plane values. But the export layer itself is dispute-shaped: §6 defines the DisputeBundle as the export "for representment submission," §6.2's export gate is specified for representment-bound exports, and §6.4's two renderer profiles are network-facing (with Appendix C mapping to PSP dispute-evidence fields). So an auditor or claims adjuster today inherits retention and custody guarantees but no export shape of their own. "rc.2 doesn't have this" is the honest summary.

My current read matches your structural conclusion: the properties in contention — a signature over the complete export (#3), exporter identity, disclosure manifest, and supersession (#16) — are reader-agnostic, and defining them per-reader would recreate exactly the drift you describe. Where the line sits between that shared export record and reader-specific profile fields (forum consent and response windows; period and reporting basis; policy identifiers) is the core/profile boundary question, and per the editor reply on #12 that architecture is the v1.1.0 design question — so #16 is the right place to press the reader-agnostic fields now, and your plan to frame them as schema fields plus a conformance vector is exactly what this round needs. Independent statements of the same requirement from different actor classes (adjudicator, auditor, insurer) are stronger evidence for that design than a single merged position, so I'd gently encourage you and @shunhe-wang to file convergent positions in the open on #16/#18 rather than pre-merging them — but coordination in public threads is of course welcome.

One request per the round's ground rules (claims about network or scheme rules should cite primary sources): can you add a citation for the Amex Agent Purchase Protection terms you reference? The claims-adjuster-as-relying-party case is one we'd like to evaluate against the actual program conditions rather than a summary.

Organization resolution: slot vs. semantics

The gap is confirmed — the §2.4 actor table has no way to say "this agent acted for Acme Corp" — and the editor reply on #12 already accepted a reserved slot for it (working shape: an optional org_ref { scheme, id, attestation? }, carrying its §2.8 signal class explicitly, Asserted by default, placement sequenced with #3).

Your comment argues for more than the slot: entity identifier, jurisdiction, and the authority chain from entity to agent, in core. I'd separate two things your "no one can reconstruct it after the fact" argument supports differently:

• Capture in core: agreed, and that's what the reserved slot is for. If the record isn't made at transaction time, no profile can recover it later.
• Semantics in core: harder. The Making AEP work for B2B transactions: A small core with profiles #12 disposition explicitly left the identification scheme to profiles, and my read is that what a jurisdiction field means and what constitutes a valid entity→agent authority chain sit on the same side of that line — §2.8 discipline applies with force here: an authority chain recorded unilaterally by the merchant or agent platform is Asserted, however detailed its fields. What upgrades it — the entity countersigning over the delegation via a published key? an external attestation scheme? — is a design question with real surface area.

On capacity and standing: worth being precise that AEP can only ever evidence the entity relationship — a signed, well-classified entity→agent link a forum or auditor can weigh. Whether that establishes capacity to consent or standing to respond is the forum's determination, not the record's. The record's job is to make that determination possible without reconstruction.

Questions

1. For your three reader classes, what is the minimum core must own for the record to be usable: the reserved org_ref slot as dispositioned in Making AEP work for B2B transactions: A small core with profiles #12 (Asserted by default, upgradeable by attestation), or normative authority-chain semantics? If the latter, which reader breaks with slot-only, and how?
2. Can you cite the Amex program terms (see above)?
3. The Making AEP work for B2B transactions: A small core with profiles #12 editor reply invited worked examples of what auditors actually ask for. A concrete artifact — the questions an auditor or claims adjuster puts to an export they didn't produce, mapped to fields — would shape [§6.1] Export record: exporter identity, disclosure manifest, and supersession #16 more than any requirement prose. Is that something Axorum can contribute?

[Dera219]

Hi Shunhe,

Your Discussion #14 argument that an outside reviewer needs the whole export signed and every omission listed stayed with me, so I tested the open AEP evidence draft against it, and 5 of 22 attacks on a dispute bundle got past a verifier, two of them producing files byte-for-byte identical to an honest one. The one-pager is below. Would you be open to 20 minutes on which of these gaps actually matters in practice? Thank you either way.

Chidera

---

What an AI-commerce dispute bundle can prove, and what it can't

When an AI agent buys something and the cardholder later disputes the charge, the merchant's whole defense is the evidence it kept, and the A-Comm Evidence Protocol (AEP) is the most complete open draft for what that evidence should look like. So I built an independent verifier for it from the specification text alone, and it passes all 55 checks in the published conformance vectors.

Then I built the other side too, a producer that refuses to emit anything the draft forbids, and I used it to make one disputed $55 purchase and attack the exported bundle 22 different ways, which is where it got interesting.

What holds. A recipient holding only the merchant's public key refuses 15 of the 22 attacks and flags 2 more, so the hash chain and signatures do what they are meant to do against anyone who doesn't hold the merchant's key.

What doesn't. Five attacks get through, and two of them produce files that are byte-for-byte identical to the honest bundle, which means no verifier that reads only the bundle can ever catch them. The reasons are structural rather than bugs:

• A signature proves which key signed, not when, so the merchant can rebuild its own chain (here, upgrading a 3DS result to "authenticated").
• Nothing commits to the end of the chain, so a returned-shipment event can be cut off, and the cut actually makes the chain report itself more complete.
• "Delivered" is signed by the merchant's server, not the carrier.
• The transaction type isn't covered by any hash, yet it alone decides whether the chain counts as complete.
• The bundle's summary fields, including customer history, are unsigned.

What would close them. Anchoring the chain head every time an event arrives (a timestamp token or a transparency-log entry, nothing exotic) takes the five misses down to two, and I measured that rather than argued it. The remaining two are already scoped in the specification's open issues or are one hashed field away.

What I'd love from you. Twenty minutes of your view on which of these gaps actually matters in real representment, in the sense that an issuer or processor would weigh it, because that is the part I can't learn from the specification.

Chidera Onyebu, Computer Science and Applied Mathematics, University of Maryland
conyebu@terpmail.umd.edu · code and demo: https://github.com/Dera219/aep-verify