Data Contracts: A Missed Opportunity — Ananth Packkildurai

The mental model: the data industry discussed data contracts extensively without reaching implementation. The conversation focused on classification rather than construction. Meanwhile, software engineering quietly adopted specifications as the primary unit of system design — and AI agents made that shift mandatory. Data contracts are the missing infrastructure layer, but only if treated as infrastructure rather than ideas.

The Missed Opportunity

Key engineering questions got cursory attention before the conversation moved on:

• Enforcement mechanisms
• Evolution strategies
• Compatibility rules
• Failure modes

The industry reached consensus that data contracts were “interesting” without shared understanding of how to build platforms around them.

The Software Engineering Parallel

Software engineering solved the same problem differently. As systems became distributed and automated:

• APIs begin with schemas, not code
• Infrastructure shifted from scripts to declarative specs
• Compatibility rules became automatically encoded and enforced
• Specifications became the systems themselves, not artifacts produced alongside them

Why Agents Forced the Issue

Agents require explicit, machine-readable, verifiable data. Where specifications exist, agents reason reliably. Without them, agents approximate — unacceptable in core infrastructure. Human integrators managed ambiguity through tickets, meetings, organizational knowledge. AI agents cannot.

This is the same structural argument as the missing interface piece: human teams absorb ambiguity socially; automated systems require it codified.

From Artifacts to Infrastructure

The crucial distinction: software engineering treats specifications as executable constraints. The data industry treated contracts as descriptive artifacts — governance tools or communication mechanisms rather than interfaces with failure semantics.

Properly implemented, data contracts are specifications:

• Define structure, semantics, and invariants
• Establish compatibility guarantees over time
• Versioned, validated, and enforced programmatically
• Create stable interfaces between independently evolving systems

The Path Forward

• Treat schemas as specifications, not documentation
• Encode quality, semantics, and compatibility as executable rules
• Enforce contracts at clear system boundaries early
• Version data interfaces with API-level rigor
• Make ownership and accountability explicit and machine-readable

Connections

• 06-reference/2026-04-04-dedp-data-contracts-schema-evolution — the DEDP treatment of data contracts and schema evolution. Ananth’s critique lands on the same ground: contracts need enforcement mechanics, not just definitions.
• 06-reference/2026-04-05-dew-data-engineering-after-ai — contracts as “executable constraints with real failure semantics” is the early binding half of the ECL framework. Bad contracts amplified at scale by AI agents is the forcing function.
• 06-reference/2026-04-05-dew-missing-interface-data-platform — contracts are the technical layer; the operating interface is the organizational layer. Both are missing. Both are needed.
• 06-reference/2026-04-04-claude-code-not-replacing-data-engineers — designing and enforcing contract systems is irreducibly human architectural work. Agents consume contracts; humans design them.
• 06-reference/concepts/products-for-agents — agents as consumers of data products require spec-driven interfaces. Products built for agents demand contracts treated as infrastructure.
• 06-reference/2026-04-04-dedp-convergent-evolution — spec-driven development in software and data is a convergent pattern. The data industry is arriving late but inevitably at the same destination.
• 06-reference/2026-04-05-dew-missing-layer-ai-stack — the Gold layer in the truth registry depends on contracts. The context graph’s triples need stable, versioned schemas underneath.
• 01-projects/phdata/index — contract implementation is high-value consulting. Most clients have informal agreements where they need executable specs. This is a natural advisory engagement.
• 06-reference/2026-04-04-dedp-etl-tool-comparisons — ETL tools assume some contract layer. As the discipline matures, tool selection will weight contract enforcement capabilities.

Part of a series: see also The Missing Interface, Data Engineering After AI, and The Missing Layer in Your AI Stack.