Situaciones, contextos y agencia

Considera dos frases que parecen decir lo mismo y no lo dicen. La primera: «alguien corre». La segunda: «el correr de alguien, ayer, en el parque». La diferencia es minúscula en el idioma y enorme en la arquitectura. En la primera, correr es un verbo fugaz: pasa y se esfuma, no deja a qué agarrarse. En la segunda, el correr se ha vuelto un sustantivo (una cosa) y, de golpe, admite un dueño, un lugar, un ayer; y mañana admitirá un más todavía: que duró cuarenta minutos, que fue su récord, que lo interrumpió la lluvia.

Toda lengua humana sabe hacer ese truco. Vender se vuelve la venta; operar, la operación; decidir, la decisión. Al convertir un verbo en sustantivo no añadimos un adorno literario: le otorgamos identidad. Lo que era un acto pasajero pasa a ser una entidad de la que podemos hablar, que podemos contar, fechar, cancelar y corregir. Este capítulo trata de cuándo conviene hacer ese truco dentro del modelo, y de las tres decisiones de diseño que lo gobiernan.

El nombre técnico de ese truco es reificación, y la entidad que produce es una situación reificada. Estas situaciones viven siempre en el eje O qué. Son los nudos de la red: los conectores maestros donde decenas de hechos atómicos convergen porque todos hablan de lo mismo. Sin ellos, el modelo solo sabría registrar oraciones simples. Con ellos, puede guardar cualquier escena humana, por intrincada que sea, sin abandonar jamás la forma de la tripleta que fijamos en el capítulo 7.

No todo merece ser un sustantivo

La tentación, una vez que descubres la reificación, es aplicarla a todo. ¿Si un cliente es alto, debo crear «la situación de su altura»? La respuesta es un no rotundo. Reificar cuesta: cada situación es un objeto nuevo en la base de datos, con su identificador único, que el sistema tendrá que buscar y mantener. Reificar por costumbre es inflar la base con abstracción vacía y volverla lenta.

La estatura de una persona se queda perfectamente como un hecho atómico plano, (cliente_1042, estatura_cm, 178): no tiene partes, no participa nadie más, nadie volverá a hablar de ese número, no caduca. Reificarla sería como guardar un termómetro dentro de una caja fuerte. La pregunta correcta, entonces, no es «¿puedo reificar esto?», sino «¿hay alguna razón de peso para hacerlo?». El modelo reconoce exactamente cuatro razones, y basta con que se cumpla una.

Si un dato no cumple ninguna de las cuatro, déjalo como tripleta plana y el sistema seguirá rápido. Esta frontera es lo bastante importante como para escribirla en piedra: es la cuarta decisión de diseño del modelo.

Léela como una compuerta de eficiencia, no como un permiso. Reificar es poderoso justamente porque es selectivo: el modelo reserva sus nudos para los eventos que de verdad articulan información, y deja el resto como átomos baratos. La economía es deliberada.

Autopsia de una situación

¿Cómo se ve uno de estos nudos por dentro? Abramos uno. Tomemos un evento cotidiano pero con suficiente sustancia: la venta número 1, en la que el vendedor 17 le vendió una camiseta al cliente 1042 a las 16:32 de una tarde de mayo. Cumple D4 de sobra (reúne varios participantes, carga media docena de datos propios y volverá a aparecer cuando el cliente reclame o devuelva). Lo primero es «hacer cosa» el evento, creándolo en el eje O:

(venta_001) ∈ O          // el nudo: a partir de aquí, todo cuelga de él

Ese identificador, venta_001, se vuelve el punto articulador. Todos los detalles de la operación se enganchan a él con hechos atómicos de tres partes, cada uno aportando una coordenada de un eje distinto:

(venta_001, instancia_de,    venta)                     ∈ M(O, K)
(venta_001, agente,          vendedor_17)               ∈ M(O, Q)
(venta_001, cliente,         cliente_1042)              ∈ M(O, Q)
(venta_001, objeto,          camiseta_88)               ∈ M(O, O)
(venta_001, momento,         2026-05-14T16:32:00-05:00) ∈ M(O, T)
(venta_001, lugar_de,        tienda_centro)             ∈ M(O, L)
(venta_001, monto,           49.90)                     ∈ M(O, N)
(venta_001, impuesto_pct,    18)                        ∈ M(O, N)
(venta_001, estatus_factual, real)                      ∈ M(O, K)

Nueve hechos atómicos dibujan la venta completa: qué clase de operación es, quién la hizo, a quién, qué objeto, cuándo, dónde, por cuánto y en qué estado. Y aquí llega la recompensa de haberla reificado. Como venta_001 ahora tiene identidad propia, otros eventos posteriores pueden apuntar directamente a ella:

(valoracion_001, sobre_situacion, venta_001)   // el cliente la puntúa
(pago_tarjeta_9, parte_de,        venta_001)   // cómo se pagó
(devolucion_088, rectifica,       venta_001)   // "talla equivocada", se cambió

La valoración, el pago y la devolución son, cada una, nuevas situaciones reificadas que se conectan al nudo original. La red crece de forma orgánica, sin cambiar jamás su formato de tres columnas. Esto es lo que la siguiente figura hace visible: un evento en el centro y sus participantes irradiando hacia los ejes, cada cable con su color.

Quién puede ser agente

Detengámonos en uno de esos cables, porque oficializa algo que los ejemplos ya venían gritando. En la venta, el rol agente lo ocupó una persona de carne y hueso. Pero abre el abanico de dominios y el protagonista de una acción puede ser otra cosa: el algoritmo que asigna un conductor, el servidor bancario que cobra el mantenimiento, el modelo de lenguaje que redacta un borrador, el sensor que dispara una alarma. El modelo no exige que el agente sea humano.

Mira una sesión de un asistente de inteligencia artificial. El protagonista de la situación (quien ejecuta la respuesta, invoca las herramientas y consume los tokens) no es la usuaria que escribe, sino el modelo mismo:

(sesion_ia_5521, instancia_de,    sesion_modelo_lenguaje)  ∈ M(O, K)
(sesion_ia_5521, agente,          modelo_lumen_2026)       ∈ M(O, Q)   ← un software es el agente
(sesion_ia_5521, usuaria,         paredes)                 ∈ M(O, Q)
(sesion_ia_5521, herramienta,     consulta_grafo)          ∈ M(O, K)
(sesion_ia_5521, tokens_salida,   920)                     ∈ M(O, N)
(sesion_ia_5521, latencia_ms,     2100)                    ∈ M(O, N)

El mismo molde sirve para un sensor. «El termopar registró 480 °C» pone a un dispositivo físico en el rol de agente de la situación medir, sin que ningún humano haya tocado nada. Esta universalidad del rol es la que nos deja auditar plantas industriales, plataformas de IA y sistemas automáticos con exactamente el mismo lenguaje que usamos para registrar ventas entre personas. Lo formalizamos así:

El rol, no la voluntad

Conviene fijar el límite, porque la pregunta es legítima: si un horno inteligente o un algoritmo de recomendación pueden «vestirse» de agente, ¿cuándo deja un objeto de ser una herramienta y pasa a ser un actor? La tentación es buscar la frontera en la voluntad o la conciencia, y por ahí no hay salida limpia: ni un algoritmo ni una empresa «quieren» nada en sentido fuerte.

El modelo esquiva la trampa filosófica. El criterio no es la voluntad: es el rol que la entidad ocupa en una situación concreta. Una misma cosa puede ser las dos cosas en momentos distintos. La cámara con la que se filma una película es un instrumento (un objeto en O) de la situación filmar; el agente es la directora. Pero «el dron sobrevoló el set y capturó el plano aéreo» pone al dron en el rol de agente de la situación capturar, donde no hay otro candidato a protagonista. El mismo aparato es herramienta o actor según qué verbo lo invoque y qué rol llene, no según una propiedad que lleve puesta.

La regla operativa, entonces, es simple: una entidad entra a Q como agente cuando ocupa el rol agente de un verbo que lo exige (vender, asignar, redactar, capturar); se queda como instrumento en O cuando es solo el medio a través del cual otro actúa. La agencia la determina la gramática de la situación, no la metafísica del objeto. Por eso el modelo puede auditar a un algoritmo que niega un crédito con el mismo rigor con que audita a un gerente que lo niega, sin tener que resolver primero si el algoritmo «tiene voluntad».

La agencia no es una propiedad que un objeto lleva puesta; es un papel que el verbo reparte. El robot que sutura es agente; el bisturí, jamás. La regla del rol

Eventos que todavía no han pasado

Una situación no tiene por qué ser un hecho consumado. Los negocios necesitan guardar reuniones planeadas, rodajes que se cancelaron, diagnósticos que son hipótesis, compras que se devolvieron. Antes que inventar etiquetas duplicadas para cada caso (un cable agente_real y otro agente_planeado), la solución más limpia es obligar a toda situación a declarar abiertamente su estatus factual:

estatus_factual : de O hacia K
  Opciones permitidas: real | planeado | confirmado | hipotético | cancelado | rectificado

Una escena de cine programada para rodarse la semana próxima se guarda igual que una ya filmada, solo que con estatus_factual: planeado. Cuando se rueda, el sistema no borra el plan: crea una situación nueva con estatus real y la conecta a la antigua diciendo que la cumple. Si se cancela, se crea una situación de cancelación. El plan original nunca se reescribe.

(escena_42) ∈ O
  instancia_de    : escena
  parte_de        : pelicula_marea
  directora       : serra
  momento         : 2026-06-04T07:00:00-05:00
  estatus_factual : planeado                    ← aún no se ha rodado

Este pequeño recurso asegura la inmutabilidad de la base: el pasado jamás se sobreescribe. Y a la vez deja mapear toda la red de expectativas, promesas y fracasos que compone el día a día de cualquier operación real. Aquí conviene fijar una convención que atraviesa todo el modelo.

Datos que caducan: la vigencia

Llegamos a uno de los recursos de diseño más finos del modelo. Hay propiedades que sencillamente no duran para siempre. El precio de una camiseta cambia con cada temporada y cada rebaja. La dirección de un cliente cambia cuando se muda. El modelo de IA que corre en producción se reemplaza por una versión nueva cada pocas semanas. Una base de datos ingenua, al recibir un valor nuevo, pisa el viejo y destruye el historial para siempre.

El modelo evita ese desastre usando la reificación para domesticar el tiempo. En lugar de la barbaridad de reescribir un dato vivo (

(sesion_ia, modelo_en_uso, modelo_lumen_2025)   ✗  // ¿y si se actualiza? ¿borrar y pisar?

) convertimos la propiedad cambiante en una sucesión de situaciones, cada una con su rango de vigencia. Esta es la sexta decisión de diseño.

Así, la pregunta «¿qué versión del modelo estaba en producción?» deja de tener una sola respuesta y pasa a tener una respuesta por fecha:

(despliegue_001) ∈ O
  sujeto : servicio_inferencia
  modelo : modelo_lumen_2025
  inicio : 2025-09-01
  fin    : 2026-03-14

(despliegue_002) ∈ O
  sujeto : servicio_inferencia
  modelo : modelo_lumen_2026
  inicio : 2026-03-15
  fin    : null          ← vacío: el sistema sabe que esta es la versión actual

Cuando le preguntas al sistema «¿qué modelo corría en producción?», la máquina te pide una fecha de referencia. Si preguntas por el 20 de febrero de 2026, recorre los rangos y devuelve modelo_lumen_2025; si preguntas por hoy, devuelve modelo_lumen_2026. La siguiente figura muestra esa sucesión como una banda temporal: cada vigencia es un tramo, y una consulta fechada es una línea vertical que cae sobre el tramo correcto.

Esta técnica (la bitemporalidad) vuelve triviales consultas que antes enloquecían a los analistas: «¿qué versión exacta del modelo corría el día que se reportó el fallo el año pasado?». Sin D6, responder eso es casi imposible; con D6, es leer un rango.

Cómo se conectan las situaciones entre sí

Para que la base no degenere en una selva de eventos sueltos, el modelo define un puñado de cables oficiales (relaciones canónicas) que organizan cómo se relacionan las situaciones entre ellas. Son pocos, pero cubren todos los escenarios. Conviene verlos en dos columnas, porque caen en familias claras.

Mira cómo se aplican a un partido de fútbol, el ejemplo arquetípico de una situación que contiene otras. El partido es el nudo grande; cada jugada es un nudo pequeño que cuelga de él por parte_de, y entre jugadas hay secuencia y reacción:

(partido_arg_per_2026) ∈ O
  instancia_de : partido
  estatus_factual : real

(gol_001, parte_de,     partido_arg_per_2026)   // la jugada cuelga del partido
(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, minuto,       87)                  ∈ M(O, N)

(pase_001, precede, gol_001)    // ocurrió justo antes
(pase_001, agente,      messi)       ∈ M(O, Q)
(pase_001, beneficiario, di_maria)   ∈ M(O, Q)

El partido, el pase y el gol son situaciones distintas, todas en O, todas tejidas con cables canónicos. Borra cualquiera y las demás siguen teniendo sentido; añade una jugada nueva y nada se rompe. La estructura n-aria (agente, asistente, minuto y pierna en un solo gol) se conserva entera porque cada situación absorbe la complejidad sin deformar la tripleta.

El zoom de la reificación

Cierro con una aclaración vital para quien implemente. Reificar no es un interruptor de encendido y apagado: es un zoom. Un mismo evento admite varios niveles de detalle, y los tres son perfectamente legales. Tómalo con la venta de antes, pero ahora pensando en las ventas de la tienda a lo largo de un día.

(tienda_centro, ventas_dia_usd, 3420)

(cierre_dia_14) ∈ O
  lugar  : tienda_centro
  total  : 3420 USD
  turno  : tarde_t2

(venta_001) ∈ O
  parte_de : cierre_dia_14
  monto    : 49.90

¿Cuál es el correcto? Los tres. Depende del presupuesto y del objetivo. Y lo más hermoso de esta arquitectura es que saltar del nivel 1 al nivel 3 no rompe la base: si mañana necesitas más detalle, inyectas situaciones nuevas y las cuelgas de las viejas con parte_de. El sistema nunca se detiene, porque nunca cambia su forma. El nivel de zoom es una decisión de negocio, no una atadura del modelo.

Darle identidad a una es nombrar a todas

Reificar tiene una recompensa que se cobra más tarde. Al «hacer cosa» a venta_001 parece que solo le damos identidad a un evento suelto para colgarle atributos: su monto, su cliente, su momento. Pero al darle un tipo —al decir que es una instancia de venta— la inscribimos, sin proponérnoslo, en un conjunto: el de todas las ventas. Esa es la otra cara del nudo. Un evento con identidad propia no solo recibe detalles; queda contado junto a sus pares, y «¿cuántas ventas hubo?» pasa a tener respuesta sin armar nada nuevo.

# Cuántas ventas se reificaron — un tipo de situación, contado entero
count(u, Pattern(type_constraint=u.ind("venta")))

Las situaciones reificadas son las rotondas por donde circula el tráfico de la base: los puntos donde convergen los hechos y desde donde se ramifican los procesos. Pero para que el mapa esté completo falta pavimentar un tipo de conexión muy especial entre esas rotondas. Saber que ocurrió una venta o un fallo es útil; saber qué lo causó, qué finalidad perseguía o qué norma lo justificó es lo que eleva una base de datos a inteligencia de negocio. Esos cables del «por qué» son tan singulares que el próximo capítulo defiende una tesis incómoda: que el porqué no es un eje.