Revenue declines absorbing Platform Identity phone repair or direct phone reads and asks Platform to define an operator-safe contact display surface for Revenue Workbench

Context

Revenue operators are reviewing Credit Accounts in the Revenue Workbench and asked Revenue to repair missing phone displays by pulling phone numbers from person_id.

Revenue confirms the Identity contract's Person minting rule: a canonical Person is minted only when the signal includes a phone number. So a Credit Account with person_id should normally imply Platform Identity has phone data somewhere in its internal identity state.

However, Revenue does not own canonical Person fields or Platform-internal contact data. The current cross-domain Identity contract deliberately excludes phone from Person reads, Person events, and the exported canonical Person shape. The same contract says outbound communication, especially for minors, must route through Platform's Guardian-aware comms-routing endpoint, and consumers must not store or use direct minor contact information even transiently.

The current Platform implementation follows that boundary. GET /api/identity/v1/person/{personId} returns the canonical Person shape only. GET /api/identity/v1/comms-routing/{personId} returns the Person who should receive outbound communications, not that Person's phone number. Platform's InternalPerson.phone_normalized is marked internal-only.

Revenue position

Revenue declines to absorb this as a Revenue data repair or direct Platform table read.

Revenue will not persist phone numbers in the Revenue database, direct-query Platform internal identity tables, or treat person_id as authorization to retrieve raw contact data. In the Workbench, Revenue can safely indicate that a phone is expected to live in Identity when person_id exists, and can indicate an identity-link problem when it does not.

Request to Platform

Please confirm the intended operator path for Revenue Workbench contact display:

1. Revenue should not display phone in the Workbench, and operators should use a Platform-owned Identity/operator screen for contact details.
2. Platform should publish an operator-authorized, tenant-scoped contact display API for Revenue Workbench, possibly returning a masked phone, a callable action token, or another privacy-preserving contact affordance.
3. Platform should run any required Identity data repair for Persons that violate the phone-at-mint invariant, then expose repair status through a Platform-owned operator or audit surface.

Revenue can wire the Workbench to the authorized Platform surface once Platform defines it. Until then, Revenue will keep the Workbench inside the current Identity contract and avoid storing or displaying raw phone data.

References

• contracts/identity/README.md section 5, canonical Person excludes contact methods.
• contracts/identity/README.md section 9.3, Guardian-aware comms-routing and no direct minor contact use by consumers.
• contracts/identity/README.md section 10.6, comms-routing returns the Person who should receive outbound communications.
• contracts/identity/README.md section 11.1, full contact data does not distribute to other domains.
• contracts/identity/person-canonical-fields.md, "Not on the contract" excludes email, phone, and messaging handles.
• Platform modules/person/dto.ts, InternalPerson.phone_normalized is internal-only.
• Platform modules/guardian/dto.ts and modules/guardian/service.ts, comms-routing returns CommsRoutingResult with a canonical Person recipient, not phone.