SocialHub.AI

Platform · Concepts · One Semantic Layer

One semantic layer. One answer to every business question.

A semantic layer means that every consumer of your business meaning — the dashboard, an AI agent, the API, a campaign tool — gets its answer from the same place. It isn’t a new product to buy; it’s the organizing principle of the SocialHub.AI architecture: a foundational ontology of objects and governed actions, with three derived assets attached to it — metrics, tags and behavior → intent— so “GMV,” a value tier, or an intent means one thing, everywhere.

Every consumer

Dashboard
AI agent
API
Campaign tool

One semantic layer

metricstagsbehavior → intent

Ontology · objects & actions

the foundation the three attach to

“GMV” · “VIP at-risk” · “drifting to churn”

mean the same thing to all four

The principle

When meaning is defined many times, it means many things.

The most expensive bug in a data stack isn’t a crash — it’s two teams looking at “revenue” and quietly seeing different numbers, because each tool re-derived the definition in its own query. As soon as AI joins the room, that ambiguity stops being a reporting nuisance and becomes an action risk: an agent that reads a different “active member” than your dashboard will confidently act on the wrong customer.

A semantic layer is the discipline of defining each piece of business meaning once, with an owner, and letting every consumer reference it — never re-derive it. In SocialHub.AI that layer is already built, in four parts: a foundational ontology of objects and actions, and the three derived assets that attach to it.

The parts of the layer

Four parts, one layer.

One part is foundational — the ontology, the objects and governed actions everything else attaches to. Three are derived— metrics, tags and behavior → intent, each answering a different question about a customer (how much, which kind, what happened) and each governed in its own right, not a loose column or a prompt convention.

The foundation · the noun layer

Ontology — objects & actions

answers “who & what, and what can be done

The nouns everything else hangs on — and the governed verbs.

The foundational layer. An explicit noun table — member, order, product — makes the objects themselves first-class, and pairs them with the governed actions that may be taken on each (issue a coupon, award points, apply a tag), every one with its preconditions, authorization and audit. The other three assets are semantics attached to these objects; the ontology supplies the objects and never restates their definitions.

objects (nouns)relationshipsgoverned actions (verbs)the base the rest attach to

Every metric, tag and behavior describes the same “member” — because there is one object it all attaches to.

The object spine & governed actions

The three derived assets · semantics that attach to the objects

Metrics

answers “how much

One certified definition per number, one engine that computes it.

The quantitative layer. Every business number — GMV, churn, retention, tier progress — has exactly one authoritative definition, with a named owner and a version, computed by a single semantic engine. Nothing is re-derived in a dashboard query or hand-rolled in a prompt.

certified definitionnamed ownerversionedone compute engine

GMV on the dashboard and GMV in the AI’s answer are always the same number.

The metrics semantic layer

Tags

answers “which kind

Classification that carries its own rules of use.

The categorical layer. Lifecycle stages, value tiers, propensities — explainable labels, but governed ones. Each tag has a lifecycle (live, sticky or manual), belongs to mutually-exclusive groups where only one label can hold at a time, honors consent, expires on a TTL, and declares where it may be used.

live / sticky / manualexclusivity groupsconsent-awareTTL + usage policy

A label doesn’t just say which kind — it comes with the boundaries of how it may be used.

Governed tags

Behavior → Intent

answers “what happened

A timeline that separates identity from observation.

The temporal layer. Raw events become the customer’s observed timeline; the subset the customer actively drove — browsed, bought, redeemed, went quiet — is marked as behavior; and from a window of that behavior the AI reads intent, a hypothesis like “drifting toward churn,” confirmed before anyone acts. Who they are lives in one place; what was observed lives in another.

eventscustomer-driven behaviorwindowed intentidentity ≠ observation

Behavior carries a semantic seed, so the AI reads the why — not only the what.

Events, behavior & intent

How the parts connect

The foundation is the join the three were missing.

On their own, metrics, tags and behavior describe the same customer in separate vocabularies with nothing joining them — a GMV figure, a churn-risk label and a purchase timeline are three statements about one person that never meet, because none of them carries a reference to the others. What connects them is the foundational part above: the object spine, an explicit noun table — member, order, product — that every asset hangs from, so a metric, a tag and a behavior stream all resolve to the same member instead of three unlinked descriptions. The rule that keeps this a base rather than a fourth derived silo is simple: it references, never duplicates. An object’s numbers point at the certified metric definitions; its labels are the tags applied under their own policies; its timeline is the behavior stream. The ontology owns the objects and actions; each derived asset keeps its own owner.

The payoff shows up when an AI reasons about a customer. Because every asset now attaches to one identified object, it can ask three questions and get answers that line up on the same noun — what is this customer (properties = metrics + tags), what has happened (behavior → intent), and what can I do about it (the governed actions on the object). Three descriptions that never referenced each other become one member object, assembled from every layer:

One member object · assembled from every layer

Member #48120 — Amelia R.

one object, read the same way by every consumer

Properties · metrics

Lifetime GMV — certified, one engine

Churn risk — one definition

owner: semantic engine

Properties · tags

VIPat-riskwine buyer

owner: tag policies

Timeline · behavior → intent

browsedpurchasedredeemed60 days quietintent: drifting to churn

owner: event stream

What can be done · governed actions

issue couponaward pointsapply tagadd note

each with preconditions, authorization and audit

Properties from metrics and tags. Timeline from behavior. Actions from the governed layer. One object — so every consumer that reads it reads the same customer.

This spine is the concept the Business Ontology page is dedicated to. This page is the layer it holds up.

How the object spine works →

Why it matters

One shared layer is now a measurable difference, not a preference.

When AI answers business questions over data whose meaning was never made explicit and shared, it doesn’t error out — it answers confidently and wrong. Give it one governed semantic layer to read through instead, and the accuracy gap is stark:

16.7% → 54.2%

LLM accuracy answering business questions over enterprise data

In a controlled benchmark on a real insurance schema, an LLM answering over the raw SQL database got 16.7% of business questions right. The same model, over the same data represented with an explicit semantic layer — a knowledge graph plus ontology — got 54.2%, roughly 3×, before any model got bigger. The representation, not the model, was the bottleneck.

data.world benchmark (Sequeda et al.), arXiv 2311.07509

→ 72%

when the semantic layer also checks and repairs the query

A follow-up used the ontology itself to validate the queries the LLM generates and repair the ones that violate it — lifting accuracy to 72%, with a further 8% of answers becoming an honest “I don’t know” instead of a confident hallucination. A shared semantic layer isn’t just context; it’s a checkable contract.

“Ontologies to the Rescue!” (Allemang & Sequeda), arXiv 2405.11706

+17–23 pts

from a single 4 KB semantic-layer document, across three frontier models

A paired benchmark ran three frontier LLMs over the same retail warehouse twice: schema only, then schema plus a ~4 KB document describing measures, conventions and disambiguation rules. Accuracy rose 17–23 points for every model — and the three became statistically indistinguishable. Shared semantics, not model choice, moved the needle.

Cube paired benchmark, arXiv 2604.25149

60% will fail

agentic analytics projects built on MCP alone, by 2028 (Gartner)

At its 2026 Data & Analytics Summit, Gartner warned that 60% of agentic analytics projects relying solely on MCP will fail by 2028 for lack of a consistent semantic layer. Plumbing that connects an agent to your systems is necessary — but without one shared model of what the business means, it isn’t sufficient.

Gartner Data & Analytics Summit 2026, as reported by Atlan

Industry consensus

The analytics field converged on this years ago: dbt and Cube popularized the metrics semantic layer precisely so that “revenue” or “active user” is a governed definition every tool reads — not SQL each dashboard re-derives its own way. Our semantic layer takes the same principle past aggregate measures, to classification, behavior and the governed actions on each object.

Cube paired benchmark, arXiv 2604.25149

One layer, many consumers

Everything reads the same layer.

The proof that it’s one layer is that unrelated surfaces — a chart, an approval card, an agent tool call, a segment builder — all resolve the same meaning to the same value.

The dashboard

Reads the certified metrics directly — every KPI, funnel and trend is the semantic engine’s single definition, never a chart-local query.

Dashboard

The AI approval console

Proposes actions as plain-language approval cards whose reasoning cites the same metrics, tags and timeline — the number a human approves is the number the agent read.

AI Governance & Approvals

MCP introspection tools

Let a connected agent list the objects, describe each field’s meaning, and enumerate the actions it may take — reading the layer’s definitions before it acts, not guessing from raw columns.

The introspection reference

Campaign segmentation

Filters audiences on the same metrics and governed tags the dashboard shows, so a “VIP at-risk” segment means exactly what the label means everywhere else.

Segments

No integration handoff, no re-mapping between tools.

Because there is one layer, adding a new consumer means pointing it at the same definitions — not teaching it your business meaning from scratch.

FAQ

The questions data and AI teams ask.

How is this different from the Business Ontology page?

They’re two views of one idea. The ontology page goes deep on one part of this layer — the objects and governed actions that form its foundation. This page zooms out to the whole: the ontology as the base noun layer, plus the three derived governed assets (metrics, tags, behavior→intent) that attach to it, and how every consumer reads one answer. Read the ontology page for the concept of the object model; read this one for how the four parts run as one layer.

Isn’t a “semantic layer” just dbt’s or Cube’s metrics layer?

That’s where the term comes from, and it’s the same instinct — a governed definition every tool reads, instead of SQL re-derived per dashboard. But an analytics semantic layer slices aggregate measures. Ours is the operational whole: a foundational ontology of objects and governed actions, with three derived assets attached to it — measures (metrics), classification (tags), and behavior and intent. Metrics are one part here, not the entire layer.

If the ontology is a part of the layer, isn’t it just a fourth silo?

No — that’s the distinction that keeps it one layer. The ontology is the foundational part (the nouns and the governed verbs), not a fourth derived semantic silo alongside metrics, tags and behavior. Those three describe things — how much, which kind, what happened; the ontology supplies the objects those descriptions attach to, plus the actions on them. It references, never duplicates: an object’s numbers point at the certified metric definitions rather than restating them, its labels are the tags applied under their own policies, its timeline is the behavior stream. Each part keeps its owner; the ontology owns the objects and actions, not the other three’s definitions.

Do our own custom fields and objects join the same layer?

Yes, automatically. Add a custom attribute to members — a membership number, a preferred store — or a whole custom object like a repair job or service appointment, and it enters the same semantic layer: introspectable by AI, describable field by field, usable in segments and personalization. There’s no second-class data and no separate integration to wire.

Does one semantic layer mean vendor lock-in?

No — the point of the layer is that the semantics are legible, not buried. Definitions, tag policies and object schemas are introspectable and exportable through the API and MCP: an agent (or your team) can list the objects, read what every field means, and export the definitions. One shared answer inside the platform, open to inspection outside it.

How does this relate to Data Governance?

They’re complementary. Data governance keeps the data itself trustworthy — one certified definition per number, consent honored, access controlled, clean data in. The semantic layer is what governs meaning on top of that: the shared nouns, labels, timeline and actions every consumer reads. Governed data is the floor; one semantic layer is the single answer built on it.

Related: Business Ontology · Metrics · Tags · Behavior & Intent · Data Governance

Give every dashboard, agent and campaign one answer to read.

400M+
50+
12+