Del evento al resultado económico: la cadena causal por objeto de negocio
Por Equipo Quantum Developers
Resumir:
Tesis operativa
Un trace ID demuestra que varias operaciones técnicas pertenecen a una ejecución. No demuestra que una decisión causó un resultado ni que ese resultado produjo valor económico. La afirmación defendible necesita cinco eslabones: evento → decisión → acción → resultado operativo → resultado económico. Deben unirse por objeto, conservar procedencia y declarar dónde termina la observación y empieza la atribución.
La ontología PROV-O de W3C ofrece conceptos para describir entidades, actividades, agentes y relaciones de derivación. No define el ROI de una automatización, pero proporciona una disciplina esencial: registrar qué fue generado por qué actividad, qué entidad se usó y quién estuvo asociado. Esa estructura evita que una cifra final quede separada de los hechos que la originaron.
El objeto como columna vertebral
El objeto de negocio es la identidad estable que atraviesa sistemas: factura, embarque, cotización, orden o caso. No es el archivo ni la llamada API. Puede tener versiones y relaciones con otros objetos, pero conserva una clave de negocio gobernada.
Cada registro de la cadena incluye:
- business_object_type y business_object_id;
- object_version y estado conocido;
- correlation_id para la ejecución;
- occurred_at de la fuente y recorded_at del observador;
- source_system, dueño y referencia de evidencia;
- schema_version para interpretar el evento después.
OpenTelemetry mantiene convenciones semánticas con nombres comunes para trazas, métricas y logs entre tecnologías. La empresa puede extender ese principio a objetos y decisiones. No debe reemplazar el estado nativo: guarde el valor original y la traducción normalizada.
Eslabón 1: evento
Un evento es un cambio o señal observada, no una conclusión. Campos mínimos:
| Campo | Propósito |
|---|---|
| event_id y event_type | identidad y vocabulario controlado |
| object_id y object_version | estado sobre el cual se observó |
| occurred_at y source_clock | tiempo y autoridad temporal |
| source_system y source_ref | procedencia verificable |
| payload_hash o artifact_ref | evidencia sin duplicar datos sensibles |
| freshness_status | si la señal era vigente al decidir |
| ingestion_status | completo, tardío, duplicado o corregido |
“Retraso probable” no debería entrar como evento si ya contiene inferencia. El evento podría ser “ETA cambió” y la decisión posterior determina si requiere intervención.
Eslabón 2: decisión
La decisión transforma eventos y política en una recomendación o elección:
- decision_id y eventos utilizados;
- estado y versión del objeto;
- decision_type, alternativas y opción elegida;
- versión de política, regla, modelo o prompt;
- límites conocidos y evidencia omitida;
- banda de confianza, sin tratarla como probabilidad de corrección;
- agente proponente, revisor y aprobación;
- razón de excepción y población elegible.
Una modificación de entrada material crea otra decisión. No sobrescriba la primera: la secuencia permite explicar por qué cambió.
Eslabón 3: acción
La acción es el intento de cambiar el mundo. Registre:
- action_id, decision_id e intención;
- sistema destino y operación permitida;
- identidad ejecutora y permiso;
- aprobación y precondiciones;
- clave idempotente;
- hora de despacho y estado: solicitada, confirmada, fallida o incierta;
- referencia nativa y compensación disponible.
Decisión aceptada no equivale a acción completada. Acción enviada tampoco equivale a resultado confirmado. Esta separación evita atribuir valor a comandos que nunca llegaron o se duplicaron.
Eslabón 4: resultado operativo
El resultado ocurre después y pertenece al proceso: caso resuelto, factura contabilizada, margen confirmado, excepción cerrada o intervención realizada dentro de ventana. Campos:
- outcome_id y acciones relacionadas;
- definición y versión de la métrica;
- valor, unidad, denominador y segmento;
- periodo de observación;
- sistema que confirma;
- estado final y reapertura;
- cobertura: cuántas acciones tienen resultado observable;
- línea base o comparación aplicable.
El resultado puede contradecir la acción. Una cotización enviada rápido puede perder margen; una alerta correcta puede llegar después de la ventana. El enlace debe conservar ambos hechos.
Eslabón 5: resultado económico
La traducción económica necesita una regla separada:
- tipo: caja, costo evitado, capacidad usada o riesgo mitigado;
- resultado operativo de origen;
- valor unitario y fuente financiera;
- tasa de realización;
- costo incremental completo;
- periodo y entidad contable;
- rango de incertidumbre;
- dueño que valida;
- estado de atribución.
No sume capacidad liberada como ahorro si no se redujo costo ni se reasignó a un resultado medible. Tampoco convierta un riesgo hipotético en caja realizada.
Una etiqueta para la fuerza de la afirmación
Use cuatro niveles:
- Observado: los eventos y resultados existen, sin afirmar relación.
- Enlazado: la cadena comparte objeto y tiempos plausibles.
- Comparado: existe línea base o cohorte que muestra diferencia.
- Atribuido: el diseño de evaluación permite defender efecto incremental.
El Magenta Book explica que atribuir impacto requiere estimar qué habría ocurrido sin la intervención. Por eso, un pipeline perfecto de eventos mejora trazabilidad, pero no crea por sí solo causalidad. El nivel viaja con el KPI.
Ejemplo ilustrativo: una excepción de embarque
Un evento registra cambio de ETA desde una fuente vigente. El agente decide que el retraso amenaza una ventana y propone expedición alternativa. Una persona aprueba; la acción crea una solicitud en el TMS y obtiene referencia. El resultado operativo confirma entrega dentro de ventana. Finanzas valida el costo adicional y compara con la alternativa contratada para estimar valor.
La cadena permite varias conclusiones. Si no hay comparación, la entrega es observada y enlazada, no beneficio atribuido. Si la acción falló pero la entrega ocurrió igual, no se acredita al agente. El ejemplo no contiene benchmark ni afirma ahorro real.
Artefacto: sobre causal por objeto
El sobre reúne IDs de los cinco eslabones, versiones, fuente, cobertura y nivel de afirmación. Una consulta debería responder:
- ¿qué evento abrió el caso?;
- ¿qué información y política sustentaron la decisión?;
- ¿qué acción realmente confirmó el sistema?;
- ¿cuándo apareció el resultado y hubo reapertura?;
- ¿cómo se convirtió en valor y quién lo validó?;
- ¿qué porcentaje de la población tiene cadena completa?;
- ¿qué parte es observación y qué parte atribución?
En Quantum Automation Center, cronologías, estados, artefactos, logs y analítica operativa y financiera pueden reunir esa vista. Los sistemas de registro siguen confirmando estado y finanzas valida la traducción económica.
Calidad, privacidad y retención
No copie payloads completos por defecto. Use referencias, hashes, campos necesarios y acceso controlado. La evidencia debe retenerse según obligación y riesgo; la telemetría técnica puede tener otra ventana. Corrija eventos mediante nuevas versiones, no edición silenciosa.
Mida cadenas incompletas, saltos sin ID, eventos tardíos, resultados no observables y valores sin validador. La cobertura es parte del resultado: un ROI calculado sobre una minoría seleccionada no describe todo el universo.
El mejor contraargumento
La cadena completa exige integración, vocabulario común y disciplina. Para decisiones de bajo valor, instrumentar cinco eslabones puede costar más que automatizar. Además, la organización puede caer en obsesión por linaje y demorar aprendizaje.
La crítica es válida. Aplique proporcionalidad: objeto, decisión y acción siempre; resultado y economía cuando se hará una afirmación de impacto. Use muestreo en etapas tempranas. Lo que no debe hacerse es presentar ROI con eslabones faltantes sin declarar la limitación.
Cuándo no usar este enfoque
No implemente el esquema completo para tareas creativas sin resultado verificable, exploraciones aisladas o flujos sin identidad estable. Tampoco intente forzar causalidad cuando no existe comparación defendible.
Úselo cuando decisiones repetidas afectan sistemas de registro y la empresa quiere gobernar o monetizar el resultado. La cadena no garantiza ROI; garantiza que toda afirmación pueda retroceder hasta el objeto y mostrar exactamente qué evidencia la sostiene.
Sources
Temas del artículo
