Shared meaning

Executive thesis

As of 2026-08-23, no mature vendor-neutral specification guarantees that a metric expressed once will retain identical meaning and numerical behavior across Power BI/DAX, SQL metric engines, notebooks, BI tools and AI agents.

Dataheart should therefore own a vendor-neutral semantic control plane, not adopt one vendor’s “universal semantic layer” as its foundation. That control plane should contain customer-owned concept identities, metric contracts, versions, policy references, provenance and conformance tests, then compile or project a bounded portable subset into:

• A Microsoft-native profile: Purview concepts, Fabric/Power BI semantic models, TMDL, DAX and native authorization.
• A self-hosted/open profile: open registry formats, SKOS/SHACL/PROV projections, an open metric compiler/runtime, and self-hosted catalog and BI components.

“Same metric everywhere” must be treated as a tested property:

result = evaluate(metric-version, query-scope, principal/policy-version, source-snapshot, engine-version)

A shared name or YAML document is insufficient. Cross-tool equality requires either one shared execution service or differential conformance tests between runtimes.

Classification used below:

• Established: deployed practice or finalized standard.
• Emerging: working implementations, but incomplete interoperability or governance.
• Hypothesis: plausible Dataheart design that still needs validation.
• Vendor claim: first-party assertion without independent proof of general portability.

State of the art 2024–2026

Established practice

• Organizations increasingly manage semantic models and measures as source-controlled code, with review, certification and reusable “thin” reports. Microsoft’s TMDL gives textual coverage of the Tabular Object Model, including DAX, M, roles and relationships, and PBIP exposes it to source control. This is strong native lifecycle management, but TMDL explicitly models TOM and embeds DAX/M; it is not a neutral analytical semantics standard. Microsoft TMDL documentation
• Metric compilers model entities, dimensions, default time axes, metric-owned filters and query filters separately. Current MetricFlow documentation makes the important point that a metric is evaluated over a scope and compiles that scope to target SQL. MetricFlow metric semantics
• Business terminology and executable analytical semantics remain separate disciplines. ISO/IEC 11179 covers identification, definitions, classification, mappings, concepts, value domains, units and derivation rules. SKOS supplies labels, broader/narrower relations and explicitly qualified cross-scheme mappings. Neither defines analytical query behavior.
• W3C DCAT 3 added stronger catalog versioning, while PROV-O supplies portable derivation and responsibility concepts. These are useful for metric-definition and result provenance, but not calculation execution.
• The EU Data Act has applied since 12 September 2025. Article 33 requires relevant data-space participants to describe content, restrictions, quality and uncertainty in machine-readable form, and to publish data structures, vocabularies, classification schemes, taxonomies and code lists consistently. This supports Dataheart’s semantic-contract direction, but does not prescribe a metrics language. EU Data Act, Articles 33 and 50

Emerging practice

• Headless metric services: Semantic definitions are increasingly served to BI, notebooks, APIs and agents through a shared compiler or service rather than duplicated inside each visualization tool.
• Open semantic interchange: Apache Ossie, formerly Open Semantic Interchange, has a released 0.1.1 model and a mutable 0.2.0.dev0 draft covering datasets, fields, relationships, metrics, multiple expression dialects, AI context and vendor extensions. Its Apache incubation proposal nevertheless lists a formal metrics language, semantic query standard and reference query engines as future work. It is therefore an important interchange candidate, not yet proof of lossless execution portability. Ossie core specification, Apache incubation proposal
• Semantic consumers in open BI: Apache Superset can expose external semantic layers such as dbt or Cube, but the integration is explicitly experimental as of August 2026. Its internal semantic layer remains deliberately thin. Apache Superset documentation
• Agent-facing metadata: Specifications and products now add synonyms, examples and natural-language instructions. These improve discovery, but are untrusted context—not executable truth—and introduce semantic prompt-injection risk.
• RDF/SHACL evolution: SHACL 1.2 was still a Working Draft in May 2026; production portability should remain grounded in the 2017 Recommendation subset. The SHACL specifications themselves warn that SPARQL extensions can behave inconsistently between processors. SHACL 1.2 Core

Hypotheses and vendor claims

• Hypothesis: A carefully bounded portable metric core can compile to both DAX/TMDL and SQL/MetricFlow with high fidelity.
• Likely false in the general case: Arbitrary DAX calculation groups, filter context, virtual relationships, SQL dialect features, window semantics and vendor extensions can be translated losslessly.
• Vendor claim: “Define once; get the same number everywhere.”
• Counter-evidence: Power BI results depend on filter context, relationship direction, path priority, storage/source groups and DAX functions such as USERELATIONSHIP and CROSSFILTER. Ossie currently permits dialect-specific expressions and arbitrary vendor extensions and has not finalized a common semantic query language. Power BI relationship semantics

Load-bearing concepts

1. Concept, measure and metric are different objects

• A concept identifies business meaning: customer, booked revenue, active account.
• A measure is an aggregation primitive or calculation.
• A metric contract is a governed, versioned business interface built from measures and concepts.

A metric contract should minimally carry:

• Stable identifier, version, lifecycle status and supersession link.
• Business definition, purpose, owner/steward and permitted use.
• Entity and grain.
• Aggregation and additivity: additive, semi-additive or non-additive.
• Formula represented as a typed expression where possible.
• Metric-owned filters versus caller-supplied filters.
• Default and allowed time dimensions, time zone, calendar, period boundaries and late-arrival/restatement policy.
• Units, currency conversion policy, scale, rounding and output type.
• Null, missing-entity, duplicate and referential-integrity behavior.
• Allowed dimensions and join paths.
• Source lineage, definition provenance and evidence requirements.
• Security classification and references to authorization policy—not copied ACLs.
• Examples, invalid uses, test vectors and expected results.
• Target-profile capability and known-loss declarations.

ISO/IEC 11179-31 is especially relevant because it explicitly covers data element concepts, value domains, units and derivation rules. ISO/IEC 11179-31:2023

2. A glossary is not a semantic runtime

Use SKOS-like concept schemes for terminology, multilingual labels and qualified mappings. Avoid turning every similar term into an exactMatch: two customer definitions may be close for discovery but incompatible for billing or regulatory reporting. SKOS itself distinguishes closeMatch from transitive exactMatch and says mapping does not replace provenance management. W3C SKOS

Use OWL only where formal inference creates concrete value. Use SHACL or an equivalent schema validator for closed-world manifest validation. Do not put heavyweight ontology reasoning in the analytical query hot path.

3. Semantic identity must survive renaming and relocation

Names, labels and physical columns change. Metric and concept identity should use opaque, durable IDs. Human names become versioned labels. A move between domains, catalogs or storage systems must not silently change identity.

4. Definition version and evaluation evidence are separate

A result needs more than a lineage link to the current metric definition. Its receipt should include:

• Metric and semantic-model version.
• Query specification and normalized filter scope.
• Authorized principal/tenant/purpose context or a privacy-preserving reference.
• Policy version and enforcement points.
• Source snapshots or watermarks.
• Compiler, adapter and runtime versions.
• Generated plan hash.
• Approximation/tolerance information.
• Execution time, freshness and warnings.

PROV-O provides reusable derivation vocabulary; DCAT 3 provides catalog and version relations. Neither replaces the domain-specific receipt. PROV-O, DCAT 3

5. Portability needs a capability model

Each target profile should declare whether it supports, for example:

• Composite keys and specified join paths.
• Semi-additive measures and snapshots.
• Arbitrary window frames.
• Fiscal calendars.
• Calculation groups or metric transformations.
• Many-to-many relationships.
• Distinct and approximate distinct counts.
• Row-, column- and object-level policy propagation.
• Multiple currencies and dynamic formatting.
• User-defined functions.
• Query-time and metric-owned filters.

Unsupported constructs must fail compilation or produce an explicit loss report. Silent approximation is unacceptable for certified metrics.

Reference patterns

Pattern A: customer-owned canonical registry

Store the authoritative semantic contract in a customer-controlled repository and registry. JSON/YAML can be the authoring form, with a JSON-LD/RDF projection for interoperability. Validate structural constraints with JSON Schema and graph constraints with a conservative SHACL subset.

The canonical schema should borrow rather than clone:

• ISO/IEC 11179 concepts for identification, definition, registration and mapping.
• SKOS for terminology and concept-scheme alignment.
• DCAT for discovery and version relationships.
• PROV for derivation and responsibility.
• Ossie as an emerging import/export profile, not yet the sole canonical representation.

Pattern B: shared execution plane

All surfaces call one semantic query service, which authorizes, plans, executes and emits a result receipt.

Advantages:

• Strongest numerical and policy consistency.
• One cache and one evidence mechanism.
• Easier action gating.

Costs and limitations:

• New critical availability and latency dependency.
• Central compute and cache cost.
• Cache keys must include tenant, principal/policy, metric version and source snapshot.
• It can become an organizational bottleneck if domain teams cannot publish independently.

Pattern C: compiled native projections

Compile the same portable contract into native targets:

• Microsoft: TMDL, DAX measures, relationships, roles and calculation objects.
• Open: MetricFlow-style manifests and SQL plans, plus catalog and BI projections.

Advantages:

• Native performance, UX and ecosystem integrations.
• Can operate without a central Dataheart query service.

Costs:

• Adapter development and regression surface.
• Runtime-specific semantics inevitably escape the portable core.
• Authorization, caching and lineage can drift between targets.

Pattern D: hybrid certification tiers

Recommended:

1. Portable certified core: executable in both profiles and covered by differential tests.
2. Profile-specific certified extension: governed and tested, but explicitly tied to DAX or an open SQL runtime.
3. Local exploratory calculation: visible but not certified and ineligible for automated action.

This preserves useful native features without misrepresenting them as portable.

Failure modes and counter-evidence

Failure	Consequence	Control
Common YAML mistaken for common semantics	Different values across tools	Differential execution tests and explicit target capabilities
Join cardinality or path is wrong	Fanout and double counting	Required entity grain, key constraints and adversarial duplicate tests
DAX context translated as ordinary SQL	Silent numerical change	Restrict portable expression subset; reject unsupported context behavior
Time policy omitted	DST, fiscal-period and late-event disagreement	Versioned calendar, time zone, boundaries and restatement policy
Local dashboard calculation bypasses contract	Semantic drift	Certification tiers and visible provenance/status
Definition edited in place	Historical result cannot be reproduced	Immutable versions and result receipts
Glossary exactMatch is overused	False equivalence between domains	Directional/qualified mappings with steward and evidence
Raw SQL, templates or AI instructions accepted as trusted semantics	Injection or privilege escalation	Typed ASTs, signed manifests, sandboxed compilers and untrusted-text handling
Cache omits identity or policy	Cross-tenant disclosure	Security-context-aware cache keys and negative tests
Metadata is treated as harmless	Formulas, columns or classifications leak	Separate metadata authorization and redacted discovery views
BI permission is assumed equivalent to data security	Sensitive data becomes queryable	Policy tests at every surface; Power BI itself warns that Read is not a sensitive-data boundary and Write bypasses RLS
Central semantic service becomes monolithic	Slow delivery and outages	Federated domain ownership, central contract rules and isolated publication
Open stack assembled from experimental adapters	Upgrade and on-call burden	Pin versions, conformance-test upgrades, and retain replaceable component boundaries

Microsoft’s permission model is particularly load-bearing: Build permits XMLA access and visibility of hidden fields; Read alone should not be relied on to secure sensitive data; and users with Write permission can read despite RLS membership. Power BI semantic model permissions

Lock-in risk differs rather than disappears:

• Microsoft profile: TMDL is excellent text-based lifecycle tooling, but its semantics are TOM/DAX/M. Fabric/Purview capacity, licensing and workspace behavior remain operational dependencies.
• Open profile: source and runtime are controllable, but the customer must operate the registry, compiler, cache, adapters, BI service and upgrades. MetricFlow or another engine can itself become a semantic dialect.
• Ossie: Apache governance lowers single-vendor ownership risk, but 0.2.0.dev0, multiple dialect expressions and free-form vendor extensions still permit practical lock-in.
• Standards stack: RDF/SKOS/SHACL/PROV improves metadata portability but does not give Dataheart a production metric runtime for free.

Implications for Dataheart

Vendor-neutral invariants versus profile choices

Invariant owned by Dataheart/customer	Microsoft-native choice	Self-hosted/open choice
Stable concept and metric IDs, versions and lifecycle	Purview concepts plus Dataheart IDs	Customer registry with SKOS/ISO-aligned model
Complete metric contract	Canonical contract compiled to TMDL/DAX	Canonical contract compiled to open metric manifest/SQL
Entity grain and join constraints	Tabular relationships and DAX semantics	Metric compiler entity graph and SQL joins
One policy identity and evidence chain	Power BI/Fabric permissions and RLS/OLS adapters	External policy enforcement plus database/runtime controls
Machine-verifiable source lineage	Fabric/Purview lineage projection	PROV projection and self-hosted lineage store
Capability and loss manifest	TOM/DAX capability profile	SQL/runtime capability profile
Conformance suite	DAX/XMLA evaluation	Open compiler/runtime evaluation
Immutable result receipt	Fabric execution evidence adapter	Open execution evidence adapter
Customer ownership and export	PBIP/TMDL export plus canonical source	Git/registry export plus canonical source

Microsoft Purview’s Enterprise Glossary remained explicitly in preview, so Dataheart should not make its internal object model the only authoritative concept store. It can be a native projection and stewardship surface. Purview Enterprise Glossary

Recommended architectural stance

• Make the Dataheart semantic contract the source of truth; TMDL, MetricFlow and Ossie are adapters.
• Define a deliberately small portable metric algebra first: typed arithmetic, explicit aggregations, filters, grain, joins, time buckets and units.
• Allow target-specific extensions only under named profiles.
• Generate a machine-readable loss/capability report with every build.
• Carry policy references and evidence fields through the same intermediate representation as the calculation.
• Require an evidence receipt before a metric can trigger a recommendation or action.
• Treat descriptions, examples, synonyms and agent instructions as untrusted annotations.
• Let customer domains own their schemes and metrics; central governance owns identity, compatibility, certification and mapping rules.
• Have forward-deployed engineers contribute through customer-visible changesets containing migration impact, test additions and profile loss reports. Avoid hidden customer-specific DAX or SQL that exists outside the contract.

Connections to other domains

• Compiler design: The canonical contract is an intermediate representation; DAX and SQL are target languages. Unsupported behavior should be a compile error, not an implicit cast.
• Type systems and metrology: Grain, unit, currency, calendar and additivity are semantic types. “Revenue + headcount” should be invalid before execution.
• API governance: A certified metric is an API. It needs compatibility rules, deprecation, consumers, service levels and contract tests.
• Financial reporting: Restatement and effective-date policy matter as much as the formula. Reproducibility requires immutable definition and source versions.
• Zero trust: Semantic metadata is both sensitive information and executable input. Authorization must cover discovery, compilation, execution and result access.
• Software supply chain: Signed semantic artifacts, compiler versions and plan hashes form a semantic equivalent of an SBOM and build attestation.
• Safety engineering: A wrong dashboard value is inconvenient; the same value driving an action is a control-system fault. Action-eligible metrics need tighter determinism, freshness and approval thresholds.
• Linguistics and knowledge representation: Shared meaning is frequently mapping between contextual vocabularies, not enforcing one global word list.

Recommended experiments and conformance tests

1. Portable-core spike

   Model 12 representative metrics: simple sum, distinct count, ratio, cumulative, semi-additive snapshot, currency conversion, fiscal period, slowly changing dimension, many-to-many allocation and late-arrival restatement. Compile them to both profiles.

   Pass condition: zero silent feature loss; every nonportable construct is rejected or explicitly profiled.

2. Round-trip test

   Canonical → TMDL/Ossie/open manifest → canonical.

   Pass condition: stable IDs and all required semantics survive; target-specific extensions return unchanged or appear in a loss report.

3. Differential execution suite

   Run identical query specifications against golden datasets in DAX and the open runtime.

   Cover nulls, duplicates, missing dimension members, filter order, decimal rounding, empty groups and join fanout.

   Pass condition: exact equality for exact metrics; declared tolerances only for explicitly approximate metrics.

4. Temporal conformance

   Test Stockholm DST changes, UTC boundaries, ISO versus fiscal weeks, leap days, month-end snapshots, late events and historical restatement.

5. Cardinality mutation testing

   Inject duplicate “one-side” keys, orphan foreign keys and ambiguous join paths. The system should fail validation or produce an expected, documented result—not silently change totals.

6. Authorization parity

   Test multiple tenants and roles across BI, API, notebook and agent surfaces. Include metadata visibility, hidden fields, cache segregation, RLS/OLS, exports and Write-level bypass scenarios.

   Pass condition: no unauthorized metadata or value disclosure and identical policy decision IDs in result receipts.

7. Semantic injection tests

   Put hostile instructions in descriptions, synonyms, examples and vendor-extension fields. Verify that agents cannot convert annotations into filters, SQL, policies or actions without typed validation.

8. Version-compatibility test

   Change formula, time axis, currency policy, allowed dimensions and join path independently. Verify that the breaking-change detector distinguishes label-only changes from result-affecting changes.

9. Evidence replay

   Given a stored result receipt, reconstruct its definition, policy, source snapshot and plan. Action-triggering results should be replayable or explicitly marked non-replayable.

10. Operational and cost benchmark

    Compare central execution with compiled-native projections for latency, warehouse compute, cache efficiency, deployment duration, adapter maintenance and incident recovery. Include upgrade testing for experimental open integrations.

Sources

1. EU Data Act, Regulation (EU) 2023/2854 — 22 December 2023; applicable from 12 September 2025.
2. ISO/IEC 11179-3:2023, metadata registry common facilities — 16 January 2023; Amendment 1 published 2026.
3. ISO/IEC 11179-31:2023, data specification registration — 16 January 2023.
4. W3C SKOS Reference — Recommendation, 18 August 2009.
5. W3C SHACL 1.2 Core — Working Draft, 16 May 2026; latest stable Recommendation remains 20 July 2017.
6. W3C DCAT Version 3 — Recommendation, 22 August 2024.
7. W3C PROV-O — Recommendation, 30 April 2013.
8. Apache Ossie core metadata specification — 0.2.0.dev0, accessed 23 August 2026; initial 0.1.1 release 11 December 2025.
9. Apache Ossie Incubator proposal — updated 16 June 2026.
10. MetricFlow metric semantics — living primary documentation, accessed 23 August 2026.
11. Microsoft TMDL view and PBIP — updated 9 July 2026.
12. Microsoft TMDL language overview — updated 5 August 2024.
13. Power BI relationship semantics — updated 5 September 2025.
14. Power BI semantic model permissions — updated 28 October 2025.
15. Apache Superset semantic-layer integration — updated 22 August 2026.