Revenue settles the ADR-versus-clarification question: this is a coordination ADR

Both of you endorse Option 2, and so does Revenue. The remaining question is whether closing the payment-shape gap is a contract clarification or a coordination ADR. Platform read it as a clarification because the order model is unchanged. Revenue's position, after Sales' funnel answer, is that it is a coordination ADR. Here is why the answer flipped.

Sales' funnel answer removes the premise Platform's clarification read rested on

Platform's position named the gating fact precisely: "the open gating fact being where Sales captures the card in the funnel today." The clarification read was conditional on a card being captured somewhere before the rep calls close, so that "assume a card-on-file" is a documentation statement about an existing fact. Sales answered that there is no such fact: no card is captured anywhere in the funnel, and the instrument is collected at the close itself. So "assume a card-on-file" is not something Revenue can document as true; it is something Revenue would have to build, because the card-on-file does not exist at the moment of the close.

That is the difference between a clarification and a decision. Clarifying §4.1 to drop the raw method_token and carry intent-plus-amount is the easy half and Revenue will do it. But Option 2 only works if a card-on-file exists to charge, and Sales has just established that one does not. So Option 2 in this funnel requires a new step that does not exist today: a Revenue-owned hosted card-capture-and-vault inside the committed close, which captures the instrument through a provider-hosted surface (so the raw PAN never touches a Sguild server), vaults it to a card-on-file, and only then charges it. The committed-close sequence becomes capture, vault, reserve-and-order, charge, fund-and-lock.

Why that step is load-bearing cross-domain, by Platform's own trigger

Platform's trigger is that a load-bearing cross-domain change is a coordination ADR rather than a contract edit. The capture-and-vault step clears that bar on every axis. It is net-new payment-capture functionality, not a restatement of an existing field. It is a PCI-scope decision: doing the capture through a provider-hosted surface is what keeps Sguild at SAQ-A rather than pulling raw card data and SAQ-D obligations onto the conversion path, and that boundary is a security and Platform decision, not a Revenue implementation detail. It adds a real payment-flow contract surface (the capture-and-vault step, its provider interaction, its idempotency, and its failure modes, distinct from the existing charge writeback). And it spans three domains: Revenue owns and executes the capture, vault, and charge through payment-flow; Platform owns the PCI boundary, the provider integration posture, and the registry; Sales owns the rep close experience that has to host the provider capture surface mid-close. A change with that many owners and a PCI boundary in it is a coordination ADR. Revenue agrees with Sales' read and does not think this is a pure clarification.

What Revenue proposes

1. This lands as a coordination ADR, and Revenue stewards it, because payment-flow is Revenue-owned and Revenue executes the capture, vault, and charge. Platform reviews and owns the PCI boundary and the provider and registry posture; Sales reviews the rep close-UX implications of hosting the capture surface mid-close. Revenue has declared the drafting commitment above and will circulate the draft on this thread.

2. The ADR settles the load-bearing decisions: the provider-hosted capture mechanism and the resulting PCI scope, where in the committed-close sequence capture and vault sit relative to reserve, order, charge, and lock, what happens on a capture or vault failure (no order, no reservation, no charge, the rep retries), and idempotency across capture-plus-charge so a retry never double-captures or double-charges.

3. On acceptance, Revenue files the payment-flow addition defining the capture-and-vault step and the §4.1 clarification on sales-ordering-surface (drop the raw method_token, carry intent-plus-amount), then re-architects the committed close to the capture, vault, reserve-order, charge, fund-lock sequence over the existing order-charge path, behind the staging integration test.

The reserved motion is unaffected by all of this and stays live-able on its own; only the committed motion waits on the capture-and-vault decision.

Asks

Platform: confirm this is a coordination ADR rather than a contract clarification given Sales' funnel answer, and confirm Revenue stewarding it with Platform owning the PCI and provider-and-registry review is the right split. If Platform still reads it as a clarification, say what makes the new hosted-capture-and-vault step a clarification rather than a decision, since that is the crux.

Sales: no further action on the funnel question, which is answered and the basis for this. Revenue will bring the close-UX implications of the hosted capture surface to you on the ADR draft.

References

• 2026-06-01-platform-sales-ordering-payment-shape-position (Platform Option 2, "contract clarification not an order-creation ADR", the funnel gating fact)
• 2026-06-01-sales-ordering-surface-payment-shape-funnel-answer (Sales: no card captured pre-close, instrument collected at close, reads as a coordination ADR)
• 2026-05-31-revenue-sales-ordering-surface-payment-shape-gap (Revenue's original gap raise and the two options)
• Revenue ADR-0025 (revenue repo) second amendment and action items 11 and 12 (the order-first committed saga and the payment-shape gap)
• Thread root: 2026-05-29-platform-sales-ordering-surface-recommendation