💡 This is the vendor review. It evaluates what the market currently offers against a set of criteria that matter for enterprise-scale AI. For the strategic recommendation on architecture and industry ontology strategy, read the companion piece: Why Enterprise AI Needs One Ontology, Not One Semantic Layer Per Tool.
§ 02
How to Read This Review
This is not a feature comparison. Features change with every product release. What this review evaluates is the architectural position of each platform — specifically whether it can serve as a shared intelligence foundation across an enterprise, or whether it is designed to govern meaning only within its own boundaries.
That distinction matters because enterprise AI has a consistency problem. The more tools and agents an organisation deploys, the more definitions of the same business concepts accumulate in different places. A platform that cannot be connected to a central semantic layer makes this problem worse over time, regardless of how good its own analytics are.
The four criteria used in this review:
No platform currently on the market scores well on all four. That is the finding, and it is the context for the strategic recommendation in the companion piece.
§ 03
Category 1: Ontology-Native Platforms
These platforms treat the enterprise knowledge model as the primary product. BI tools, AI agents, and applications are consumers of it — they do not own the definitions.
§ 04
Palantir Foundry / AIP
What it is
Palantir's Foundry platform is built around its Ontology — a formal model of the enterprise's real-world entities, relationships, and business logic. Objects (Aircraft, Customer, Purchase Order, Field Service Ticket), their properties, the links between them, and the actions that can be taken on them are all defined in one place. Every downstream application — dashboards, workflows, AI agents — reads from this shared model.
The AIP (AI Platform) layer extends this to agentic use cases. AI agents built on Foundry reason over the Ontology directly, which means they operate from the same business understanding as every other system in the enterprise. The Ontology carries not just what things are but what can be done with them — approvals, escalations, automated actions — which is what makes Palantir agents operationally reliable rather than experimental.
Strengths
Limitations
Criteria scorecard
| Criterion | Assessment |
|---|---|
| Semantic scope | ✅ Full entity-relationship ontology with typed links and actions |
| External connectivity | ✅ API and MCP surfaces for external agents |
| Access control architecture | ✅ Ontology-native, granular, object-level |
| Tenant / domain configurability | ✅ Per-object overrides; multi-tenant supported |
Best fit: Organisations ready to make the ontology the operational backbone of the enterprise, not a reporting layer on top of existing tools.
§ 05
Stardog Enterprise Knowledge Graph (EKG)
What it is
Stardog is an RDF/OWL-native knowledge graph platform with SPARQL reasoning. Its distinguishing architectural feature is that data is never moved — Stardog creates a virtual knowledge graph over existing systems, querying them in place. The ontology connects to your databases, ERP, data warehouse, and other sources wherever they already live.
AI agents query the knowledge graph and receive governed, relationship-aware answers grounded in the formal ontology. Stardog also supports logical inference — the ability to derive new facts from existing relationships, not just retrieve stored ones. If a regulation implies a classification that is not explicitly stored in the data, Stardog can surface it.
Strengths
Limitations
Criteria scorecard
| Criterion | Assessment |
|---|---|
| Semantic scope | ✅ Full formal ontology with OWL reasoning and inference |
| External connectivity | ✅ SPARQL, REST, MCP; external agent access supported |
| Access control architecture | ✅ Semantic-layer-native; fine-grained |
| Tenant / domain configurability | ✅ Supported; requires modelling investment |
Best fit: Regulated industries (finance, healthcare, defence, insurance) with serious governance requirements and willingness to invest in ontology engineering. Strongest for organisations that need logical inference, not just retrieval.
§ 06
Graphwise (formerly Ontotext GraphDB + PoolParty)
What it is
Graphwise is the product of merging two mature semantic web platforms: Ontotext's GraphDB triplestore and Semantic Web Company's PoolParty knowledge management system. It covers both structured data (knowledge graph) and unstructured content (document understanding, taxonomy management).
Its GraphRAG capability is particularly relevant for AI use cases where answers need to be grounded in both structured knowledge and documents — legal, regulatory, life sciences, publishing. An AI model retrieves semantically grounded answers from the combination rather than hallucinating from context alone.
Strengths
Limitations
Criteria scorecard
| Criterion | Assessment |
|---|---|
| Semantic scope | ✅ Full ontology; strong on document/knowledge integration |
| External connectivity | ✅ Standards-compliant; open APIs |
| Access control architecture | ⚠️ Supported but less enterprise-hardened than Palantir or Stardog |
| Tenant / domain configurability | ⚠️ Possible; requires configuration |
Best fit: Legal, life sciences, publishing, regulatory compliance — domains where the intelligence layer must span structured data and document content simultaneously.
§ 07
Category 2: AI Analytics Platforms With Embedded Semantic Layers
These platforms deliver real and immediate value: consistent metrics, natural language querying, governed access to data. They are the platforms most enterprises are actively deploying today. The limitation — relevant to the strategic argument in the companion piece — is that each carries its own definition of what things mean, creating a cross-tool consistency problem as the number of deployed platforms grows.
§ 08
AtScale
What it is
AtScale is a universal semantic layer — a platform that sits between any data warehouse and any consuming tool, defining metrics once and serving them to BI tools, AI agents, and embedded applications simultaneously. It is warehouse-agnostic: Snowflake, BigQuery, Databricks, Redshift, and others are all supported.
The GigaOm 2025 Radar named AtScale a leader in semantic layers and metric stores. A Forrester study found 551% ROI with a two-month payback period. Its governance depth — row-level security, column-level masking, object-level security, audit trails — is the strongest in this category. MCP integration means AI agents can query governed metrics without being able to bypass the semantic layer and hit raw tables.
Strengths
Limitations
Criteria scorecard
| Criterion | Assessment |
|---|---|
| Semantic scope | ⚠️ Metrics and dimensions; not typed entity-relationship ontology |
| External connectivity | ✅ Multi-API; MCP for AI agents |
| Access control architecture | ✅ Best in category; semantic-layer-native |
| Tenant / domain configurability | ⚠️ Possible via multi-tenant configuration; not natively ABox-style |
Best fit: Organisations whose primary problem is metric inconsistency across multiple BI tools and AI agents. Not the right choice if the goal is cross-domain entity-relationship reasoning.
§ 09
dbt Semantic Layer (MetricFlow)
What it is
dbt is the dominant analytics engineering platform. Its Semantic Layer, powered by MetricFlow, allows data teams to define metrics in YAML alongside the dbt models that produce them. Any downstream tool — BI platforms, AI agents, APIs — queries those definitions through a consistent interface.
dbt is also the closest thing the market has to an open standard. The Open Semantic Interchange (OSI), launched in January 2026, uses MetricFlow as its declarative specification. Snowflake, Salesforce, Cube, AtScale, and Databricks are among the 40+ signatories, meaning dbt metric definitions may eventually be portable across platforms.
Strengths
Limitations
Criteria scorecard
| Criterion | Assessment |
|---|---|
| Semantic scope | ⚠️ Metrics and dimensions; not entity-relationship ontology |
| External connectivity | ✅ JDBC, GraphQL, API; OSI portability in progress |
| Access control architecture | ⚠️ Warehouse-native RBAC; not semantic-layer-native |
| Tenant / domain configurability | ⚠️ Requires model separation; not natively configurable per tenant |
Best fit: Organisations with a strong analytics engineering practice already on dbt, where the goal is metric consistency across BI and AI consumers.
§ 010
Cube
What it is
Cube is a headless semantic layer — it exposes metrics and dimensions through SQL, REST, GraphQL, and MDX simultaneously, making it the strongest option for organisations that need to serve multiple BI tools, AI agents, and embedded analytics applications from one metric definition. The GigaOm 2025 Radar named it an Outperformer.
Its dedicated AI API endpoint and semantic model agent serve the full data model in a format LLMs can reason over directly — further along in AI readiness than dbt. No dbt Cloud dependency; works across any warehouse, multi-cloud, global deployments.
Strengths
Limitations
Criteria scorecard
| Criterion | Assessment |
|---|---|
| Semantic scope | ⚠️ Metrics and dimensions; not entity-relationship ontology |
| External connectivity | ✅ Best in category; multi-API including dedicated AI endpoint |
| Access control architecture | ⚠️ Supported; less deep than AtScale |
| Tenant / domain configurability | ⚠️ Feasible; requires deliberate construction |
Best fit: Embedded analytics products and organisations serving multiple BI tools and AI agents that need one definition to rule all consumers. Strongest AI API readiness in this category.
§ 011
Looker (Google Cloud / LookML)
What it is
Looker pioneered the semantic-layer-first approach in business intelligence. LookML defines all dimensions, measures, access grants, and exploration paths centrally; every query generated by Looker runs through this model. Gemini now queries LookML semantics for conversational analytics.
It remains the most mature semantic layer inside a BI tool, with a deep track record in large enterprise deployments and a sophisticated access control model (access grants, access filters, user attributes).
Strengths
Limitations
Criteria scorecard
| Criterion | Assessment |
|---|---|
| Semantic scope | ⚠️ Metrics, dimensions, drill paths; not entity-relationship ontology |
| External connectivity | ⚠️ API access available but locked to Google Cloud ecosystem |
| Access control architecture | ✅ Sophisticated; LookML-native |
| Tenant / domain configurability | ❌ Requires schema or deployment separation; not semantic-layer-native |
Best fit: Large enterprises committed to Google Cloud with dedicated LookML modelling capacity. Not the right choice for multi-cloud or multi-vendor environments.
§ 012
What the Market Is Missing
Across both categories, every platform reviewed requires the customer to build the semantic model of their business — whether that is a full ontology or a metric configuration — from scratch at deployment time. There is no platform currently shipping a pre-built, formally specified industry ontology that a customer can configure and go live on in weeks.
This is the most significant unmet need in the market. The companion piece — Why Enterprise AI Needs One Ontology, Not One Semantic Layer Per Tool — develops the argument for why this is the right strategic move for both vendors and enterprise buyers, and what it would look like in practice.
§ 013
Selection Guide
| Your situation | Recommended path |
|---|---|
| Ready to make ontology the enterprise operating layer | Palantir Foundry |
| Regulated industry, need formal inference, data stays in place | Stardog EKG |
| Heavy document + structured data use cases (legal, life sciences) | Graphwise |
| Metric consistency across multiple BI tools is the primary problem | AtScale |
| Strong analytics engineering practice, already on dbt | dbt Semantic Layer |
| Embedded analytics product or multi-consumer API requirement | Cube |
| Google Cloud committed, dedicated LookML team | Looker |
No platform on this list scores well on all four criteria. That gap is intentional — it reflects the actual state of the market, not an oversight in the review.