Data contracts anti-pattern #4: Your CI passed. Your data still broke.
Hello, hope you’ve had a good week!
This week we had a hackathon and I built a data support agent 🤖 It was fun! I’ll probably write about what I learned soon.
On to the newsletter, and today is the fourth and final post in my series of data contracts anti-patterns, and is about change management for changes that impact the meaning of data, but not the structure.
There’s also links to articles on building a context layer, Write-Audit-Publish for analytics agents, and a new data streaming framework.
Enjoy!
Your CI passed. Your data still broke.
One of the outcomes of implementing data contracts is the adoption of change management for data. Many of these can be implemented with CI checks, for example preventing breaking schema changes.
However, CI checks cannot catch everything. Sometimes a data producer will make a change that would be considered a breaking change for downstream users, but which passes a CI check.
Often these are changes in the semantics, for example an amount field switching from including tax to excluding it. The schema compatibility check passes because it’s only comparing the structure of the data, and knows nothing about its meaning.
This happens when producers follow the processes and respect the outputs of automated tooling, but have not yet adopted full ownership of the data as a product, one where they consider deeply how their changes impact their downstream users (i.e. their customers).
The impact on those consumers of data can be significant! Changing the meaning of the data without changing the structure often means pipelines continue to run, reports and artefacts continue to be generated, but the results are completely different.
To prevent these issues you need to clearly set the expectation on what it means to be a data owner, and that includes being responsible for managing all changes that may impact their downstream users, including semantic changes.
Consider adding one mandatory question to your change process: does this change what the data means? If the answer is yes, treat it as a breaking change, regardless of what the schema diff says.
Interesting links
How to Build a Context Layer (Because You Cannot Buy One)
Semantic layers only give agents the what, while a context layer captures the why. Practical advice on building a context layer.
Write-Audit-Publish for Analytics Agents by Julien Hurault
Interesting use of the WAP pattern for agent workloads.
Introducing Streamling: Performant and Extensible Data Streaming Framework by Yaroslav Tkachenko
A new, lightweight stream processing framework.
Being punny 😅
Germany is advising people to stock up on cheese and sausages, in what officials are calling the Wurst Käse scenario.
Upcoming events
- 🆕 Lost in translation - Data vs Integration Architecture, 2026.07.21 19:00 CEST (GMT+2), LinkedIn and YouTube Live
- Data Community Conference, September, Online
Thanks! If you’d like to support my work…
Thanks for reading this weeks newsletter — always appreciated!
If you’d like to support my work consider buying my book, Driving Data Quality with Data Contracts, or if you have it already please leave a review on Amazon.
Enjoy your weekend.
Andrew