The manifest, explained: your first data contract

Why a data product needs a contract

Most data pipelines don't have a written specification. They have a script, a schedule, and whatever the person who built it remembers about why it works the way it does. That's tolerable for an AI learning pipeline nobody looks at twice. It's not tolerable for something an agent uses to answer a customer, or a model uses to make a decision.

A manifest is that missing specification, written down before anything gets built. It's the one document every later stage, infrastructure, code, validation, deployment, gets measured against. Nothing ships that isn't in it.

The five questions it answers

Every manifest, regardless of consumer, answers the same five questions:

• Who consumes it: the consumer and its interface (agent over MCP, a RAG retrieval API, a GraphRAG traversal endpoint, and so on).
• Where it comes from: every source system, connected with the permissions that system already enforces.
• What we need: freshness, provenance, the permission model, and whether temporal consistency matters.
• What we produce: the exact capabilities and output formats the consumer will call.
• How we measure it: the thresholds a build has to clear before it's allowed to deploy.

Reading a real manifest

Here's a manifest for a support agent that needs contract, ticket and CRM context:

Each field is a promise, and every promise in a manifest is checked, not assumed. freshness: 15min isn't documentation, it's a threshold the deployed product is monitored against. traceability: 100% means every answer the agent gives has to trace back to a source, or the build fails validation.

What happens when a field is wrong

The failure modes are specific enough to name:

• Wrong consumer type: declare rag when you actually need multi-hop reasoning over relationships, and you'll get a product that answers "what" questions well and "how are these connected" questions badly, no matter how good the retrieval is.
• Missing freshness: without an explicit SLO, there's nothing to monitor and nothing to alert on when a source stops updating. The product doesn't fail loudly, it just quietly goes stale.
• Missing provenance: an agent that can't cite where an answer came from can't be audited, and in a regulated workflow, can't be trusted with the question in the first place.