A legacy authentication flow could encounter two related representations of a person's identity, shaped by historical account conventions. The question was not simply how to find an alternative identifier; it was how to avoid authenticating the wrong person when the relationship was missing or ambiguous.

Un flujo de autenticación heredado podía encontrar dos representaciones relacionadas de la identidad de una persona, moldeadas por convenciones históricas de cuentas. La pregunta no era solo cómo encontrar un identificador alternativo; era cómo evitar autenticar a la persona equivocada cuando la relación faltaba o era ambigua.

The request did not establish which flow should change, whether a shorthand was literal or only descriptive, how identifiers should take precedence, or what should happen for zero or multiple possible matches. Existing logic was repeated differently across several flows, so an apparent convention could not be treated as a business rule.

La solicitud no establecía qué flujo debía cambiar, si una abreviatura era literal o solo descriptiva, qué precedencia debían tener los identificadores ni qué debía ocurrir ante cero o varias coincidencias posibles. La lógica existente se repetía de forma distinta en varios flujos, por lo que una convención aparente no podía tratarse como regla de negocio.

The investigation established that the affected flow was a secondary authentication step, that its external account lookup required exact matching, and that an existing fallback could repeat the same failed attempt when an alternate value was absent. It also found that related flows already had different responsibilities, reducing the change surface to one guarded point.

La investigación estableció que el flujo afectado era un paso secundario de autenticación, que su búsqueda externa de cuenta requería coincidencia exacta y que un fallback existente podía repetir el mismo intento fallido cuando faltaba un valor alternativo. También encontró que los flujos relacionados ya tenían responsabilidades diferentes, reduciendo la superficie de cambio a un punto protegido.

An intermediate implementation added the guarded lookup, an exact retry, fail-closed handling, masked diagnostic logging, and focused tests. It did not change public contracts, external services, stored data, or unrelated identity types. The implementation and tests were later removed from the current tree; the available evidence documents the removal but not its cause. This case therefore describes an investigated and focal-validated proposal, not a retained solution.

Una implementación intermedia añadió la búsqueda protegida, un reintento exacto, manejo seguro ante fallos, registro diagnóstico enmascarado y pruebas focalizadas. No cambió contratos públicos, servicios externos, datos almacenados ni otros tipos de identidad. La implementación y pruebas se retiraron después del árbol actual; la evidencia disponible documenta el retiro, no su causa. Este caso describe una propuesta investigada y validada focalmente, no una solución retenida.

The work converted an ambiguous cross-system request into a verifiable flow map, isolated a no-op fallback, and defined a conservative policy for missing or ambiguous evidence. The focal implementation passed its recorded checks, but the required integration gate remained open. The correct outcome was no false closure: the change was not represented as deployed or complete, and the current behavior remains the prior one after the undocumented withdrawal.

El trabajo convirtió una solicitud ambigua entre sistemas en un mapa de flujo verificable, aisló un fallback sin efecto y definió una política conservadora para evidencia faltante o ambigua. La implementación focal pasó sus verificaciones registradas, pero la puerta de integración requerida permaneció abierta. El resultado correcto fue no declarar un cierre falso: el cambio no se representó como desplegado o completo, y el comportamiento actual sigue siendo el anterior tras el retiro no documentado.