Possible MISBINDING: Terra profile bound to an auth account whose display name does not match it, while a failed-noMatch account does (Case B, carved from TERRA-274)
Carved out of TERRA-274 on 2026-10-06. support-evolutiva-cc identified it and withdrew its own benign explanation on the evidence (support-evolutiva-cc-muw8fp4elunx). SHAPE: among the historical noMatch GoTrue accounts, one case (Case B) has the FAILED account's Google display name equal to the Terra profile's full name, while the account currently BOUND to that profile does NOT match the profile name. The benign reading - one person holding two Google accounts who signed in with the wrong one - is evidence AGAINST itself here: if the bound account is a different person's, then the person whose name is on the profile is locked out while someone else's session holds their profile and whatever it exposes. WHY p1 AND NOT PART OF THE COHORT: a second Google account is nothing wrong and needs only an instruction. A misbinding is an active access-control problem. They were being triaged at equal priority because both were 'candidate-level'; they have very different costs and only one is an active problem. VERIFICATION ASKED (read-only, aggregate to this row, specifics privately to support): (1) does the BOUND auth id look like a same-person address for that profile, or a different person's - that is the wrong-account-used vs misbound discriminator; (2) does that profile hold practica or paciente rows and how many - per support, the EXPOSURE sets the severity, not the binding. Report both even if (1) returns same-person: a null on (1) with clinical rows present still records what was at stake. NOT AN AGENT REPAIR: no unbind, no write, no outreach. Characterise it, then it is Elazar's to resolve. Distinct from Case A, the surname cross-pair of two different real people EACH already correctly bound - that pair is the demonstrated argument for the catedra human gate, since a surname-driven repair would have written each one's address onto the other's profile.
Activity
-
3
-
DOWNGRADED p1 -> p3 on 2026-10-06, same night it was filed, on db-terra-ca's read-only verification (db-terra-ca-muw8ju8lpqpx). It was filed p1 because a misbinding is an active access-control problem; the measurement says this is probably not one. BOTH VERIFICATIONS I ASKED FOR CAME BACK AGAINST THE MISBINDING READING: (1) Same-person signals on the BOUND account are STRONG, not contrary. Its current canonical email equals the profile's stored email; its local-part is first name + middle initials + surname while its Google display name is first name + surname with the middle name omitted. The FAILED account's local-part is surname + first + middle + digits and its display name equals the full profile name. Both plausibly belong to the named person. So the asymmetry support originally spotted - failed account's display name matches the profile, bound account's does not - is explained by the bound account simply OMITTING the middle name, not by belonging to someone else. (2) Exposure is ZERO: 0 terraPracticas created live or historical, 0 live practice participations, 0 distinct patients on linked live practices, 0 Terra pacientes created live or historical. So: second-account explanation favoured, no clinical exposure, severity falls. p3 and behind catedra confirmation with the rest. WHAT I AM NOT CONCLUDING, because two separate limits were stated and both matter: - Same-person signals do NOT prove shared ownership. No unbind, no correction, no instruction to the user, and NO decrement of the 18-account count without per-case identity/enrolment confirmation. The count is of accounts, not people, and it stays 18. - db-terra-ca named its own coverage limit and I am recording it rather than rounding it off: that census is PROFILE-LINKED, not a measurement of every record the role could read. 'Zero rows created' is not 'zero rows readable'. The exposure finding is as wide as the query, no wider - and if this ever gets re-escalated, the readable-set question is the one that was never asked. Keeping the row open rather than closing it: the benign explanation is favoured, not established, and the thing that would settle it is the catedra confirmation already queued. Also retained for the record - support filed this after WITHDRAWING its own benign default on the evidence, and the evidence then came back supporting the default after all. Both moves were correct at the time they were made.