El modelo de datos de Vectry: cinco primitivas, un grafo causal
Un recorrido por Event, Trace, CausalThread, EventExplanation y Anomaly — las cinco primitivas a las que se reduce todo en Vectry.
Toda la superficie de Vectry — SDKs, API de ingesta, explicaciones, detección de anomalías — se reduce a cinco primitivas organizadas en cuatro capas: observación → ejecución → semántica → diagnóstico. Este post recorre cada una.
Event (observación)
La unidad atómica. Un Event representa una acción, cambio o señal capturada dentro de un sistema, y siempre responde cuatro preguntas por esquema, no por convención:
- Quién —
actor_id+actor_type(user,system,aiodevice) - Qué — un objeto
operationembebido - Dónde —
organization_idyapp_id(multi-tenant por diseño) - Cuándo — timestamps de auditoría completos
La operation es el corazón de la gramática. Nombra el verbo (created, updated, deleted, restored, patched, merged, duplicated, signaled, triggered, evaluated), el system_domain, la system_entity y la instancia exacta afectada. Cuando la operación muta estado, lleva un diff estructurado — original vs updated, campo por campo.
Un namespace legible como inventory.item.updated le da a cada evento una identidad amigable para filtros y streams.
Trace (ejecución)
Un Trace agrupa los eventos que pertenecen a una unidad coherente de comportamiento alrededor de una entidad — una reserva moviéndose por booking, una cotización en negociación. Registra las coordenadas de la entidad (system_domain, system_entity, system_entity_id), inicio y fin, y el actor principal. Los traces responden: ¿qué le pasó a esta entidad durante este proceso?
CausalThread (ejecución)
Los hilos son la capa entre sistemas: un CausalThread enlaza muchos traces en la historia amplia de una entidad, y cierra con un desenlace — approved, error, abandoned. Cuando un incidente cruza cuatro servicios, el hilo es lo que te permite recorrerlo como una sola narrativa.
EventExplanation (semántica)
El porqué. Dado un evento, una EventExplanation almacena la cadena reconstruida de causas — un arreglo caused_by de eventos causantes con sus timestamps y snapshots de payload — más una narrativa generada y legible por humanos:
“La cotización fue rechazada porque el ítem había sido marcado como vencido por el sistema.”
Es una capa de auditoría potenciada por inteligencia, generada cuando se necesita profundidad causal, y persistida como registro de primera clase.
Anomaly (diagnóstico)
Las desviaciones se registran en el nivel donde ocurren — event, trace o causal_thread — con el patrón esperado, el patrón real y un deviation_score. Cada anomalía puede referenciar la EventExplanation que razona sobre ella: un pico nunca es solo un número, enlaza a la historia detrás.
Por qué esta forma
De este modelo se desprenden dos propiedades. La atribución es total: cada registro lleva actor, tenant y metadata de auditoría. La causalidad es de primera clase: los hilos y las explicaciones se escriben en el grafo, no se reconstruyen desde timestamps al consultar. Esa es la diferencia entre observabilidad y explicación.