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.
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.
99d2d938 is parked on this.