Platform · Concepts · Business Ontology
Your AI needs a world model of your business. That’s an ontology.
A business ontology is a living map of what your business is — the objects (members, orders, products), what each field means, how they relate — and what may be done: governed actions with preconditions, authorization and audit. Not a copy of your data. A layer of meaning pinned to the data you already have, that both people and AI read the business through.
Dynamics layer · the verbs
Governed actions — each with preconditions, an authorization gear and an audit record.
Semantic layer · the nouns
Member
tier · consent · tags
Order
total · store · date
Product
category · price
Objects, their properties, and the relationships between them — the map of what exists.
The data you already have
profiles · orders · events · catalog — nothing copied, nothing moved
What it is
A digital twin of the business, in two layers.
Every business already has an implicit ontology — everyone sort ofknows what a “member” is, what “an order” contains, which actions are acceptable. The problem is the word implicit: the knowledge lives in people’s heads, in tribal SQL, in six tools with six definitions. An explicit ontology writes it down once, as a machine-readable model with two layers:
Layer 1 · Semantics — the nouns
Objects, properties, relationships
The entities your business runs on — member, order, product, coupon, campaign, store — each with named, described properties, connected by real relationships: a member places an order, an order contains products, a coupon belongs toa member. Ask “what is this customer?” and there is one answer, with every field’s meaning attached.
Layer 2 · Dynamics — the verbs
Governed actions
What may be doneto those objects: issue a coupon, award points, apply a tag, add a note — each action carrying its preconditions (when it’s valid), its authorization (who or what may take it, and on what gear), and its audit trail (what happened, and why). This is what separates an ontology from a passive dictionary: it models change, not just state.
The pattern isn’t ours alone. Palantir carried it into the enterprise mainstream — Foundry’s ontology pairs a semantic layer of objects with a kinetic layer of governed actions across entire enterprises. We apply the same architecture to one domain, deeply: the customer.
What it is not
Map the data you already have.
The fastest way to understand an ontology is by what it doesn’t ask of you: no new database, no migration, no crawl-and-catalog project.
Not a data catalog
A catalog inventories datasets for people — where tables live, who owns them. An ontology models the business itself for machines and people: what a customer is, how an order relates to a product, and what may be done about either. A catalog describes storage; an ontology describes the world.
Not another database
Nothing is copied or migrated. The ontology is a metadata layer that maps the data you already have — your profiles, orders, events and catalog stay exactly where they are. What’s added is meaning: names, definitions, relationships and rules pinned to the data underneath.
Not just a semantic layer
Metric semantic layers define aggregate numbers — revenue, retention — one certified way. An ontology goes two steps further: it makes the objects themselves first-class (this member, this order), and it adds a dynamics layer of governed actions. Nouns and verbs, not just measures.
One semantic layer
You already have three semantic assets. What’s missing is the noun table.
A platform like ours doesn’t arrive at the ontology empty-handed. Three layers of meaning are already built, certified and governed — each strong in its own right:
answers “how much”
Metrics
The certified quantitative layer. GMV, churn, retention — every business number has exactly one authoritative definition, computed by the semantic engine. When two dashboards show revenue, they show the same revenue.
The metrics semantic layer→answers “which kind”
Tags
The governed classification layer. Lifecycle stages, value tiers — explainable labels applied under policy: consent-aware, with TTLs, exclusivity rules and an audit trail. Who a member is, on the record.
Governed tags→answers “what happened”
Behavior → Intent
The timeline layer. What a customer actually did — browsed, bought, redeemed, went quiet — and the intent the AI reads from a window of that behavior: hypotheses like “drifting toward churn,” confirmed before anyone acts.
Events, behavior & intent→Look closely, though, and all three are the same kind of thing: derived semantics hung on objects that were never made explicit. Metrics describe amounts of something; tags describe kinds of someone; behaviors describe events happening toentities. The adjectives and the verb phrases are all there — what’s missing is the noun table. “Member,” “order,” “coupon” have no single shared definition; each asset re-describes the entities in its own terms, and none of them reference each other.
The ontology’s job is to supply that noun table — as a spine, not a fourth silo. An object’s derived properties referencethe certified metric definitions; nothing is re-computed, and the metrics layer remains the sole authority for every number. Tags surface as the object’s classification properties, still applied under their own consent and TTL policies. The behavior stream becomes the object’s observed timeline — identity in one place, observation in another. And the kinetic layer adds what none of the three could: the verbs — the governed actions that may be taken on each object.
AI agents & the console
what is this customer · what has happened · what can be done
Ontology · one semantic layer
objects · links · actions
Metrics
certified measures
owner: semantic engine
Tags
governed labels
owner: tag policies
Behavior → Intent
observed timeline
owner: event stream
The data you already have
profiles · orders · events · catalog
Metrics, tags and behaviors answer how much, which kind and what happened. The ontology makes them work around the same who and what — and adds what can be done.
The result is one whole semantic layer: when an AI asks what this customer is (properties = metrics + tags), what has happened (behavior → intent), and what it may do (actions), the three answers share the same noun system for the first time. Each layer keeps its owner; the ontology references, never duplicates.
Read the full picture: how the one semantic layer runs →Why it matters
AI over raw data fails quietly. The evidence is now measurable.
The missing noun table isn’t a cosmetic gap. When an AI answers business questions over data whose objects were never made explicit, it doesn’t error out — it answers confidently and wrong. The cost has been benchmarked:
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 as a knowledge graph with an ontology, got 54.2% — roughly 3× — before any model got bigger or smarter. The representation, not the model, was the bottleneck.
data.world benchmark (Sequeda et al.), arXiv 2311.07509↗→ 72%
with ontology-based query checking and repair
A follow-up study used the ontology itself to validate the queries the LLM generates and repair the ones that violate it — lifting overall accuracy to 72%, with a further 8% of answers becoming an honest “I don’t know” instead of a confident hallucination. The ontology isn’t just context; it’s a checkable contract.
“Ontologies to the Rescue!” (Allemang & Sequeda), arXiv 2405.11706↗+17–23 pts
from a 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 percentage points for every model — and the three models became statistically indistinguishable. 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 a model of what the business means, it isn’t sufficient.
Gartner Data & Analytics Summit 2026, as reported by Atlan↗Industry signal
In June 2026, Zeta Global and Palantir announced a strategic partnership to build unified data and AI infrastructure for marketing — with Palantir Foundry contributing “the ontology, governance, and operational infrastructure that enterprise data demands” underneath agentic marketing execution. A semantic model plus governed action is becoming the industry’s architecture for letting AI act, not just analyze.
Zeta Global press release, June 23, 2026↗The deeper shift
The traditional stack models data. It never modeled decisions.
Warehouses, pipelines and catalogs answer “what is true?” They capture state — rows, columns, snapshots. What they never capture is the decision: the judgment that was formed, the action it led to, who authorized it, and what happened next. That loop lived in people’s heads and in tickets, so it was never queryable, never learnable, never governable.
The moment AI starts acting— not just reporting — that gap becomes the whole problem. Agentic systems don’t need another data integration; they need decision integration: evidence → judgment → authorized action → recorded outcome, as first-class, connected objects. That is precisely what the ontology’s dynamics layer provides — and why we treat every AI decision as data, in a log you can filter, replay and audit.
A decision, as the ontology records it
Evidence — the member records and metrics the AI actually read
Judgment — the reasoning, in plain language, on the record
Authorization — the gear it ran on — or the person who approved it
Action — what changed: the coupon issued, the tag applied
Outcome — the result — feeding the next decision, and reversible
In the platform
Not a slideware concept. It’s running.
In SocialHub.AI the ontology isn’t a project you build — it ships with the platform and extends to the fields and objects you add. Here is what it enables today:
AI that can ask what exists
Before acting, any connected AI can introspect the ontology: list the business objects your workspace has, describe an object’s fields and what each one means, see how objects relate, and list the actions it may take — with the conditions and current authorization for each. Fields holding personal data are described, but their values are never handed over.
The introspection reference→Actions that are governed, not free-form
The dynamics layer at work: every AI action carries its own authorization gear — automatic, human review, or forbidden — set per team. Proposals arrive as plain-language approval cards, reasoning is re-checked at approval time, a misbehaving action demotes itself to human review, and any action can be undone.
See the governance console→Every decision, on the record
Because actions are ontology objects too, each one leaves a complete decision record: the reasoning, the evidence read, who authorized it (a gear or a person), what changed, and the result. AI activity stops being a black box and becomes a log you can filter, replay and audit.
The decision log→Your extensions inherit the semantics
Add a custom field to members, or a whole custom object — repair jobs, service appointments — and it enters the same ontology automatically: introspectable by AI, describable field by field, usable in segments and personalization. No second-class data, no separate integration.
Custom objects→The concept is this page. The console is the product.
AI Governance & Approvals is where the ontology’s dynamics layer becomes a daily workflow — approval cards, action gears, the decision log, one-click undo.
FAQ
The questions data teams ask.
How is an ontology different from a data catalog?
A data catalog answers “where is the data and who owns it?” — it inventories tables and files for human data teams. An ontology answers “what does the business consist of, and what can be done?” — it models members, orders, products, their relationships, and the governed actions that operate on them, in a form both people and AI agents can read and act through. Many organizations need both; they are not the same tool.
How does it relate to a metrics semantic layer (like dbt’s or ours)?
They’re complementary layers of one idea. A metrics layer certifies aggregate definitions — what “revenue” means, computed one way. The ontology extends that from measures to the objects themselves (this member, this order, how they connect) and adds the action layer: what may be done, by whom, under what conditions. In SocialHub.AI, an object’s derived properties reference the certified metric definitions rather than re-computing them — the metrics layer stays the sole authority for every number — and the ontology unifies it with the classification semantics of tags and the timeline semantics of behavior and intent, around the same objects.
Do we need a graph database to have an ontology?
No. An ontology is a modeling layer, not a storage technology. It maps the data you already have — relational tables, event streams, a product catalog — and pins names, relationships and rules on top. Some vendors implement ontologies over graph stores; ours is metadata over the operational data that’s already in the platform. Nothing is re-platformed.
Is this the same as Palantir’s ontology?
Same concept, different scope. Palantir brought the ontology pattern — a semantic layer of objects plus a kinetic layer of governed actions — into the enterprise mainstream with Foundry, applied across whole enterprises. Ours applies the same pattern to one domain, customer engagement: members, orders, products, campaigns and the governed marketing actions on them, built into the platform rather than assembled as a project.
How does this relate to data governance?
Data governance keeps the data trustworthy — one certified definition per number, consent honored, access controlled, clean data in. The ontology builds on that foundation and adds the layer AI needs to act: what the objects are and which actions are allowed. Trustworthy data is the floor; a governed world model is what an agent stands on.
Related: Data Governance · The metrics semantic layer · AI Governance & Approvals
Related reading
Keep exploring the pages most related to this one.
Intelligent Decision
A next-best-action: who, which offer, which channel, when.
Read more CapabilityDashboard
Real-time scan-to-redemption data as KPI trends, funnel diagnostics, and a rule + LLM next-best-action panel.
Read more CapabilitySoTag for Slack
The Slack agent that hands governed, audited numbers to Claude in-thread: daily anomaly scan + human-approved coupon-send. Early access.
Read more CapabilitySoClaw — AI Win-Back
An autonomous AI teammate that wins back high-value, at-risk customers one at a time — a personalized offer or a deliberate hold — and proves the real incremental lift against an untouched control group. Off by default, capped, instantly pausable. Early access.
Read more CapabilityAI Governance & Approvals
Every AI action runs on a per-action authorization gear — automatic, human review, or forbidden — with an approvals console, a complete decision log, one-click undo, and automatic demotion to human review when an action starts misbehaving.
Read more CapabilityOne Semantic Layer
The organizing principle of the platform: three governed assets — certified metrics, governed tags, and behavior → intent — hung on one shared object spine, so every consumer (dashboard, AI agent, API, campaign tool) reads business meaning from one authoritative place and never disagrees.
Read more