No hay fuente única de verdad sin estado, procedencia y reglas de conflicto

Una base central no se convierte en verdad por concentración: solo una capa que conserva hechos, procedencia, tiempo efectivo y reglas de conflicto puede explicar qué estado se cree y por qué. Si dos fuentes discrepan y el último valor recibido gana sin considerar quién lo afirmó ni cuándo ocurrió, la organización tiene una caché conveniente, no una fuente de verdad.

Separe hecho, proyección e inferencia

Un hecho es una afirmación recibida: una orden fue aprobada, un pago fue liquidado, un contenedor salió. Una proyección calcula el estado actual a partir de hechos y reglas: “orden lista para despacho”. Una inferencia estima algo no declarado: “riesgo de retraso alto”.

Mezclar las tres categorías hace imposible auditar. Una inferencia puede reemplazar silenciosamente un dato de fuente; una corrección puede parecer un evento nuevo; una proyección puede almacenarse como si siempre hubiera sido cierta. El contrato debe etiquetar origen y función.

Identidad antes que estado

Defina un identificador estable para el objeto y relaciones explícitas con identificadores externos. No use correo, nombre de proveedor o número de documento sin ámbito como clave universal. Mantenga:

• object_id interno inmutable;
• object_type y esquema versionado;
• source_aliases con sistema, ámbito y vigencia;
• parent/child y relaciones de negocio;
• estado proyectado y versión;
• referencias a los eventos que lo sostienen.

Un alias puede cambiar o reutilizarse. El objeto conserva continuidad mientras la relación explica cuándo y desde qué sistema era válida.

Contrato mínimo de la capa de verdad

Campo	Regla
object_id/type	identidad estable y tipo versionado
event_id/source	combinación única para deduplicar
assertion_type	hecho declarado, corrección, inferencia o decisión
effective_at	cuándo la afirmación fue cierta en el negocio
observed_at	cuándo la organización la recibió
payload_schema	contrato usado para interpretar datos
provenance_ref	fuente, actividad, agente y evidencia permitida
supersedes	afirmación corregida, nunca borrada
expected_version	versión que el escritor cree actualizar
conflict_status	ninguno, pendiente, resuelto o aceptado
policy_version	regla que proyectó o resolvió estado
projection_version	estado derivado reproducible

La especificación CloudEvents requiere atributos de contexto como id, source, specversion y type y recomienda no poner información sensible en esos atributos. Puede servir como sobre de transporte; el contrato de negocio añade objeto, tiempo efectivo, procedencia y política.

Procedencia: entidad, actividad y responsable

La recomendación W3C PROV-O modela Entity, Activity y Agent y relaciones como used, wasGeneratedBy, wasDerivedFrom y wasAssociatedWith. No necesita adoptar toda la ontología para obtener valor. Use la tríada:

• Entidad: documento, evento, versión de objeto o artefacto.
• Actividad: extracción, comparación, aprobación o transformación.
• Agente: persona, organización o software responsable de la actividad.

Ejemplo: la proyección “factura aprobada” fue generada por una actividad de aprobación que usó factura y orden, se asoció con un aprobador y siguió una política. Esa cadena es más útil que guardar únicamente un campo approved=true.

Dos tiempos para evitar una historia falsa

Guarde effective_at y observed_at. Un proveedor puede informar hoy que un evento ocurrió ayer. Ordenar por recepción haría que la historia operacional sea incorrecta; ordenar solo por ocurrencia ocultaría que el equipo decidió con información tardía.

La proyección actual usa la política vigente y los hechos conocidos en un punto. Para auditoría, debe poder responder tanto “¿qué creemos que ocurrió?” como “¿qué sabíamos cuando decidimos?”. No requiere una implementación académica compleja; requiere no sobrescribir esos tiempos.

Reglas de conflicto que no dependan de llegada

Defina por campo o transición:

1. Autoridad: qué fuente puede afirmar el dato.
2. Precedencia: cuándo una fuente puede corregir a otra.
3. Vigencia: desde y hasta cuándo aplica la afirmación.
4. Compatibilidad: qué estados pueden coexistir.
5. Resolución: regla automática o dueño humano.
6. Evidencia: qué debe conservarse para aceptar el cambio.

No use “última escritura gana” para campos con consecuencias. En APIs de actualización, el mecanismo If-Match de RFC 9110 permite condicionar una escritura a que la etiqueta de entidad coincida, evitando sobrescribir cambios concurrentes. ETag no resuelve el conflicto de negocio, pero detecta que el escritor operaba sobre una versión antigua.

Ejemplo ilustrativo de conflicto

Este caso es ilustrativo. El ERP afirma que una orden está cancelada con effective_at del lunes. Un sistema de almacén informa el martes que fue preparada, pero el mensaje llega el miércoles. La truth layer no selecciona “preparada” solo por llegar última.

La política declara al ERP autoridad para cancelación y al almacén autoridad para preparación física. Ambos hechos permanecen. La proyección marca conflicto: objeto cancelado con actividad física posterior. Se abre una excepción para decidir devolución, liberación o corrección. La resolución genera otro evento, asociado a persona y política, sin borrar los anteriores.

Si un agente resume el caso, debe citar los eventos y reconocer el conflicto. No puede inventar una secuencia limpia.

Lecturas y escrituras como contratos diferentes

Una lectura ejecutiva puede devolver una proyección compacta: estado, edad, dueño y próxima acción. Una lectura de auditoría devuelve eventos, procedencia y versión. Una escritura exige expected_version, razón, actor y evidencia. Separar vistas evita enviar todo el historial a cada consumidor sin perder reconstrucción.

Materialice proyecciones para velocidad, pero trátelas como derivadas. Si cambia una regla, genere una nueva projection_version y reprocesa desde hechos compatibles. Conserve qué versión vio una decisión ya ejecutada.

Cómo representarlo en Quantum

En Quantum Automation Center, el objeto de negocio puede enlazar ejecuciones, estados, línea de tiempo, artefactos y logs. Agentes y automatizaciones aparecen como actividades; permisos y aprobaciones identifican autoridad; analíticas consumen proyecciones sin borrar la evidencia. La ontología de Quantum ofrece el punto de conexión entre objetos y procesos.

Evite cargar todo el payload sensible. Mantenga referencias protegidas y datos mínimos para correlación y decisión.

El contrapunto: esta disciplina encarece consultas simples

Sí. Eventos, dos tiempos, procedencia y versiones requieren diseño y almacenamiento. Un tablero no debería reconstruir toda la historia en cada carga. La respuesta son proyecciones materializadas, índices y políticas de retención, no volver a sobrescribir.

Use profundidad proporcional. Un objeto financiero irreversible necesita más evidencia que una preferencia temporal de interfaz. El contrato común puede mantener campos mínimos y extensiones por dominio.

Cuándo no construir una truth layer

No la construya para datos temporales que ninguna decisión comparte. No replique un sistema de registro que ya ofrece identidad, historial, permisos y concurrencia suficientes; publíquelo como fuente autoritativa y enlace sus eventos.

Tampoco comience por una plataforma central sin acordar autoridad y conflictos. La tecnología solo hará más rápida una regla indefinida.

La prueba de verdad útil

Tome un estado controvertido y responda: qué hechos lo sostienen, quién los afirmó, cuándo ocurrieron, cuándo se conocieron, qué política proyectó el estado y cómo se resolvió el conflicto. Después reproduzca la proyección. Si una respuesta depende de “esa tabla siempre gana”, todavía falta el contrato de verdad.

Sources

• W3C PROV-O: The PROV Ontology — w3.org
• IETF RFC 9110: HTTP Semantics — ietf.org
• CloudEvents Specification — github.com