Making AEP work for B2B transactions: A small core with profiles

[timaxorum]

Comment: Making AEP work for B2B transactions

From: Tim Fisher, co-founder, Axorum (with Roland Rodriguez, who has commented separately)
Perspective: I'm a former CFO. Axorum builds the controls and record-keeping layer for money moved by AI agents. We are commenting because we want to use AEP, and because the questions our customers' auditors will ask are different from the questions a chargeback reviewer asks.

First: this is strong work. The parts of the spec that make evidence trustworthy are exactly right, and none of it is specific to consumer shopping. We'd like to see that neutral core protected as the spec grows. Specifically the chained records, the signatures, the honest grading of every field by how it can be checked (recomputed, signed by someone with standing, inferred, or merely claimed), and the discipline of wrapping other protocols instead of competing with them. These are core foundations.

1. Split the spec into a small core and separate profiles (responds to open question 3)

Today the spec mixes two kinds of material: things that are true for any recorded transaction (how records chain together, how signatures work, how evidence strength is graded, how other protocols get wrapped) and things that describe one particular kind of transaction: a consumer shopping journey with discovery, a cart, a shipping address, and payment at checkout.

Business transactions don't follow that journey. They have contracts instead of carts, invoices instead of instant payment, and companies instead of shoppers. But they need the same core: the same chaining, the same signatures, the same evidence grades.

We suggest formalizing the split the spec has already started (the Minimal Merchant and Minimal Platform profiles, and the proposed extension registry): a small core that never assumes what kind of transaction it's witnessing, plus profiles that define the vocabulary for each kind. The current spec becomes the consumer-checkout profile, and a business-to-business profile can be developed separately without touching the core.

Two practical reasons this matters beyond tidiness:

• You often can't tell which kind a transaction is when it happens. For exampe: a small business paying for software on a card, or usage fees settled from a wallet. Is that consumer or business? A shared core lets that be decided later. Two separate standards would force the decision at the worst possible moment.
• Every consumer sale is also a business record. The same payment that ends the shopper's journey starts the merchant's accounting journey. If the two worlds use incompatible formats, the merchant's finance team is left holding two halves of one transaction that can't reference each other.

2. Add room for the company behind the agent

The spec's cast of characters includes the user, the agent, the merchant, and various service providers, but no organization. In business transactions there are three layers: the agent that acted, the person who authorized it, and the company they both act for. The company is the one that owes the money, signs the contract, and gets the tax form. Today the spec has no way to say "this agent acted for Acme Corp." [Note, that might be more complicated for organizations acting on behalf of others, like brokers. That's beyond the scope of this comment.]

We're not asking the core to define how companies are identified; that's genuinely unsettled (although Axorum is looking forward to contributing to solving that). We're asking the core to leave a clearly marked place for it, so profiles can fill it in.

3. Add a general way to point at the agreement that governed the transaction

Business transactions happen under agreements: a contract, a purchase order, a rate card that says this customer pays half the posted price. The spec currently has exactly one contract-like reference (the link to a recurring-billing mandate), built for one card-payment case.

We suggest a general-purpose reference in the core: a pointer to a governing document, identified by its fingerprint (hash) and where to find it. This helps the consumer side too: the same field can point at a merchant's terms of service or a published legal-context file (see the AAA's Legal Context Protocol). The chain would then record not just what happened but which rules were in force when it happened, which is what most disputes are actually about.

4. Let a stopped transaction leave evidence too

Chains seal at payment authorization. A transaction that a policy check blocks never reaches that point so it never seals, and there's no finished, exportable record of it. For a business, proving what you correctly refused is half the control story: "show me the agent tried to overspend and the system stopped it" is the first thing an auditor asks.

We suggest allowing a chain to close with a "stopped" outcome and be exported like any other bundle. This also strengthens the consumer side where a merchant who blocked a suspicious agent purchase would surely want the proof.

5. Let profiles set their own retention clocks

The 12–24 month retention window fits chargeback deadlines. Business records live seven years or more. If an evidence bundle supports an entry in a company's books, it has to survive as long as the books do. We suggest making retention a profile-level setting rather than a spec-wide ceiling, so the consumer profile keeps its privacy-friendly short clock and a business profile can require a longer one.

What we're offering

We are not asking AEP to become an accounting standard. Bookkeeping belongs in implementations, not in the spec, the same way the spec already separates the protocol from any vault that implements it. What a business profile needs from the spec is only this: a neutral core, a place for the company, a pointer to the agreement, evidence of refusals, and time.

We're building finance-instrumented implementations now, and when a business-to-business profile is chartered we'd be glad to contribute real transaction shapes, worked examples, and requirements drawn from what auditors and controllers actually ask for, so the profile is designed from practice rather than extrapolated from a shopping cart.

Thanks for doing this in the open. It's the right way to build something meant to outlive all of us.

[krystal-gracier]

Thank you for this comment — and for the care behind it. Every claim it makes about rc.2 checked out against the text, which made it unusually easy to disposition. We're treating it as five distinct proposals and giving each its own disposition below, which will be recorded in the COMMENT-ROUND.md log. (We've also noted issue #3 from your co-founder — the two together are exactly the kind of engagement this round is for.)

Summary of dispositions

#	Proposal	Disposition
1	Core/profile split	defer (versioned) → v1.1.0
2	Organization slot	accept-with-modification
3	Governing-document pointer	accept-with-modification
4	Stopped-transaction closure	defer (versioned) → v1.1.0, design invited now
5	Profile-scoped retention	accept-with-modification in principle; lands with the profile architecture

1. Core/profile split — defer (versioned) to v1.1.0.
   We agree with the direction, and we want to be precise about what we're agreeing to. The Minimal Merchant and Minimal Platform profiles (§8.6, §8.7) are conformance-reduction profiles — subsets of the same consumer journey — and open question 3 covers splitting protocol sub-wrappers into a registry. What you're proposing is larger: journey-vocabulary profiles over a transaction-neutral core. That's the right destination, but the surgery is real: the artifact-type enum participates in the §4.1 hash input, and Appendix B's expected-artifact counts are keyed to the consumer journey, so extracting a neutral core touches surfaces our versioning policy (§0.2) and governance commitments place at or near MAJOR. v1.0.3 is an additive MINOR release and can't carry it.
   What we commit to: the v1.1.0 stabilization release already reserved for after this round (§0) will take up the profile architecture as a first-order design question — what the core owns (chain mechanics, seal and closure states, signal classification, signatures/anchoring, the wrapper mechanism) versus what profiles own (artifact vocabulary, expected counts, retention clocks, export renderers). Your two practical arguments — that transaction kind is often undecidable at capture time, and that every consumer sale is simultaneously a business record — are the strongest statement of why we've seen, and this comment will be cited in that design. Related comments (Proposal: an independent dispute-handoff profile for AEP (§§2.7, 2.8, 4.3, 6, and 6.5) #14, [bug] §3.7 Fulfillment cannot be satisfied by reserved time-and-place commerce #20, GENERIC chains cannot record an identity verification event (Delegation omitted per §3.9.2) #26) point at the same architecture from other verticals, which strengthens the case for answering once rather than piecemeal.

2. Organization slot — accept-with-modification.
   Confirmed gap: the §2.4 actor model has no way to express "this agent acted for Acme Corp" (the closest thing today is the secure_corporate authentication-method value in §3.6, which is not that). We accept the reserved-slot approach with one modification we consider load-bearing: the slot must carry its §2.8 signal class explicitly. An organization reference with no attestation mechanism is Asserted — the weakest class — and the field must say so on export, or implementers will treat a free-text company name as evidence. Working shape: an optional org_ref { scheme, id, attestation? } member, Asserted by default in core, with profiles able to upgrade it to Attested by binding a named attestation scheme. The core will not pick an identification scheme; that is deliberately left to profiles, per your framing. Exact placement (chain-level vs. delegation payload) depends on the resolution of issue [bug] spec_version and the chain-level fields have no defined integrity mechanism #3, which governs which envelope integrity-protects it — the two will be sequenced together.

3. Governing-document pointer — accept-with-modification.
   Confirmed: mit_mandate_ref (§3.6) is the spec's one contract-like reference, built for the MIT/SCA card case, and it deserves to be the special case of something general. We intend an additive optional field along the lines of governing_agreement_ref { doc_sha256, uri?, kind?, effective_at? }, targeted at v1.0.3-final or v1.0.4 depending on how quickly the placement questions settle. The modification, again, is evidentiary honesty: a unilaterally recorded pointer proves "this party claims this document governed" and classifies as Asserted; it upgrades only when the counterparty has signed over the same hash. The core will provide the pointer and the classification rules; profiles define who must sign it for it to carry weight. Hash pointers to private documents are explicitly fine — the hash commits to the document without disclosing it. One request: you mention the AAA's Legal Context Protocol as a consumer-side target for this field. We couldn't locate a primary source; per the comment-round ground rules, could you add a citation? We'd like to evaluate it as a kind value.

4. Stopped-transaction closure — defer (versioned) to v1.1.0, with the design conversation starting now.
   One correction to the framing, in fairness to the current text: the evidence of a refusal already exists in-chain — §3.4's policy artifact records outcome: 'blocked' | 'escalated' with a required reason, before any authorization. What's missing is exactly what you say is missing: closure. A blocked chain never reaches the §2.5 seal point (the seal is the authorization artifact's hash), never gets completed_at, therefore never gets a §8.5 retention clock, and has no defined export state. We agree "proving what you correctly refused is half the control story," and we want it — but the design surface is wide: a second seal construction (likely sealing on the policy artifact when outcome is terminal), a retention trigger for chains that never complete, expected-count and verification-result semantics (§5, Appendix B), an export profile that isn't dispute/representment-shaped (§6 and Appendix C have no channel for "audit export of a refusal"), volume discipline so fraud-probe traffic doesn't become an unbounded sealed archive, and the §6.5 named-actor-rights question, which applies with more force to a record that accuses an agent of attempted overreach (see issue [§6.5] Safe harbour: non-attribution rule or evidence exclusion? #18). That's a profile-architecture-adjacent design, so it lands in v1.1.0 — but we'd welcome a scoped follow-up issue on closure semantics alone, and this is a place where worked examples of what auditors actually ask for would shape the design directly.

5. Profile-scoped retention — accept-with-modification in principle.
   Confirmed: §8.5 sets a 24-month maximum, and business records outlive it. Two observations shape the modification. First, the ceiling already bends: the rc.2 legal-hold rule suspends deletion indefinitely for open matters. Second — and this is the key — the two-plane model (§8.2.1) already contains the resolution: the raw-plane clock MUST NOT exceed the chain clock, so a business profile can extend the chain-plane (pseudonymized) clock to seven-plus years while raw-plane PII custody stays short. That composes cleanly with the hash-only-profile question (open question 2). So: retention becomes a profile-level parameter, with two guardrails we intend to keep normative — the consumer profile retains the current ceiling for both planes, and profile extensions apply upward to the chain plane only unless the profile defines custodian obligations for a longer raw plane. Lands with the profile architecture in v1.1.0.

On the offer.
Transaction shapes, worked examples, and auditor/controller requirements drawn from practice are precisely what a B2B profile should be built from, and we'd be glad to receive them — through the public process (issues and discussions, per CONTRIBUTING.md), so the profile is designed in the open the same way the core is. One vocabulary note: "chartered" implies process we haven't published yet; the governance charter is step 2 of the roadmap in GOVERNANCE.md, and profile chartering will be defined there. Until then, treat v1.1.0's profile-architecture work as the venue.

Thanks again! Let us know your thoughts here.

[timaxorum]

Thanks, Krystal, for such a thorough response. The corrections and comments are very useful; let me respond in your order.

1. Core/profile split deferred to v1.1.0.

• That sounds good. It's probably a larger undertaking than I initially thought. If Proposal: an independent dispute-handoff profile for AEP (§§2.7, 2.8, 4.3, 6, and 6.5) #14, [bug] §3.7 Fulfillment cannot be satisfied by reserved time-and-place commerce #20, and GENERIC chains cannot record an identity verification event (Delegation omitted per §3.9.2) #26 are pushing at the same seam from other verticals, that's the argument arriving from several directions. Good reason to solve it once in the core rather than per profile.

2. Organization slot and 3. Governing-agreement pointer

• Good idea on the signal-class modification; agreed. A free-text company name treated as evidence is not sufficient for legal compliance and audit-grade evidence. Forcing the field to carry its class on export will keep org_ref and governing_agreement_ref honest. Agreed that asserted should be the default, and upgraded only when a counterparty signs over the same hash.
• Sequencing both behind issue [bug] spec_version and the chain-level fields have no defined integrity mechanism #3 makes sense. Whichever envelope ends up integrity-protecting the chain-level fields is where these two belong.
• The AAA citation: its own launch page at adr.org, plus the spec, reference implementation, and white paper at www.legalcontextprotocol.org. Apache-2.0, stewarded by the AAA and Integra Ledger. It's a legal-terms layer: what was agreed, which law governs, what recourse exists.
  That maps onto governing_agreement_ref as a kind value, and it strengthens the case for a general pointer over the single card-mandate reference. LCP is the consumer-and-B2B version of the same "which rules were in force" question the field is for.

4. Stopped-transaction closure deferred to v1.1.0.

• You're right that the evidence of a refusal already exists: the policy artifact records the block and the reason. I'll open an issue on closure semantics alone, so the surface you listed (second seal, retention trigger, audit-shaped export, volume discipline, named-actor rights under [§6.5] Safe harbour: non-attribution rule or evidence exclusion? #18) can be worked one piece at a time instead of as a lump.
• I'm reaching out to some of my audit contacts and will come back with what they might request

5. Retention accepted-with-modification.

• I like it, and I like it more given that the structure already exists. Extending the chain-plane clock to the seven-plus years a business record lives; keep the raw-plane PII clock short. No complaints here.

On "chartered."

• Fair catch; I missed that. There's no chartering process to invoke until the governance charter ships as step 2 of the roadmap.
• I'll treat the v1.1.0 profile-architecture work as the venue to really contribute to this shape, and we'll bring the material and suggestions through the issues and discussion here, in the open.

Tim
Axorum | co-founder