La identidad a través de los sistemas

Un martes de mayo, María Gonzales compra una camiseta en la tienda del centro.

Para la caja registradora, María no es María. Es cliente_1042, quien compró la camiseta_88.

Tres semanas después, esa misma María llega a urgencias con una arritmia. Para el sistema de la clínica no existe ningún cliente_1042: existe paciente_maria_g.

Y cuando al mes paga sus arbitrios, la municipalidad la conoce por un tercer nombre: contribuyente_77‑3389.

Tres sistemas, tres identificadores, una sola persona. Y ninguno de los tres sabe que la comparte con los otros.

Esa es la grieta que este capítulo cierra.

El libro prometió, desde la introducción, que las preguntas servirían de vocabulario común para que sistemas que hoy no se hablan pudieran responder juntos.

Pero un vocabulario común no basta.

Aunque la tienda y la clínica coincidieran en llamar agente al cable que apunta a una persona, seguirían sin saber que cliente_1042 y paciente_maria_g son la misma.

Responder a eso, quién es quién de verdad a través de los sistemas, es lo que llamamos resolución de identidad. Es el último eslabón.

Identidad no es lo mismo que identificador

Conviene separar dos palabras que el habla corriente confunde.

La identidad es la persona real: María Gonzales, única en el mundo, que existía antes de comprar nada y existirá cuando la camiseta se decolore.

Vive en el eje Q quién, y es una entidad del modelo, no una cadena de texto.

El identificador es el rótulo que un sistema concreto le pega encima para referirse a ella. cliente_1042 es el que eligió la tienda, y solo tiene sentido dentro de la tienda.

La distinción importa porque los identificadores son locales y arbitrarios.

Cada sistema acuña los suyos sin consultar a nadie. La tienda numera a sus clientes en orden de llegada, la clínica usa el apellido, la municipalidad concatena un código tributario.

Ninguno es más correcto que otro. Son tres nombres privados para una misma persona pública.

El error clásico, y la causa de media torre de Babel, es confundir el rótulo con lo rotulado: tratar cliente_1042 como si fuera la persona, en vez de como una flecha que apunta a ella.

La analogía que lo aclara todo: punteros

Quien haya programado a bajo nivel reconocerá la situación, porque es la de los punteros.

Un puntero no es un objeto. Es una dirección, un papelito que dice «lo que buscas está allá».

Varios papelitos pueden señalar el mismo rincón de la memoria. El objeto es uno; las direcciones que lo apuntan, muchas.

Esa asimetría es la columna vertebral de este capítulo.

Traduzcamos el modelo entero a ese vocabulario, porque la correspondencia es asombrosamente limpia:

• Cada identificador es un puntero. cliente_1042 no contiene a María: apunta a ella. Es la dirección que usa la tienda para llegar a la persona.
• Reificar es «tomar la dirección». Cuando en el capítulo 9 convertimos un evento fugaz (una venta, un gol) en un objeto con identidad propia, lo que hicimos fue darle una dirección estable para poder apuntarlo después. Reificar es el operador & del modelo: pasar de «algo ocurrió» a «este algo, al que ahora puedo señalar».
• mismo_que es aliasing de punteros. Dos direcciones, un mismo objeto. Declarar (cliente_1042, mismo_que, persona_maria_g) es decirle al sistema: «estos dos papelitos llevan al mismo sitio; trátalos como sinónimos».
• El grafo entero es una estructura de punteros. Cada tripleta enlaza nodos por referencia, no por copia. El conocimiento no es una pila de tablas planas: es un tejido de direcciones que se apuntan unas a otras, como un montón de objetos en un heap.

Cómo se resuelve la identidad, en la práctica

Saber que hace falta resolver la identidad es la mitad fácil. La otra mitad es cómo el sistema decide que dos punteros llevan al mismo sitio. Hay tres vías, ordenadas de la más fiable a la más resbaladiza.

Vía 1 · Claves naturales con autoridad externa

La situación ideal: existe un identificador que no es local, porque lo emite una autoridad que todos reconocen.

El DNI de una persona, el RUC de una empresa, un correo verificado, el ISBN de un libro, el IBAN de una cuenta.

Cuando dos sistemas registran el mismo DNI, la identidad se resuelve sola. No hay nada que adivinar, porque los dos citan la misma fuente.

Es, siguiendo la imagen del puntero, una dirección canónica que todo el mundo acordó usar.

(cliente_1042,  documento_dni, "20148833")   ∈ M(Q, K)   // la tienda lo registró
(paciente_maria_g, documento_dni, "20148833")   ∈ M(Q, K)   // la clínica también
// misma clave natural ⇒ misma identidad: la resolución es deductiva, no probable

Vía 2 · mismo_que declarado como un hecho más

A veces no hay clave común, pero alguien sabe que dos identificadores coinciden y quiere dejarlo escrito.

El modelo no necesita maquinaria nueva. La identidad compartida se guarda como cualquier otro hecho, con el cable mismo_que.

Ahí está la elegancia: una afirmación de identidad es un dato de primera, que se puede fechar, atribuir y revisar como cualquier otro.

Porque es un hecho como los demás, puede reificarse cuando importa quién lo afirmó y cuándo (exactamente las razones de reificación del capítulo 9). Una fusión de identidades en un banco no es trivial: conviene saber qué operador la aprobó, con qué evidencia y en qué fecha, por si mañana hay que deshacerla.

Vía 3 · Matching probabilístico

El caso incómodo, y el más frecuente en la vida real: no hay clave común y nadie declaró nada.

La tienda guardó «María Gonzales», la clínica «M. Gonzales Ramos», la municipalidad «Gonzales, María A.».

¿Son la misma? Probablemente. Y «probablemente» es una palabra peligrosa en una base de datos.

Aquí la identidad se deduce comparando rasgos (nombre, fecha de nacimiento, dirección, teléfono) y calculando cuánto se parecen.

Por encima de cierto umbral, el sistema propone que son la misma persona. Por debajo, los deja separados.

El modelo: una persona canónica con identidades colgando

Con las tres vías sobre la mesa, el patrón es directo.

Existe una identidad canónica, un único nodo en Q. Y a su alrededor, los identificadores locales de cada sistema, unidos a ella por mismo_que.

Cada sistema sigue usando su rótulo de siempre, sin renunciar a nada. El grafo se encarga de que todos esos rótulos lleven a la misma persona.

(persona_maria_g,  instancia_de, persona)      ∈ M(Q, K)   // la identidad canónica
(persona_maria_g,  documento_dni, "20148833")  ∈ M(Q, K)   // su clave natural

(cliente_1042,        mismo_que, persona_maria_g)  ∈ M(Q, Q)   // alias de la tienda
(paciente_maria_g,       mismo_que, persona_maria_g)  ∈ M(Q, Q)   // alias de la clínica
(contribuyente_77_3389, mismo_que, persona_maria_g) ∈ M(Q, Q)  // alias de la municipalidad

// y los hechos de cada sistema cuelgan de su propio puntero, como siempre:
(venta_001,  comprador, cliente_1042)   ∈ M(O, Q)   // la tienda vendió la camiseta_88
(urgencias_2026_071, paciente, paciente_maria_g) ∈ M(O, Q)   // la clínica abrió el episodio

Mira el reparto de trabajo.

Cada sistema escribe sus hechos contra su puntero, como siempre, sin coordinarse con nadie. La tienda no necesita saber que la clínica existe.

La única tripleta que cruza fronteras es la afirmación de identidad.

Resolver un grafo de muchos sistemas no exige reescribir los datos de cada uno. Exige tender los hilos mismo_que que faltan. El resto del tejido ya estaba.

Reconciliar que la María Gonzales de la tienda, la de la clínica y la de la municipalidad son una sola no sirve únicamente para esa María. Hecho a escala, es lo que permite el padrón único: cruzar los registros de todas las personas repartidas entre sistemas y contarlas una sola vez, sin duplicados.

Tres cosas que le pasan a un identificador

La reacción natural es preguntarse por qué tanto rodeo.

Si cliente_1042, paciente_maria_g y contribuyente_77_3389 son la misma señora, ¿por qué no corregir los tres y terminar?

Porque corregir es una de tres operaciones distintas, y aquí es la equivocada.

Conviene separarlas, porque desde fuera se parecen mucho y el sistema no va a avisarte.

María se mudó. Su dirección era la avenida Grau 220 y ahora es el jirón Camaná 415.

Nada estuvo mal anotado. Lo que cambió fue el mundo.

El valor viejo fue verdad durante un tiempo y hay que poder seguir consultándolo, porque el envío que llegó a Grau el año pasado llegó a la dirección correcta.

Esto es la vigencia: el hecho lleva su rango de inicio y fin, y preguntar por una fecha devuelve lo que valía en esa fecha.

A María le tecleamos mal el apellido. En la ficha de la clínica figura «Gonzalez» y siempre fue «Gonzales».

Aquí no cambió nada afuera. Cambió lo que nosotros habíamos escrito.

El valor viejo no fue verdad ni un solo minuto, y por eso no debe seguir respondiendo consultas.

Esto es una corrección, y su diferencia con el caso anterior no es de grado. Es de naturaleza.

Una vigencia certifica que algo fue cierto durante un periodo. Aplicarla a un tecleo deja escrito en el grafo que María se apellidó «Gonzalez» entre marzo y julio: una afirmación falsa que nadie hizo nunca.

contribuyente_77_3389 resulta ser María. Este es el caso del capítulo.

No hay nada que corregir, porque nada está mal. La municipalidad la registró bajo ese identificador, y bajo ese identificador ocurrieron sus arbitrios.

Tampoco cambió el mundo.

Lo único que pasó es que ahora sabemos algo que antes no sabíamos: que ese papelito y los otros dos llevan a la misma persona.

Y eso se escribe con mismo_que, sin tocar ninguno de los hechos que ya estaban.

Vistos así, los tres casos no se distinguen por lo que ocurrió afuera. Se distinguen por sobre qué están afirmando algo.

La vigencia afirma sobre el mundo: esto fue así y luego dejó de serlo.

La corrección afirma sobre la anotación: lo que escribimos no correspondía.

mismo_que afirma sobre el referente: estos dos papelitos llevan al mismo sitio.

Tres cosas distintas (el mundo, el registro y la cosa señalada) que este capítulo ya había separado al distinguir el papelito de lo que encuentras al final.

Nada de esto añade maquinaria. La vigencia venía del capítulo 9, corregir es asentar un hecho nuevo y mismo_que es el cable que llevamos toda la sección tendiendo. Lo que hay que añadir no es un mecanismo sino una decisión, y hay que tomarla antes de escribir: cuál de las tres cosas ha pasado.

No es una decisión numerada: es una convención de fondo

Conviene ser claro sobre el estatus de esto.

La resolución de identidad no introduce una regla de diseño nueva. Aquí no hay maquinaria que no existiera ya.

Es una convención fuerte que sale de piezas que ya conoces: la entidad del eje Q como referente, el cable como referencia, la reificación como dirección estable.

La identidad sale de juntarlas bien, no de añadir nada.

Por qué esto sostiene toda la promesa del libro

Detente a imaginar la consulta que da sentido a este libro entero: «muéstrame todo lo que el sistema sabe de María Gonzales».

Sus compras en la tienda, su episodio en urgencias, sus arbitrios en la municipalidad. Tres dominios que nunca se diseñaron para hablarse, reunidos en una sola respuesta.

Esa consulta es la prueba viva de lo que prometió la introducción.

Y es imposible sin resolución de identidad. Sin las flechas mismo_que, «¿qué sabemos de María?» se rompe en tres preguntas que ningún sistema puede juntar, porque ninguno reconoce a la María del otro.

De aquí sale un principio que reaparece con fuerza en la municipalidad: el de «una sola vez».

Si la clínica ya verificó la dirección de María, la municipalidad no debería volver a pedírsela. Si la tienda ya tiene su correo, ningún tercer sistema tendría por qué exigirlo de nuevo.

El dato vive una vez, en el individuo canónico, y todos lo consultan allí.

«No vuelvas a pedir lo que otro sistema ya sabe» es la cara amable de todo esto para el ciudadano, el paciente, el cliente.

Lo que para el ingeniero es un puntero compartido, para la persona es no tener que llenar el mismo formulario tres veces.

La identidad bien resuelta no es una sutileza técnica. Es lo que convierte un montón de sistemas aislados en algo que, por fin, se comporta como si supiera quién eres.

Un identificador es un papelito que dice dónde mirar; la identidad es lo que encuentras al mirar. El error de toda torre de Babel es confundir el papelito con la persona.La tesis del capítulo

Con esto, la Parte III queda completa.

Tenemos el hecho atómico, el espacio donde vive, las situaciones que lo enriquecen, la causalidad que lo enlaza y, ahora, la identidad que permite que todo eso cruce de un sistema a otro sin perderse.

Lo que sigue es tender la mano a los mundos vecinos (los objetos de la programación, los bits, los grafos, las cadenas de bloques) y mostrar que el modelo no es una isla, sino un puente.