Essay

Versioning the Meaning of Data

Software teams routinely version code and schemas while treating meaning as if it were timeless. In reality, the interpretation of a field, status, metric, population, or Data Object changes through policy, organisational practice, scientific knowledge, and regulatory context. This essay argues that semantic versioning must extend beyond interface syntax to the meaning of data itself. It distinguishes data, schema, transformation, vocabulary, metric, and policy versions; proposes formal models for validity intervals and semantic compatibility; and examines historical restatement. The essay also considers the philosophical problem of conceptual change: when a category evolves, are old and new records instances of one concept or different concepts sharing a name? A mature Data Platform should not merely preserve values. It should preserve the interpretive regime under which values became claims.

7 minute read·July 2026·Davide Scuteri Moretti

semantic versioningconceptual changemetric definitionsvocabulariesbitemporalityhistorical restatementdata governance

Themes

— Semantics
— Governance

Abstract

1. The unversioned semantic layer

A pipeline may record Git commit, container digest, schema version, and execution timestamp, yet remain unable to explain why a metric changed. The missing dependency is often semantic: the definition of “active,” “completed,” “eligible,” “valid,” or “delayed” changed without a corresponding technical interface change.

Let a published value be

y = F (X; v_{c}, v_{s}, v_{r}, v_{m}, v_{p}),

where $v_{c}$ is code version, $v_{s}$ schema version, $v_{r}$ reference-data version, $v_{m}$ meaning or metric version, and $v_{p}$ policy version. Conventional lineage frequently records the first three incompletely and the last two not at all.

Semantic versioning begins from the recognition that definitions are dependencies. A field can retain its name and type while changing population, unit convention, timing rule, inclusion threshold, or institutional purpose. Such a change may be more consequential than adding a column.

2. Layers of version

It is useful to separate several version axes:

V = (V_{d}, V_{s}, V_{t}, V_{r}, V_{o}, V_{m}, V_{g}),

where $V_{d}$ is data snapshot, $V_{s}$ physical schema, $V_{t}$ transformation, $V_{r}$ reference vocabulary, $V_{o}$ Data Object contract, $V_{m}$ metric or derived meaning, and $V_{g}$ governance policy.

These axes evolve at different rates. A source schema may be stable while the code dictionary changes monthly. A Data Object may remain stable while a metric revises its exclusion rules. A policy may restrict a previously permitted use without changing data at all.

The platform should therefore avoid a single monolithic version number that conceals causality. Composite version identifiers can be generated for publication, but the components must remain queryable. When an output changes, engineers should be able to compute which version dimension moved.

3. Semantic objects and intensions

A concept can be represented extensionally by the set of things currently classified under it, or intensionally by the rule that determines membership. Let concept $K_{v}$ have intension $ϕ_{v}$ and extension

E x t (K_{v}) = {x ∣ ϕ_{v} (x) = 1} .

When $ϕ_{v}$ changes, the extension may change even if the underlying records do not. A revised “active customer” definition can alter historical counts without any new customer event.

Semantic versioning must preserve $ϕ_{v}$ , not merely the resulting extension. Otherwise historical numbers can be stored but not regenerated or defended.

The philosophical difficulty is whether $K_{v + 1}$ remains the same concept. A minor threshold correction may be a refinement; a shift from contractual status to behavioural engagement may constitute a new concept under an inherited label. Versioning should not become a device for pretending continuity where conceptual rupture occurred.

4. Compatibility of meanings

Software semantic versioning distinguishes breaking and non-breaking changes. Meaning requires a more contextual model. Let $K_{1}$ and $K_{2}$ be two concept versions. We may define extensional relations:

E x t (K_{2}) \subseteq E x t (K_{1}),

for narrowing, or the reverse for widening. But equal extensions over current data do not prove semantic equivalence; future records may expose the difference.

For consumer $u$ with assumption set $A_{u}$ , semantic compatibility holds when

ϕ_{2} ⊨ A_{u}

for all relevant inputs. A reporting consumer may tolerate a vocabulary enrichment that preserves aggregate membership. A clinical or financial control may require exact continuity of threshold and timing semantics.

Changes can be classified as lexical, structural, extensional, intensional, procedural, or normative. Lexical changes rename without altering meaning. Structural changes reorganise representation. Extensional changes alter membership. Intensional changes alter the defining rule. Procedural changes alter how evidence is obtained. Normative changes alter what uses or consequences are permitted.

This classification provides more useful release notes than “schema compatible.”

5. Valid time, system time, and version time

A definition has at least two temporal dimensions: when it is valid for the represented domain and when the platform knows or adopts it. Let

K_{v} = ¿

A rule may become operational on 1 January but be loaded into the platform on 5 January. A correction may later declare that the rule should have applied from the first date. Bitemporal storage enables reconstruction of both domain validity and institutional knowledge.

Version time adds another dimension when artefacts are developed, approved, and deployed separately. The platform may preserve draft, approved, effective, deprecated, and retired states. A definition is not simply present or absent; it has a lifecycle.

Temporal discipline prevents anachronism. Historical decisions should be evaluated under the definitions and knowledge available when they were made, while retrospective analyses may deliberately apply current definitions. Both are legitimate if labelled.

6. Restatement and the multiplicity of history

When a semantic rule changes, an organisation must choose whether to preserve historical outputs, restate them, or publish both. Let historical metric series under version $v$ be

M_{v} (t) = F_{v} (X_{\leq t}) .

A new version produces $M_{v + 1} (t)$ . Replacing the old series hides definitional change. Preserving only the old series impedes comparability under current rules. A mature platform supports a relation

Δ_{v} (t) = M_{v + 1} (t) - M_{v} (t)

and records the reason for material differences.

Restatement policy should specify whether historical publications are immutable, whether revised values supersede them, and how consumer interfaces expose version. In financial, scientific, and regulated contexts, the distinction between “as originally reported” and “restated” is essential.

The platform should not insist on one eternal history. It should preserve the genealogy of legitimate histories.

7. Vocabulary versions and semantic drift

Reference vocabularies, code sets, ontologies, and master data are semantic infrastructure. Codes are added, retired, split, merged, and reclassified. A mapping from local code $l$ to standard code $s$ is therefore versioned:

m_{v} : l \mapsto s .

If the mapping changes, derived historical data may change even when local records remain constant. The platform should retain local code, mapping version, confidence, and mapping method. Replacing local values with current standard codes destroys the evidence needed to reinterpret history.

Semantic drift can occur without formal vocabulary release. Operational teams may begin using an existing status differently. Distribution monitoring and domain review are required because technical version registries cannot detect changes in human practice.

Meaning is partly encoded and partly enacted. Versioning must attend to both.

8. Governance of semantic change

A semantic change proposal should include rationale, affected concepts, old and new intensions, expected extension difference, consumer impact, validity dates, owner, and migration policy. Automated analysis can estimate affected records and downstream products:

I m p a c t (v \to v + 1) = {d ∣ dd e p e n d so n K_{v}} .

Approval should be proportional to consequence. A spelling correction differs from changing an eligibility population. Domain stewards, engineers, risk owners, and consumers may each hold part of the decision authority.

Semantic tests can complement schema tests. Golden examples encode cases expected to remain included, excluded, or disputed. Metamorphic tests express invariants, such as monotonicity under specified input changes. Distribution comparison reveals unexpected population movement.

Governance is strongest when change is both deliberated and executable.

9. Culture, language, and conceptual humility

Data programmes often seek a “single language” for the organisation. Shared language is valuable, but the phrase can conceal domination by the vocabulary of the most powerful system or department. Different domains may distinguish phenomena differently because their work requires different distinctions.

Semantic versioning offers an alternative to forced timeless uniformity. It allows concepts to be negotiated, compared, and revised while preserving translation paths. The platform can support local terms, canonical concepts, and mappings without claiming that one vocabulary exhausts reality.

This is conceptual humility in engineering form. Categories are necessary, but revisable. Definitions should be stable enough for computation and open enough for correction. Versioning institutionalises that balance.

Conclusion

A value cannot be interpreted independently of the semantic regime that produced it. Versioning only code and schema leaves the most consequential dependency invisible: the evolving definitions through which records become categories, measures, and decisions.

Semantic versioning decomposes change across data, schema, transformations, references, Data Objects, metrics, and policies. It preserves validity intervals, compatibility assumptions, restatement choices, and the genealogy of concepts. It also recognises that a stable name may conceal a new meaning and that equal outputs may arise under different rules.

A mature Data Platform therefore versions not only representations, but interpretations. It can answer: which definition was used, when was it valid, who approved it, what changed, which products were affected, and whether history was restated. The result is not semantic rigidity. It is disciplined conceptual change.

Conceptual references

Kuhn, T. S. The Structure of Scientific Revolutions (1962). Koselleck, R. Futures Past (1979). Bowker, G. C., and Star, S. L. Sorting Things Out (1999). Ogden, C. K., and Richards, I. A. The Meaning of Meaning (1923). Guarino, N., Oberle, D., and Staab, S. “What Is an Ontology?” (2009).

In this series