Dimensional data, established from first principles.

I. The class of data this primer is about.

Some data measures and some data describes. The data that measures supports arithmetic: revenue can be summed, latency averaged, headcount ranked. The data that describes does none of these things. Country, vendor, customer segment, support ticket type, these values classify and segment, and they do their work through the identity of the label rather than the magnitude of a number.

The descriptive class has a name. The convention in data warehousing is to call these values dimensions, and to call the data they constitute dimensional data. Other vocabularies exist, “categorical data,” “reference data,” “controlled vocabulary”, and each carries a slightly different emphasis, but all refer to the same underlying class of values. This primer uses dimensions throughout.

The class deserves its own treatment because dimensions behave differently from numbers under nearly every operation that matters in analysis. Numbers add. Dimensions do not. Numbers can be averaged or ranked or differentiated. Dimensions can only be grouped, filtered, or joined. The shapes of failure that affect dimensions are also different: a number can be wrong by a definite amount, whereas a dimension can be wrong by being incompatible with another dimension that means the same thing, which is a category of wrongness that arithmetic does not have a vocabulary for.

II. Without standards, dimensions become unruly.

Imagine a customer table in which the industry of each account is recorded by the sales rep who created the account. The field is a free-text input. The rep types whatever they think is most descriptive. Multiply by a few thousand reps over a few years, and the field accumulates forty-seven distinct strings that, on inspection, refer to roughly ten real industries.

The accumulation is not a fault of any single rep. Each rep made a defensible local choice. The aggregate, taken together, is the predictable consequence of having a free-text field where a dropdown should be, and a dropdown that lags reality by two years where a managed reference should be. The pattern repeats in every operational system: the CRM's industry field, the ERP's supplier category, the ticketing platform's issue type, the marketing platform's campaign tag. Whichever field is asked to bear dimensional information without infrastructure to support that work will degrade.

With standards in place, the picture is different. Standards in this sense are not a wiki page; they are a live reference the operational systems can read from. A managed reference of accepted industry values, with definitions and aliases, exposed through an API the CRM can validate against. When a rep starts typing an industry that does not match the reference, the system either resolves it to a known canonical (because “Fin Svcs” is a recognised alias for “Financial Services”) or opens an intake request for a steward to review. The discipline this primer describes is the practice of building and operating such references.

III. The five forms of variance.

Dimensional inconsistency takes five common forms. Each is produced by a different mechanism and resolves with a different intervention.

• Surface variance. The same concept, recorded with different formatting: casing, punctuation, spacing, abbreviation. Mechanical to detect, mechanical to resolve. The form most associated with dimensional inconsistency in the general imagination, and the smallest part of the actual problem.
• Semantic variance. Different strings for the same concept where the equivalence cannot be inferred from the strings alone. “Laptop” and “Notebook”. “Freelancer” and “Independent Contractor”. Resolution requires picking a canonical and mapping the others to it. The pick is not deterministic; it requires organisational agreement.
• Definitional variance. The same label, used for different things in different parts of the organisation. The most dangerous form, because the inconsistency produces no visible artefact in the data. Reports run without error. The conclusions drawn are nevertheless built on incompatible underlying populations.
• Granularity variance. The same concept, recorded at different levels of a hierarchy. The CRM has “Financial Services” where the warehouse has “Retail Banking.” Each value is correct at its level; the levels do not aggregate without an explicit hierarchy mapping.
• Temporal variance. The canonical form changes over time. A product is renamed. A department is restructured. New records use the new label; old records keep the old label. Longitudinal queries silently drop one side or the other.

These five are the practical core. The full catalogue , the four-layer taxonomy , extends the list to eight forms and locates each within the broader chain of process, organisational, and downstream consequences. A practitioner working in the field can usually identify which form is dominant in a given dimension within a few minutes of looking at the data.

IV. How the variance accumulates.

The text field that absorbs whatever the rep types is the first source of variance, but it is not the only one. The same dimensional value passes through pipelines on its way from the operational system to the warehouse, through APIs between systems that may or may not agree on the vocabulary, through manual exports into spreadsheets that introduce a fresh round of degradation at every iteration.

The volume produced by humans is bounded by typing speed. Three years of free-text entry produces a few thousand variants. A quarterly cleanup project can absorb a few thousand variants. This is why reactive cleanup, taken cycle by cycle, has been a workable response to the problem for the last thirty years.

The bound is changing. Agents, software acting on behalf of users to classify, categorise, and tag, produce dimensional values at machine speed. A field that previously accumulated dozens of new values per week accumulates thousands. The character of the variance also shifts: agents do not typo, do not improvise, do not get tired on Friday. They reproduce, faithfully and at scale, whichever convention they were configured with. Surface variance shrinks as a share of the problem; configuration variance, two agents configured with two different conventions, each internally consistent and structurally incompatible with the other, grows to dominate. The reactive cleanup model assumes a human-bounded volume that no longer holds.

V. What it costs.

The cost of dimensional inconsistency is paid by consumers of the data, not producers. The analyst writes the CASE WHEN statements that reconcile vendor names across systems. The data scientist trains a model whose predictive feature is degraded by forty-seven label variants of ten real industries. The finance team produces a board deck whose vendor-spend total depends on which spelling of each supplier survived the consolidation heuristics. The rep who created the variants experiences no consequence.

The visible costs, analyst time, hidden spend, regulatory exposure, get measured. They are not the largest costs. The larger costs are downstream and invisible: wrong reports informing wrong decisions, blocked analyses that never get attempted, models attributed to algorithmic weakness when the actual lever is the dimensional surface they trained on, trust in the data function eroding faster than it recovers.

The full catalogue of downstream consequences, nine specific categories of business harm with the mechanisms that produce each, is in Layer 4 of the problem taxonomy.

VI. Why the problem stays unsolved.

The dimensional data problem is widely recognised inside the organisations that suffer from it. The retros mention it. The post-mortems point at it. The conversation never resolves into action, because four conditions reinforce each other.

Dimensions are owned by no one. The vendor field is touched by procurement, finance, accounts payable, the data team, and at least one external integrator; the question of who should fix it cycles through these teams without resolution because no one has the authority to decide who decides. The existing data management disciplines, MDM, DQ, catalog, governance, each address some adjacent layer and none addresses the categorical surface specifically. The harm is invisible: inconsistency does not throw an error, surfaces weeks or months later in a meeting where two leaders look at two dashboards, and gets attributed to “we need to reconcile our reporting” rather than to the dimensional layer. And the work is unglamorous: standardising vendor names builds nobody's career, produces no new capability, and the consequence of doing it well is the absence of a category of failure that nobody else can see.

These conditions are not character flaws. They are structural. What changes them is the recognition that dimension management is a discipline in its own right, requiring its own ownership, governance, metrics, and funding. That recognition is what the manifesto argues for and what the target state specifies.

VII. What well-managed dimensional data looks like.

A practitioner asking what good looks like will recognise five elements that work together. None of them works on its own.

• A canonical reference. For each dimension that matters, a single source of truth: the accepted values, their definitions, ownership, version history, and aliases. The reference is system-agnostic; it does not live inside any single warehouse or catalog or MDM platform; it is its own surface, exposed via API to every consumer that needs it.
• Named ownership. Each dimension has a steward. One person, not a committee. Decision rights for additions, definitional changes, deprecations, and contested cases. Stewardship is typically part-time and layered onto an existing role.
• An intake process. New values do not appear in the canonical reference by accident. They are proposed (automatically by the system observing a new variant, or manually by anyone in the organisation), reviewed, and accepted or rejected according to a documented process. Every change leaves a record.
• Operational propagation. The canonical reference is readable by every system that produces or consumes the dimension. Operational systems validate against it. Pipelines map to it. Agents read it through synchronised local caches. A reference that lives in a wiki and is not read by any system is decorative.
• Versioning. The canonical reference changes over time. Records written under version N remain interpretable under version N+1. Historical analysis can reconstruct what a value meant at the time it was written, not only what it means now.

These elements are described as observations of what works in practice, not as recommendations. The full specification , including the operating model, the propagation architecture, the five metrics by which the system is measured, and the maturity path organisations follow, is in the target state.

VIII. How to keep reading.

This primer is one of three foundational essays. The manifesto argues that dimension management is a category in its own right and that the cost of leaving it unmanaged is rising. The target state specifies what well-managed dimensional data looks like in operational detail. The four-layer taxonomy catalogues the specific failure modes by layer and is the reference companion this primer points back to throughout.

For practitioners who learn best by working through a structured curriculum, the Foundations module covers the same material at greater length, with more worked examples. For the reader who wants to test the framing against their own organisation, the Trace the Chain diagnostic walks from a symptom to a root cause interactively.