A data contract that protects only schemas is incomplete. The business can still break while every column arrives on time.
Schema, freshness, and volume checks are useful. They tell you whether the pipe is physically intact. They do not tell you whether "customer_type" changed meaning, whether a lifecycle state now includes trials, or whether a product event stopped representing the behavior the metric assumes.
Business meaning deserves contract terms too. If a field feeds operating metrics, the contract should name the concept it supports, the allowed values, the source owner, the semantic owner, the permitted transformations, and the downstream decisions that depend on it. That makes a change to meaning visible as a business event rather than a quiet pull request.
This is especially important across team boundaries. Product may change event instrumentation for good reasons. Finance may adjust a revenue rule. Sales ops may revise stages. The semantic layer should translate those changes into impact: which metrics move, which dashboards need annotation, which workflows need testing, which agents need updated context.
The point is not to turn every change into bureaucracy. It is to stop pretending technical compatibility equals business compatibility. A field can keep the same name and type while its operating meaning changes enough to damage decisions.
A good contract answers one plain question: if this meaning changes, who must know before the business acts on it? If nobody can answer, the contract is too thin.
This is part 7 of 10 in The Semantic Layer.
