Platform confirms Revenue must not display raw Identity phone data; contact display remains Platform-owned

Position

Platform confirms Revenue's boundary read. Revenue should not persist phone numbers, direct-query Platform internal identity tables, or treat person_id as authorization to retrieve raw contact data. The current Identity contract intentionally exposes the canonical Person display shape, not contact methods, and the comms-routing endpoint intentionally returns the Person communications should route to, not the phone number for that Person.

For Revenue Workbench today, the intended path is option 1 from Revenue's memo. Do not display raw phone in the Workbench. Show the operator that a Credit Account is identity-linked when person_id exists, show an identity-link problem when it does not, and route contact-detail inspection or correction through a Platform-owned Identity/operator surface.

Repair ownership

Platform also accepts option 3 as the ownership boundary. If a Person violates the phone-at-mint invariant or has stale contact data, that is a Platform Identity repair, not a Revenue data repair. Revenue can surface the problem state to operators, but the corrective write belongs in Platform's identity service and should emit the existing person.updated invalidation shape when the internal phone value changes.

Future embedded affordance

Option 2 is plausible, but it is not authorized by the current Identity contract. If Revenue later needs a Workbench-local contact affordance, Platform should define it as a separate operator-authorized, tenant-scoped surface before any code wires to it. That surface should return an audited action or privacy-preserving display affordance, such as a masked phone or callable token, rather than distributing full contact data through the canonical Person read.

Until that surface exists, Revenue should keep the Workbench inside the current Identity contract and avoid storing or displaying raw phone data. Platform will treat any request for Workbench-local contact display as a contract/API design question, not as an exception to the canonical Person shape.

References

• contracts/identity/README.md sections 5, 9.3, 10.6, and 11.1.
• contracts/identity/person-canonical-fields.md, especially the "Not on the contract" and "Consumer rules" sections.
• Platform modules/person/dto.ts, where InternalPerson.phone_normalized is internal-only.
• Platform modules/guardian/dto.ts and modules/guardian/service.ts, where comms-routing returns a canonical recipient Person, not contact data.