The data contracts movement has changed how teams manage database and pipeline quality. But it's ignored the messiest, most business-critical data in the warehouse — behavioural events.
Every data team I talk to has the same dirty secret.
They've invested heavily in data quality for the warehouse. They run dbt tests. Maybe Monte Carlo or Soda for observability. They've probably read Chad Sanderson's writing on data contracts, maybe his O'Reilly book. They understand the principle: producers and consumers should have explicit, enforceable agreements about what data looks like and how it behaves.
And then they have a Google Sheet called "Tracking Plan" that hasn't been updated since Q3.
That spreadsheet (or Confluence page, or Notion doc, or Avo workspace) is supposed to govern the event data powering their most consequential systems. The events feeding Meta's bidding algorithm. The conversion signals that determine ad spend allocation. The activation events that trigger Braze campaigns. The experiment metrics that decide whether a feature ships.
This isn't a minor data source. For most product-led and e-commerce companies, behavioural events are the single highest-leverage data flowing into the warehouse. And they get the least governance of anything in the stack.
The blind spot in the conversation
The data contracts conversation has focused almost entirely on one class of data: entity and transactional records from production databases.
Sanderson's original work at Convoy centred on Change Data Capture from operational databases. The ODCS (Open Data Contract Standard) spec models schemas, SLAs and quality rules for database tables. Gable, Soda and the growing ecosystem of contract tooling all orient around the same paradigm — data that originates in a database, flows through a pipeline, and lands in a warehouse.
Historically that makes sense. CDC and ELT pipelines were the first place where the producer-consumer relationship became painful enough to formalise. When a backend engineer changes a column type in Postgres and it silently breaks a dbt model three layers downstream, that's a clear contract violation, even if no contract was ever written.
But there's an entire category of data that follows the same producer-consumer pattern, suffers from the same quality problems, and has been left out of the conversation.
Behavioural event data.
Your tracking plan already is a data contract
Strip the spreadsheet formatting off a tracking plan and look at the structure.
It defines a schema. Every tracking plan specifies event names, property names, property types, required vs. optional fields. That's the shape of data the producers (application code) must emit and the consumers (analytics tools, the warehouse, ML models) depend on.
It's a producer-consumer agreement. The tracking plan is authored by someone on the data or product side and implemented by an engineer. It's an agreement between those parties about what flows and in what format.
It carries semantic context. Good tracking plans describe what each event means, when it should fire, what business question it answers. That's the semantic layer — the business meaning attached to the technical schema.
It's versioned, sort of. Teams update tracking plans over time. Events get added, properties change, conventions evolve. That's versioning, minus all the tooling and change management that makes versioning useful.
Compare that to the formal definition of a data contract: an agreement between producers and consumers that specifies schema, semantics, quality expectations and ownership, enforced through automation.
A tracking plan is a data contract. It's just one that exists as a document rather than as code. It isn't versioned in git. It isn't validated in CI. It isn't enforced at ingestion. It has no SLAs. There's no automated way to know when it's been violated, and no automated way to fix violations when they occur.
It's a handshake agreement. And as the saying goes, a verbal contract isn't worth the paper it's written on.
Why event data is structurally harder to govern
There's a reason tracking plans are so bad. Event data has properties that make quality enforcement fundamentally harder than database data.
Events are generated by application code, not by database operations. When you're doing CDC from Postgres, the producer is the database itself — a well-understood, deterministic system. When you're tracking behavioural events, the producer is JavaScript running in a browser, Swift in an iOS app, or a server-side SDK call buried in a microservice. The surface area for bugs is enormous. A tracking call can be placed in the wrong lifecycle hook, wrapped in the wrong conditional, duplicated across components, or simply forgotten during a refactor.
Events are distributed across codebases. Database schemas live in one place. Event tracking calls are scattered across your entire frontend and backend. There's no single place to look to understand what events are actually firing. Every deploy is a potential schema change, even when no one intended to change the tracking.
Events have no natural enforcement point. Databases enforce schemas at write time — try to insert a string into an integer column and the database rejects it. Events have no equivalent. A track() call will happily accept any payload. Segment, RudderStack and most CDPs will ingest whatever you send them. The violation only becomes visible when someone queries the data downstream and notices that revenue is sometimes a string.
The feedback loop is weeks, not minutes. When a database migration breaks a downstream query, the dbt run fails within hours. When an engineer accidentally removes a tracking call in a refactor, you might not notice for weeks — until a PM opens a dashboard and sees a gap, or marketing realises their conversion events stopped flowing to Meta.
These aren't excuses for bad data quality. They're structural properties that explain why event data needs more governance than database data, not less. And yet it consistently gets less.
What an event data contract actually looks like
If you take the data contracts framework seriously — schema, semantics, quality rules, SLAs, ownership, versioning, enforcement — and apply it to behavioural events, the result looks very different from a spreadsheet.
Schema as code, not as documentation. The event schema should be a machine-readable artefact (JSON Schema, Protobuf, or a purpose-built DSL) living in version control and validated programmatically. When a developer implements a tracking call, the schema is the source of truth. When the data lands in the warehouse, the schema is what validates it.
Enforcement at multiple points. Unlike database data, which has a single enforcement point, event data needs enforcement at three layers. At the source: schema registries like Segment Protocols or RudderStack's Data Catalog validate at ingestion and block or quarantine violations. In the codebase: CI checks verify tracking calls match the contract before code ships. In the warehouse: SQL-based validation detects drift between the contract and the actual data landing in Snowflake.
Ownership that maps to reality. A data contract has an owner. For event data, that's usually the analytics engineer or head of data who defines what events the business needs. But there's also a producer — the software engineer who implements the tracking. The contract formalises the relationship and creates accountability on both sides.
Change management as a first-class operation. When a backend team changes a database column, the contract framework catches it through CDC monitoring. Event data needs the same discipline. When a frontend deploy changes tracking behaviour, the system should detect it, trace it to the specific code change, and determine whether it was intentional (a contract evolution) or accidental (a violation to fix).
SLAs that reflect business criticality. Not all events are equal. The purchase_completed event that feeds your revenue attribution needs different quality guarantees than a tooltip_viewed event. Event data contracts should express these differences (expected volume, maximum latency, required property completeness) and alert when SLAs are violated.
The gap in the market is the gap in the conversation
The reason nobody has built this properly is that the data contracts community and the event tracking community don't talk to each other.
Data contract practitioners — the people reading Sanderson's newsletter, attending Data Quality Camp, contributing to ODCS — think in databases, Kafka streams, dbt models, warehouse tables. They use terms like CDC, schema evolution, shift-left. Their mental model of a "data producer" is a backend service.
Event tracking practitioners (the people in the Segment, Amplitude and Mixpanel ecosystems) think in tracking plans, SDKs, CDPs and analytics tools. They use terms like event taxonomy, property mapping, implementation spec. Their mental model of a "data producer" is a frontend developer instrumenting a button click.
These are the same problem. The vocabulary is different, but the underlying architecture is identical — a producer emits structured data, a consumer depends on that data, and quality degrades when there's no enforceable agreement between them.
The data contracts movement gave us the framework. The event tracking world has the problem. Connecting them isn't a naming exercise; it's an architectural one.
What changes when you treat tracking plans as real contracts
When you actually apply data contract discipline to event data, a few things shift.
Discovery replaces guesswork. Instead of maintaining a tracking plan by hand and hoping it matches reality, you query the warehouse to see what events actually exist, what properties they carry, what volume they generate and how they've changed. The contract is built on observed reality, not aspirational documentation.
Enforcement becomes continuous. Instead of a one-time QA check during implementation, every event flowing through your pipeline is validated against the contract. Violations surface in real time. The contract isn't a document you wrote once; it's a living system that tells you, continuously, whether your data meets your standards.
Root cause becomes traceable. When a violation occurs, the system should trace it back to the source. Which deploy changed the tracking? Which code change introduced the regression? Was it intentional? It's the difference between "something is wrong with our checkout events" (an observability alert) and "PR #4521 removed the currency property from purchase_completed on iOS" (a contract violation with a root cause and a fix).
Schema changes become deliberate. Instead of tracking plan drift — where the documented plan gradually diverges from reality — changes go through a formal process. Propose. Review the impact on downstream consumers. Approve. Publish to the registry. Update the warehouse validation. That's how APIs evolve. Event data deserves the same rigour.
What I'm building at suky
I started suky because I've seen this problem from too many angles. At Fivetran, I saw how much teams invest in pipeline reliability for database data. At Atlan, I saw the governance frameworks enterprises build around their catalog. And I kept noticing the same thing — behavioural event data was always the afterthought. The messiest data, powering the most important business decisions, governed by a spreadsheet nobody trusts.
suky treats tracking plans as what they actually are: data contracts. We connect read-only to your Snowflake warehouse to discover what events are actually flowing. We help you define contracts with schemas, quality rules and ownership. We enforce those contracts by publishing to your schema registries — Segment Protocols, RudderStack, Snowplow — and by continuously validating against the warehouse. When something breaks, we trace the violation to the code change that caused it, and can generate the PR to fix it.
We don't ingest your data. We don't sit in your pipeline. We read from your warehouse, enforce through your existing tools, and implement fixes in your codebase.
If your tracking plan is a spreadsheet, it's already a data contract — just one that can't enforce anything. I think it's time to upgrade.
If you're running Segment or RudderStack into Snowflake and you're tired of tracking plan drift, come take a look.
— Kevin