đ± 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.â
Using Data Contracts as a Value Assessment Framework for Data or AI Initiatives
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
Data-Product Management
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.
Model-as-contract
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.
Postelâs Law
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.
Other highlights đ
The unwritten laws of software engineering
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.
Axios hack exposes AI-codingâs dependency problem
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.
The Hard Part About Proving Copilotâs ROI
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.
Find Yourself đ»
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 đ
Credits đ
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.
Thanks for sharing! Great to discover this account