Chad Sanderson argues that a semantic data model should describe the entities and relationships a business cares about before teams build physical tables and pipelines.
2
Data contracts can be added incrementally to existing warehouse systems so producers and consumers agree on ownership, schema, timing, and allowed changes.
3
Lineage connected to production services can warn engineers that a change will break a downstream training set or pricing model before the change is made.
Summary
Chad Sanderson explains why data modeling matters for machine learning and business analysis. He separates the physical model, which describes how data is stored in systems such as Snowflake, from the semantic model, which describes business entities, properties, relationships, and cardinality. Without that layer, teams repeatedly write similar queries, spend more on warehouse computation, and struggle to connect events such as support interactions, shipments, and purchases. Sanderson argues for incremental data contracts. A contract gives a data asset a clear owner, schema, meaning, and expected delivery behavior. It can flow through a service, Kafka, and the warehouse without requiring a new platform. Josh Wills and Sanderson also discuss organizational incentives. Machine learning engineers are often the first users who care about both production data and downstream models. Sanderson describes how Convoy used contracts and semantic events to improve pricing data and answer product questions about shipment lifecycles. Lineage can then warn producers about downstream breakage before they change a field.
A semantic model gives business meaning to physical data
Chad Sanderson separates two forms of data modeling. A physical model describes how relationships appear in a data environment, such as Snowflake, including tables and joins. A semantic model describes meaningful company entities, their properties, and relationships without tying them to a particular storage system. It includes questions such as whether a relationship is one-to-many or many-to-one. Sanderson says the semantic design should inform the physical model. He also argues that this work is less common in cloud-first organizations, where teams often collect data from many sources and model only enough of it to answer an immediate business question.
Weak data models create repeated work and higher warehouse spend
Sanderson says incomplete models cause people to write and copy similar queries because reusable relationships have not been defined. At Convoy, he saw poor modeling create substantial Snowflake spend through replication. Query complexity also becomes more costly as a company accumulates more data. The problem affects more than data teams. Business partners repeatedly ask data engineers, analysts, and data scientists for answers that a well-designed model could make easier to obtain. Sanderson connects this directly to machine learning because teams need reliable relationships between business entities when they construct training data.
Poor relationships make automation and machine learning unreliable
Sanderson gives customer support and operations as examples. A team may want to know whether a support ticket or email exchange affected a customer's later purchase. Without a useful model, analysts resort to fuzzy matching, long case statements, and guesses about which shipment or event relates to the conversation. Sanderson says this can be inaccurate enough to make automation difficult and can make machine learning on top of the data unreliable. He also describes a company as a network of entities interacting through lifecycles. If those relationships are not modeled, teams can miss information that matters to models such as pricing.
Cloud warehouses need guard rails that can be introduced over time
Josh Wills describes the tradeoff created by cheap, flexible cloud warehouses. It is often cheaper to run a new query than to understand someone else's business question and extract reusable components. Sanderson compares the needed response to GitHub's support for moving quickly with branches, reviews, visibility, and alerts. He does not expect startups to have a complete model from their first day. Instead, he argues that teams need a way to improve the model incrementally as scale problems appear, with contracts and collaborative data design providing review and safety around each change.
A data contract defines an owned, trustworthy asset
Sanderson describes data design as a collaborative surface where people define entities such as shipments and shippers, list their properties, and add relationships needed to answer a business question. A proposed change should be reviewed, enforced through a contract, and delivered into the warehouse. He says the contract gives data a clear owner, a specific purpose, trustworthy contents, and an expected arrival time. The approach can begin with one business problem and one contract. It does not require a new advanced technology stack, since the necessary pieces are process, workflow, schemas, and existing data infrastructure.
Contracts fixed a concrete failure in Convoy's pricing model
Sanderson describes Convoy's pricing model as an important consumer of data. Its training set was losing rows because transformations dropped columns and changed column names upstream, while software engineers were not aware of the downstream effects. The original approach treated production data as something that could be captured indiscriminately and modeled later. Sanderson says the better arrangement is for consumers to state the data they need, for a producer to own its delivery, and for the contract to make the data trustworthy and timely. He says this can be introduced one contract at a time.
Semantic events let teams model real business lifecycles
Sanderson says consumers do not always care about the implementation code. They may care about a real-world event, such as every time a shipment is cancelled, along with the properties that explain the cancellation. At Convoy, the team used semantic events to describe those business meanings and map them to warehouse code. This helped product teams investigate shipment cancellations and allowed teams to reconstruct the history of an entity. Josh Wills connects the same pattern to customer journeys in marketing and traces and spans in observability. Sanderson's point is that the data model should make the business lifecycle explicit.
Lineage should connect warehouse data back to production services
Sanderson says typical lineage systems collect metadata from the warehouse and show relationships between tables. That does not tell a producer what will happen if a field is dropped or renamed in a production service. Combining contracts with lineage could show every downstream consumer and warn that a proposed change will break a pricing model or training set. Sanderson also wants systems to identify backwards-incompatible data changes and communicate them to downstream consumers. Josh Wills adds that schemas and contracts prevent many accidental errors, while downstream validation is still needed because ordinary bugs can pass through.
Machine learning engineers can provide the first incentive for data quality
Josh Wills explains that machine learning engineers at Slack had a reason to care about both production data and warehouse data because they generated data upstream and consumed it downstream. They became early users of schemas, processing, and quality checks, after which growth and performance engineers adopted the tooling. Sanderson says Convoy found a related path through data engineers who were caught between unreliable upstream systems and demanding downstream users. He also warns that a GitHub-style workflow depends on consumers caring about code quality. When users only want a particular data asset at a particular time, semantic data and contracts may be a better abstraction than asking them to manage implementation code.
"The purpose that the contract serves is that it does all of that through schema, and you can introduce this in a totally iterative way, one contract at a time, solve a business problem, get the value, and move on to the next one."Chad Sanderson20:03
Who should watch
You are building machine learning models from production data and keep finding missing columns, renamed fields, or unclear ownership upstream.
Your warehouse is flexible enough that teams answer every question with a new query, and you need a gradual way to reduce duplicated work and spend.
You work between software, data engineering, and data science teams and need contracts, lineage, or semantic events to make downstream effects visible.
