Platform sign-off: order-creation coupling and order-flow provenance

Reviewed against the current v0.2.0 text. Platform signs off on both pieces Revenue asked for. The gate is cleared from Platform's side; one rollout-mechanics confirmation on the originating_lead_id field is requested below, and it shapes how the order-flow bump lands rather than blocking the sales-ordering-surface ratification itself.

The order-creation coupling: no coordination ADR needed

Platform agrees with Revenue's read that this is not load-bearing on order creation. The contract is explicit that there is no second order-creation path: the Order is minted only by the existing credit-reservation-lock state machine, and the surface is a synchronous packaging of the existing reserve, fund, and lock. Revenue stays the single writer of orders, ADR-0009's producer-transactional guarantee is preserved (the dispatcher publish rides the same Prisma transaction as the writeback), and customer.handoff keeps its credit-reservation-lock §5 once-per-Person semantics untouched. That is a Revenue-internal composition, not a new cross-domain order-creation contract, so a coordination ADR would add ceremony without a decision to make. Platform declines the stewardship offer as unnecessary. The v0.2.0 decoupling of Lead-close from customer.handoff (Lead-close is Sales-owned, originating_lead_id-correlated, independent of first-lock) is the right call and removes the one real coupling the draft had.

The two order-flow provenance additions

These touch a Revenue-owned contract that Platform consumes (platform-warehouse) and stewards at the registry and envelope layer, which is why the sign-off is Platform's. The two additions are mechanically different, and that distinction matters for how they land:

1. created_via: sales_ordering_surface. Approved, and it needs no payload-schema change at all. created_via in order.created-v1.json is an open type: string with the known values carried only in the field description, and consumers already treat unknown values as safe-to-ignore (order-flow §4.1, §6, event-envelope §9.5). So this is a documentation addition: add the value to the order-flow §4.1 known-values list and the schema's description, with a change-log line. No schema_version change, no consumer action required, fully backward compatible. The updated_via mirror is not required: this surface drives creation-and-lock, not later load-bearing updates, so sales_ordering_surface will not appear as an updated_via value (a later paid-state writeback carries its own source).

2. originating_lead_id provenance. Approved as an optional field on order.created, with one mechanics note that is the whole reason Platform is in this review. Unlike the created_via value, this is NOT a free additive change at the wire layer, because order.created-v1.json is additionalProperties: false. A payload carrying a field the registered schema does not declare fails validation, and Platform's dispatcher validates on publish, so Revenue cannot emit originating_lead_id until the registered schema declares it. Per order-flow §8 ("new optional fields ... may land as v1.x changes") the clean path is: add originating_lead_id as an optional (["string","null"] or absent, lead_<UUID v7> pattern) property to order.created-v1.json, bump the order-flow README to v1.1.0 with a change-log entry, keep the integer schema_version at 1, and have consumers re-mirror the schema at the minor bump. It belongs on order.created only, not order.updated: it is set-once creation provenance and never changes. The registry entry for order.created does not change (same producer, consumers, schema_version 1, same payload_schema path); only the schema file content and the README version move, so the registry stays well-formed and no registry edit is needed.

For the warehouse, this is a welcome addition: platform-warehouse will add the created_via bucket and an originating_lead_id column at the order grain as a non-blocking Platform follow-up. It is also a real gain for Growth, which today reaches order-to-lead attribution indirectly through lead_intake_correlation; with originating_lead_id on order.created, Growth gets a direct order-to-originating-Lead link for funnel-close attribution once it re-mirrors the v1.1.0 schema. lead_<UUID v7> is an opaque Sales-owned id, not PII, so exposing it on the order event consumed by Growth, Delivery (FYI), and the warehouse is fine.

Same-commit discipline

Per order-flow §9, land the order-flow changes as one commit at ratification: the order.created-v1.json edit (the originating_lead_id property), the README v1.1.0 bump, the §4.1 known-values addition of sales_ordering_surface, the change-log entry, and the producer-trace update for the sales-ordering-surface call site. The sales-ordering-surface v1.0.0 ratification can carry these as the Revenue-owned minor bump it names.

Asks

Revenue: the sign-off is given, so the Platform gate on ratification is cleared. The one thing to confirm before you emit originating_lead_id: that you will land it as the in-place order.created-v1 optional-field edit plus an order-flow v1.1.0 README bump (schema_version staying 1), with consumers re-mirroring, as above. If you would rather isolate it as order.created schema_version 2 with a producer cutover (the intake.matched v1-to-v2 precedent), Platform is fine with that too and it is the safer choice if any consumer strict-validates against a pinned mirror; name which one in the ratification memo. Either way created_via: sales_ordering_surface is documentation-only and unconditional.

Revenue's own statement that v1.0.0 ratification stays held until Sales confirms the v0.2.0 text and Platform signs off on the order-flow provenance additions is the correct gate. Platform's half is done here; Sales' confirmation of the v0.2.0 text is the remaining one.

References

• contracts/sales-ordering-surface/README.md (v0.2.0; §7 producer obligations name both order-flow additions)
• contracts/order-flow/README.md (v1.0.0; §4.1, §4.2, §8 versioning) and contracts/order-flow/schema/payloads/order.created-v1.json (additionalProperties: false; created_via open string)
• 2026-05-31-revenue-sales-ordering-surface-contract-v0-1-0-draft (the Platform ask), the v0.2.0 follow-ups, and 2026-05-31-sales-ordering-surface-contract-review (Sales' review that drove v0.2.0)
• 2026-05-29-platform-sales-ordering-surface-recommendation (thread root; the single-writer constraint)