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 una cosa. Y de golpe admite un dueño, un lugar, un ayer. Y mañana admitirá más: 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.

Convertir un verbo en sustantivo no es un adorno literario. Le da identidad.

Lo que era un acto pasajero pasa a ser algo de lo que podemos hablar, y que podemos contar, fechar, cancelar y corregir.

Este capítulo trata de cuándo conviene hacer ese truco, y de las tres decisiones de diseño que lo gobiernan.

El nombre técnico del truco es reificación, y lo que produce es una situación.

Estas situaciones viven siempre en el eje O qué.

Son los nudos de la red: los puntos donde decenas de hechos convergen porque todos hablan de lo mismo.

Sin ellos, el modelo solo sabría registrar frases simples. Con ellos, guarda cualquier escena humana, por enredada que sea, sin abandonar la forma de la tripleta del capítulo 7.

No todo merece ser un sustantivo

La tentación, una vez que descubres esto, es aplicarlo a todo. Si un cliente es alto, ¿debo crear «la situación de su altura»?

No.

Reificar cuesta. Cada situación es un objeto nuevo, con su identificador, que el sistema tendrá que buscar y mantener. Reificar por costumbre infla la base y la vuelve lenta.

La estatura de una persona se queda como un hecho 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 guardar un termómetro dentro de una caja fuerte.

La pregunta correcta no es «¿puedo reificar esto?», sino «¿hay alguna razón de peso para hacerlo?».

El modelo reconoce 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 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 hacerla cosa, creándola 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, situaciones nuevas que se enganchan al nudo original.

La red crece sola, sin cambiar nunca su formato de tres columnas.

Eso es lo que hace visible la figura siguiente: un evento en el centro y sus participantes saliendo 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 y el protagonista de una acción puede ser otra cosa: el algoritmo que asigna un conductor, el servidor 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 aparato en el rol de agente de la situación medir, sin que ningún humano haya tocado nada.

Gracias a eso podemos auditar plantas industriales, plataformas de IA y sistemas automáticos con el mismo lenguaje con que registramos 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 pueden vestirse de agente, ¿cuándo deja un objeto de ser herramienta y pasa a ser actor?

La tentación es buscar la frontera en la voluntad, 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 cada situación.

Una misma cosa puede ser las dos en momentos distintos.

La cámara con la que se filma una película es un instrumento 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.

El mismo aparato es herramienta o actor según qué verbo lo invoque, no según una propiedad que lleve puesta.

La regla práctica es simple. Una entidad entra en Q como agente cuando ocupa el rol de agente de un verbo que lo exige: vender, asignar, redactar, capturar.

Y se queda como instrumento en O cuando es solo el medio a través del cual otro actúa.

Lo decide 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, sin tener que resolver antes 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 cancelados, diagnósticos que son hipótesis, compras devueltas.

Antes que inventar etiquetas duplicadas para cada caso, lo más limpio es obligar a toda situación a declarar su estatus factual:

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

Una escena de cine programada para 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 más finos del modelo.

Hay propiedades que no duran para siempre. El precio de una camiseta cambia con cada temporada. La dirección de un cliente cambia cuando se muda. El modelo de IA que corre en producción se reemplaza cada pocas semanas.

Una base 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.

Si preguntas por el 20 de febrero de 2026, recorre los tramos y devuelve modelo_lumen_2025. Si preguntas por hoy, devuelve modelo_lumen_2026.

La figura siguiente muestra esa sucesión como una banda: 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.

1 · Jerarquía (parte_de y su inverso contiene). Mete eventos pequeños dentro de eventos grandes. Un gol es parte_de un partido; una escena es parte_de una película. El todo y la parte coexisten como entidades de pleno derecho, sin que el todo aplaste a sus partes.

2 · Secuencia lógica (precede y su inverso sigue_a). Ordena el flujo de un proceso. No importa tanto la hora del reloj como qué paso va obligatoriamente antes que otro: la grabación del sonido precede a la mezcla, sin importar cuántos días medien.

3 · Acción y reacción (cumple, cancela, modifica, rectifica). Define cómo un evento nuevo impacta o anula a uno del pasado. El rodaje real cumple la escena planeada; una toma corregida rectifica la anterior. Aquí vive la inmutabilidad: se supera, no se borra.

4 · El grupo del «por qué» (causado_por, motivado_por, justificado_por). Los cables que explican los motivos (humanos o mecánicos) detrás de las situaciones. Son tan particulares que merecen su propio capítulo: el siguiente.

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 los mismos cables.

Borra cualquiera y las demás siguen teniendo sentido. Añade una jugada nueva y nada se rompe.

Agente, asistente, minuto y pierna caben en un solo gol 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 mejor es que saltar del nivel 1 al 3 no rompe nada. Si mañana necesitas más detalle, creas situaciones nuevas y las cuelgas de las viejas con parte_de.

El sistema nunca se detiene, porque nunca cambia de 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 para colgarle atributos: su monto, su cliente, su momento.

Pero al darle un tipo, al decir que es una venta, la inscribimos sin querer 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.

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

Las situaciones son las rotondas por donde circula el tráfico de la base: 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ó, para qué se hizo o qué norma lo justificó es lo que convierte una base de datos en inteligencia de negocio.

Esos cables del «por qué» son tan singulares que el próximo capítulo defiende una tesis incómoda: el porqué no es un eje.