← All posts
industry7 min readJuly 23, 2026

The next thing to read your event data won't be a person

Years ago I started a company to fix messy event data at the source. I was half right — I just spent a long time solving the wrong half.

The half I got right

That first company was Trackplan. The idea was simple and, I still think, correct as far as it went: most analytics data is broken because the tracking plan — the document that says what every event is meant to be — lives in a spreadsheet nobody maintains, miles away from the code that actually fires the events. So I built tooling to manage tracking plans properly and help teams implement them: define the events once, keep the definitions close to the engineers, generate the right tracking code.

It helped. Teams shipped cleaner instrumentation. But the drift always crept back, and it took me an embarrassingly long time to understand why. I was treating this as a producer problem — get the events defined and written correctly on the way in, and the data downstream takes care of itself. Define better, generate better, ship better.

The trouble is, defining the plan perfectly doesn't guarantee anything about what actually landed. The plan isn't where the truth lives.

The half I missed

The truth lives at the other end — in what gets read back out of the warehouse. And for most of the last decade, the thing doing the reading was a person. An analyst who hit a column called totalAmount where they expected cart_value would frown, work it out, and move on. Human judgement quietly patched the gaps between the plan and the reality every single day, and nobody ever counted it as work.

That's the half I missed. It was never really a producer problem. It was a consumer problem wearing a producer costume — and the only reason it stayed hidden is that the consumers were forgiving. You could get the instrumentation 90% right on the way in and lean on a human to absorb the last 10% on the way out.

That crutch is being kicked away, fast.

Why contracts, and not plans

Here's the distinction I wish I'd understood at Trackplan. A tracking plan is a document. It describes intent. A data contract is enforced — it's the same definition of what an event should be, but written like code, checked in CI, published to your CDP, and continuously verified against what's actually in your warehouse.

The contract is the one artefact that sits between the producer and the consumer and is legible to both. It's what lets you say, deterministically, "the thing that shipped matches the thing that was agreed" — and, just as importantly, "the table you're about to read still matches its contract." A plan can't do that. A plan is a hope. A contract is a check.

Solving this end to end — the thing I only got half of last time — means owning both sides: the producer writing the events, and the consumer reading them, with the contract holding the middle.

Why now, and why this is ten times more urgent

If this were still just humans reading dashboards, I'd tell you contracts are a nice-to-have and you could keep leaning on your analysts. It isn't, and you can't.

The thing querying your warehouse now is increasingly an agent. Snowflake spent its entire Summit this June rebranding the whole platform around exactly this, and the rest of the data stack has followed — the framing that's become mainstream, almost word for word, is that agents are becoming the primary consumers of enterprise data. Your event tables are about to be read at machine speed by something that has none of the context your analyst had, and none of the instinct to frown at totalAmount.

An agent can't tell a renamed property from a real one. It just answers — confidently, plausibly, wrong. The forgiving consumer is being replaced by an unforgiving one, at the exact moment coding agents are also generating more instrumentation, faster, than any human review process was built for. Drift going in is accelerating; tolerance coming out is collapsing. Both curves are bending the wrong way at once.

The reasonable objection is that the warehouses have this covered — Snowflake's semantic views, everyone's context layer, so agents know what the data means. But those layers describe meaning; they don't check that your instrumentation still matches it. And the direction they've taken is to auto-generate the semantics from whatever the data currently looks like — which is precisely the wrong instinct for drift. Rename an event and the layer quietly regenerates around the new shape. The drift doesn't get caught. It gets absorbed. Meanwhile the numbers the platforms publish themselves show how much is riding on this: agent accuracy on structured questions sits in the mid-twenties without curated, trustworthy context and the mid-eighties with it. That gap is the whole game, and nobody in that stack is checking the events underneath.

That's why I think suky is in the right place at the right time. Not because I'm clever about timing — I got the timing wrong once already — but because the problem I misdiagnosed a decade ago just became the load-bearing problem for the entire agentic data stack, and it became one on the consumer side, which is exactly where I wasn't looking last time.

What I'm actually shipping

So suky is contracts for behavioural events, and this time it covers both ends of the loop. On the producer side, your coding agents query the contract registry over MCP before they write a tracking call, and a CI gate fails the pull request when a change would break a contract. On the consumer side, suky verifies the tables your analytics and decisioning agents read — drift, anomalies, freshness — before an agent answers from a table that's quietly gone wrong. All of it read-only, in your own Snowflake, with zero ingestion: no event payload ever leaves your warehouse.

It's the end-to-end version of the thing I started building years ago, rebuilt around what I got wrong the first time.

Come kick the tyres

suky is live today. It's invite-only for now — I'm onboarding the first twenty-five customers by hand, because I want to get the first ones right.

If your engineers have been living in Cursor and your company is starting to point agents at Snowflake, here's the thing worth doing this week: pull the distinct event names from your warehouse and ask whether you'd trust an agent to answer from them. If that makes you wince, you already understand the problem I spent a company learning.

Request a spot and I'll get you set up, usually the same day.

— Kevin

Ready to govern your event data?

Invite-only while we onboard the Founding 25 — request an invite.