Sales acks ADR-0037 and confirms the subscriber design

Sales has read ADR-0037 and acknowledges it. The new-dedicated-event decision is the right call. Keeping person.updated PII-free and standing up person.contact.updated as an explicitly authorized, restrictable contact channel is a stronger privacy posture than extending the canonical event, and it avoids a major version bump of the identity contract. We agree with the rejected options as recorded.

Design alignment

The v1 payload (person_id, phone_normalized, email_normalized, changed, provenance with source and actor, occurred_at) matches the Sales subscriber design one for one, so we have no requested changes. Sales' internal application is captured in Sales ADR-0009 (a Sales-repo ADR, distinct from the coordination ADR-0009 producer-transactional guarantee you cite), which we have updated to track the confirmed contract. Carrying both current normalized values and firing on either change is exactly right; it lets the subscriber write the LeadIntakeSnapshot mirror without a follow-up fetch.

Provenance handling

You asked us to decide separately how to treat system-driven changes. Sales will apply both operator and system source values as authoritative overwrites to the snapshot. The mirror's job is to match identity truth regardless of what triggered the change, so an operator correction and a system merge or backfill are handled the same way on write; the provenance is recorded on the per-lead audit event for traceability rather than gating the write. If Platform later needs a class of system change held back, that is a payload signal we would honor, but the default is apply-all.

Consumer authorization (ADR-0037 action item 6)

Sales supports setting this deliberately rather than by precedent. Our proposed principle: a domain may subscribe to person.contact.updated only if it is already entitled to the lead's contact through an existing channel. Sales qualifies on that test (it receives contact at intake.captured and reads it on the close path through the operator-contact endpoint), so the event distributes nothing Sales did not already hold. Enforce the entitlement through the dispatcher fanout consumer set as an explicit allowlist, not a broadcast, which is what the current fanout already supports. For v1 that is Sales only. Platform owns the rule; Sales is content to be the single v1 consumer under it.

One additive note on validation

Sales' close pre-check, and the validator the subscriber will reuse, reject a phone whose exchange (the NXX leading digit) is not 2-9, in addition to the area-code and length checks. Platform's mint validator currently checks area code and length only, to keep the 1-555-0100 and 555-1XX test fixtures minting. The two gates are additive and Sales is the stricter on the writes it controls; the subscriber will drop an invalid incoming value rather than mirror it, so a value that passes Platform but fails NXX simply does not land in the Sales snapshot. No action requested, just shared awareness so the asymmetry is intentional on both sides.

Status

The subscriber commitment stands as declared on this thread, gated on the event reaching definition-of-ready (your schema, registry entry, and emit landing). Sales will implement Sales ADR-0009 against the confirmed payload when that gate clears. Separately, the intake-phone-validation thread is closed out on Sales' side: both validation asks shipped and the production sweep came back clean.