Pin the mapping in the data layer; never configure it chart by chart

What it is

A versioned semantic mapping registry centralizes stable entity keys, encoding roles, colours or symbols, default order, theme scope, and version so charts consume one contract. “Data layer” in the title means a mapping layer adjacent to data semantics and independent of per-chart styling, not RGB embedded in raw fact tables. “Never configure chart by chart” rejects manual copying as governance; a documented, validated local override remains possible.

Why it happens

Per-chart configuration scatters one decision across chart specifications, themes, and export scripts, inviting every author or tool to regenerate it. A registry resolves stable IDs rather than translated display names and separates identity, status, magnitude, and highlight roles so one value is not assigned conflicting meanings. Version, scope, and deterministic fallback make new categories and replay of old charts traceable. If each client gives an unknown value “the next colour,” loading order and filtering produce drift.

Studying it

Audit mapping lineage from entity key through registry version, theme token, chart specification, and final pixels. Count one key with several encodings, several keys with one encoding, unknown categories, and undeclared overrides. Compare centralized and per-chart workflows on production time, defects, migration cost, and cross-chart correspondence. Qu and Hullman expressed multi-view consistency as checkable scale-pair constraints with validations and exceptions, supporting automated review rather than blind enforcement.

Where it stops holding

Exploratory sketches, one-off analysis, and third-party embeds may not initially use the registry, but publication still needs a declared scope and conflict check. Analytical highlight is runtime state: it may override emphasis without rewriting identity. Brands, tenants, themes, and cultural contexts may require distinct accessible palettes; model them as explicit variants instead of hidden chart forks. Quantitative scales usually derive from field definition and view domain and should not be frozen as categorical lookup tables.

Applying it

• Define stable_id + semantic_role + scope + theme + version → encoding; never key identity by display name, translated text, or row order.
• Let chart specifications declare field and role and use a shared resolver. Give unknown, deleted, and conflicting values deterministic fallbacks plus telemetry or build warnings.
• Require overrides to state reason, scope, owner, and expiry or migration condition. Save mapping versions with exports, caches, and historical reports for replay.
• Combine contract tests, rendered snapshots, and cross-chart sampling with theme, colour-vision, greyscale, and assistive-technology checks.

Related

• Same group: U1.11.1 The same entity keeps the same colour and position across a chart series · U1.11.2 Encoding that jumps between charts forces readers to relearn the legend · U1.11.3 Only charts sharing a scale can be compared on magnitude · U1.11.5 Extend category sets by appending, never by reassigning
• Adjacent: U1.08.4 Determine the data type before choosing the chart type · U1.10.5 Redundant channels that disagree semantically give contradictory cues
• Search terms: semantic mapping registry · stable entity ID · mapping lineage