¿Qué es ODCS? El Open Data Contract Standard, explicado

Qué es el Open Data Contract Standard, qué contiene realmente un contrato v3, por qué un estándar abierto le gana al formato de reglas de un proveedor y cómo importar y exportar ODCS mantiene portables tus reglas de calidad de datos.

2026-09-02 · 9 min read

El Open Data Contract Standard (ODCS) es una especificación abierta para describir lo que promete un dataset: su esquema, su propietario, sus niveles de servicio y —la parte que más le importa a la mayoría de los equipos— sus reglas de calidad de datos. Es un documento YAML, versionado como el código, legible por una persona y ejecutable por una herramienta. ODCS se desarrolla en abierto como parte del proyecto Bitol, bajo el paraguas de AI & Data de la Linux Foundation, lo que significa que ningún proveedor lo controla en solitario y que ningún proveedor puede dejar tus reglas tiradas.

El problema que resuelve

Cada herramienta de calidad de datos se inventa su propio formato de reglas. dbt tiene tests en un schema.yml. Great Expectations tiene expectation suites en JSON. Soda tiene SodaCL. Monte Carlo tiene monitores en su interfaz. Cada formato es razonable por separado y ninguno viaja.

Eso tiene tres consecuencias prácticas:

1. Tus expectativas quedan atadas a un runner. Pasar de una herramienta a otra significa reescribir a mano todas las reglas, que es la razón por la que los equipos no se mueven, que es la razón por la que el formato conserva su público cautivo.
2. Productores y consumidores no coinciden en qué se prometió. Las reglas viven en el repositorio del pipeline, en el formato del equipo del pipeline. El equipo de analítica que depende de la tabla no puede leerlas, y mucho menos revisar un cambio.
3. Nada es revisable. Una regla modificada en la interfaz de un proveedor no deja diff. Si el umbral se movió porque cambió el negocio o porque alguien se cansó de la alerta es algo irrecuperable.

Un contrato de datos aborda los tres problemas convirtiendo la propia promesa en el artefacto: separada de la herramienta que la hace cumplir, versionada en el mismo repositorio que todo lo demás y escrita en un formato que pueden leer los dos lados de la interfaz.

Qué hay realmente en un contrato ODCS

Un contrato v3 es un documento YAML con un número reducido de bloques de primer nivel. Lo esencial:

apiVersion: v3.0.0
kind: DataContract
info:
  title: orders
  version: 1.2.0
  owner: data-platform
schema:
  - name: orders
    physicalName: orders
    physicalType: table
    properties:
      - name: order_id
        logicalType: string
        physicalType: uuid
        required: true
        primaryKey: true
        description: Business key, stable across restatements.
        quality:
          - rule: nullCount
            dimension: completeness
            severity: error
            mustBe: "0"
          - rule: duplicateCount
            dimension: uniqueness
            severity: error
            mustBe: "0"
      - name: status
        logicalType: string
        quality:
          - rule: validValues
            dimension: conformity
            severity: error
            mustBe: "['pending', 'paid', 'shipped', 'refunded']"
      - name: created_at
        logicalType: timestamp
        quality:
          - rule: freshness
            dimension: timeliness
            severity: error
            mustBe: "<= 24h"
    quality:
      - rule: rowCount
        dimension: consistency
        severity: warning
        mustBe: "> 0"

Leyéndolo de arriba abajo:

• apiVersion y kind identifican el documento como un contrato de datos ODCS v3. Las herramientas los usan para decidir si siquiera pueden parsearlo.
• info lleva los metadatos para humanos: título, versión semántica, propietario. La versión es la del contrato, no la de los datos, y es lo que le dice a un consumidor si un cambio fue aditivo o rompedor.
• schema describe los objetos físicos. Las properties son las columnas, con un logicalType (portable: string, number, timestamp) y un physicalType (el propio del motor: uuid, NUMERIC, datetime2). Mantener ambos es lo que permite que un mismo contrato describa el mismo dataset en Postgres y en BigQuery.
• Los bloques quality adjuntan expectativas, ya sea a una columna o a la tabla en su conjunto.

Anatomía de una regla de calidad

Cuatro campos hacen el trabajo:

mustBe es la parte que hace agradables de leer los contratos. No es un lenguaje de expresiones booleanas; es una abreviatura específica de cada regla:

• Las reglas de recuento aceptan un comparador: "0", "<= 5", "> 0". Un número a secas significa “exactamente”.
• between acepta límites: "[0, 100000]".
• validValues acepta una lista: "['pending', 'paid']".
• regex acepta un patrón entrecomillado: "'^ORD-[0-9]{6}
  #39;".
• freshness acepta una antigüedad máxima: "<= 24h", "<= 2d".
• referentialIntegrity acepta un destino: "customers.id".

Alguien que no haya usado nunca la herramienta puede leer mustBe: "<= 24h" en una regla freshness y saber exactamente qué va a pasar. De eso se trata.

Las dimensiones no son decoración

El campo dimension parece taxonomía por la taxonomía misma hasta que tienes cien reglas. Entonces se convierte en la única forma de responder a las preguntas que de verdad se hacen: *¿estamos cubiertos en actualidad en nuestros datasets críticos, o solo en completitud?* Las reglas agrupadas por dimensión se convierten en una matriz de cobertura, y los huecos de esa matriz suelen ser más informativos que cualquier comprobación fallida concreta.

Las seis dimensiones de uso común —completeness, uniqueness, conformity, accuracy, timeliness, consistency— están lo bastante asentadas como para que un informe de cobertura signifique lo mismo en todos los equipos.

Por qué merece la pena un estándar abierto

La portabilidad es la razón evidente. El mismo contrato describe el mismo dataset lógico tanto si aterriza en PostgreSQL como en BigQuery o en SQL Server. El runner compila nullCount al SQL de ese motor. Migrar de warehouse deja de ser una migración de reglas.

La revisabilidad es la razón infravalorada. Como el contrato es un archivo, un cambio de umbral es un diff en un pull request, con un autor y un motivo. La propiedad más valiosa de un contrato de datos no es que una máquina pueda ejecutarlo, sino que una persona pueda discutirlo antes de que se fusione.

La independencia es la razón estratégica. Las reglas escritas en un estándar abierto no son un activo de quien las ejecuta. Si cambias de herramienta de validación, los contratos se van contigo. Eso cambia la posición negociadora, y cambia cuánto estás dispuesto a invertir en escribir reglas para empezar.

Interoperabilidad con los catálogos. Como ODCS también recoge la propiedad, las descripciones y los niveles de servicio, el mismo documento alimenta un catálogo, una herramienta de linaje y un runner de calidad sin que tres fuentes de la verdad separadas se vayan desalineando.

Importar y exportar, en la práctica

Un estándar vale exactamente lo que valga la facilidad para entrar y salir de él. Dos reglas prácticas:

La importación debe venir a buscarte donde estés. Apunta una herramienta a una tabla existente y debería leer information_schema, inferir las columnas y los tipos, proponer un contrato de partida a partir de lo que encuentre —las columnas obligatorias se convierten en reglas nullCount, las claves primarias en reglas duplicateCount, las marcas de tiempo en candidatas a freshness— y dejarte editar desde ahí. Partir de un borrador generado de treinta reglas y borrar diez es una experiencia muy distinta de partir de un archivo en blanco.

La exportación debe ser byte a byte lo que editas. Aquí es donde la mayoría de las herramientas fallan discretamente. Si el YAML es la representación de una fila de base de datos, cada ida y vuelta por la interfaz reformatea el archivo, reordena las claves y se come tus comentarios, y el diff de tu pull request se convierte en ruido ilegible. El contrato tiene que *ser* el formato de almacenamiento, no una proyección de él.

Catalyst se toma el segundo enfoque al pie de la letra. El YAML es la fuente de la verdad; el constructor visual de reglas edita el documento en el sitio, preservando comentarios y orden de claves, de modo que una regla añadida desde la interfaz produce un diff de una línea. La exportación es una descarga de archivo, la importación acepta cualquier documento v3 válido, y nada se guarda en una forma de la que no puedas recuperarlo.

Versionar un contrato

Usa versionado semántico en info.version, y en serio:

• Patch: un umbral relajado o endurecido, una descripción mejorada. Los consumidores no necesitan enterarse.
• Minor: una columna nueva, una regla nueva. Aditivo; los consumidores existentes siguen funcionando.
• Major: una columna eliminada o renombrada, un tipo cambiado, una regla que ahora rechaza datos que antes se aceptaban. Rompedor; los consumidores necesitan aviso.

La disciplina se paga sola en el momento en que alguien pregunta si puede eliminar una columna sin riesgo. Con contratos versionados y un diff, eso es una conversación de cinco minutos en lugar de una semana de grep.

Dónde encajan los contratos junto a los dbt tests

No son competidores, y conviene ser preciso con la diferencia.

Los dbt tests se ejecutan dentro de una build de dbt y cubren los modelos que dbt controla. Son excelentes exactamente en eso y, si todas las tablas que te importan son modelos de dbt, puede que sean todo lo que necesitas.

Un contrato de datos está un nivel por encima. Describe la garantía del dataset con independencia de lo que lo haya producido —dbt, Airflow, un notebook de Spark, la herramienta de replicación de un proveedor, un cargador escrito a mano— y con independencia de quién ejecute la comprobación. Es la interfaz entre un productor y un consumidor, versionada como artefacto de primera clase.

En la práctica, los equipos que usan ambos ponen aserciones rápidas y baratas en los dbt tests, donde hacen fallar la build, y ponen las promesas duraderas en el contrato, donde se revisan, se versionan y se monitorizan de forma programada sin importar qué pipeline escribió la tabla hoy.

Preguntas frecuentes

¿Qué significa ODCS?

Open Data Contract Standard. Es una especificación abierta para describir el esquema, la propiedad, los niveles de servicio y las expectativas de calidad de datos de un dataset en un único documento YAML versionado, desarrollada como parte del proyecto Bitol bajo el paraguas de AI & Data de la Linux Foundation.

¿Es ODCS lo mismo que un contrato de datos?

“Contrato de datos” es el concepto: una promesa acordada y versionada entre un productor de datos y sus consumidores. ODCS es un formato concreto y abierto para poner esa promesa por escrito. Puedes tener contratos de datos sin ODCS, en un formato propio; usar un estándar abierto es lo que los hace portables entre herramientas.

¿Cuál es la diferencia entre ODCS y los dbt tests?

Los dbt tests son aserciones dentro de un proyecto de dbt, limitadas a los modelos que dbt construye, y se ejecutan como parte de una build de dbt. Un contrato ODCS describe las garantías del dataset con independencia de la herramienta que lo produjo o que lo comprueba, se versiona como artefacto propio y puede hacerse cumplir por cualquier runner compatible. Muchos equipos usan ambos.

¿Qué reglas de calidad de datos admite ODCS?

El bloque quality de la especificación es lo bastante abierto como para llevar cualquier regla que un runner entienda. En la práctica, el conjunto habitual es completitud (nullCount), unicidad (duplicateCount), valores permitidos (validValues), rangos numéricos (between), coincidencia de patrones (regex), frescura (freshness), recuentos de filas (rowCount), integridad referencial y una vía de escape para SQL personalizado. Cada una lleva una dimensión y una severidad para que los resultados se agreguen en una vista de cobertura.

¿Puedo importar un contrato ODCS existente en Catalyst?

Sí. Catalyst lee cualquier documento ODCS v3 válido, lo valida contra las columnas importadas del dataset —de modo que una regla que referencia una columna inexistente se detecta al guardar, con número de línea— y almacena el propio YAML como fuente de la verdad. La exportación te devuelve el mismo archivo, con los comentarios y el orden intactos.