# Chad Sanderson

Chad Sanderson writes about data engineering, data quality, and AI in production. His work argues that teams need to trace data through the application code that creates and changes it—not just through warehouses and databases.

- Profile: https://b2binfluencer.marketing/creators/chad-sanderson/
- LinkedIn: https://www.linkedin.com/in/chad-sanderson
- Median of last 9 posts: 135 reactions, 23 comments (checked 2026-11-02)
- Topics: artificial-intelligence, data-governance, data-quality
- Based on 8 dated posts, latest 2026-10-08

## Summary

Chad Sanderson is most useful for explaining code-level data provenance, lineage limits, and system entropy to technical B2B audiences.

- Best for: A data platform or governance vendor enterprise webinar on end-to-end lineage beyond the warehouse.
- Not for: A consumer packaged-goods brand seeking paid product placement in short-form lifestyle video.
- Check first: Confirm commercial availability and request comparable audience results before contacting them.

### Takeaways

- Provenance, where data came from and what depends on it, should come before data contracts.
- Lineage tools start too late, capturing database to dashboard but not application code.
- System entropy is loss of understanding in systems that still run.

## Main ideas

- **Provenance comes before data contracts**: Sanderson's revised position is that contracts do one thing well: they take a boundary everyone already agrees is critical and turn it into an agreement enforced automatically on every change. The data that causes the worst failures rarely sits at such a boundary. It is the field two teams away that nobody thought to flag, feeding a model whose owner never knew it existed. What teams actually need is provenance — where a value came from, what logic shaped it, what depends on it — and that record is a property of the code that produced the data, recovered by reading the code and keeping the map current. Contracts then sit on top of the map for a few lines rather than being spread thin across thousands of boundaries. Sanderson frames this as a trust problem rather than a regulation problem, and points out that coding agents change code they do not fully understand, quietly rewriting provenance faster than anyone can reconstruct it after the fact.
- **Lineage tools start too late in the journey**: The recurring claim is that lineage focused on the database-to-dashboard path captures the cleanest and easiest-to-explain part of the flow. It may show that a metric came from a particular table, which is traceable without complex tooling, but it cannot answer what a value means, who produced it, or how it was produced, because those systems have no context on where the data came from or why it has the shape it does. That context has to come from the source systems — not the PostgreSQL databases that stored the data but the application code further upstream. Sanderson estimates teams get less than half of the information needed to make lineage useful beyond data teams. The obvious alternative, asking producers to label data or attach metadata at generation, runs into two problems: every producer in the company has to buy in, and the historical data and older systems responsible for the largest data movement still have to be accounted for.
- **Data is any system output, not only warehouse data**: Sanderson argues that data engineering organizations limit their own influence by treating data as whatever sits in the warehouse or lake. Data, in the technological sense, is the output of one system available for consumption by another: an API response, an event on a Kafka topic, a PostgreSQL record, a file in object storage, a queue message, an application log, a SQL query result. All follow the same pattern of producing information that others consume, trace across systems, and transform. The common split — anything upstream is a software problem, anything downstream is a data problem — breaks down because a Java change that causes an outage for an API consumer and a dbt change that breaks a dashboard are the same kind of failure. If that is right, then quality rules, lineage, governance, and contracts should apply across all applications of data, not just the final stage of the supply chain. Sanderson's conclusion is that software teams do not think about data problems day in and day out while data teams do, and that applying data engineering principles at the organization level could be one of the highest-return investments a business can make.
- **System entropy is the barrier underneath most data and AI failures**: Sanderson uses the term System Entropy for the gradual loss of understanding, predictability, and control in a software system as it evolves. As systems grow, code changes accumulate, services multiply, execution paths become implicit, transformations scatter across the codebase, and the original developers leave. The system may still run, but teams no longer know how it works, what depends on what, where critical behavior is defined, or what a change will break. This is deliberately separated from tech debt: debt is an explicit trade-off that a team knows it will have to handle later, while entropy occurs whether or not scalable decisions are made, because it is about the accuracy of a team's understanding over time. Sanderson treats poor change management, long migration timelines, and slow bug triage as restatements of the same problem, and says AI both suffers from entropy and accelerates it when nothing keeps track of what AI changes in a codebase.
- **The five-word question that stops a regulated bank's roadmap**: Sanderson writes that the most expensive question in a regulated bank is "where did this field come from?" It usually arrives from compliance or risk after an audit or regulatory inquiry. Answering it honestly means pulling the most senior engineers off their work and putting them on archaeology: tracing a single value backwards through services, reading git history, and interviewing whoever still remembers how the pipeline worked two years ago. Sanderson says this runs for weeks and burns hundreds of hours of expensive people, and the resulting map is already wrong when it is finished because the code kept changing while it was documented; a different field and a different examiner bring the same exercise back next quarter. The answer does not live in the warehouse or the catalog, the argument goes, because a regulated value is computed in application code, in a service, in a transformation that shipped three releases ago. Teams that stopped paying this tax captured field-level lineage from source code as part of continuous integration, so every release carries its inputs and transformation history and the next inquiry becomes a lookup rather than a project.
- **AI is an exceptional driver and a poor navigator**: Sanderson splits production experience with large language models by the type of outcome rather than by model capability. Models are strong on binary questions around common pattern recognition — does this function exist, does this query exist, does a relationship exist — because they are trained on a large corpus of what things are and what describes them. They are also strong in the messy middle, where a problem has some degree of subjectivity and several acceptable answers, as in greenfield coding where there is no correct approach, only trade-offs. They are weak on non-binary outcomes with many variables, such as explaining the architecture of a complex ecosystem, where the output looks correct but is never fully correct, and they are weak on objective questions with one definitive answer, where the more specific and business-relevant the question becomes, the more likely the model lacks the specificity to answer accurately and consistently. Sanderson also describes AI as lazy: when it meets a pattern it does not recognize, it assumes one it does understand for efficiency, so a system might be right ninety percent of the time with no way to tell which ten percent is wrong, which makes the output unusable. The conclusion is that models should handle subjective problems and deterministic tools should handle objective ones, with both feeding each other.
- **Independent AI agents make data meaning harder, not easier**: Sanderson argues the age of AI reproduces the previous era's data quality problems and makes them worse, because the earlier gap was never about monitoring. Monitoring tells you what happened and contracts tell you what should happen, but quality depends on whose point of view you take: data can be correct from the producer's perspective and incorrect from the consumer's, and a contract was a way to bridge that gap rather than a guarantee. Independent agents creating and consuming data raise new questions — who decides what the data means, what happens when agents take dependencies on each other, how anyone knows when an agent is making an incorrect assumption, and how far off an answer is when it is wrong. Without a shared agreement on meaning, Sanderson says, data does not merely have no value, it has negative value, because being led to the wrong conclusion would have been better avoided. Contracts cannot solve this on their own, but visibility derived from the true source of the data, the code, can give both people and AI the context on how data should be used, where it goes, and what depends on it.

## Work to read

- [The data-contracts pitch, revised: provenance first](https://www.linkedin.com/posts/chad-sanderson_a-year-ago-i-would-have-told-you-to-start-activity-7481083276187656192-39V9)
- [System Entropy: systems that run but stop being understood](https://www.linkedin.com/posts/chad-sanderson_one-of-the-biggest-problems-in-adopting-new-activity-7417272691591921664-WbeE)
- [The five-word question that costs a regulated bank weeks](https://www.linkedin.com/posts/chad-sanderson_the-most-expensive-question-in-a-regulated-activity-7472338248741335040-pAWu)
- [Why table-to-table lineage misses more than half the journey](https://www.linkedin.com/posts/chad-sanderson_data-lineage-is-consistently-failing-to-deliver-activity-7427731908689850368-yhJJ)
- [Data problems do not stop at the warehouse](https://www.linkedin.com/posts/chad-sanderson_so-many-data-engineering-organizations-cripple-activity-7419445618772795393-ZZJz)
- [Where LLMs help and where they quietly fail](https://www.linkedin.com/posts/chad-sanderson_ai-is-not-a-magical-wonder-tool-that-can-activity-7482546784645611520-Efa_)
- [The data-flow map most teams do not have](https://www.linkedin.com/posts/chad-sanderson_data-flow-refers-to-how-data-moves-through-activity-7416886748103856129-fing)

## Brand relationships

- **Gable** (employment)

## Partnerships

None of the material reviewed documents a partnership or sponsorship offer from Chad Sanderson. The supplied posts are technical arguments about data contracts, data quality, data lineage, and running AI in production; they describe ideas and a company, not paid formats. No sponsored placement, paid appearance, webinar collaboration, or brand integration is shown, and there is no rate information, deliverable list, disclosure of past paid work, audience package, or route for a company to open a commercial conversation. The only commercial context in the posts is Gable, the company Chad Sanderson says they built code-level lineage tooling with and are hiring for — an employer and product relationship, not a partnership format. The practical consequence for a buyer is that a thought-leadership webinar proposal is being planned against a person whose paid availability is unverified here. That is a gap in the reviewed evidence rather than a finding that Chad Sanderson never accepts sponsorships, and it should be closed before a budget is committed: confirm directly whether a paid format exists, what it includes, and who handles inbound commercial requests. No formats are listed below because inventing one would misrepresent the evidence.

## Alternatives

- Antonio Grasso: Choose Grasso when the webinar needs to be a plain-language explainer that a mixed audience can follow without a data-engineering background, and when one session should span several topics instead of making a single deep argument. The material covers why a data lake and a data lakehouse are different in practice, with retail and manufacturing examples, and it also shows a working interview format: a conversation with Barry Elliott from Rockwell Automation used to ask why manufacturers still struggle to turn collected data into decisions. That suits a co-hosted or partner-produced session aimed at a broad data and IT audience rather than one narrow engineering room.
- Jim Beddows: Beddows is the better choice when the audience sits closer to government, defence, or research and development programmes, and when the session should be a strategic framework talk rather than a practitioner build walkthrough. The posts name sources-sought and RFI processes, laboratory-to-market ecosystems, and the Pentagon Papers, and they ask how data should be assessed for completeness, age, provenance, and the assumptions behind its use. That provenance framing overlaps directly with the lineage question and gives a policy or innovation audience a way into it.
- Sam Reeve: Reeve becomes the better choice only if the buying decision shifts to a different subject: compensation strategy and pay transparency for HR, total-rewards, and people-leadership audiences. The posts make a focused case that compensation data has a shelf life, that salary surveys and real-time labour market data each carry different signals, and that publishing a salary range without the logic behind it leaves employees unable to understand how pay decisions are made. A vendor selling compensation or HR technology would get a ready-made conversation, including a stated interview with Cary Sparrow on the People/AI Strategy Forum and a clear route to a follow-up resource.

---
AI-assisted summary of public posts. Audience demographics are not available. Engagement appears only where we checked recent posts. Method: https://b2binfluencer.marketing/methodology/