Here is a short video about AstraZeneca’s Semantic Layer Approach
Most organizations know how to build a knowledge graph. Far fewer know how to stop that graph from becoming the next generation of data swamp once it leaves the project team and tries to serve the enterprise.
In a recent talk at the Rough Eyes AI Summit, Ben Gardner (Lead for Data Mesh and Semantic Infrastructure at AstraZeneca) laid out a practical path from project-level graphs to a governed semantic data layer. The distinction matters. A project graph can be built by a small team that understands both the domain and the technology. An enterprise semantic layer must survive multiple teams, uneven semantic expertise, federated data products, and the constant pressure to move faster than governance allows.
AstraZeneca’s framing is useful. Instead of treating the classic T-box (model), C-box (reference and master data), and A-box (assertions) as stacked layers, they treat them as overlapping sets. The semantic layer only appears where meaning, reference data, and actual data intersect. Everything else is just another isolated graph.
This leads to a set of concrete practices rather than abstract architecture:
Persistent identifiers (PIDs) are assigned not only to high-level assets but down to individual fields and vocabulary terms. Controlled vocabularies are exposed as ordinary tables so data engineers can enrich products with SQL instead of needing to master the full semantic stack. Fields are linked to the business processes that depend on them, along with the quality and business rules that apply. Catalog metadata, reference data, ontology mappings, and process context are then serialized into what they call a context graph.
That context graph does double duty. For AI agents it supplies navigable structure: which data products and fields are relevant to a question, and how they relate. For human curators it surfaces fragmentation, prioritizes effort, and powers tools (fuzzy matching, synonym suggestions, composite unit generation) that keep people in the loop rather than replacing them.
The approach also reflects hard-won lessons about scope. They started roughly seven years ago in a high-value but difficult area—creating cohorts across clinical studies—where others had already failed. They built modular ontology patterns from the beginning rather than a single monolithic model, so later teams could import and reuse them. Only after a working graph existed did they focus on scaling, quality left-shifting, and broader enterprise adoption. The advice they received early (“start small, think big”) appears to have been followed in practice.
None of this is finished. They remain largely in-house and are still looking for platforms that can accommodate both deep semantic expertise and the much wider range of skills across the company. That tension is familiar to anyone who has tried to move knowledge engineering beyond a specialist team.
The larger shift on offer is from application-centric AI (an LLM placed on top of a known dataset) to data-centric AI (agents that can discover and act across a governed semantic layer that reflects how the organization actually works). Most current deployments still live in the first mode. The second requires the unglamorous work of identifiers, modular models, field-level description, and process linkage. Knowledge graphs are no longer the hard part. Turning them into durable, federated context that both people and machines can use—without recreating the messes of earlier data eras—is the real challenge. AstraZeneca’s experience suggests the solution lies less in new tools and more in deliberate design choices about modularity, identifiers, and where meaning is allowed to meet data.
Conceptual Schema: Semantic Data Layer (AstraZeneca Approach)
Core Classes
- SemanticDataLayer
The enterprise-level, federated context that emerges from the intersection of model, reference data, and operational data. - OntologyModule (T-box)
Modular conceptual models (e.g., ClinicalStudy, HumanSubject, Observation). Designed for reuse across application ontologies. - ReferenceDataAsset (C-box)
Controlled vocabularies, taxonomies, master data, and preferred labels. Each concept and label has a PID. - DataProduct (A-box source)
Cataloged, field-level described datasets or data products. Enriched with PIDs and linked to processes. - ContextGraph
The serialized governance graph that integrates catalog metadata, reference data, ontology mappings, critical data elements, and process/quality rules. - BusinessProcess
Operational context that gives fields meaning and priority.
Key Relationships / Properties
- hasPID — every asset, concept, label, and field receives a persistent identifier.
- subclassOf / importsModule — modular ontology design for consistency across teams.
- enrichesWith — DataProduct fields are enriched with preferred labels and PIDs from ReferenceDataAsset.
- linksToProcess — fields or critical data elements are connected to BusinessProcess steps, quality rules, and business rules.
- serializesInto — catalog records + reference data + ontology + process info are serialized into the ContextGraph.
- supportsCurationOf — ContextGraph powers human-in-the-loop tools (fuzzy matching, synonym suggestion, composite unit generation).
- providesContextFor — ContextGraph supplies navigable context to AI agents (which products/fields are relevant, how they relate).
- assessesAIReadinessOf — health checks and FAIR/AI-readiness scoring derived from the graph.
Design Principles (as constraints)
- FAIR-by-design (findable, accessible, interoperable, reusable, machine-actionable).
- Modular over monolithic.
- Left-shift quality and semantics into data products and source systems.
- Human-in-the-loop for curation; graph provides prioritization and tooling.
References
Original Video by Ben Gardner: