Semantic Data Unification Architecture - Enterprise Blueprint

Updated October 2026

A semantic data unification architecture is a stack of seven layers that turns scattered source records into shared business entities, relationships, and metrics. Data lands once, entity resolution links records that describe the same thing, and an ontology or semantic layer gives them meaning. Every dashboard, app, and AI agent then reads one governed model.

What does a semantic data unification architecture look like?

It looks like a layered pipeline of meaning, not just a pipeline of data. Physical data moves only in the bottom two layers. The upper layers add identity, definitions, and relationships, so that "customer" means the same thing in finance, sales, and support.

This article covers the architecture itself, meaning the layers, the flows between them, the patterns, and who owns what. For the definition, the business case, and a vendor comparison, read the semantic data unification guide and vendor evaluation.

The stakes are concrete. Gartner predicts organizations will abandon 60 percent of AI projects unsupported by AI-ready data through 2026 (Gartner). The same survey found about 63 percent of organizations lack or are unsure of the right data management practices for AI.

What are the seven layers, from source to consumer?

The seven layers run from raw sources at the bottom to people and agents at the top, with a governance plane running alongside all of them. Each layer has one job and hands a clear contract to the next. Keeping those contracts explicit is what lets you swap a tool in one layer without rebuilding the rest.

Layer 1. Sources and landing

This layer copies data from operational systems into one analytical store. That store is usually a warehouse or lakehouse such as Snowflake, Databricks, BigQuery, or Postgres. Use change data capture for databases that change often and scheduled syncs for SaaS APIs.

Land data raw and keep source keys untouched. Entity resolution later depends on seeing every original identifier, including the messy ones.

Layer 2. Modeled tables

Modeled tables clean, type, and conform the raw data. Teams usually build them as dbt models or SQL views. This is where you standardize dates, currencies, country codes, and phone formats, which makes matching in the next layer far more accurate.

Do not put business metric logic here. Metrics belong in the semantic layer, where every consumer can reuse them.

Layer 3. Entity resolution

Entity resolution decides which records across systems describe the same real person, company, or product. Senzing defines it as determining when records refer to the same real-world entity, and when they do not (Senzing). The output is a stable entity ID plus a crosswalk from every source key to that ID.

Open-source options exist. Splink is a Python library for probabilistic record linkage that runs on DuckDB, Spark, and other SQL backends (Splink). For techniques, see what entity resolution is and how it works.

Layer 4. Ontology and semantic layer

This layer gives the resolved entities their meaning. An ontology names entity types, their properties, and how they relate. A semantic layer turns that model into governed metrics and dimensions that compile to SQL.

Platform options now exist in every major stack. Snowflake semantic views store logical tables, facts, dimensions, and metrics as database objects (Snowflake). Databricks metric views register metric definitions in Unity Catalog (Databricks). Microsoft Fabric IQ ontology, still in preview, defines entity types, relationships, and data bindings (Microsoft Learn).

For portable definitions, MetricFlow is now Apache 2.0 (dbt Labs). Apache Ossie entered the Apache Incubator in July 2026 as a vendor-neutral format for metrics, dimensions, and business concepts (Apache Ossie). The semantic layer explainer covers this layer in more depth.

Layer 5. Knowledge graph

The knowledge graph is optional. It stores resolved entities as nodes and their relationships as edges, which suits questions that hop across many connections. Supplier risk, fraud rings, and product dependencies are typical examples.

Add it when relationship questions are central or when you want formal reasoning over the ontology. Skip it when your questions are mostly aggregates over a few joins, because the semantic layer already handles those well.

Layer 6. Serving

Serving exposes the model to consumers. People use BI tools and notebooks. Applications call APIs. AI agents increasingly connect through the Model Context Protocol, which Anthropic donated to the Linux Foundation's Agentic AI Foundation in December 2025 (Anthropic).

The rule for this layer is simple. Consumers should ask for entities and metrics by name, never by raw table. That keeps every answer tied to the same definitions.

Layer 7. Governance plane

Governance runs beside every layer rather than on top. It covers lineage from source to metric, access policies, tests, and change control for definitions. For graph data, the W3C SHACL standard validates RDF graphs against declared shapes (W3C).

Treat definitions like code. Store them in version control, review changes in pull requests, and run tests that compare new metric values against agreed reference numbers.

How does data flow through the blueprint?

Two flows run through the architecture. The build flow carries definitions downward into the system, and the query flow carries questions down and answers back up. Mixing them up is a common reason projects stall.

The build flow

1. A domain owner proposes or changes a definition, such as what counts as an active customer.

2. The change lands as code in the ontology or semantic layer repository.

3. Tests check the new definition against reference numbers and graph shapes.

4. A reviewer from the owning domain approves it.

5. The platform deploys it, and lineage records which downstream assets changed.

The query flow

1. A person or agent asks for a metric or entity by name.

2. The semantic layer resolves the name to a definition and checks access.

3. It compiles the request into SQL or a graph query over resolved entities.

4. The warehouse or graph store runs the query.

5. The answer returns with its definition and lineage attached, so the consumer can explain it.

Should you materialize unified data or query it in place?

Materialize what many consumers read often, and federate what you rarely read or cannot copy. Most enterprises end up with a hybrid. The choice is made per entity, not once for the whole stack.

Federated engines such as Trino can join data from several systems in a single query (Trino). That is useful for exploration. It is harder to use for entity resolution, which usually needs all candidate records in one place to compare them.

Which architecture pattern fits your organization?

The right pattern depends on how many platforms you run and how independent your business units are. Four patterns cover most real deployments. Many companies start with one and move toward another as they grow.

Central hub

One team owns one semantic model on one warehouse. It is the fastest way to get consistent numbers. It strains when many domains need changes at once.

Federated domains

Each domain owns its slice of the model, joined by shared core entities such as customer and product. This follows the data mesh idea of federated computational governance, which balances domain autonomy with global standards (Martin Fowler). It scales well but needs firm naming and ID rules.

Platform native

Definitions live inside the warehouse, as semantic views or metric views. Setup is quick and agents on that platform pick them up directly. Keep a portable copy in an open format if you might change platforms.

Graph backed

Resolved entities load into a knowledge graph, and the ontology drives both queries and validation. This pattern suits multi-hop questions and explainable reasoning. For when to choose it, compare RAG, knowledge graphs, and semantic layers.

Who should own each part of the architecture?

Domains should own meaning, and a platform team should own the machinery. That split keeps definitions close to the people who understand them while keeping the infrastructure consistent. Write the ownership down before you build anything.

Ownership has a second meaning too. Your entity model and metric definitions are institutional knowledge, and they are among the most valuable assets a company has. They should live in open formats, in your repository, on infrastructure you control, so they survive any vendor change.

Some teams build this with a partner. Galaxy is an applied lab that builds semantic foundations with teams on the stack they already run, using internal tooling to set up ontologies, semantic layers, and entity resolution quickly. It builds in the open with Filament, its Apache 2.0 data movement engine, and plans to open source more of that tooling.

Why does this architecture matter for AI agents?

Agents need the same shared meaning that people need, but they cannot ask a colleague when a column is ambiguous. Without resolved entities and governed definitions, they guess at joins and filters. The evidence shows that semantics close much of that gap.

A data.world benchmark found GPT-4 answered 16 percent of enterprise questions correctly over raw SQL and 54 percent over a knowledge graph of the same data (arXiv). An April 2026 study gave Claude Opus 4.7, Claude Sonnet 4.6, and GPT-5.4 a short document of business semantics. Accuracy rose 17 to 23 points for all three models (arXiv).

The architectural lesson is to point agents at Layer 6, never at Layer 1. An agent that asks the semantic layer for "net revenue by region" inherits the right joins, filters, and access rules automatically.

How should you sequence the build?

Build one thin slice through every layer before you widen any layer. A narrow slice proves the contracts between layers. A wide first layer usually stalls before anyone sees a trusted number.

1. Pick one failing question. Choose something sources disagree on today, such as active customer count.

2. Map its entities. List the three to five entities it needs and every system that holds them.

3. Land and model those sources. Bring only those tables into Layers 1 and 2.

4. Resolve one entity first. Usually customer or account, with a crosswalk and a review queue for uncertain matches.

5. Define the metric once. Write it in the semantic layer with an owner and a reference number.

6. Serve it two ways. Expose it to one BI dashboard and one agent tool, then compare the answers.

7. Widen by domain. Add the next entity or domain only after the first slice is trusted.

If you are deciding whether this replaces your MDM program, see semantic data unification versus MDM.

What are the most common failure modes?

Most failures come from skipped layers or unclear ownership, not from tool choice. Watch for these patterns early.

• Metrics defined in BI tools. Each dashboard grows its own formula, and the semantic layer is ignored.

• Joining on raw source keys. Metrics double count because the same customer has three IDs.

• No owner for core entities. Every domain edits "customer" and nobody can approve a change.

• Agents on raw tables. Answers look plausible but use the wrong filters.

• Graph first, questions later. A large knowledge graph gets built before anyone names the question it should answer.

• Definitions locked in one tool. A migration means rewriting years of business logic by hand.

Frequently asked questions

What is a semantic data unification architecture?

It is the set of layers that turns scattered source data into shared business entities and metrics. Data lands in a warehouse or lakehouse, entity resolution links records for the same customer or product, and an ontology or semantic layer defines what those entities mean. BI tools, applications, and AI agents then read one governed model instead of raw tables.

How is this architecture different from a data warehouse?

A warehouse stores and computes data. The unification architecture adds meaning on top of it. It decides which records describe the same real thing, how entities relate, and how metrics are calculated. You usually keep the warehouse as the physical home and add entity resolution, an ontology or semantic layer, and a governance plane above it.

Do I need a knowledge graph for semantic data unification?

Not always. Many teams start with resolved entity tables and a semantic layer such as MetricFlow, Snowflake semantic views, or Databricks metric views. A knowledge graph earns its place when questions cross many relationships, when you need reasoning over a formal ontology, or when agents must traverse connections that are awkward to express in SQL joins.

Should unified data be materialized or queried in place?

Most enterprises do both. Materialize the entities and metrics that many consumers read often, because that gives predictable speed and easy testing. Use federated queries through an engine such as Trino for sources you rarely read or cannot copy. Decide per entity, and record the choice so consumers know how fresh each answer is.

Where does entity resolution sit in the blueprint?

It sits after data lands and is cleaned, and before the semantic layer defines metrics. Resolution produces a stable entity ID and a crosswalk from each source record to that ID. Everything above it, including metrics, graph edges, and agent tools, should join on the resolved ID rather than on raw source keys that disagree across systems.

Who should own the ontology and the semantic layer?

Business domains should own the definitions for their entities, such as finance for revenue and sales for accounts. A small central team should own the shared core concepts, naming rules, and the platform that hosts them. This mirrors the federated governance idea from data mesh, which balances domain autonomy with global standards.

Why does this architecture matter for AI agents?

Agents that query raw tables guess at joins and business rules. A 2023 benchmark found GPT-4 answered 16 percent of enterprise questions correctly over raw SQL and 54 percent over a knowledge graph. An April 2026 study found explicit business semantics added 17 to 23 points across three frontier models.

What is the first step in building this architecture?

Pick one business question that fails today because sources disagree, such as how many active customers you have. Map the three to five entities it needs, find every system that holds them, and agree on owners. Then build each layer narrowly for that question before you widen the scope to more entities or domains.

How do open standards fit into the blueprint?

Open formats keep your definitions portable. MetricFlow is Apache 2.0, Apache Ossie defines a vendor-neutral format for metrics and business concepts, W3C SHACL validates graph data against shapes, and MCP gives agents a common way to reach tools. Storing definitions in these formats, in your own repository, keeps the model yours if you change vendors.

How is semantic data unification different from master data management?

Master data management usually produces golden records for a few core domains and pushes them back to operational systems. Semantic data unification is broader. It links entities across many domains, defines metrics and relationships, and serves analytics and agents. Many teams use MDM or entity resolution as one layer inside the larger unification architecture.