Model as a Data Contract: The Contract-First System Behind Dynamic Semantics
From fundamentals of data modelling to contractual abilities, and how they uphold the constantly evolving semantics between data producers and data consumers
TOC
Semantics is Key
šµ Dot #1
šµ Dot #2
šµ Dot #3
šµ ā¢ šµ ā¢ šµ Connecting the Dots
In the realm of Data, a model would usually refer to a data model: a collection of data entities (e.g., ācustomersā, āaccountsā, āordersā) and how they are related to each other. But we are taking a step back here to the broader and more fundamental understanding of āModelā:
A model represents a concept, system, or process structurally. The purpose of the simplified structure is to help in navigating, understanding, and interacting with complex realities. Like a map in a new city. It is the simplified abstraction that captures important details while bypassing unnecessary complexity so users comprehend a larger reality through the modelās lens.
A model is an informative representation of an object, person, or system.
Models can be divided into physical models (e.g. a ship model and abstract models (e.g. a set of mathematical equations describing the workings of the atmosphere for the purpose of weather forecasting). [refer]
Semantics is Key
Etymology is one of the most foundational fields of study when it comes to data.
It is the study of the origin of words. And as we know, a single word could change the meaning of data. Which is why Semantics is such a major area of innovation and discussion in the data space.
This leads us to go back to the origin of āModelā to understand the perception of the word in the broader subconscious. Or the deeply embedded root sentiment the word evokes. Weāll find out in a minute why this is so critical.
The word āmodelā comes from Latin root modulus, which means āa small measureā or āa standardā. This is a diminutive form of modus, which means āmeasure,ā āmanner,ā or āway.ā
Ergo, the connection between model as a structured representation and measure as a unit of quantification is almost intuitive when we break it down:
šµ Dot #1: A Model is a Measure of Reality
Originally, modulus (small measure) referred to a standard unit: a way to quantify and compare things. Over time, this idea expanded: instead of just measuring physical dimensions, models became ways to measure conceptual coherence, relationships, and expected behaviours.
A blueprint is a model that measures proportions in architecture.
A financial model measures risk and opportunity.
A data model measures the validity and consistency of data.
Thus, a model is a measure of how well a system holds together: it captures the essence of something in a structured way.
šµ Dot #2: A Model Sets the Boundaries for Interpretation
A measure tells us how much of something exists, while a model tells us what is relevant in the first place.
A ruler measures length, but the architectural model decides which dimensions matter.
A sensor measures temperature, but the weather model decides how those readings predict future conditions.
In other words, a model is a higher-order measure, not just a number, but a structured way of defining what should be measured and what relationships exist.
šµ Dot #3: A Model is Constituted of Both Structural & Measurable Features
When we say Model-First Data Products, we are embedding measurement inside the model:
The Model is a SQL Query
The SQL (acting as models or blueprints for tables/views) defines what data is valid, how itās structured, and how it can be used, setting measurable expectations.
The Model is Unit-Testable
The model itself contains tests, ensuring that data conforms to predefined constraints (e.g., uniqueness, integrity, quality thresholds).
The Model Embeds Data Quality Requirements
Instead of an after-the-fact measurement of data quality, the model encodes the measurement criteria upfront.
The Model is Defensive
Defensive programming is a coding philosophy where developers anticipate and guard against potential failures, edge cases, and unexpected inputs. Instead of assuming all inputs and conditions will be correct, a defensive program is built to handle errors gracefully, prevent failures, and maintain stability under uncertain conditions.
šµ ā¢ šµ ā¢ šµ Connecting the Dots: Model as a Contract
When we combineĀ the model as a structured representationĀ andĀ the model as a measure of reality, what emerges is the idea of aĀ contract.
A contract exists to create alignment: between parties, across contexts, and over time. It defines what is valid, what is expected, and what will not be tolerated. Thatās exactly what a model does in the data space.
Shared Understanding: A data model goes beyond a technical framework, it is akin to a semantic agreement. It tells producers and consumers of data what entities exist (customers, accounts, transactions), how they relate, and what rules govern their integrity.
Guardrails for Reliability: By embedding tests and quality constraints directly in the model, we move from after-the-fact policing to built-in assurances. The model doesnāt just describe data; it enforces the contract that data must uphold.
Boundary of Trust: Contracts make collaboration possible even among untrusted actors. Similarly, models make data usable across domains, teams, or platforms by guaranteeing consistency of shape, meaning, and measure.
Thus, a Model-First Data Product is, at its core, a contract-first system. The model is the contract that binds intent with execution, semantics with measurement, and structure with reliability.
And just like legal contracts in society, the strength of the data ecosystem depends on the strength of these contracts: clear, enforceable, and universally interpretable.
Key Attributes of āModel as a Contractā
Blueprint for Understanding: Provides a mental framework to describe how things work, reduces ambiguity, and helps define what should be true before implementation.
Declarative, Not Procedural: Specifies what should exist, not necessarily how to produce it. In contrast to step-by-step instructions, a model defines relationships, rules, and expected behaviours.
Constraints & Properties: Defines the boundaries and characteristics of a system, ensuring consistency, accuracy, and expected behaviour.
Reusability & Composability: Can be built upon, extended, or combined with other models to represent more complex systems.
Testable & Verifiable: A well-formed model allows validation against real-world data, expected outcomes, or logical constraints.
MD101 Support āļø
If you have any queries about the piece, feel free to connect with the author(s). Or feel free to connect with the MD101 team directly at community@moderndata101.com š§”
Author Connect
Find me on LinkedIn šš» | Find more about Animesh on our Expert Directory š
From MD101 team š§”
The Modern Data Masterclass: Learn from 5 Masters in Data Products, Agentic Ecosystems, and Data Adoption!
With our latest 10,000 subscribers milestone, we opened up The Modern Data Masterclass for all to tune in and find countless insights from top data experts in the field. We are extremely appreciative of the time and effort theyāve dedicatedly shared with us to make this happen for the data community.
