El hecho atómico

Son las 16:32 y el vendedor Marco cierra la venta de una camiseta.

Ese gesto dura tres segundos y esconde más datos de los que parece: alguien que vende, un cliente que paga, un artículo que se entrega, un monto en dólares y una hora exacta.

En los seis capítulos anteriores aprendimos a colocar cada uno de esos trozos en su eje. Marco es un Q, la camiseta un O, los 49,90 dólares un N.

Pero clasificar no es describir. Tenemos las piezas sobre la mesa y nos falta el gesto que las une.

Ese gesto es el tema de este capítulo.

Para que las siete coordenadas dejen de ser cajones de un archivador y empiecen a contar la historia de la venta de Marco, hace falta la pieza más pequeña con la que se puede decir algo sobre el mundo.

La llamaremos el hecho atómico, y su forma es desconcertantemente simple.

La forma de un hecho

Un hecho atómico es siempre una frase de exactamente tres partes (una tripleta): un sujeto, un predicado y un objeto.

Se lee de izquierda a derecha, como una frase corriente: «la venta 001 tiene como agente al vendedor 17».

El sujeto y el objeto salen de alguna de las cajas de valor: un evento del eje O, una persona del eje Q, un número del eje N.

El cable del medio es el que vimos en el capítulo anterior: un habitante del eje M, el cómo, que une los dos extremos.

Y eso es todo. No hay un cuarto campo escondido, ni una nota al pie, ni una excepción para los casos difíciles.

La afirmación que sostiene este capítulo cuesta creerla al principio: toda la información que el sistema sabe del mundo se construye con esta misma forma, repetida una y otra vez.

Las ventas, las jugadas de fútbol, las películas, las ordenanzas de un municipio, las llamadas a un agente de inteligencia artificial. Todo.

El resto del capítulo lo demuestra, y explica por qué esa terquedad por una sola forma es lo que hace que el sistema no se rompa nunca.

La misma forma viaja entre dominios sin deformarse. Mira cinco hechos sacados de cinco industrias que no tienen nada en común. Cambian los individuos, cambian los cables; la estructura, jamás.

(venta_001,      vendedor,       vendedor_17)          ∈ M(O, Q)   👕
(gol_001,        agente,         messi)                ∈ M(O, Q)   ⚽
(pelicula_marea, directora,      serra)                ∈ M(O, Q)   🎬
(ordenanza_142,  fecha_publicacion, 2026-05-14)        ∈ M(O, T)   🏛️
(sesion_ia_5521, tokens_entrada, 4180)                 ∈ M(O, N)   🤖

Cinco cables distintos y cinco pares de cajas distintos. Y las cinco líneas son, estructuralmente, la misma línea.

Esa uniformidad no es un capricho para que el código se vea ordenado. Es la propiedad de la que cuelga todo lo demás. Vale la pena escribirla en piedra.

La decisión D3

Ya tomamos dos decisiones de diseño en los capítulos previos (D1 y D2). La que sigue es, con diferencia, la más pesada del libro, porque el resto de la arquitectura se apoya literalmente sobre ella.

Léela despacio, porque tiene dos prohibiciones tan importantes como sus permisos.

La primera: un cable sin tipo no es un cable válido.

La segunda: ante un dato más rico, la respuesta nunca es «cambiemos la estructura». Es «agreguemos más tripletas».

Todo lo que sigue sale de haber tomado esa decisión.

Tres exigencias que el átomo debe cumplir

Para que esta unidad mínima funcione como cimiento de cualquier base de datos del mundo, debe satisfacer tres exigencias estrictas. No son adornos: si fallara cualquiera de las tres, el modelo se vendría abajo.

Exigencia 1 — Tipada: protección contra el caos

Cada cable lleva pegada su regla de seguridad, su signatura: qué caja admite a la izquierda y qué caja admite a la derecha.

El cable monto_usd sabe de fábrica que conecta un objeto del eje O con un número del eje N. Eso es lo que dice la parte ∈ M(O, N) al final de cada línea.

(venta_001, monto_usd, 49.90)      ∈ M(O, N)   // válido: 49.90 vive en la caja N
(venta_001, monto_usd, "caro")     ✗ rechazada  // "caro" no es un número

Si un programador cansado intenta registrar (venta_001, monto_usd, "caro"), el sistema lo rechaza al instante. La palabra «caro» no vive en la caja de los números.

Esa protección, que ocurre en el momento, es lo que convierte la tripleta en un bloque seguro. Un dato absurdo ni siquiera llega a guardarse.

Exigencia 2 — Independiente: cada hecho se sostiene solo

Cada hecho tiene que tener sentido por sí mismo, sin depender de ningún otro.

La tripleta (gol_001, agente, messi) significa lo mismo aunque nadie haya anotado todavía en qué minuto ocurrió ni cómo quedó el marcador. Quitarle contexto no la corrompe: solo la deja menos detallada.

Esa independencia es un superpoder silencioso: permite guardar el hecho en un archivo de texto, en una base de datos relacional o enviarlo por internet a otro continente sin que pierda una gota de su significado. El átomo es portátil porque no arrastra dependencias ocultas.

Exigencia 3 — Componible: los átomos se apilan

Aunque cada hecho es independiente, su verdadera potencia se libera cuando los apilas sobre un mismo sujeto. Una venta no se describe en una frase gigante; se describe con una lluvia de átomos que comparten a venta_001 como sujeto, cada uno aportando una coordenada distinta.

(venta_001, instancia_de,  venta)            ∈ M(O, K)
(venta_001, vendedor,      vendedor_17)      ∈ M(O, Q)
(venta_001, cliente,       cliente_1042)     ∈ M(O, Q)
(venta_001, objeto,        camiseta_88)      ∈ M(O, O)
(venta_001, talla,         talla_m)          ∈ M(O, K)
(venta_001, color,         azul)             ∈ M(O, K)
(venta_001, cantidad,      1)                ∈ M(O, N)
(venta_001, monto_usd,     49.90)            ∈ M(O, N)
(venta_001, medio_pago,    tarjeta)          ∈ M(O, K)
(venta_001, momento,       2026-05-14T16:32:00-05:00)  ∈ M(O, T)

Diez piezas de Lego que juntas dibujan la operación entera: qué se vendió, quién la atendió, a qué cliente, en qué talla y color, cuántas unidades, por cuánto, con qué medio de pago y a qué hora.

Cada pieza se entiende por separado. Sumadas, forman el retrato completo de la venta.

Lo revelador llega cuando el negocio quiere hilar más fino.

Supongamos que la tienda decide auditar de qué lote de inventario salió cada artículo, con su fecha de ingreso.

En una base tradicional habría que alterar la tabla de ventas, añadirle columnas y migrar miles de filas. Tocar la estructura, con todo el riesgo que eso lleva.

Aquí la estructura no cambia nunca. Se eleva la entrega del artículo a la categoría de evento, lo que ya aprendimos a llamar reificar, y se le cuelgan sus propias tripletas:

(entrega_001, parte_de,    venta_001)        ∈ M(O, O)
(entrega_001, articulo,    camiseta_88)      ∈ M(O, O)
(entrega_001, lote,        lote_2026_044)    ∈ M(O, K)
(entrega_001, cantidad,    1)                ∈ M(O, N)
(entrega_001, ingresado_el, 2026-05-02)      ∈ M(O, T)

El universo de datos es una pizarra de tripletas

Cuando una empresa empieza a guardar miles, y luego millones, de estos hechos, se va tejiendo una red inmensa de nodos conectados por cables. A esa red se le llama grafo.

Y conviene decir con claridad qué es una base de datos WQuestions: un montón enorme de frases de tres partes escritas en una pizarra común. Ni más, ni menos.

El estado entero de la realidad, para el sistema, se reduce a contar cables sobre una pizarra. No hay archivos ocultos ni arquitecturas secretas que solo entiendan los creadores del software.El principio de la pizarra

Esa transparencia es liberadora.

Si le preguntas a la máquina «¿quién dirigió la película Marea?», no hay misterio. Busca cables que arranquen en pelicula_marea y lleven la etiqueta directora.

Y si pides algo más ambicioso, «dame todas las directoras de largometrajes estrenados después de 2020», el sistema hace un trabajo tonto y velocísimo.

Localiza los cables año_estreno cuyo número supere 2020, mira a qué películas están pegados y busca quién figura como directora en cada una.

Cada paso es saltar de una tripleta a la siguiente. Fin del enigma.

Cuando tres palabras no alcanzan: la reificación

A veces la realidad se niega a caber en una sola tripleta. Piensa en esta crónica deportiva, de las que se narran en una sola respiración:

«Messi le pasó el balón a Di María en el minuto 87 con un toque de pierna izquierda.»

Esa frase es una veta de oro. Tiene un autor (Messi), un beneficiario (Di María), un objeto (el balón), un momento (minuto 87) y un instrumento (la pierna izquierda).

Meterla a la fuerza en una tripleta simple, (messi, paso_el_balon_a, di_maria), sería tirar a la basura casi toda la información.

¿Cómo lo resolvemos sin romper la D3?

Con la reificación, que ya asomó en capítulos anteriores. La maniobra es elegante: elevamos ese pase al estatus de evento con nombre propio dentro del eje O (lo bautizamos pase_001) y colgamos a cada participante con su propia tripleta, todas apuntando a ese evento central.

(pase_001, instancia_de,  accion_pasar)               ∈ M(O, K)
(pase_001, agente,        messi)                      ∈ M(O, Q)
(pase_001, beneficiario,  di_maria)                   ∈ M(O, Q)
(pase_001, objeto_pase,   balon_partido_001)          ∈ M(O, O)
(pase_001, minuto,        87)                         ∈ M(O, N)
(pase_001, instrumento,   pierna_izquierda)           ∈ M(O, K)

Lo que era un nudo imposible de meter en una fila de tabla se desarmó en seis hechos independientes, cada uno con su tipo, cada uno sostenido por sí solo.

Un evento con muchos participantes se conservó entero sin abandonar la forma de la tripleta. La figura siguiente muestra esa estrella de hechos alrededor del evento central.

Aquí va una regla práctica que conviene tatuarse: reifica solo cuando te falte sitio.

Si la relación es entre dos individuos y nada más, como (pelicula_marea, directora, serra), basta una tripleta directa.

Si el hecho mete a más participantes o arrastra detalles propios (tiempo, lugar, instrumento), entonces sí: dale nombre propio de evento y cuélgale sus tripletas.

Ni más de la necesaria, ni menos de la que el detalle exige.

El modelo y el lenguaje humano son gemelos

Aquí ocurre algo que la primera vez parece magia.

Toma un artículo de prensa cualquiera y pásaselo a un modelo de lenguaje moderno con esta instrucción: «resume paso a paso quién hizo qué en esta noticia».

La respuesta casi siempre vuelve como una lista de líneas limpias, sin que nadie haya pedido ese formato:

Cuatro líneas, cuatro hechos. Cada una con su sujeto, su verbo y su objeto.

La IA no responde así porque haya leído este libro. Responde así porque así funciona el lenguaje humano cuando describe la realidad.

Las frases simples que nos enseñaron en la escuela (sujeto, verbo, predicado) son idénticas a nuestros hechos atómicos.

El impacto de esa coincidencia es enorme.

Si tu base guarda la información como tripletas, y la IA piensa en tripletas, la comunicación entre las dos se vuelve casi automática.

No hace falta programar algoritmos caros de comprensión del lenguaje ni levantar capas de traducción frágiles. Hay un enchufe directo entre lo que la IA dice y lo que tu sistema guarda.

Esa es la llave del agente que el mercado persigue: uno capaz de conversar, auditar y registrar en cualquier empresa, sin memorizar la estructura de la base de cada cliente.

Es lo que el capítulo 26 lleva hasta el fondo.

Consultar es tapar un hueco

Si toda la información se guarda como tripletas, buscar en ella es un juego de niños.

Hacer una consulta es escribir una tripleta tapando uno de sus tres campos, y dejar que el sistema rellene el hueco.

Mira tres formas de buscar sobre nuestros ejemplos:

(serra,          ?,           ?)         // "Dime todo lo que sepas de Serra"
(?,              directora,   serra)      // "¿Qué obras dirigió Serra?"
(?,              agente,      messi)      // "Busca todas las jugadas de Messi"

Y si necesitas una consulta digna de un analista, no hay que aprender un lenguaje nuevo: basta encadenar varias «tripletas con huecos» y pedirle al sistema los datos que encajen en todas a la vez. Las variables que se repiten (las que empiezan con ?) son las junturas: amarran un patrón con el siguiente.

(?gol,     agente,   messi)
(?gol,     parte_de, ?partido)
(?partido, fecha,    [2026-01-01, 2026-12-31])
// → "Todos los goles de Messi en partidos del año 2026"

Así de simple. No hacen falta diagramas enrevesados ni consultas eternas: consultar es decirle a la máquina que busque un patrón de cables dentro de la red. Y la operación matemática es idéntica en cualquier industria y a cualquier escala: exactamente lo que la vieja torre de Babel de los datos, que vimos en el capítulo 1, nos impedía hacer.

Un cable repetido es una columna

Apilar tripletas tiene un efecto lateral que conviene ver desde ya.

Cuando mil ventas distintas llevan el mismo cable monto_usd, ese cable deja de ser un dato suelto de venta_001 y se convierte en una columna que se puede recorrer entera.

Con agente pasa igual. Escribirlo sobre cada gol es, sin querer, dejar armada la lista de todas las jugadas que lo comparten.

Por eso el patrón (?, agente, messi) de hace un momento no era un truco. Era la forma natural de leer esa columna de punta a punta.

Cada hecho que registras sobre un sujeto es también una fila en el informe de todos los que comparten ese cable. Lo que parece guardar un dato suelto está sembrando, sin avisar, la consulta colectiva.

El contraste con SQL

Para medir la diferencia, traduzcamos esa última pregunta (los goles de Messi en 2026) al mundo de las tablas de siempre.

Allí los hechos no viven en una pizarra común. Viven repartidos en tablas que muchas veces ni se diseñaron para hablar entre sí.

Recuperar el dato obliga a coserlas, una operación que el grafo no necesita porque nunca separó la información.

SELECT j.nombre, g.minuto
FROM goles g
JOIN jugadores j ON j.id = g.jugador_id
JOIN partidos  p ON p.id = g.partido_id
WHERE j.nombre = 'Messi'
  AND p.fecha BETWEEN '2026-01-01' AND '2026-12-31';

No es que el SQL esté mal escrito. Es que carga con un trabajo que el modelo de tripletas ni siquiera tiene.

Cada JOIN es la cicatriz de haber partido el mundo en tablas. Y si mañana el negocio quiere registrar quién asistió cada gol, hay que alterar el esquema.

En la pizarra de tripletas, eso era una línea más.

El mismo átomo, viajando por el cable

Cuando un hecho necesita salir del sistema y viajar a otro (una API, un agente, otra empresa), se serializa sin perder un solo eje. La reificación se vuelve un objeto JSON casi sin esfuerzo: el sujeto es el id, cada cable es una clave y cada objeto es el valor. Así se ve una venta sobre el cable:

{
  "id": "venta_74921",
  "instancia_de": "venta",
  "agente": "vendedor_17",
  "cliente": "cliente_1042",
  "objeto": "camiseta_88",
  "monto": { "valor": 49.90, "unidad": "Currency:USD" },
  "momento": "2026-05-14T16:32:00-05:00"
}

Cada clave es un cable; cada valor, un individuo en su eje. El mismo átomo que dibujamos como una estrella de nodos en la Figura 7.1 es, sobre el cable, un objeto que cualquier sistema (o cualquier IA) lee sin manual de instrucciones. La figura siguiente cierra el círculo: una sola afirmación, vista de tres maneras que son la misma.

El repertorio entero, pasado por el átomo

Para cerrar con los pies en la tierra, recorramos los cinco escenarios de este capítulo y veámoslos descompuestos en hechos atómicos. La lección, repetida cinco veces, es siempre la misma: basta apilar tripletas sobre un sujeto, y reificar solo cuando un evento lo pide.

👕 La venta. Ya la desmenuzamos: diez tripletas bastan para el retrato general de la operación, y si la tienda exige trazar el lote de inventario, se reifica la entrega del artículo sumando cinco tripletas más (sin tocar el diseño base).

⚽ El gol. El fútbol se describe apilando roles tácticos sobre el evento. Seis hechos atómicos conservan al autor, al asistente, el partido, el minuto y la pierna. Suficiente detalle para una casa de apuestas o un analista de rendimiento, sin reducir la jugada a una fila gris de hoja de cálculo:

(gol_001, instancia_de, gol_jugada_abierta)    ∈ M(O, K)
(gol_001, agente,       messi)                 ∈ M(O, Q)
(gol_001, asistente,    di_maria)              ∈ M(O, Q)
(gol_001, parte_de,     partido_arg_per_2026)  ∈ M(O, O)
(gol_001, minuto,       87)                    ∈ M(O, N)
(gol_001, pierna,       zurda)                 ∈ M(O, K)

🎬 La película. Una obra cinematográfica se describe apilando autoría (que tiene roles distintos: dirigir no es escribir) y composición recursiva, porque una escena es «parte de» la película:

(pelicula_marea, instancia_de, largometraje)         ∈ M(O, K)
(pelicula_marea, genero,       genero_drama)         ∈ M(O, K)
(pelicula_marea, directora,    serra)                ∈ M(O, Q)
(pelicula_marea, guionista,    haddad)               ∈ M(O, Q)
(pelicula_marea, año_estreno,  2026)                 ∈ M(O, N)
(escena_42,      parte_de,     pelicula_marea)       ∈ M(O, O)
(escena_42,      tiempo_narrativo, fin_segundo_acto) ∈ M(O, K)

Siete hechos en los que directora y guionista son cables distintos (Serra y Haddad cumplen papeles que no se confunden) y donde escena_42 se cuelga de la película por parte_de, abriendo la puerta a describir cada escena con su propia lluvia de tripletas. La composición no tiene fondo.

🏛️ La ordenanza. Un acto de gobierno combina fechas, vigencias y entidades afectadas. Nótese que afecta_a es un cable múltiple: el mismo sujeto lo usa varias veces, una por cada gerencia tocada.

(ordenanza_142, instancia_de,     ordenanza_municipal)   ∈ M(O, K)
(ordenanza_142, promulgada_por,   alcalde_reyes)         ∈ M(O, Q)
(ordenanza_142, organo,           municipalidad_centro)  ∈ M(O, Q)
(ordenanza_142, fecha_publicacion, 2026-05-14)           ∈ M(O, T)
(ordenanza_142, entra_en_vigor,   2026-06-13)            ∈ M(O, T)
(ordenanza_142, afecta_a,         gerencia_transito)     ∈ M(O, Q)
(ordenanza_142, afecta_a,         gerencia_fiscalizacion) ∈ M(O, Q)

La fecha de entrada en vigor (30 días después de la publicación) no se inventa a mano: es un tiempo derivado por reglas, un tema que el capítulo siguiente y los de la Parte V exploran. Si alguien pregunta «¿qué normas promulgó el alcalde Reyes este año?», la máquina cruza las primeras dos tripletas y responde sin demora.

🤖 El agente de IA. Y el dominio más moderno de todos: la telemetría de una sesión con un modelo de lenguaje. Diez hechos atómicos que registran qué usuaria preguntó, qué modelo respondió, cuántos tokens costó y qué herramientas tuvo que invocar el agente.

(sesion_ia_5521, instancia_de,   sesion_modelo_lenguaje)  ∈ M(O, K)
(sesion_ia_5521, modelo,         modelo_lumen_2026)       ∈ M(O, K)
(sesion_ia_5521, usuaria,        paredes)                 ∈ M(O, Q)
(sesion_ia_5521, tokens_entrada, 4180)                    ∈ M(O, N)
(sesion_ia_5521, tokens_salida,  920)                     ∈ M(O, N)
(sesion_ia_5521, latencia_ms,    2100)                    ∈ M(O, N)
(sesion_ia_5521, costo_usd,      0.015)                   ∈ M(O, N)
(sesion_ia_5521, temperatura,    0.7)                     ∈ M(O, N)
(sesion_ia_5521, herramienta,    busqueda_web)            ∈ M(O, K)
(sesion_ia_5521, herramienta,    consulta_grafo)          ∈ M(O, K)

Toda la telemetría que un ingeniero moderno exige (quién, qué modelo, cuánto costó, si tuvo que buscar en la web o consultar el propio grafo) vive en diez líneas tipadas. Es incomparablemente más limpio, y más consultable, que un volcado de logs sin estructura.

Lo que llevamos, y lo que viene

El hecho atómico es la piedra sobre la que se levanta todo.

Tiene siempre la misma forma de tres partes. Lleva dentro la protección que impide mezclar cosas absurdas. Y se apila consigo mismo para describir realidades tan complejas como haga falta, sin pedir nunca un cambio de programación.

En este modelo, la base de datos es un océano de estos hechos. Sin metáfora.

Lo bonito del hallazgo no es haber inventado un código nuevo. Es haber descubierto que esta forma coincide al milímetro con cómo hablan las personas (y la IA) cuando describen el mundo.

El modelo no obliga a nadie a aprender un idioma robótico. Toma la estructura del lenguaje y la convierte en algo que se puede consultar.

Hasta aquí hemos tratado cada hecho como una pieza solitaria. Pero cuando se amontonan por millones, emerge algo nuevo: un espacio geométrico. No una metáfora, sino una herramienta matemática real, donde consultar masivamente equivale a poner restricciones sobre coordenadas (como jugar a la batalla naval a escala planetaria). Ese espacio es el tema del próximo capítulo.