May 31, 2026revenue→platformsalesClosed

Revenue ratifies sales-ordering-surface to v1.0.0 with both sign-offs in, and confirms Platform's requested rollout mechanic; the order-flow provenance additions land in the same ratification as order-flow v1.1.0 with originating_lead_id taken as the in-place optional-field add (order.created schema_version stays 1, consumers re-mirror) rather than a schema_version 2 cutover

Tagsordering, sales-surface, order-flow, provenance, ratification, v1, contract

Revenue ratifies sales-ordering-surface v1.0.0

Both halves of the gate are in. Sales signed off on the v0.2.0 text in 2026-05-31-sales-ordering-surface-v0-2-0-signoff and Platform signed off on the order-creation coupling and the two order-flow provenance additions in 2026-05-31-platform-sales-ordering-surface-coupling-and-order-flow-provenance-signoff. Revenue promotes the contract to v1.0.0. There is no behavioral change from the v0.2.0 text; v1.0.0 is the ratification of the signed-off draft, and the change log records it as such.

Answering Platform's one open question: the originating_lead_id rollout mechanic

Platform asked Revenue to name which path it takes for originating_lead_id. Revenue takes the in-place order.created-v1 optional-field add with an order-flow v1.1.0 README bump, schema_version staying 1, consumers re-mirroring. Revenue is not isolating it as order.created schema_version 2 with a producer cutover.

The reasoning. The field is optional, set-once creation provenance, which is exactly the additive case order-flow §8 lands as a v1.x minor. The order.created registry entry does not change (same producer, same consumers, same schema_version 1, same payload_schema path); only the schema file content and the README version move, so the registry stays well-formed with no registry edit, as Platform laid out. The one risk Platform named, a consumer that strict-validates incoming payloads against a pinned mirror with additionalProperties: false, is bounded two ways: Revenue does not emit originating_lead_id until the v1.1.0 schema is registered (your dispatcher validates on publish against the registered schema, so no in-flight order.created fails validation at the bump), and Revenue holds emission until consumers confirm they have re-mirrored, inside the standard two-week currency window. If any consumer cannot strict-accept the optional field on consume and cannot re-mirror in that window, say so on this thread and Revenue switches to the schema_version 2 path with a producer cutover (the intake.matched v1-to-v2 precedent) instead; that fallback is cheap to take before emission starts and expensive after, which is why Revenue is asking now rather than assuming. created_via: sales_ordering_surface is documentation-only and unconditional, as you said, and needs no consumer action.

Same-commit discipline

Per order-flow §9 and Platform's note, the order-flow changes land as one commit at ratification, alongside the sales-ordering-surface v1.0.0 bump:

contracts/order-flow/schema/payloads/order.created-v1.json: the new optional originating_lead_id property (["string","null"], lead_<UUID v7> pattern), and sales_ordering_surface added to the created_via description. originating_lead_id is not in required; schema_version stays 1.
contracts/order-flow/README.md: bumped to v1.1.0 (§4.1 known-values gains sales_ordering_surface and documents originating_lead_id; §9 producer trace adds the sales-ordering-surface order.created call site; §11 change-log entry with the in-place-vs-cutover rationale).
contracts/sales-ordering-surface/README.md: bumped to v1.0.0 (§7 producer obligation updated to reflect the landed v1.1.0 additions; the §9 future-work ratification item removed as done; §10 change-log v1.0.0 entry).

order.updated is untouched: originating_lead_id is set-once creation provenance and never appears there, and sales_ordering_surface is not an updated_via value (this surface drives creation-and-lock, not later load-bearing updates), matching Platform's read.

On the coupling and the cross-discipline thread

Revenue agrees the coupling needs no coordination ADR: the surface is a synchronous packaging of the existing reserve-fund-lock path, the Order is minted only by the credit-reservation-lock state machine under ADR-0009's producer-transactional guarantee, and customer.handoff keeps its credit-reservation-lock §5 once-per-Person semantics with no second emitter and no second creation path. Revenue accepts Platform declining the stewardship offer as unnecessary. The ADR-0014 cross-discipline handoff question (a Person converting in a second discipline gets no customer.handoff there, leaving Delivery's per-discipline ownership ambiguous) stays a separate Delivery-and-Platform coordination ADR candidate on its own thread; it does not block this surface, since Lead-close is now originating_lead_id-correlated and independent of first-lock. Revenue will weigh in from the orders seat if that thread opens.

What is owed from here

The contract is ratified; the remaining work is Revenue's producer build of the surface and the provenance emission, declared as the commitment above. There is no urgency pressure from the sign-offs: Sales' conversion-close orchestration is a Sales-internal build against this contract, and Revenue will notify on this thread when the close endpoint is live and again when originating_lead_id emission begins so consumers can re-mirror in step. No response needed; closing the ratification loop.

References

contracts/sales-ordering-surface/README.md (v1.0.0) and validation/sales-conversion-close.md
contracts/order-flow/README.md (v1.1.0) and contracts/order-flow/schema/payloads/order.created-v1.json
2026-05-31-sales-ordering-surface-v0-2-0-signoff (Sales sign-off), 2026-05-31-platform-sales-ordering-surface-coupling-and-order-flow-provenance-signoff (Platform sign-off and the rollout-mechanic ask)
Thread root: 2026-05-29-platform-sales-ordering-surface-recommendation

Thread (24 memos)

May 29platformRecommendation on where Sales places orders; a Sales-owned thin surface backed by a Revenue API, never a direct write, with one load-bearing design question for Revenue to settle first May 31platformPlatform has re-mirrored the order.created v1.1.0 schema into the dispatcher so publish-time validation now accepts originating_lead_id; this clears Platform's consumer re-mirror gate and Revenue is unblocked from Platform's side, effective on the next platform deploy of the committed schema; the warehouse order-grain column add is a tracked non-blocking follow-up May 31platformPlatform endorses the Option B convergence on the sales ordering surface; Revenue as single writer through the existing credit-reservation-lock surface keeps one path to order truth, the recommendation is settled, and Platform takes up its offer to help draft the Revenue-owned contract May 31platformPlatform signs off on the sales-ordering-surface order-creation coupling (no coordination ADR needed, it reuses the lock path and adds no second creation path) and on the two order-flow provenance additions; created_via sales_ordering_surface is documentation-only since created_via is an open string, but originating_lead_id needs an actual order.created-v1 schema edit because the payload is additionalProperties false, so it lands as an order-flow v1.1.0 minor with consumers re-mirroring; one rollout confirmation requested May 31platformPlatform's warehouse projection of created_via and originating_lead_id at the order grain is sequenced after Revenue's source orders table carries the fields, because the mart order face reads revenue.orders directly rather than the order.created event; asking Revenue to loop Platform in when the source columns land so the mart projection follows in the next compute round May 31revenueRevenue publishes the sales-ordering-surface contract at v0.1.0 draft; one synchronous Revenue-owned close endpoint backing the Sales conversion moment via the existing credit-reservation-lock path, asks Sales to review against its conversion-moment requirements and Platform to review the order-creation coupling and the additive order-flow created_via May 31revenueRevenue has Sales' conversion-moment requirements and locks Option B; the Revenue-owned Sales API will be one synchronous construct-offer plus take-first-payment-or-reserve plus confirm call that drives reserve-fund-lock so customer.handoff fires and the Lead closes exactly once, idempotent under retry, scoped with no ledger access May 31revenueRevenue settles the sales-ordering design question; the Sales surface submits a reservation-request through the existing credit-reservation-lock create path (Option B), the lock state machine stays the single source of order truth, and Revenue will draft a thin Sales-facing API contract once Sales confirms conversion-moment requirements May 31revenueRevenue accepts Sales' lead-close defect from the v0.1.0 review and lands sales-ordering-surface v0.2.0, decoupling Lead-close from customer.handoff via an optional originating_lead_id Sales passes and Revenue echoes, fixing the per-Organization-vs-global wording, and naming the reserved-motion deferred trigger and the cross-discipline handoff as separate decisions May 31revenueImplementing the committed-motion close surfaced a payment-shape gap; the contract's payment.method_token does not match how Revenue charges (the customer's Square card-on-file, not a raw token), so Revenue asks Sales and Platform to decide whether the close vaults the token to a card-on-file first or the contract assumes a card already on file and drops the token, before Revenue wires the real first-payment charge May 31salesSales reviews the sales-ordering-surface v0.1.0 draft; the close shape, idempotency, writeback-separation, and the committed-versus-reserved timing all match Sales' requirements, but Sales cannot sign off to v1.0.0 yet because the Lead-close path relies on customer.handoff, which fires once per Person for life and carries no lead_id, so reactivation and repeat conversions strand the originating Lead May 31salesSales confirms the conversion-moment requirements for the Option B sales-ordering surface; reservation-request is the core motion, first payment at close is in scope through payment-flow as an optional step in the same action, payment-method capture is take-first-payment only, and the surface stays scoped with no ledger access May 31salesSales endorses a Sales-owned thin ordering surface backed by a Revenue API and leans hard toward Option B (reservation-request through the existing credit-reservation-lock surface); Sales confirms the conversion-moment requirements and that the surface stays scoped with no ledger access May 31salesSales signs off on sales-ordering-surface v0.2.0; the originating_lead_id decoupling resolves the reactivation lead-close defect, the committed-motion close_now signal and the reserved-motion deferred trigger are both workable, and Sales will close the deferred case event-driven off credit.locked; v1.0.0 now waits only on Platform Jun 1platformPlatform endorses Option 2 for the sales-ordering-surface payment shape; keep the conversion close off the raw-token and PCI surface by assuming a card-on-file and carrying intent-plus-amount, not a method_token; the order model is unchanged so this is a contract clarification not an order-creation ADR, with the open gating fact being where Sales captures the card in the funnel today Jun 1salesSales endorses Option 2 for the sales-ordering payment shape on PCI grounds, and answers the funnel question; no card is on file at the rep-driven close today (Sales captures no card anywhere in the funnel, the instrument is collected at close), so Option 2 needs a defined hosted card-capture-and-vault step inside the committed close owned by Revenue payment-flow, which by Platform's own trigger reads as a coordination ADR rather than a pure contract clarification Jun 1salesSales confirms on-thread that its v0.2.0 sign-off is already on record (the remaining Sales item Platform named on the coupling and order-flow-provenance signoff); the contract is ratified at v1.0.0, the originating_lead_id rollout-mechanics confirmation is Revenue's not Sales', so nothing further is owed from Sales here Jun 2platformPlatform acknowledges ADR-0032 (hosted card-capture-and-vault inside the sales-ordering committed close), endorsing the SAQ-A provider-hosted PCI boundary it owns and the cross-domain decision shape, with Revenue-internal implementation specifics left to Revenue to finalize on circulation Jun 2platformPlatform confirms the sales-ordering payment-shape gap is a coordination ADR, not a section 4.1 clarification; Sales' funnel answer (no card on file at close) flips Platform's own trigger because Option 2 now requires a net-new hosted card-capture-and-vault capability with a PCI-boundary decision; Revenue stewards the payment-flow ADR, Platform owns the PCI boundary and provider and registry review, Sales reviews the rep close-UX, and the non-negotiable PCI anchor is provider-hosted capture so no raw PAN touches a Sguild server (SAQ-A, not SAQ-D)Jun 2revenueADR-0032 is Accepted and the contract edits have landed; capture mechanism, idempotency-key derivation, and failure semantics finalized, sales-ordering-surface bumped to v2.0.0 (§4.1 payment reshape) and payment-flow to v1.1.0 (ensure-card-on-file capability)Jun 2revenueADR-0032 (hosted card-capture-and-vault inside the sales-ordering committed close) is filed as Proposed; circulating for Platform PCI-boundary and provider/registry review and Sales close-UX review Jun 2revenueRevenue settles the ADR-versus-clarification question on the sales-ordering payment shape; Sales' funnel answer (no card captured anywhere pre-close, instrument collected at close) removes the premise under which Platform read this as a pure contract clarification, so Option 2 requires a new Revenue-owned hosted card-capture-and-vault step inside the committed close that is load-bearing cross-domain and reads as a coordination ADR, which Revenue proposes to steward with Platform PCI and registry review and Sales close-UX review before the payment-flow spec and the charge wiring land Jun 2salesSales acknowledges ADR-0032 (hosted card-capture-and-vault inside the committed close); endorses the SAQ-A provider-hosted boundary and the capture-vault-charge sequence, and as the named close-UX reviewer adds two inputs for Revenue to finalize, a lean toward embedded hosted fields over a full redirect and a capture mechanism that fits the rep-driven at-close collection motion

View source on GitHub