¿El problema es del proveedor o de la franquicia? — el catálogo que aprende y la huella del rechazo

La regla puesta a prueba

La semana pasada dejé al chef del Mediterráneo con una llamada concreta a las 19:30 del jueves 18 de marzo. La ficha del Tomate San Marzano DOP — versión 1, firmada el 12 de enero — había dejado pasar un lote técnicamente correcto pero sustantivamente equivocado. Sello DOP visible en la caja. Número de certificación en su sitio. Pero el sello pertenecía a un lote del año pasado, ya consumido. La regla R3 verificaba que el sello estuviera; no verificaba que fuera válido contra el registro oficial del Consorzio.

Y dejé también la versión 1 de la regla del contrato cancelado en banca — “si estado = CANCELADO, entonces saldo = 0”. Tres palabras, severidad CRITICAL, ejecutándose cada noche sin incidencias. Hasta el día en que el negocio aprueba el redondeo de saldos residuales hasta cinco euros por intereses devengados, y la regla empieza a bloquear casos que ahora son legítimos.

Las dos reglas son el mismo escenario en dos dominios distintos: la regla correcta de ayer es incompleta o incorrecta hoy. La cadena tiene que aprender. Y la pregunta es: ¿cómo aprende sin parar la cocina, sin comité de tres semanas, sin correo a las cuarenta sedes?.

Hoy entro a contestar esa pregunta. Y al cierre del Pulse contesto la del título: ¿el camión BLUE-LINE del martes — los cinco mil litros de tomate triturado que nadie pidió — fue un problema del proveedor, fue un problema de la franquicia, o fue otra cosa?

Vamos por orden.

Eje 1 — Cuando la realidad evoluciona: el catálogo que aprende

Hay un patrón que aparece en todas las cadenas que escalan, y que la mayoría de implementaciones de calidad no contemplan. El patrón es este: las reglas correctas hoy no son las reglas correctas mañana. No porque hoy estén mal — porque la realidad cambia, el negocio cambia, los proveedores cambian, los reguladores cambian. Una cadena viva tiene que tener un mecanismo para que el catálogo de reglas evolucione con la realidad, sin tirar lo anterior, sin esperar a un comité trimestral, sin dejar la actualización al heroísmo de un equipo central.

Volvamos al chef del Mediterráneo. La queja es legítima — la regla R3 (“DOP visible en la caja”) deja pasar un lote que técnicamente cumple (el sello está, el número está) pero que sustantivamente no es lo que la cadena firma como tomate San Marzano DOP. El sello pertenecía a un lote del año pasado.

¿Qué pasa después?

En una empresa tradicional, lo que pasa es lo siguiente. La queja entra al ticketing, llega semanas después a un comité de calidad, se discute y se genera un documento de propuesta. El documento se aprueba al mes siguiente, alguien actualiza el procedimiento y notifica a las sedes por correo. La mitad de las sedes lee el correo y la otra mitad no. Y el lote que el martes que viene llegue a otra sede del Mediterráneo con el mismo problema vuelve a colarse. Porque el procedimiento, aunque actualizado, no se ejecuta — solo se describe.

En la franquicia con documentación viva, lo que pasa es esto. La queja del chef llega el jueves 18 a las 19:30. El responsable de calidad de la central abre el repositorio del dominio Productos. Edita la Recipe — la versión 1 — y añade una cuarta regla (usando un sistema de tres niveles de severidad que explicaré un poco más abajo):

Ficha 2 — Receta refinada del Tomate San Marzano DOP (versión 2, refinada el 18 de marzo tras llamada de la sede del Mediterráneo)

INGREDIENTE         : Tomate San Marzano DOP
FIRMA EL CONTRATO   : Dirección de Calidad de la cadena
VIGENTE DESDE       : 2026-03-18 19:47   (← versión 2, sustituye a versión 1 vigente desde 2026-01-12)
REGLAS DE PUERTA    :
  R1 — origen           = Campania (Italia)                        · severidad: CRITICAL
  R2 — variedad         = San Marzano                              · severidad: CRITICAL
  R3 — certificación    = DOP visible en la caja                   · severidad: CRITICAL
  R4 — verificación     = número de certificación contra el        · severidad: CRITICAL
        cruzada           registro oficial del Consorzio
                          (consulta API; cachear 24h)
MOTIVO DE LA v2     : queja sede Mediterráneo del 18-mar — sello
                       DOP estaba en caja pero pertenecía a lote
                       de cosecha anterior ya consumido.
                       Verificación contra Consorzio detecta
                       este caso. Revisión retroactiva pendiente
                       para los últimos 30 días.
ACCIÓN si CRITICAL  : devolución del lote al productor con motivo
ACCIÓN si WARNING   : aceptar y marcar para revisión humana
ACCIÓN si INFO      : aceptar y dejar huella en QSAT

A las 19:47 del jueves, la Recipe está editada. La plataforma genera automáticamente el nuevo test ejecutable a partir de la regla R4. Lo despliega. A partir de esa noche — la del 18 al 19 de marzo —, todos los lotes de tomate San Marzano DOP que entren en cualquiera de las 40 sedes pasan por la verificación cruzada contra el Consorzio. Sin correo a las sedes. Sin esperar al siguiente comité. Sin actualización manual de un procedimiento. La regla está en el catálogo, el catálogo se ejecuta cada noche, el catálogo aprendió.

Y la huella queda. La V1 no se borra — se cierra con un sello temporal de fin de validez (“vigente del 12 de enero al 18 de marzo”). La V2 entra con un sello de inicio (“vigente desde el 18 de marzo a las 19:47”). Cualquiera que pregunte dentro de seis meses “¿qué reglas estaban vigentes el 14 de marzo cuando entró el lote XYZ?” tiene respuesta. La V1, no la V2. La cadena no acumula deuda — consolida conocimiento.

Y este patrón — el de la regla que nace simple, choca con la realidad, y aprende — no es un caso aislado de cocina. Es el patrón estructural de toda cadena que escala. Y aquí entra el callback al ejemplo del dominio Cuentas que ya aterricé en la Semana 5.

El contrato cancelado, V1 → V2

En la Semana 5 mostré un ejemplo del pase del chef en el dominio Cuentas. La regla V1 era esta: “Si un contrato cancelado tiene saldo de 500.000€, no me lo creo. Si estado = CANCELADO, entonces saldo = 0”. Tres palabras, una regla, severidad CRITICAL. Vivía en la Recipe del dominio Cuentas. Se ejecutaba cada noche. Y rechazaba — correctamente — los contratos donde un fallo de migración o de origen había dejado el saldo distinto de cero después de cancelar.

Hasta que un día el negocio cambió de política. Por motivos de redondeo en el cálculo de intereses devengados, se aprobó que un contrato cancelado pudiera mantener un saldo residual de hasta cinco euros, sin que eso fuera un error. La realidad había evolucionado. La regla V1 — “si CANCELADO, entonces saldo = 0” — ahora estaba bloqueando casos legítimos: contratos cancelados con un residual de 1,73€ o 4,27€ que la operativa nueva consideraba normales.

En una empresa con documentación tradicional, lo que pasaría sería previsible: el PDF de calidad sigue diciendo “saldo = 0”. El equipo técnico, presionado por el ruido operativo, aflojaría la regla por la fuerza — comentándola, bypaseándola, parcheando aguas abajo. La documentación y la realidad se desincronizarían para siempre. Y la próxima vez que un auditor leyera el PDF, vería una regla que el sistema lleva nueve meses sin cumplir.

En la franquicia con documentación viva, el camino es otro. La queja de operativa entra al repositorio del dominio Cuentas como una solicitud de refinamiento. El responsable del dominio — que conoce la operativa nueva — abre la Recipe y la actualiza. La V1 se cierra:

Recipe Cuentas — Regla R-CUENTA-CANCEL-001
v1 — vigente del 2025-09-01 al 2026-04-15
    si estado = CANCELADO entonces saldo = 0
    severidad: CRITICAL

v2 — vigente desde 2026-04-15
    si estado = CANCELADO entonces (saldo = 0 OR saldo < 5)
    severidad: CRITICAL
    motivo: refinamiento por aprobación de redondeo de
            saldo residual en intereses devengados (Q2 2026)

A partir del 15 de abril por la noche, la regla V2 está en producción. Los contratos cancelados con saldo de 4,27€ pasan; los de 500.000€ siguen sin pasar. El catálogo aprendió. La documentación se mueve con la realidad — porque la documentación es la realidad ejecutada. Cero ventana de desincronización.

Y aquí cae la pieza intelectual que cierra el eje. Porque la pregunta natural es: “vale, las reglas evolucionan, pero ¿cómo distinguimos cuándo una regla aprende de cuándo simplemente se afloja por dejadez? ¿Qué la sostiene operativamente?”. La respuesta tiene casi dos décadas y un autor concreto que conviene nombrar antes de seguir.

Maydanchik y las tres severidades — el marco del semáforo

Hay un falso dilema que envenena casi todas las conversaciones operativas de calidad de datos: “O validamos todo en la entrada y entonces nada entra y se nos para el negocio, o no validamos nada y entonces entra cualquier cosa y nadie sabe qué tenemos.”

Es un falso dilema. Lo es porque está mal planteado. La pregunta correcta no es “¿se valida o no se valida?”. La pregunta correcta es “¿con qué severidad se valida cada tipo de regla?”.

Quien resolvió esto antes que nadie, y con un rigor que sigue siendo el estándar operativo del campo, fue Arkady Maydanchik en su libro Data Quality Assessment (2007). El aporte concreto es la separación clara entre tres severidades de regla, cada una con un comportamiento operativo distinto:

• CRITICAL — la hard rule. El dato no entra al modelo. Se desvía a cuarentena con motivo registrado. Ejemplos: business key duplicada (caso del camión BLUE-LINE que veremos en el siguiente eje), campo obligatorio vacío (NIF a null en un cliente de Pólizas), formato roto (fecha que dice 32 de marzo), regla del Consorzio del San Marzano que falla.
• WARNING — la soft rule. El dato entra al modelo, pero con un flag pegado. Es válido formalmente, pero hay algo en él que merece una mirada humana. Ejemplo: un asegurado de 78 años contrata una póliza de vida con prima de 95€/mes; entra, sirve para operar, pero queda marcado para que una persona lo revise por la mañana.
• INFO — el registro al pasar. El dato entra y queda anotado. No hay alerta. No hay revisión humana esperada. Pero el sistema deja huella de la observación por si en el futuro alguien quiere construir una serie histórica. Ejemplo: la cebolla del proveedor X llega hoy a 1,20€/kg, los lunes anteriores estaba a 1,00€.

Las tres severidades en la misma franquicia. Las tres ejecutándose cada día como parte del catálogo vivo. Las tres pegadas al Hub/Satellite/Link correspondiente.

Y aquí cae el cierre del segundo pilar de Data Mesh. Zhamak Dehghani — la creadora del marco de Data Mesh — describe la Federated Computational Governance como la propiedad por la cual, como ella resumiría, la gobernanza no puede ser un comité; tiene que ser código que se ejecuta. La documentación viva con sus tres severidades es exactamente eso: gobernanza ejecutándose, con tres niveles de respuesta operativa, cada uno apropiado al tipo de problema. No es comité. Es semáforo. Y el semáforo lo configura el dominio que conoce el contexto, sobre el contrato canónico que firma la central.

Maydanchik aporta el marco intelectual del semáforo. La doctrina del shift left — que cerramos la semana pasada — aporta el principio. Pero el motor operativo lo aporta la documentación viva — el catálogo que se ejecuta cada noche, deja huella, y aprende con cada queja. El marco sin motor es un PDF. El motor sin marco es heroísmo. Las dos cosas juntas son una franquicia que escala.

Falta una pregunta — la última — que cierra el día. “Vale, las reglas se ejecutan, las tres severidades viven en el catálogo, el catálogo aprende. Pero cuando una regla CRITICAL rechaza un dato — el camión BLUE-LINE del martes —, ¿dónde queda la huella? ¿En un log? ¿En una carpeta de errores?”. Esa pregunta tiene una respuesta concreta y tiene nombre.

Eje 2 — El camión BLUE-LINE: la huella estructural del aprendizaje

Dejamos la cocina central y volvemos al muelle del martes para contestar la segunda pregunta del día: la huella del rechazo.

Cinco mil litros de tomate triturado llegan en el camión de BLUE-LINE. Etiqueta “Tomate triturado tipo italiano”, lote MZ-7842-IT. La operadora del muelle escanea el código y el sistema responde inmediatamente: CRITICAL — duplicate business key. El lote MZ-7842-IT ya estaba registrado en el sistema, marcado el 14 de febrero como “no entregado — proveedor BLUE-LINE indicó que el lote había sido retirado por problema de etiquetado en origen”. El lote que dice no entregado el 14 de febrero está aterrizando hoy en otro muelle. Algo no cuadra.

La hard rule rechaza. El camión se queda fuera. Los cinco mil litros vuelven al proveedor con devolución motivada. El operativo de la sede no decide nada — la regla decidió.

Pero la huella queda — o debería quedar. Y aquí está el matiz operativo que conviene separar.

El dato no entró. El modelo está limpio. La hard rule cumplió su función — esa es la garantía fundamental y no requiere nada más. Pero “el dato no entró” contesta a la pregunta de seguridad del modelo, no a la pregunta de negocio: “¿cuántos lotes ha rechazado BLUE-LINE este trimestre?”, “¿qué regla está disparando más rechazos esta semana?”, “¿podéis demostrar a compliance que el lote MZ-7842-IT no entró al modelo el 18 de marzo?”. Esas preguntas necesitan que el evento de rechazo quede en algún sitio con estructura — no en una carpeta errors/ que nadie mira hasta que ya es tarde.

La opción con mayor trazabilidad analítica nativa en el aparato Data Vault 2.0 es una pieza con nombre propio: el QSAT — Quality Satellite. Es otro Satellite del mismo aparato, exactamente del mismo material que los Satellites que vimos hace dos semanas — la diferencia es lo que registra. Donde el Satellite de un Hub Cliente registra atributos del cliente versionados, el QSAT registra eventos de calidad versionados: qué regla disparó, sobre qué dato, en qué momento, con qué severidad, qué motivo, qué acción se tomó. El dato rechazado no entra al modelo. La noticia del rechazo — sí.

Ficha 3 — La fila del QSAT del lote MZ-7842-IT (martes 18 de marzo, 09:14:32)

QSAT — fila del 2026-03-18T09:14:32

Regla disparada     : R-HUB-LOTE-001 — duplicate business key check
Severidad           : CRITICAL
Versión de la regla : v1 (vigente desde 2025-11-04)
Business key        : MZ-7842-IT
Origen              : BLUE-LINE (proveedor — Hub PROVEEDOR)
Motivo              : Lote ya registrado el 14-feb como "no entregado".
                       Aparición en muelle norte el 18-mar incoherente.
Acción              : Rechazado — devuelto a origen
Código devolución   : DEV-2026-0318-MZ-7842-IT
Operador            : marina.lopez@objectville.com (sede norte)

Esa fila vive en el modelo. Porque el QSAT es, estructuralmente, un Satellite más, igual que cualquier otra fila del modelo. La consulta que contesta a “¿qué lotes hemos rechazado por duplicate business key este trimestre?” es la misma consulta SQL que la que contesta a “¿qué clientes han renovado póliza este trimestre?”. Son consultas de Satellites — uno con eventos de cliente, otro con eventos de calidad. El aparato es el mismo.

Y aquí cierra el callback técnico que llevamos abierto desde la primera semana de B2: la calidad no es una capa montada encima del modelo. Es otra cara del modelo. El QSAT es Data Vault 2.0 puro — un Satellite — usado para registrar el comportamiento del propio aparato cuando rechaza un dato. La calidad y la operación viven dentro de la misma estructura. La trazabilidad de los rechazos no exige otra herramienta, otro servidor, otro equipo. Exige una consulta más al mismo modelo.

¿Qué cambia eso en la práctica? Lo voy a aterrizar con un ejemplo del dominio que tocamos en la Semana 6 — Pólizas — porque la mecánica es exactamente la misma y conviene verla cruzando ingredientes.

La calidad vive en el modelo — el caso del dominio Pólizas

La Semana 6 cerró con una Recipe del dominio Pólizas que tenía tres reglas de calidad firmadas por negocio: “El NIF tiene formato válido. El scoring está entre 0 y 10. Prima neta = Prima bruta - Reaseguro, con tolerancia de 0,01”. Tres niveles — propiedad, entidad, relación. Tres severidades — las tres CRITICAL en aquella Recipe inicial.

Las tres se ejecutan cada noche. Cada vez que entra un cliente, una póliza, una operación. Y cada disparo deja huella en el QSAT del dominio Pólizas. Si el día 18 de abril llega un lote de altas con tres NIFs mal formateados, el QSAT registra tres filas. Cada una con su regla, su severidad, su business key, su sello temporal, su acción. Tres devoluciones al sistema fuente con motivo concreto.

Y la pregunta que un equipo de control interno de un banco quiere poder hacer en cualquier momento es esta: “¿cuántas operaciones hemos rechazado este trimestre por NIF mal formateado, por cuál proveedor de altas, y con qué tendencia respecto al trimestre anterior?”. En la mayoría de implementaciones, esa pregunta dispara una odisea de excavar logs en cinco sistemas distintos. En una implementación con QSAT, esa pregunta es una consulta SQL contra el QSAT del dominio Pólizas — agrupada por proveedor, filtrada por severidad CRITICAL, agregada por trimestre. La respuesta sale en milisegundos. Sin trabajo extra. Sin equipo dedicado a reconstrucción.

Cambia que cuando el equipo de fraude pregunte dentro de seis meses “¿cuántas veces nos ha intentado colar BLUE-LINE un lote sospechoso este año?”, la respuesta sale del QSAT en una consulta. Cambia que cuando el equipo de compliance pregunte “¿podéis demostrar que el lote MZ-7842-IT NO entró al modelo el 18 de marzo?”, la respuesta es la fila del QSAT con la severidad CRITICAL y el código de devolución — no buscar en logs antiguos. Cambia que cuando un nuevo proveedor pregunte “¿qué tasa de rechazo tenéis con los proveedores actuales?”, la respuesta sale de un dashboard sobre QSAT y los Hubs de proveedor — sin trabajo extra.

Y cambia, sobre todo, lo que ya hemos repetido varias veces y que hoy gana cuerpo: la calidad como código, no como auditoría. La auditoría llega tarde — cuando el dato malo ya está esparcido. La calidad como código intercepta el dato malo en la puerta y deja huella estructural del rechazo. La diferencia no es de proceso. Es de arquitectura.

Cerrando el bucle — ¿el proveedor o la franquicia?

Ahora ya puedo contestar de un solo trazo la pregunta del título.

¿El problema es del proveedor o de la franquicia? La frontera, en una cadena con documentación viva, no la decide un comité. La decide el catálogo de reglas ejecutándose en el Staging cada noche — antes de que el dato toque el modelo.

Si el catálogo dispara en Staging — CRITICAL en la puerta, lote rechazado, fila en la tabla de calidad —, el problema es del proveedor. El dato base llegó mal. El correo sale al productor con el código de devolución y el motivo concreto. La sede no investiga su proceso porque el proceso no llegó a tocar el dato. La operadora del muelle escanea el código, el sistema decide, el camión vuelve.

Si el catálogo deja pasar — todas las reglas verdes, dato entra al modelo, sirve para operar — y después aparece un comportamiento raro aguas abajo, el problema es de la franquicia. Tu transformación. Tu Facade. Tu Vault Component que combina mal dos Satellites. Ahí entras tú con criterio porque el dato base estaba bien.

Y si el catálogo deja pasar y luego una sede detecta que la regla era incompleta — el chef del Mediterráneo del jueves —, entonces estamos en el tercer caso, el del aprendizaje. El catálogo no estaba mal: estaba incompleto. La queja entra. La V2 nace. Al día siguiente toda la cadena está protegida. El catálogo aprendió. La franquicia consolidó conocimiento estructural. Y la cadena no acumuló deuda.

Tres preguntas. Una sola pieza. La documentación viva.

Y aquí cerraría el día… si no fuera porque nos hemos dejado un cabo suelto. El gordo.

Lo que viene

Esa es una mitad del problema. Falta la otra: ¿qué pasa cuando el dato que entró bien resulta que era incorrecto — y nadie sabe hasta dónde se ha esparcido el error?

Os dejo el giro con una imagen concreta. Un viernes de marzo, una sede pequeña de Objectville en una ciudad costera del norte llama a la central. Al teléfono, la gerente con voz contenida:

— El queso DOP que nos llegó hace seis semanas. El que firmamos como Pecorino Romano DOP. Acaba de llegarnos el aviso oficial: el laboratorio del proveedor envió mal el certificado. No era DOP de verdad. Era pecorino de pasto, sí, pero sin la denominación de origen. Hemos servido pizzas con ese queso. ¿Hasta dónde se ha esparcido?

Silencio en la sala. La central no sabe responder en el día. ¿Cuántas pizzas? ¿En qué sedes? ¿A qué clientes? ¿Qué auditor independiente, mañana, podrá leer el menú con DOP escrito y comprobar qué se sirvió de verdad cada día? ¿Y cómo se hace todo eso sin tener que destruir nada de lo que ya está en el modelo?

Las tres preguntas no se contestan con calidad como la de hoy. Se contestan con una propiedad del modelo que se llama Audit-Only-Never-Delete. Y se contestan con una mecánica concreta: reproducir el pasado contra la regla del momento, sin borrar nada. Eso es lo que abro el martes que viene. La fábrica que nunca olvida.

Hoy hemos cerrado el lado del proceso del pilar Federated Computational Governance — el lado que decide qué entra y qué se queda fuera, con quién y bajo qué severidad, y que aprende cada vez que la realidad le enseña algo nuevo. La memoria — la otra mitad — la abro la semana que viene. Y con ella cierra el pilar entero.

Hasta la semana que viene.