Sales accepts Platform's person.updated archive propagation ask and commits the Lead consumer that pauses active cadence while preserving Lead history
Why
Platform's producer-side shape is the right one for Sales. Person status belongs to Platform, and Sales should consume the status transition rather than store a parallel Person archive flag. The person.updated predicate is also narrow enough for a safe subscriber: Sales only needs to react when changed_fields includes status and the post-update Person status is archived.
Sales accepts the ask and will build the consumer declared in the frontmatter commitment. The intent is operational suppression, not deletion. A Lead remains the historical work item for a Person, but an archived Person should not continue to receive Sales cadence prompts, callbacks, or new outbound communication.
What
Sales will add a person.updated subscriber in the Sales repo and filter on:
changed_fields.includes("status") && person.status === "archived"
On that predicate, Sales will find active Leads keyed to the emitted person_id and move them out of active work. The Sales-side lifecycle interpretation is: preserve the Lead row, preserve lead_activity, preserve lead_attempt, and preserve callback history, while stopping future operator prompts and outbound comms. In the current CRM vocabulary, the implementation should use the existing paused or terminal-lost shape rather than inventing a Platform-owned stage. The exact row mutation can land in Sales code review, but the external semantic is stable: archived Persons are not actionable in Sales.
This does not change reactivation semantics. If Platform later sends a status transition back to active, Sales can decide whether that should reopen an old Lead, require a new intake/reactivation Lead, or remain a manual operator decision. This memo commits only the archived-path suppression because that is the propagation gap Platform filed.
Growth's acquisition-suppression consumer and Sales' cadence-suppression consumer are independent. Sales is not waiting on Growth to build this, and Growth does not need Sales' lifecycle decision to build its own handler.
Asks
None. Sales' reply obligation on the Platform archive propagation thread is satisfied by this memo and the frontmatter commitment above.
References
- Platform parent memo:
memos/2026/2026-05-11-platform-archive-propagation-sales-growth.md - Identity contract:
contracts/identity/README.md - Canonical fields spec:
contracts/identity/person-canonical-fields.md - Person resolution semantics:
contracts/identity/person-resolution-semantics.md - Event envelope contract:
contracts/event-envelope/README.md person.updatedpayload schema:contracts/identity/schema/payloads/person.updated-v1.json- Event-types registry:
contracts/event-types-registry.json - Sales domain doc:
domains/sales.md