🌱 Dive into Learning-Rich Sundays with groCTO ⤵️
Article of the Week ⭐
“Product managers also understand the concept of the user story: a commitment made on behalf of a specific consumer, for a specific use case, under specific conditions. Data contracts are user stories operationalised.”
Animesh Kumar opens with a definition for AI-related data contracts: a contract is a promise with consequences. An enforceable commitment between a producer and a consumer, where breaking it triggers something real.
Quality metrics measure the data and contract metrics measure whether someone kept their word. A 3% null rate is either a violation or acceptable operating noise, you cannot know which without knowing what was actually promised and to whom.
The four components he breaks contracts into:
The Promise: what the producer commits to: schema, semantics, delivery frequency, permitted failure rate
The Parties: both producer and consumer, each with explicit obligations (many pipeline failures start not at production but at undeclared consumer assumptions)
The Terms: observable, verifiable SLAs written before data flows, not reverse-engineered after
The Consequence: automatic incident triggers, team notifications, impact signals; without this, the contract is decoration
A feature is not done until it passes acceptance criteria agreed on before development starts. A data product is not done until its contract is honoured. That framing shifts the conversation from engineering metrics to product accountability and makes failure attributable.
Kumar also draws on API design to make a systems argument: API contracts let teams deploy services independently without collision. Data contracts do the same for data producers and consumers.
They contain blast radius: a broken contract should alert a bounded, known set of downstream systems, not send unexplained anomalies rippling through dashboards and models for days.
In a right-to-left engineered data product, the data model is not a representation of the contract but rather is the contract. SQL tests, various nuances of integration tests, integrity constraints, quality thresholds, and semantic definitions embedded in the model make it a machine-executable commitment.
Every clause is a contract term. The model runs; the contract is audited automatically without manual periodic review. This also encodes semantics, which Kumar treats as the thing that separates trustworthy data products from well-labelled datasets.
“Revenue” means recognised revenue after refunds. “Customer” means an entity with at least one completed transaction. These definitions are not stored in a wiki. They are enforced at execution.
A data product is not done until its contract is honoured, the same logic as acceptance criteria in product development. That framing makes failure attributable rather than diffuse.
Postel’s Law applied to data: be strict about what you emit, tolerant within the bounds you have agreed to absorb. In practice:
A producer never changes a field name, drops a column, or shifts delivery cadence without a contract amendment
A consumer never quietly relies on a field outside the agreed terms
When either side drifts without declaration, the contract has already broken, ready to be audited and fixed
The model is the contract. In a right-to-left engineered data product, SQL tests, integrity constraints, and semantic definitions embedded in the model make it machine-executable. The model runs and the contract is audited automatically. Semantics are enforced at execution, ie. “revenue” means recognised revenue after refunds, not whatever the upstream system happened to send.
The same fidelity signal serves two audiences:
Engineering teams: breach rates, mean time to recovery, instrumented contract surface
Business stakeholders: which decisions were made during a degradation period, and whether those outputs have been audited
Most teams report only to the first audience, which is why they struggle to justify the investment. The contract framework makes both readable from the same source of truth.
Every engineer learns these rules the hard way. Here are seven that nobody puts in the onboarding docs. Thank you, Anton!
1. It’s always related. When production breaks after a deploy, your first instinct is to defend your PR. It’s wrong. Roll back immediately, stabilise, then debug.
2. Backups aren’t real until you’ve restored from them. Not “I know the option exists”, actually run the restore, confirm the data, time how long it takes. Do you know who has permission to trigger one? Do you know where to click during an outage, or are you figuring it out under pressure?
3. You’ll always hate your own logs. Too sparse when an incident hits, too verbose when AI writes them. The balance of all needed info, shared request IDs across services, nothing extraneous is harder to hit than it looks.
4. Always have a rollback plan. Always. Adding a column, inserting rows, changing a constraint, etc. every data touch needs a tested reversal path. Untested rollback plans have roughly 50/50 odds of making things worse.
5. Every external dependency will fail. A 3rd-party API with 99.9% uptime added to your own 99.9% SLA doubles your potential downtime. Know the rate limits, test what actually breaks when it goes down, and have a fallback before you need one.
6. If there’s any doubt, use four eyes. Senior permissions plus solo late-night changes is how databases get destroyed. If you’re hesitant to ask someone because it’s a weekend, that hesitation is the signal to stop.
7. Nothing is more permanent than a temporary fix. V2 rarely arrives. Push instead for a minimal solution you can stand behind, simple and limited is not the same as held together with duct tape.
There’s something quietly brilliant about AI-coding tools: you describe what you want, and working software appears almost like magic. Entire products are being built faster than ever, by more people than ever. But… there’s always a catch.
This week’s catch came in the form of a major security breach targeting Axios, one of the most downloaded JavaScript libraries in the world. Hackers compromised its npm account, slipped malicious code into a new release, and watched it spread across millions of projects before anyone noticed. Days earlier, the same thing happened to LiteLLM’s PyPI package, this time delivering a credential stealer into any project that pulled it in.
Let’s talk about a structural vulnerability that’s been quietly building:
AI tools tend to over-engineer solutions, bundling in far more dependencies than a project actually needs
Most developers, especially newer “vibe coders” using AI to build without formal training have little visibility into what those dependencies do or how to secure them
Attackers have figured this out and compromise one popular package to reach hundreds of millions of downloads in a single move
Defense strategies haven’t kept pace with how fast AI is changing who builds software and how
None of this means AI-coding tools are bad, or that open-source dependencies should be avoided. They have their merit. But speed without scrutiny is a risk multiplier, and right now the industry is heavy on the former and light on the latter.
Everyone agrees tools like GitHub Copilot feel faster, but turning that feeling into something measurable is where things break down. Output goes up, yet it’s unclear how much of that translates into real value versus added review effort or hidden rework.
The piece unpacks why ROI can’t be judged on usage or speed alone. It needs a more grounded view across delivery, quality and developer effort. The focus shifts to understanding where Copilot actually saves time, where it shifts effort downstream, and how those trade-offs show up over time. If you’ve ever tried to justify AI spend with shaky metrics, this gives a more practical way to think about it.
That’s it for Today!
Whether you’re innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.
See you next week, Ciao 👋
Curators - Diligently curated by our community members Denis & Varun
Featured Authors - Animesh Kumar, Anton Zaides, Chris Stokel-Walker (c. LeadDev)
Sponsors - This newsletter is sponsored by Typo AI - Engineering Intelligence Platform for the AI Era.
1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.
2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.