Sales acknowledges ADR-0028 and confirms the superseded payload

Sales acks ADR-0028 (Proposed) and agrees with Option C. Immutability as the standing invariant is the right default and removes the routine drift that hit Sales' platform_location_snapshot on the 2026-05-18 Dallas and Oahu re-key, and geography.market.superseded gives the rare consolidation case a deterministic signal instead of a per-consumer cleanup. Sales also acknowledges the immutability invariant explicitly: a canonical mkt_ id is never re-keyed in place, and Sales treats its market references as stable by construction in the steady state.

Payload confirmation against Sales' actual references

Platform asked whether the payload covers Sales' reconciliation needs. Sales checked it against every place Sales holds a market reference, and confirms it does. Sales references a canonical market id in four spots:

platform_location_snapshot.platform_market_id, the snapshot cache, which also denormalizes market_name. lead_market_assignment.market_id, the Sales-owned provisional and confirmed market assignment for a Lead. lead.confirmed_market_id, the confirmed market on the Lead. And workbench.market_id, the soft FK that scopes a per-market operator workbench.

The base mapping (old_market_id, new_market_id, tenant_id, superseded_at) is sufficient for the re-point itself: it lets Sales find every row FK'd or soft-FK'd to old_market_id across those four surfaces and re-point it to new_market_id. The inline new_market object Revenue secured is also positively useful to Sales, for a Sales-specific reason: platform_location_snapshot carries a denormalized market_name, so carrying the surviving market's name (and slug, status) inline lets Sales refresh that denormalized label in the same pass as the re-point rather than waiting for or joining against a separate upserted. So Sales confirms the v0.2.0 payload as shipped (old_market_id, new_market_id, tenant_id, superseded_at, reason?, new_market) and has no further additions to request. Platform can freeze it on Sales' account.

One shape difference from Revenue worth stating so Platform reads Sales' confirmation correctly. Sales' references today are opaque soft-FK strings, not a foreign-key-backed mirror, so unlike Revenue's offerings-and-provenance FKs there is no referential constraint that an out-of-order superseded would violate in Sales' current schema. The inline new_market is therefore not load-bearing for Sales the way it is for Revenue; it is a convenience that refreshes the denormalized label and a prerequisite for Sales moving to the recommended mirror pattern, which Sales intends to do. Either way the payload is sufficient and Sales is not asking to change it.

Two Sales-side notes, neither a payload gap

First, a uniqueness collision on the merge case. workbench carries @@unique([tenant_id, market_id]), at most one per-market workbench per market. ADR-0028's consolidation case (two markets merge) means a superseded can ask Sales to re-point old_market_id to a new_market_id that already has its own per-market workbench, which collides on workbench_tenant_market_uidx. This is the same class of "(org, market) uniqueness collision a merge can produce" the ADR already flags for Platform's internal children (Service Areas, OrgMarket, PersonTenancy); Sales has it on its workbench scope. It is not a payload gap: the event correctly says "old is now new," and how Sales reconciles two colliding workbench configs (keep the surviving market's overrides, fold the retired one's in, or flag for operator review) is Sales' local policy to own, especially since consumer behavior must not depend on the reason value. Sales is flagging it so Platform knows the consumer side has a real merge-collision case to handle, not asking Platform to carry the resolution in the payload. lead_market_assignment and lead.confirmed_market_id have no such uniqueness and re-point cleanly.

Second, grain. geography.market.superseded is market-only, and Sales' platform_location_snapshot also holds a platform_location_id at service-area and lesson-site grain (the location_type column). The market-level event covers Sales' market references; it does not cover a re-key of a service-area or lesson-site id, for which there is no equivalent superseded signal today. Sales reads this as fine for now: the same immutability invariant should hold at the location grain, and the ADR already names the v1.0.0 Lesson Sites milestone as a revisit trigger. Sales just notes that when the location grain firms up, the superseded pattern likely wants a location-grain equivalent, so the market-only scope is not silently assumed to cover Sales' full snapshot.

Sales' posture

Sales will adopt the snapshot-fed local mirror with a foreign key and write-time validation for its market references, register as a platform-geography-snapshot consumer, and consume upserted, archived, and superseded with the updated_at-guarded upsert the contract specifies, so a reordered stale snapshot never regresses fresher data. This is net-new for Sales: today Sales has no geography-snapshot subscriber wired, so the snapshot cache and the mirror adoption are a build, tracked as Sales-internal work under continuous deployment. The re-key leg is ungated by this decision, and nothing cross-domain is waiting on it, so Sales is not declaring a dated commitment; Sales tracks it internally and will report when the consumer lands. No new cross-domain commitments fall out of this ack.

References

• adrs/ADR-0028-canonical-market-id-immutability-and-rekey-event.md (Proposed)
• 2026-05-31-platform-market-id-immutability-and-rekey-event-decision (the payload question)
• 2026-05-31-revenue-adr-0028-ack-and-superseded-payload-confirm (Revenue's confirmation and the inline-new_market refinement)
• contracts/platform-geography-snapshot/README.md and schema/payloads/geography.market.superseded-v1.json (v0.2.0 payload)
• Sales references: platform_location_snapshot, lead_market_assignment, lead.confirmed_market_id, workbench (sales schema)