Platform owns person.contact.updated; design decisions and ADR-0037

Platform accepts ownership of the event and the ADR. Answers to your three asks below, and the decision is captured as ADR-0037 (Proposed), Platform-owned.

Ask 1: own and define the event

Decided as a new dedicated event type, person.contact.updated, not an extension of person.updated.

Why a new type rather than extending the existing one: person.updated is deliberately PII-free. The identity contract §11.1 keeps full contact data off the canonical contract as privacy-load-bearing, and §7.2 has person.updated carry only the phone_normalized changed-field marker, never the value. Putting contact values on person.updated would broadcast PII to every one of its subscribers and would relax §11.1 on the canonical contract, a major version bump. A dedicated event keeps the canonical event clean, makes the PII-carrying channel explicit and auditable, and lets us restrict delivery to consumers already entitled to the lead's contact (Sales receives it at intake.captured and reads it on the close path through the operator-contact endpoint), so this distributes nothing to a domain that was not already entitled to it.

Provenance: yes, carried. provenance.source is operator or system, derived from the updatePersonContact actor, plus the actor reference. You can treat operator corrections as authoritative overwrites and decide separately how to handle system-driven changes (merges, backfills).

Email rides along: yes. The payload carries both current normalized phone and email and fires when either changes, so you write your mirror without a follow-up fetch.

Payload v1: person_id, phone_normalized (nullable), email_normalized (nullable), changed (subset of ["phone", "email"]), provenance (source, actor), occurred_at. Emitted inside the same writeback transaction as the Person update, per the ADR-0009 producer-transactional guarantee, alongside the existing person.updated marker that invalidates caches.

Ask 2: the immutability carve-out (Growth)

Confirmed reading: the exception is scoped specifically to Platform-originated authoritative corrections and does not touch the intake.amended consumer path the immutability rule was written for. A Platform-originated person.contact.updated may overwrite a consumer mirror; an intake.amended event still may not mutate phone or email. Growth, please ack ADR-0037 and state the exception in the intake-amendment contract so the carve-out is explicit rather than folklore.

Ask 3: capture as an ADR

Done. ADR-0037 (Platform-originated person.contact.updated event for propagating identity contact corrections), Proposed, Platform-owned, acks requested from Growth and Sales. It records the new-type decision, the immutability carve-out, the payload, and the rejected options (extend person.updated, pull-on-render, re-capture).

Platform commitment and sequencing

Platform commits to authoring the payload schema and registry entry and emitting the event from updatePersonContact, with fanout restricted to entitled consumers. This is gated on ADR-0037 acceptance and the Growth immutability ack (declared conditional in the frontmatter). Platform reaching the event to definition-of-ready is the schema, the registry entry, and the emit landing, which is the gate your subscriber commitment is waiting on.

One open question

ADR-0037 action item 6: person.contact.updated is the first PII-carrying event on the identity surface, so we should decide the general consumer-authorization rule (who may subscribe) before a second consumer appears. For v1 it is simply Sales via fanout config; flagging it so we set the rule deliberately rather than by precedent.