Two terms come up in almost every data governance conversation I have: "data contract" and "schema registry". They get used interchangeably, including by people who should know better. They're related, but they solve different problems — and getting the distinction right is the difference between a complete event governance setup and one with gaps you only notice when something breaks.
I'll lay out what each one is, where they overlap, and where the actual seams are.
What a data contract is
A data contract is a formal agreement between a data producer and its consumers. It specifies:
- Schema — what fields exist, their types, and which are required.
- Semantics — what each field means, not just its type.
- Quality rules — freshness SLAs, volume expectations, null rate thresholds.
- Ownership — who is responsible for the data's accuracy.
- Lifecycle — whether the event is draft, active, deprecated, or retired.
- Change management — how changes are proposed, reviewed and approved.
A data contract is a specification. It's a document (or configuration) that describes what data should look like and what happens when it doesn't. On its own it enforces nothing; it needs an enforcement mechanism to do real work.
What a schema registry is
A schema registry is a runtime system that stores schemas and validates data against them at processing time. Common examples:
- Segment Protocols — validates analytics events at CDP ingestion.
- RudderStack Tracking Plans — validates events at the RudderStack pipeline.
- Snowplow Iglu — stores JSON schemas and validates Snowplow events.
- Confluent Schema Registry — validates Kafka messages against Avro/Protobuf schemas.
- AWS Glue Schema Registry — validates data in AWS streaming pipelines.
A schema registry answers exactly one question: "does this piece of data match the expected schema?" It validates at runtime, typically at the point of ingestion or transmission.
How they differ
| Aspect | Data Contract | Schema Registry |
|---|---|---|
| What it is | A specification (the rules) | A runtime system (the enforcer) |
| Scope | Schema + semantics + quality + ownership + lifecycle | Schema validation only |
| When it acts | At design time and review time | At runtime (ingestion / transmission) |
| Change management | Approval workflows, diffs, audit trails | Schema versioning (backward/forward compatibility) |
| Quality rules | SLAs, volume, freshness, null rates | Type and structure validation only |
| Ownership | Explicit team/individual assignment | No ownership concept |
| AI capabilities | Can be auto-generated from product goals | Stores schemas, doesn't generate them |
The simplest way I've found to explain it: the data contract is the policy; the schema registry is the enforcement mechanism.
Why you need both
Contract without registry
You've defined exactly what checkout_started should look like, who owns it, and what the SLA is. But nothing stops a developer from shipping a malformed event. The contract exists, and it has no teeth. That's the spreadsheet problem — documentation without enforcement.
Registry without contract
Your CDP validates events at ingestion, blocking anything that doesn't match the schema. But there's no process for how the schema itself changes. No approval workflow, no ownership, no quality rules beyond structure. Someone updates the schema directly, and downstream consumers don't know until their dashboards break.
Both together
The contract defines the full specification — schema, semantics, quality, ownership, lifecycle. The registry enforces the structural part at runtime. The contract system manages the change process (proposal, review, approval) and monitors the quality rules the registry can't — volume, freshness, SLA compliance.
For behavioural events specifically
The split is especially relevant for behavioural events.
CDP schema registries (Segment Protocols, RudderStack Tracking Plans) are the natural enforcement point. They sit at the ingestion layer where events flow through. Pushing your contract to a CDP registry means enforcement happens at the source — before bad data enters the warehouse.
Event data contracts add what registries lack:
- Discovery — auto-discover events from your warehouse to build contracts from reality, not assumptions.
- AI generation — generate contracts from product goals instead of editing JSON by hand.
- Approval workflows — require review for every schema change with a full audit trail.
- Cross-CDP support — maintain one contract, publish to multiple registries.
- Warehouse validation — monitor quality beyond what the registry checks (volume anomalies, SLA breaches, property drift over time).
- Implementation — generate tracking code from the contract (auto-PRs, SDK codegen, MCP server for IDEs).
The practical workflow
Here's how contracts and registries work together in practice:
- Define the event contract, manually or with AI. Schema, properties, types, rules, ownership.
- Review via changeset workflow — propose changes, review diffs, approve.
- Publish the schema to your registry — Segment Protocols, RudderStack, Snowplow Iglu.
- Enforce at runtime — the registry validates events at ingestion, blocking non-conforming data.
- Monitor in the warehouse — the contract system checks volume, freshness and SLA compliance.
- Resolve violations — correlate with deploys, identify root cause, generate fix PRs.
The schema registry handles step 4. The contract system handles steps 1, 2, 3, 5 and 6. Together, they give you end-to-end event governance.
Choosing the right tools
If you only need runtime schema validation and you're committed to a single CDP, your CDP's built-in registry is probably enough. Segment Protocols, RudderStack Tracking Plans and Snowplow Iglu all provide solid ingestion-time enforcement.
If you need the full lifecycle — AI-assisted contract authoring, approval workflows, cross-CDP publishing, warehouse validation and implementation automation — you need a contract platform that publishes to your registry of choice.
They aren't competing alternatives. They're complementary layers of a complete event governance stack. The contract layer is where most teams have the biggest gap today, and it's the layer I'm building at suky. If you want to see what it looks like against your own data, come have a look.
— Kevin