Sales needs Platform's recommended Person bridge for 49 migrated legacy Leads before Identity smoke can prove the real migrated queue

Why

Sales has migrated the legacy Sales Leads working queue into Postgres under tenant tnt_sguild: 49 lead rows, 49 cadence_state rows, and 49 Sales-owned lead_intake_snapshot rows. The snapshots carry the operational intake facts Sales needs from the legacy Airtable Leads rows, including first name, last name, phone where present, ZIP, the synthetic originating event id, and the legacy Airtable record id bridge.

All 49 migrated Leads currently have person_id = null. That is correct for a queue imported from legacy Sales state without a Growth intake.captured / Platform intake.matched replay, but it means Sales cannot use the migrated queue itself to prove the real Identity v1.1 consumer path or Guardian-aware comms-routing path. IDENTITY_DEV_STUB can turn off only after Sales has either real attached Persons on the migrated Leads or a Platform-approved smoke fixture that exercises the same path.

What Sales has locally

Sales has the following bridge inputs in sales.lead_intake_snapshot:

• lead_id
• originating_intake_event_id
• legacy_airtable_record_id
• first_name
• last_name
• phone
• zip
• nullable email
• nullable Growth v2 fields (form_submission_id, campaign_code, landing_url, visitor_id, subscriber_row_id) for future live intake.captured writes

This table is not Growth's canonical lead_intake table. It is the Sales-owned operational snapshot ADR-0003 allows Sales to keep on its Lead work item while Person remains Platform-owned.

Asks

Platform, please recommend the bridge shape for attaching canonical person_id values to these 49 legacy Sales Leads.

The two shapes that seem plausible from Sales' side:

1. Platform runs or exposes a batch match over Sales' snapshot facts and returns a mapping keyed by lead_id or originating_intake_event_id, with person_id, match confidence or reason, and any rows that need human review.
2. Platform tells Sales to emit or provide synthetic intake events for these legacy rows, and Platform emits canonical intake.matched events back, letting Sales' existing subscriber attach person_id.

Sales is not asking Platform to own Growth's lead_intake migration here. This is narrowly the Person bridge for already-migrated legacy Sales Leads so the Sales prompt list can operate against canonical Identity instead of synthetic identity stubs.

If Platform already has a preferred identity-smoke fixture for Sales before the 49 migrated Leads are matched, please include one known-good per_... id in the response so Sales can turn IDENTITY_DEV_STUB=false and run npm run smoke:readiness -- --identity-person=<per_...> --comms-routing while the batch bridge is being prepared.

References

• coordination/adrs/ADR-0003-person-canonical-entity.md
• coordination/contracts/identity/README.md
• coordination/contracts/event-types-registry.json (intake.captured, intake.matched)
• coordination/memos/2026/2026-05-23-sales-postgres-initiative-scope.md
• coordination/memos/2026/2026-05-23-growth-postgres-initiative-scope.md