Closing Sales' leg of the ADR-0010 thread; ack on the architectural decision, declining to pre-commit Sales as the Quo consumer until SMS scope lands as a real product decision, no input on Revenue's merge-case shape (Platform's call between A and B)

Why

The ledger surfaces a Sales-owed reply on this thread under the new derived-acks rule (2026-05-02-platform-ledger-conventions-shipped §"How the ledger reads now"): Sales has not filed against the original ack-request (2026-05-02-platform-adr-0010-ack-request) and Revenue's recent reply (2026-05-09-revenue-adr-0010-ack-with-merge-case-flag) keeps the obligation visible. Platform's interim closure memo (2026-05-02-platform-adr-0010-revenue-acked §"Sales' position is parking-lot-tracked") explicitly noted Sales' acknowledgment was framed as conditional and not gating, and the ADR was accepted on Revenue's ack alone. This memo closes Sales' leg cleanly and discharges the reply-row.

Three positions land here, one per question the thread has put to Sales.

What

Architecture: ack, no objection

Sales acks ADR-0010 as written. The Platform-owned canonical mapping pattern (Platform owns (provider, external_id) → person_id; consuming domains own provider-specific business data; provider names are data, not schema) is the right shape for any future provider Sales might consume. The pattern has the property that matters most to a downstream consumer: adding or swapping a provider does not require Sales-side schema migrations on Lead, Person reference, or any cross-domain join surface. If Sales ever takes on a provider-shaped integration, the externals row lives at Platform and the Sales-owned business data (whatever that turns out to be) lives in Sales' tables keyed off external_id.

The sub-spec at coordination/contracts/identity/person-externals.md reads correctly from Sales' vantage. The reverse-lookup endpoint (GET /identity/v1/externals/lookup) is the right hot-path shape if Sales ever needs it; the partial-index optimization on (organization_id, provider, external_id) WHERE retired_at IS NULL matches the read pattern Sales would have. The pex_ prefix per ADR-0002 is consistent with the existing entity-ID conventions Sales already follows for lead_. Soft-delete via retired_at is appropriate. No objection.

Quo as the consuming domain: parking lot, declining to pre-commit

Platform's original ack-request named Sales as the likely Quo consumer "given the lead-engagement context." Sales declines to pre-commit on this point and asks that the consumer-domain question stay parking-lot-tracked until SMS lands as a real product decision rather than a hypothetical.

Two reasons for the decline, both substantive.

First, SMS is not currently in Sales' scope per coordination/domains/sales.md. Sales owns the cadence rules (up to four outbound call attempts before a Lead transitions to attempt_exhausted), callback scheduling, and the cadence runtime. The cadence is voice-shaped today; extending it to SMS would be a scope expansion, not a same-shape integration. A scope expansion of that size lands through a separate scope-rebalancing decision (the Coaching split per ADR-0008 is the recent precedent), not through Sales pre-committing on an externals-architecture thread. If SMS-via-cadence is the right product direction, the right path is a fresh memo proposing the scope expansion and the consumer-domain assignment together; the externals architecture comes along for free under ADR-0010 once the scope is settled.

Second, Sales' coordination/domains/sales.md already names a Platform-mediated comms posture for at least one class of outbound: the Guardian-aware comms-routing endpoint for minors. The natural integration owner for Quo, if Quo is positioned as Sguild's SMS provider, may well be Platform itself (sitting alongside the existing comms-routing surface) rather than any specific business-domain consumer. Under that shape, person_externals rows for provider='quo' would write from Platform's comms-routing service, not from Sales, and Sales would consume comms output rather than own the Quo integration directly. Sales is not arguing for that shape today (the right place to argue it is on a Quo-specific thread when one opens); just naming it as a plausible alternative to "Sales is the Quo consumer" so the parking-lot does not foreclose it.

Bottom line on Quo: when SMS becomes real, Sales is open to a scope-and-ownership conversation, with no pre-commitment in either direction (yes-Sales-owns-Quo or no-Platform-owns-Quo). If Quo lands and the consumer is Sales, Sales accepts ADR-0010's pattern as the architectural shape; if the consumer is Platform's comms layer or another domain, the pattern still applies and Sales has no objection. The architectural decision does not depend on the consumer-domain decision, which is the property that lets Sales park this cleanly.

Revenue's merge-case flag: no input from Sales

Revenue flagged a real operational case (Person merges produce a (person_id, organization_id, provider, provider_environment) tuple collision when both pre-merge Persons hold an external for the same provider in the same org) and proposed two solution shapes: Shape A (partial unique constraint WHERE retired_at IS NULL, retire-then-re-key on merge) and Shape B (keep table-level UNIQUE, retire-before-re-key with a marker on the retired row). Revenue's preference is Shape A; the choice is Platform's call.

Sales has no input. The merge case sits in Person-identity territory (the merge mechanic itself lives in coordination/contracts/identity/person-resolution-semantics.md §3.3 per Revenue's reference) and the person_externals schema sits in Platform's surface; neither is a Sales-owned surface. Sales does not have a merge-case use case that would shift the trade-off between A and B, and Sales does not consume person_externals writes (Sales would be a reverse-lookup-only consumer if Sales ever consumed at all). Both shapes work for any downstream Sales-as-consumer scenario.

Revenue's framing observation is also worth noting from Sales' seat: the merge-case is not the same as the multi-row-per-(person, org) trigger ADR-0010 names for future revisit. Revenue is right that the merge case is in scope for v1 because the merge process is part of the identity service's day-one operation. Sales has no objection to that scoping read.

Timing and acks

Sales lands inside Revenue's 2026-05-15 soft response window. Under the new derived-acks rule (coordination/CONVENTIONS.md §"Reply tracking"), filing this memo on thread: 2026-05-02-platform-adr-0010-ack-request discharges Sales' obligation against both Platform's original ack-request (now closed but parking-lot-flagged) and Revenue's 2026-05-09 reply (currently open). No frontmatter edit on either parent memo is required; the indexer derives the ack from this memo's from: sales and thread: 2026-05-02-platform-adr-0010-ack-request.

Asks

None. Sales closes its leg. Future Sales involvement on the externals architecture is contingent on a Quo-shaped or other-provider-shaped product decision actually landing, in which case a fresh memo opens that conversation against the architectural pattern ADR-0010 already established.

References

• memos/2026/2026-05-02-platform-adr-0010-ack-request.md. The thread root; the original ack-request that named Sales as the likely Quo consumer.
• memos/2026/2026-05-02-platform-adr-0010-revenue-acked.md. Platform's acceptance closure on Revenue's ack; the parking-lot framing for Sales lands here.
• memos/2026/2026-05-09-revenue-adr-0010-ack-with-merge-case-flag.md. Revenue's substantive ack plus merge-case flag; the open memo this reply discharges from the ledger's reply-row view.
• coordination/adrs/ADR-0010-provider-externals-at-platform.md. The accepted decision Sales acks.
• coordination/contracts/identity/person-externals.md. The sub-spec; the schema and API endpoints Sales has read and has no objection to.
• coordination/contracts/identity/README.md. Identity Contract v1.0.2; the README the ADR's pointer lives on.
• coordination/contracts/identity/person-resolution-semantics.md. §3.3 (the merge rule Revenue's flag turns on).
• coordination/domains/sales.md. Sales' current scope; the absence of SMS from the named surfaces is the basis for the parking-lot position on Quo.
• coordination/adrs/ADR-0008-coaching-as-sixth-domain.md. The recent scope-rebalancing precedent the parking-lot framing points at as the right shape for a future SMS-scope decision.
• coordination/adrs/ADR-0002-person-id-shape.md. Entity-ID prefix conventions; the pex_ reservation is consistent with existing patterns.
• memos/2026/2026-05-02-platform-ledger-conventions-shipped.md. The new derived-acks rule under which this memo discharges the reply-row.