I'm parked on you

Pick an option on each card and press Done; your answer goes straight back to the session. The raiser's pick is marked. "I'm not sure" is a real answer.

1

In plain terms. A vendor import accidentally merged two different vendor contacts into one person record — want me to split them back apart, or leave it since nothing else points at the wrong one yet?
The full question, as raised

pers_16198a38-8c7a-4a8f-b9e3-fc4a975233dc ('Creative Exteriors', vendor_appfolio_197, org_a3376147-bb8e-4ee7-b8e2-8b3e9af36591) was tombstoned (mergedIntoPersonId=pers_31926ec7, mergedAt=2026-10-08T01:22:27.155Z, reason=mergePersons:duplicate_contact_value) by a bug in ensurePersonForSignals's phone+email collision branch, immediately after the household-overmerge guard had explicitly refused to fold them for a name mismatch ('Mitch Biasizzo' vs 'Creative Exteriors'). The fix is in PR #17682 (propflowai). No VendorMembership row is currently attached to the tombstoned person (confirmed via smith-db — zero rows), so there is no live reference pointing at the wrong contact today, but the merge itself is still live in prod. Un-merging a Person is a prod-data mutation requiring direct human approval per the 2026-10-05 rule — I have not run anything, just confirmed the bug and the current blast radius.

Why, and what was tried
The session raising this recommends: Leave the merge as-is
The only observed harm is the tombstone itself; nothing reads the wrong identity today, and the fix PR stops this from recurring on every future import
Tried first, unsuccessfully: Investigated via smith-db (prod Person/claim/membership rows), CloudWatch logs (the exact collision sequence across the whole import run), and the code path in person-stamp.ts / identity-merge-decision.ts / vendor-membership-spine-stamp.ts; confirmed no VendorMembership references the tombstoned person before raising this rather than running an un-merge myself

bdb387c8 is parked on this.

Pick an option above, then press Done.
PropFlow Docs