Reproducir, no recalcular — la regla del momento, el mapa del error esparcido y el cierre del pilar

La mecánica está en su sitio. Falta la doctrina

Antes quedó la fábrica con una propiedad estructural firmada: no se borra nada y no se sobrescribe nada. Insert-Only + Audit-Only-Never-Delete (Dan Linstedt, vocabulario canónico de Data Vault 2.0). Y quedó también el patrón del versionado dentro de cada Satellite — HASH_DIFF + ventanas VALID_FROM/TO; en el ejemplo del lote, el número de versión etiqueta el orden de ese registro concreto — con el MZ-2026-PRO-014 en la mesa: dos filas, dos verdades convivientes, una ventana temporal precisa que cierra una y abre la otra.

Esa es la mecánica. Pero la mecánica no es la doctrina. Una fábrica con todas las propiedades del versionado en su sitio puede usarlas mal — y de hecho casi todas las cadenas que veo en producción las usan mal — el primer día que llega una auditoría seria. Hoy cierro las dos preguntas que aún teníamos abiertas desde el viernes de la sede costera:

• ¿Qué significa exactamente reprocesar el cálculo del 14 de marzo?. Spoiler: hay una respuesta correcta y una incorrecta. La diferencia entre las dos no es estética — es estructural. Y la respuesta correcta es la que cierra el pilar entero.
• ¿Cómo se reconstruye antes del lunes la lista exacta de pizzas servidas con el lote MZ-2026-PRO-014 en cinco sedes durante seis semanas — sin proyecto, sin volcado de logs, sin coordinación con plataforma?. Spoiler: una consulta sobre el modelo. La fábrica no construye la prueba; la fábrica es la prueba.

Vamos por orden.

Eje 1 — Reprocesar es reproducir, no recalcular: la regla del momento, no la regla de hoy

Hay una palabra que aparece con frecuencia en las conversaciones de gobernanza de datos y que casi siempre se entiende mal. La palabra es reproceso. Y la confusión cuesta cara.

Para una parte muy grande de los equipos de datos, reproceso significa recalcular con la regla actual. Es decir: si una métrica de marzo se calculó mal — porque la regla del momento estaba mal — reprocesar es ejecutar otra vez el cálculo de marzo, ahora con la regla corregida, y sobrescribir el resultado anterior. La métrica antigua desaparece, la métrica nueva ocupa su sitio. Reproceso como sinónimo de limpiar el pasado con el conocimiento del presente.

Esa interpretación es la que hunde a las cadenas el día que llega una auditoría seria. Y la razón es estructural, no de buena voluntad.

Una auditoría seria — la del campo italiano que firma denominaciones de origen, la de un regulador financiero, la de un cuerpo sanitario que vigila trazabilidad de medicamentos — pregunta cosas como esta:

“Reconstrúyeme el cálculo del 14 de marzo con la regla vigente ese día, no con la regla vigente hoy. Quiero ver lo que el aparato te decía aquel día — no lo que sabes hoy a posteriori.”

Si el equipo de datos reprocesó en el sentido de recalculó con la regla de hoy, la respuesta es: no se puede. La métrica del 14 de marzo según la regla del 14 de marzo se ha perdido — fue sobrescrita por el reproceso. La auditoría no acepta la versión de hoy; la versión de hoy es una conjetura sobre el pasado, no una reconstrucción del pasado.

Lo que la fábrica de la cadena hace — y lo que el lado del modelo del pilar Federated Computational Governance pone como obligación — es reproducir, no recalcular. La diferencia es nítida y operativa.

Reproducir significa: ejecutar el cálculo del 14 de marzo contra los datos vigentes el 14 de marzo (los que tenían VALID_FROM ≤ 14-mar y VALID_TO > 14-mar o abierta), con la regla que estaba viva el 14 de marzo. La consulta filtra por la ventana temporal del modelo, la regla aplicada es la versión de la regla que estaba activa ese día, y el resultado del cálculo es idéntico al resultado original. No igual con suerte — idéntico estructuralmente, porque la entrada (los datos) y el algoritmo (la regla) son las que eran, no las de hoy.

Recalcular, en cambio, sería filtrar por la ventana temporal del 14 de marzo pero aplicar la regla de hoy — o aún peor, leer los datos en su versión más reciente y aplicar la regla de hoy. Eso no es reproducir: eso es reescribir el pasado con el conocimiento del presente. Estructuralmente válido para algunas tareas analíticas; estructuralmente inadmisible cuando lo que se quiere demostrar es lo que el modelo decía en su momento.

¿Por qué es la fábrica capaz de reproducir y no solo recalcular? Por dos propiedades que ya quedaron fijadas al cerrar la mecánica del versionado:

1. Los datos de cualquier fecha pasada siguen vivos en su versión correcta. El versionado nativo garantiza que la fila vigente el 14 de marzo se puede recuperar filtrando la ventana temporal — no es un dato perdido, es una fila concreta con su VALID_FROM y su VALID_TO.
2. Las reglas de calidad y de cálculo también están versionadas. Las reglas viven en el aparato — no en código de scripts dispersos — y como cualquier otra cosa que vive en el aparato (el almacén central distribuye estructuras y reglas), están sometidas a la misma propiedad Insert-Only + Audit-Only-Never-Delete. La regla de validación del Pecorino Romano DOP del 2 de febrero vive con su propia ventana de vigencia. Cuando se actualiza — porque la información sobre certificados defectuosos del laboratorio fuerza un cambio en la regla — la regla vieja no desaparece. Se cierra su ventana, se abre la nueva. Y al reproducir el cálculo del 14 de marzo, la regla aplicada es la que estaba viva el 14 de marzo, no la viva hoy.

El caso opuesto al chef del Mediterráneo: el auditor que pregunta por el pasado

Esta propiedad — reproducir, no recalcular — no es exclusiva de la cocina. Aterriza idéntica en cualquier dominio donde una regla evoluciona y un auditor pide cuentas del pasado. Y conviene aterrizarla con un caso del mundo del dato que ya viene rodando desde hace tiempo en esta serie: el pase del chef y una regla viva del dominio Cuentas: “Si un contrato cancelado tiene saldo de 500.000€, no me lo creo”. La regla nació simple — “si estado = CANCELADO, entonces saldo = 0” —, severidad CRITICAL. Vivía en el aparato. Se ejecutaba cada noche. Y rechazaba — correctamente — los contratos donde un fallo de origen había dejado saldo distinto de cero después de cancelar.

El catálogo hizo entonces lo que toca cuando un dominio aprende. Esa misma regla evolucionó. Por una aprobación operativa de redondeo de saldos residuales en intereses devengados, la versión V2 entró en producción el 15 de abril: “si CANCELADO entonces saldo = 0 OR saldo < 5”. La V1 quedó cerrada con su VALID_TO el 14 de abril a medianoche. La V2 abrió con su VALID_FROM el 15 de abril a las 00:00:01. Cero ventana de desincronización — el catálogo aprendió, el aparato consolidó.

Llega un viernes de junio. Un auditor de control interno del Banco de España pide algo concreto:

“Reconstruyan qué contratos cancelados con saldo distinto de cero figuraban como rechazados el 1 de marzo, según la regla vigente esa fecha. Quiero la lista exacta — no la de hoy.”

Aquí está el corte fino. La pregunta tiene dos respuestas posibles, y solo una es correcta.

La incorrecta — la que sale de recalcular con la regla de hoy (V2) — devolvería la lista de contratos cancelados con saldo > 5€ el 1 de marzo. Eso es lo que el aparato rechazaría hoy si llegara un lote con esa información. Pero no es lo que el aparato rechazó el 1 de marzo. Aquel día la regla V1 estaba viva — saldo = 0 —, así que cualquier contrato cancelado con 1,73€ o 4,27€ figuraba en la lista de rechazados. Recalcular con V2 los excluye. La respuesta sub-reporta el pasado por aplicar una regla que entonces no existía.

La correcta — la que sale de reproducir con la regla del momento — filtra los datos vigentes el 1 de marzo (los contratos con su VALID_TO posterior a esa fecha) y aplica la versión de la regla viva el 1 de marzo (V1, vigente del Q3 de 2025 al 14 de abril de 2026). Devuelve la lista exacta — incluyendo los 1,73€ y los 4,27€ — que el aparato rechazó aquel día. La auditoría queda cerrada en una consulta. El aparato sabe qué regla estaba viva qué día porque la regla V1 no se borró: se cerró su VALID_TO el 14 de abril. Igual que el certificado del lote del queso.

Y aquí está el patrón. La misma propiedad estructural opera en cocina y en banca. El chef del Mediterráneo forzó la V2 de una regla — la cadena aprendió hacia adelante. La gerente costera pide reconstruir el pasado bajo la regla de aquel momento — la cadena reproduce hacia atrás. Las dos preguntas, dos sedes distintas, dos dominios distintos, un solo aparato. Las dos respuestas vienen de la misma consulta — solo cambia el filtro temporal y la versión de la regla aplicada.

Esto cierra un callback que llevaba abierto desde que esta serie entró en el bloque técnico, con un nombre concreto. Federated Computational Governance — el pilar de Data Mesh formulado por Zhamak Dehghani — propone que la gobernanza no es un programa de comités humanos que aprueban excepciones a contracorriente. Es gobernanza ejecutable, llevada por código que viaja con el dato y vive en el modelo. La memoria de la fábrica es la cara estructural de ese principio: la gobernanza no solo decide qué entra y qué se queda fuera hoy (reglas en la puerta, cuarentena, registro de calidad cuando algo huele mal), sino que mantiene viva la huella de lo que decidió ayer y lo que sabía ayer, para poder responder preguntas sobre el ayer sin disfrazarlas de preguntas sobre el hoy.

Es la misma propiedad que, en términos industriales, separa la fábrica donde los hornos recuerdan a qué temperatura trabajaban el mes pasado de la fábrica donde solo saben a qué temperatura trabajan ahora. El aparato Data Vault 2.0 permite reproducir por construcción, sin trabajo adicional. Y esa es la propiedad que cierra el pilar Federated Computational Governance.

Eje 2 — La trazabilidad del error esparcido: el lote MZ-2026-PRO-014 y la consulta del lunes

Volvemos al viernes. La gerente de la sede costera ha colgado, la central tiene hasta el lunes para reconstruir la trazabilidad del lote MZ-2026-PRO-014 y la pregunta operativa concreta es esta:

¿En qué sedes, durante qué ventana, se sirvieron pizzas con el lote MZ-2026-PRO-014 etiquetado como Pecorino Romano DOP — siendo en realidad pecorino de pasto sin denominación de origen?.

El lunes a las nueve de la mañana, la respuesta llega.

El sábado por la tarde alguien en la central había lanzado una sola consulta al modelo. El lunes no hay que reconstruir el incidente a mano: el aparato ya dice dónde se coló el lote y durante cuánto tiempo quedó en circulación con la etiqueta equivocada. El mapa devuelve cinco sedes; la costa concentra el golpe. Costa Norte carga el peso: 142 pizzas entre el 2 de febrero y el 18 de marzo, 89 mesas tocadas, 27 clientes con factura nominativa — el rastro más largo y denso. Bahía Sur muestra el mismo patrón con menos volumen pero el mismo cierre temporal: 98 pizzas desde el 9 de febrero hasta la corrección del certificado, 64 mesas, 19 clientes nominativos. Centro Oeste, Estación Este y Plaza Mayor completan el reparto con tramos más cortos; el modelo las devuelve en la misma consulta.

Resumen cadena (las cinco sedes juntas): 371 pizzas con el MZ-2026-PRO-014 bajo la etiqueta DOP que el laboratorio certificó mal; 253 mesas afectadas; 70 clientes con factura nominativa en el corte. Ventana global del incidente: del primer servicio con el lote a la corrección del 18 de marzo — eso es lo que va a importar cuando la asociación del campo italiano pida fechas.

Esa respuesta no es una respuesta hipotética ni una conjetura. Es el resultado de esa consulta al modelo, sin proyecto, sin volcado de logs antiguos, sin coordinar con plataforma ni esperar ventana de mantenimiento. La consulta cruzó tres Satellites (el del lote, el del menú, el de la pizza servida), dos Hubs (el de lote y el de sede) y un Link (el que conecta lote con pizza servida y sede). Sintaxis SQL convencional sobre el modelo Data Vault 2.0. El mismo perfil de consulta que el equipo usa para responder “¿cuántas pizzas servimos en marzo en Costa Norte?” — solo que esta vez la condición filtra por un lote concreto y por su ventana temporal de vigencia como DOP, antes de la corrección del 18 de marzo.

Y aquí la fábrica gana algo más que velocidad. Gana demostrabilidad. Porque cuando la asociación del campo italiano pida documentación trazable del incidente — “demuestre que entre el 2 de febrero y el 18 de marzo la cadena no sabía que el lote era no-DOP” — la respuesta no requiere construir un post-mortem desde fuera del modelo. La respuesta vive en dos filas del Satellite del lote: la versión 1 del registro con certificado DOP y VALID_FROM = 02-feb-2026 09:14:08, y la versión 2 del registro con certificado NO DOP y VALID_FROM = 18-mar-2026 11:42:33. Las dos firmadas por sus operadores, las dos sin tocar desde su inserción. La fábrica no construye la prueba — la fábrica es la prueba.

¿Y qué pasa con la calidad a la entrada — ese registro donde la fábrica anota severidad y contexto cuando algo no encaja, sin mezclarlo con el rumor operativo del Satellite de negocio? Aquí encaja la otra pieza. Esa pieza — en Data Vault 2.0 suele modelarse como Quality Satellite — registró el 18 de marzo una entrada de severidad WARNING — “corrección retroactiva de certificación: lote MZ-2026-PRO-014, motivo error documental del laboratorio del proveedor, requiere acción de comunicación a sedes consumidoras del lote en ventana 02-feb a 18-mar”. Esa entrada es la que dispara, automáticamente, el reparto sede a sede y el total de 371 pizzas. El registro de calidad en la puerta y la memoria del modelo no son dos sistemas que se mandan correos — son dos caras del mismo aparato, y cuando una corrección retroactiva entra en ese registro, la trazabilidad sale del modelo sin trabajo extra.

¿Hay algo más para hacer el lunes, además de comunicar a las sedes y preparar la documentación para la asociación? Sí — y aquí cierra el aprendizaje fundacional del día.

Hay que revisar la regla de validación de certificados DOP que pasó el lote el 2 de febrero. La regla del momento era razonable — confiaba en el certificado del laboratorio acreditado y en el sello visual oficial. La realidad es que esa confianza no era suficiente, porque un laboratorio acreditado puede emitir un certificado erróneo (en este caso, lo emitió). La nueva versión de la regla — la versión 2 de la regla, no del lote — empieza a vivir el 19 de marzo, y añade un paso: “contraste cruzado del número de certificado con el registro central del organismo emisor de denominaciones de origen, antes de aceptar el lote”. La regla vieja queda en el modelo con su VALID_TO cerrada el 18 de marzo. La regla nueva entra con su VALID_FROM el 19 de marzo y VALID_TO abierta. La cadena no rompe lo que validó en febrero — eso era válido bajo la regla del momento. La cadena aprende y mejora la regla hacia adelante, sin tocar el pasado.

Y la propiedad más sutil pero quizá más importante: la mejora de la regla no obliga a tirar nada de lo que ya estaba en el modelo. La estructura del Satellite no cambia. Los datos viejos siguen donde estaban. La regla mejora — eso entra como nueva versión de la regla, no como nueva estructura de datos. El aparato es abierto a extensión (las reglas pueden mejorar) y cerrado a modificación destructiva (la mejora no exige tocar lo ya construido). Esa propiedad aún no la nombramos por su nombre canónico — viene de un autor concreto y aterrizará formalmente en el siguiente capítulo del plano del modelado, anclada al apellido del autor — pero está sembrada aquí. Si el lector ha visto que esta forma de evolucionar la cadena es lo que separa una fábrica que dura del proyecto de seis meses que se rehace cada vez que cambia una regla, ya tiene la mitad del principio en la cabeza.

Hay una imagen que cierra el día. La pizarra de la cocina central, el lunes a las nueve de la mañana, después de comunicar a las cinco sedes y enviar el dossier de trazabilidad a la asociación del campo italiano. Alguien ha escrito con tiza, debajo del reparto que la consulta volcó sobre la pizarra, una frase que un visitante de fuera entendería sin contexto:

“Aquí no se borra nada. Aquí se versiona todo. Y por eso la fábrica recuerda — sin tener que apuntar.”

No es marketing. Es la propiedad estructural de la fábrica.

Lo que viene

El pilar Federated Computational Governance queda cerrado aquí.

La pregunta que decide si la cadena escala más allá de cinco sedes es otra: cuando abre un local nuevo en una ciudad donde Objectville no estaba antes — ¿qué hace la sede el primer día? Si la respuesta es montar horno, contratos y reglas desde cero, cada apertura es un proyecto. Los proyectos no escalan — se acumulan.

La cadena que escala hace lo contrario: horno ya montado, salsa medida, reglas firmadas, memoria disponible desde el día uno. Una operadora nueva llega a las siete con el café y una libreta. A las siete y cuarenta y dos, el horno ya está caliente.

Hasta el martes que viene.