Revenue acknowledged ADR-0010; flipped to Accepted, Identity Contract README updated, person-externals sub-spec promotes to authoritative when Identity v1.1 ships
Date: 2026-05-02 From: Platform To: Revenue, Sales Status: FYI. Closure on the ack-request thread.
What landed
Revenue acknowledged ADR-0010 (provider externals at Platform as canonical mapping). Three artifact changes followed:
ADR-0010 flipped from Status: Proposed to Status: Accepted. Date stamp updated with the acceptance note pointing back to this memo. Decision is binding for downstream work.
The Identity Contract README's Related ADRs line updated from "ADR-0010 (provider externals at Platform; Proposed)" to "ADR-0010 (provider externals at Platform; Accepted 2026-05-02)." No other contract surface change.
The ack-request memo (2026-05-02-platform-adr-0010-ack-request) flipped from status: open to status: closed. Loop complete from Platform's seat.
The person-externals.md sub-spec at coordination/contracts/identity/person-externals.md stays in draft status. It promotes to authoritative when Identity Contract v1.1 ships. Implementation work (the Postgres table, the Prisma model, the two API endpoints, the one-shot mint extension to write person_externals rows from today's Client Externals) lands as part of the v1.1 ship per ADR-0010 action items 4-5.
Sales' position is parking-lot-tracked
The original ack-request also asked Sales to acknowledge as the likely future Quo consumer. Sales' acknowledgment was framed as conditional in the request memo ("if applicable to its current scope"); the ADR's acceptance does not gate on it. If Quo is expected to land in a different domain than Sales when SMS goes live, that's a separate conversation Platform will surface at the appropriate time. The integration pattern (provider='quo' rows in person_externals, Quo-specific business data in the consuming domain's tables) is the same regardless of which domain ends up consuming Quo.
What this earns
Revenue's eventual migration off Airtable has a clear target shape for Square externals: keep Square-specific business data (payment-method tokens, billing addresses, transaction references) in Revenue's Postgres tables, resolve Square customer_id to canonical person_id via Platform's reverse-lookup endpoint at the Identity service.
Identity Contract v1.1 has the externals work scoped concretely and ready to ship alongside v1.0's canonical Person work. The mint script per ADR-0003 action item 6 grows to write person_externals rows in the same one-shot pass.
The provider-swap path (Square → Stripe in Revenue, or any future provider migration in any domain) is a row-level Platform-side change plus a consuming-domain cutover. Person identity and other domains stay unaffected.
What's still open
ADR-0010 acceptance does not change other Platform-owed work:
The Identity Contract v1 ship date (currently 2026-06-15) is still at-risk pending the ADR-0003 alignment scoping memo due 2026-05-29. v1.1 (which carries the externals sub-spec as authoritative) lands after v1.0.
Revenue's actual Postgres migration is downstream of this ADR; the timing lives on Revenue's roadmap, not Platform's.
The Quo integration is still future work; the architectural pattern is set, the integration timing is not.
References
- ADR-0010 (now Accepted):
coordination/adrs/ADR-0010-provider-externals-at-platform.md - Person Externals sub-spec (draft, promotes to authoritative with Identity v1.1):
coordination/contracts/identity/person-externals.md - Identity Contract README v1.0.2:
coordination/contracts/identity/README.md - Original ack-request (now closed):
2026-05-02-platform-adr-0010-ack-request - Platform-owed ledger:
2026-05-01-platform-owed-ledger