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 property-management tool refused to link two tenant records that are very likely the same renter — can I merge them into one record?
The full question, as raised

identity_contact_match_refused (phone-name-mismatch, cotenant.spine-stamp) at org org_a3376147 (Situs Group), property appfolio-situsgroup-property-42. Existing person pers_4ffd16a7 ('Nelson A. De La Cruz Garcia', phone +17206762881, AF tenant 3176, active occupancy unit 1, lease 2022-01-03..2027-02-28). New/kept person pers_df952b52 ('Nelson A. De La Cruz', email nelsonmilian125@icloud.com, AF tenant 3140, former occupancy unit 110, lease 2025-12-01..2026-11-30). Same first name + same leading surname token, same property, same phone signal on the incoming record — only difference is the maternal surname 'Garcia' present on one AppFolio tenant record and missing on the other. The strict household-overmerge name guard (person-stamp.ts reuseAllowedByName, design review C-01) treats the missing surname token as a structural mismatch and refuses to merge/follow, by design — it exists to stop gluing two DIFFERENT humans sharing one phone. A near-identical case in this SAME org (block b90699227, 6 days ago) got the answer 'Merge them into one record' from you. Merging would run the canonical mergePersons(source=pers_df952b52, target=pers_4ffd16a7) primitive (ADR-0032 §4a, a soft-redirect — re-targets df952b52's email claim and former-unit-110 occupancy onto pers_4ffd16a7, deprecates/redirects the source). This is a prod identity-data mutation, so I'm not running it without your direct go-ahead on this exact pair.

Why, and what was tried
The session raising this recommends: Merge them into one record
Same org already answered this exact alert shape the same way 6 days ago (b90699227); here the only name delta is a missing maternal surname on one AppFolio tenant record, and both records share a phone signal and the same property across adjacent unit tenancies.
Tried first, unsuccessfully: Pulled both Person rows + claims + occupancies from propflow-prod via smith-db, traced the refusal to person-stamp.ts's strict household-overmerge name guard, confirmed the strict comparator (not the lenient one used elsewhere) is what refused this pair, and found an existing resolved precedent for the same org/alert shape before raising.

99d2d938 is parked on this.

Pick an option above, then press Done.
PropFlow Docs