The Semantic Layer
Define revenue, customers, and every core metric once, on top of your raw and lakehouse data — so BI tools, analysts, and AI agents all get the same answer, grounded in your governed ontology instead of a bolt-on config file.
One Metric, Defined Once
Revenue, active customer, churn — each metric and dimension is defined a single time and inherited everywhere it's queried.
Grounded in the Ontology
Definitions sit on the same entities and relationships as your knowledge graph, so the semantic layer evolves with the business instead of drifting from it.
Consistent for BI & AI
Dashboards, analysts, and AI agents all query the same governed definitions — so a chatbot's answer matches the report on the same question.
A semantic layer is a governed layer of business meaning — metrics, dimensions, and entity definitions — placed on top of raw and lakehouse data, so every tool and person that queries it gets the same answer. Scrydon's semantic layer is grounded in the ontology rather than a standalone metrics config, so definitions stay consistent as the underlying graph of entities and relationships evolves.
Ask three analysts what "active customer" means and you'll often get three different SQL queries — and three different numbers. A semantic layer closes that gap by defining metrics, dimensions, and entities once, centrally, so every dashboard, report, and query inherits the same definition instead of re-deriving it. Scrydon's semantic layer isn't a standalone YAML metrics file bolted onto the warehouse: it is grounded in the ontology, so a metric like "revenue" is defined in terms of the same entities and relationships your knowledge graph and AI agents already reason over — and it evolves with the graph rather than drifting out of sync with it.
Semantic Layer in the Scrydon platform
One integrated, sovereign architecture. Here is where Semantic Layer sits — highlighted against the full stack it works with.
The AI OS (Agentic OS) for Humans & AI Agents to enable your processes
df.plot.bar()
Link your processes, knowledge & data to ontologies.
Unified storage, structured compute, and secure multi-modal data processing.
Autonomous operatives with specialised skills executing tasks across systems.
Sovereign pipelines, federated APIs, and seamless connector meshes.
Secure domain federation, trusted data sharing, and cross-boundary intelligence.
Semantic Layer in depth
Insights
Data sitting in warehouses and dashboards that nobody reads is data they can't use. The Insights layer changes that — giving the right people the right information without them having to ask for it. Every metric is anchored to the Cognitive Enterprise ontology, so a revenue figure doesn't arrive in isolation. Data in context — not just in dashboards.
Decision-makers get a live view of the enterprise — financial performance, operational health, procurement status — without waiting for a data team to prepare a report.
- Interactive notebooks: Python and SQL environments with full access to your lakehouse data — no data movement required.
- Visual dashboards: Pre-built, always-current reporting updated automatically as the business moves — no manual refresh, no stale numbers.
- Agent-native analytics: AI agents can query, summarise, and act on insights autonomously — closing the loop between analysis and action.
Cognitive Enterprise
Link your processes, knowledge & data to ontologies.
Most organisations have data they can't use — not because it doesn't exist, but because nothing connects it. The Cognitive Enterprise layer is the defining intelligence of the AI OS: a living, queryable semantic model of your organisation's entities, processes, and rules. It is the single source of truth that allows every agent, analyst, and workflow to reason about your business with a consistent understanding.
Without it, AI agents reason on noise. With it, they reason on the business.
- Entity graph: Model customers, accounts, orders, products, and any domain concept — then connect them with typed, traversable relationships.
- Process integration: Link real-world workflows to ontology entities so agents understand how data flows through your business.
- Continuous enrichment: Agents automatically enrich ontology nodes with fresh data from the lakehouse, keeping the model current without manual effort.
Define it once, trust it everywhere
A semantic layer sits between your raw and lakehouse data and everyone who queries it — BI tools, analysts, notebooks, and AI agents. Instead of each team writing its own SQL to work out what "revenue" or "active customer" means, the definition is set once, centrally, and every query inherits it. Because Scrydon grounds those definitions in the ontology, metrics are defined against the same entities and relationships your knowledge graph already models, not a parallel set of tables nobody else sees.
Metrics — Define revenue, churn, active customer, and every core figure once, centrally.
Dimensions — Model how metrics can be sliced — by region, product, or segment — consistently.
Entities — Ground definitions in the same customers, products, and accounts as the ontology.
Inherited, not re-derived — Every dashboard, report, and query pulls the shared definition instead of rebuilding it.
Why metric drift breaks trust in data and AI
Without a semantic layer, every team re-derives its own version of "revenue" or "active customer," and the small differences compound: a board deck, a regional dashboard, and a sales report each show a slightly different number, and nobody can say which is right. That erosion of trust gets worse once AI enters the picture, because an agent computing figures straight from raw tables will confidently produce yet another number with no way to reconcile it. A shared semantic layer removes the re-derivation entirely, so every answer — human or AI — comes from the same governed definition.
The layer that keeps AI agents and dashboards consistent
AI agents that answer business questions need to compute the same figures your dashboards show, not a plausible-sounding approximation. When an agent queries the semantic layer instead of raw tables, it resolves "revenue" or "churn" to the exact governed definition your analysts use, so its answer matches the report on the same question. Because the semantic layer is grounded in the ontology rather than a standalone config, it updates as your entities and relationships evolve — keeping agents, dashboards, and analysts permanently in agreement.
Shared source of truth — Agents compute metrics against the same semantic layer as your BI tools — no separate, ungoverned definition of "revenue" for AI.
Grounded, not guessed — Agents resolve business terms to governed definitions instead of inferring meaning from column names or prompts.
Explainable numbers — Every figure an agent returns traces back to a defined metric, so answers are checkable, not just plausible.
Evolves with the graph — As entities and relationships change in the ontology, the semantic layer updates with them — no separate config to maintain.
Frequently asked questions
What is a semantic layer?+
What is the difference between a semantic layer and an ontology?+
How is this different from dbt or Cube-style metrics layers?+
Does a semantic layer replace my BI tool?+
How does a semantic layer reduce metric drift?+
Why does the semantic layer matter for AI agents specifically?+
Explore the platform
Email us
Prefer to write? Email hello [at] scrydon.com and we will get back to you.
Partners
Building the future of Data & AI together with leading innovators. Learn more .
