Cuando una cifra comercial cambia, la primera pregunta no es qué herramienta la dibuja, sino de dónde salió y qué ocurrió en el camino. Un diagrama dibujado una vez ayuda poco si no distingue la transformación diseñada de la ejecución que produjo el dato visible.

El modelo de OpenLineage separa datasets, jobs y ejecuciones. Los datasets representan entradas y salidas; los jobs describen transformaciones; los eventos de ejecución aportan el contexto de una corrida concreta. Esa separación permite responder tanto “qué debería alimentar esta tabla” como “qué ejecución la actualizó anoche”.

Empieza por una métrica con una decisión asociada

No intentes cartografiar toda la plataforma antes de demostrar utilidad. Elige, por ejemplo, ventas_netas en el informe de dirección y registra:

  • definición visible y unidad;
  • tabla y columna que la suministran;
  • modelo semántico y medida que la calcula;
  • transformación que genera esa columna;
  • fuentes originales;
  • responsables de negocio y técnicos;
  • frecuencia y última ejecución correcta.

El recorrido debe poder navegarse en ambos sentidos. Desde el dashboard se baja al origen para explicar una anomalía; desde una tabla fuente se sube a consumidores para evaluar el impacto de un cambio.

Ejemplo de cadena verificable

CRM.orders + ERP.credit_notes
        ↓ job normalize_sales / run 2026-04-08T05:00Z
warehouse.fact_sales
        ↓ job build_commercial_model / run 2026-04-08T06:00Z
semantic.sales
        ↓ measure net_sales
Dashboard Dirección / tarjeta Ventas netas

Cada arista necesita evidencia. En SQL puede obtenerse del análisis de consultas; en un orquestador, de entradas y salidas declaradas; en BI, de las dependencias entre modelo, medida y visual. Cuando no exista extracción automática, declara el enlace y marca su procedencia para no confundirlo con linaje observado.

No mezcles diseño con ejecución

El diseño afirma que normalize_sales escribe fact_sales. Una ejecución concreta puede fallar, producir cero filas o leer una partición distinta. Los eventos de ciclo de ejecución de OpenLineage expresan estados como inicio, finalización o fallo y permiten asociar entradas y salidas a la corrida.

Para investigar una cifra necesitas ambos planos:

Plano Responde
Linaje de diseño qué dependencias se esperan
Linaje de ejecución qué ocurrió en una corrida concreta
Frescura cuándo se actualizó con éxito cada nodo
Calidad qué controles superó el dato
Propiedad quién decide definición y corrección

Evita relaciones falsas

Si un job lee clientes y pedidos y genera dos salidas independientes, relacionar cada entrada con todas las salidas crea un producto cartesiano engañoso. Registra dependencias a nivel de salida o columna cuando sean conocidas. El objetivo no es dibujar más flechas, sino conservar las que ayudan a decidir.

También normaliza identidades. warehouse.sales, PROD.WAREHOUSE.SALES y una URL del catálogo pueden referirse al mismo activo. Define namespace, nombre y entorno para evitar nodos duplicados.

Prueba el linaje con preguntas reales

Un linaje es aceptable si permite responder en minutos:

  1. ¿Qué informes se ven afectados si cambia ERP.credit_notes.amount?
  2. ¿Qué versión del job produjo la cifra del cierre?
  3. ¿Dónde se introdujo una conversión de moneda?
  4. ¿Qué ejecución fue la última correcta?
  5. ¿Quién valida la definición de ventas netas?

Vincula estas preguntas con contratos de datos para anticipar cambios y con elección entre ETL y ELT para diagnosticar fallos. El catálogo aporta contexto; el linaje aporta relaciones y ejecuciones.

Seguir una cifra hasta su origen requiere capturar metadatos durante la operación, no reconstruirlos después de una incidencia. Empieza por una decisión crítica, comprueba el recorrido de extremo a extremo y amplía desde ese núcleo.