Propagate Platform identity contact corrections to consumer mirrors

Why

When an operator corrects a phone number (or email) on a Person in Platform identity, the Sales workbench keeps showing the old value. The Sales display reads LeadIntakeSnapshot, a Sales-owned mirror seeded once from Growth's intake.captured. The Platform Person record and the Sales snapshot are independent copies, and there is no path for a correction in one to reach the other. The operator fixes the number in Platform, and the lead still reads wrong in Sales until someone edits the snapshot directly.

This is the follow-on to 2026-06-15-sales-intake-phone-validation. That memo is about stopping bad phone data at the source. This one is about getting corrections to flow once they are made.

The constraint

Two existing rules make this impossible to solve cleanly inside Sales alone.

The identity contract keeps phone and email Platform-internal (per the contract's "not on the contract" section, §11.1). They are exposed only through the operator-contact endpoint, which Sales already calls on the close path. Consumers do not get contact changes pushed to them.

The intake-amendment contract makes phone and email immutable downstream. Sales applies Growth's intake.amended events but is explicitly forbidden from mutating phone or email in its snapshot. So even when Platform is the authoritative source of a correction, Sales has no sanctioned way to update its own mirror.

The net effect is that an authoritative correction in Platform cannot reach Sales through any approved channel, which is the gap this memo asks us to close.

Proposal

Platform emits a contact-change event when a Person's normalized phone or email changes (working name person.contact.updated, or an extension of person.updated). The payload carries the personId, the new normalized phone and email, and provenance (operator edit versus system change). Sales subscribes and updates LeadIntakeSnapshot phone and email for the leads that resolve to that personId. A Platform-originated contact update is treated as authoritative and may overwrite the Sales mirror. That overwrite is the sanctioned exception to the downstream-immutability rule, scoped specifically to authoritative identity corrections, not to the intake.amended path the immutability rule was written for.

This keeps the display fast and Sales-owned (the workbench queue still renders from the local snapshot, no per-lead Platform call), and it makes corrections flow everywhere rather than only on the one lead an operator happens to open.

Asks

1. Platform: own and define the event. Register it in event-types-registry.json, author the payload schema, and decide whether it extends person.updated or stands up as a new type. Confirm the provenance field and whether email rides along with phone.

2. Growth: bless the exception to phone and email immutability for Platform-originated corrections. The immutability rule was aimed at the intake.amended consumer path, not at authoritative identity corrections, and we want to confirm that reading is right and that this does not conflict with intake.amended semantics.

3. Both: if there is appetite, capture the decision (the propagation mechanism and the immutability exception) as an ADR. Platform is the natural owner, since it produces the event and stewards identity.

Sales commitment

Once the event ships, Sales will build the subscriber and the snapshot write path. This is declared as a conditional commitment gated on the event in the frontmatter, with no deadline until the event reaches definition-of-ready.

References

Prior memo 2026-06-15-sales-intake-phone-validation covers validating phone numbers at the intake boundary. The relevant contract surfaces are the identity contract's Platform-internal contact fields (§11.1) and the operator-contact endpoint Sales already consumes on the close path, and the intake-amendment consumer in Sales that enforces phone and email immutability today.