logo
|
Blog

    Ontology: A Structure for Decisions, Not Data

    Most AI transformation stops at the dashboard. The ontology layer is what turns scattered meeting context into decisions an agent can act on.
    Jun 27, 2026
    Ontology: A Structure for Decisions, Not Data
    Contents
    Ontology is not a databaseThe three layersSemantic layerDynamic LayerKinetic LayerThe dashboard trapWhen the loop closesThe next questionFAQGet started

    "The Ontology is designed to represent the complex, interconnected decisions of an enterprise, not simply the data."

    - Palantir Foundry Documentation

    Every organization runs into this scene at some point.

    A CS team lead asks the AI: "summarize what our top account, Acme, has been worried about lately." The AI searches three months of meeting records. Seven meetings come back. And the answer is strange.

    "Acme wants API integration. A Corp asked for a discount. Acme Inc. is considering a refund."

    Same company. Sales writes the legal name on contracts (Acme Inc.). CS uses the short form (Acme). Engineering uses the abbreviation (A Corp). From the AI's perspective, three different entities. No matter how much meeting context you feed it, without a structure to bind those three names into one, the AI gets lost the moment it has context.

    In the previous article I walked through the pipeline that turns meeting context into LLM-Ready Data: transcribed, structured, embedded, searchable. That alone is not enough. The AI still does not know that Acme, A Corp, and Acme Inc. are the same company. Without that, it also does not know that last week's sales meeting and this week's CS meeting are about the same customer.

    That binding is the job of ontology.


    Ontology is not a database

    For twenty years, Palantir has been structuring data for some of the world's most complex organizations: intelligence agencies, military operations, global manufacturers. The sentence they use to define Ontology in their public docs is precise:

    "The Ontology is designed to represent the complex, interconnected decisions of an enterprise, not simply the data."

    Not "a database." Not "a knowledge graph." A structure for decisions.

    Why does that distinction matter? A database stores facts. Acme Inc.'s contract amount, renewal date, account owner. But decisions are not lists of facts. "Why is this customer hesitating to renew" is not in any column. Neither is "which alternatives did we evaluate, and why did we reject them." Those live in people's heads and in the conversations of meetings.

    Palantir's docs continue: "Nouns alone cannot model decisions. Nouns must be paired with verbs. Semantic must be paired with Kinetic." That single line maps directly onto the outcome-vs-process distinction from the previous article. Static stored data cannot, by itself, express how an organization runs.

    Let us look at how ontology is actually composed.


    The three layers

    Palantir's Ontology model uses three layers working together: Semantic, Dynamic, Kinetic. We carry that structure into the design of AI transformation.

    Semantic layer

    The layer that defines the organization's vocabulary. What "customer" means inside our company. How "contract" and "meeting" relate. Whether Acme Inc., Acme, and A Corp are the same entity. Think of it as the organization's dictionary of concepts.

    If an AI can read your data but not understand it, the Semantic Layer is empty — just names without meaning. Without understanding, the AI can search, but it can’t reason. That’s exactly what went wrong in the opening scene.

    Dynamic Layer

    This is where context flows in real time. A decision from this week's meeting becomes a task next week. The outcome of that task shapes the agenda for the week after. The Dynamic Layer tracks that flow.

    This is the most overlooked layer. Most companies think about data being stored. Few are comfortable with the idea that data flows. But an organization is, by nature, a flow. What gets decided Monday becomes a task Tuesday, produces a result by Friday, and shows up again in the following Monday's meeting. If the AI cannot follow this flow, it can only see snapshots at each point.

    Kinetic Layer

    The layer where the AI actually takes action. Agents create tasks, gather data, design projects, validate results.

    But here's the thing: a Kinetic Layer operating without proper Dynamic context is like flooring it with no idea where you're going. An agent that moves fast without context just moves in the wrong direction fast.

    Palantir calls these three layers together "the organization's digital twin." The phrase sounds significant, but the mechanics are simple. There are nouns (Semantic), the nouns flow over time (Dynamic), and the AI acts on top of that flow (Kinetic). When all three are in place, the AI can actually make sense of what's going on.


    The dashboard trap

    Most of what companies call "AI transformation" stops at the Semantic Layer.

    Connect the data. Set shared definitions. Build dashboards. Automate reports. The output is a pretty dashboard, and that is it. "Activation Rate," "NRR," "CAC" all update in real time. Executives put it on a big screen in the conference room.

    Dashboards can be useful. But it's worth asking: how often does a dashboard actually change what the team does?

    You can see a metric drop. Diagnosing why it dropped, and knowing what to do about it, is still entirely up to the humans. That work happens in meetings. And the context of those meetings, again, goes nowhere. The loop stays open.

    We call this the dashboard trap. The organization has grounds to claim it "invested in AI transformation," while the actual quality of decisions barely moved. Semantic is built. Dynamic and Kinetic are left empty.

    Why does it stall there? Not because Dynamic is technically harder, but because it's organizationally harder. A data team can own the Semantic Layer. Vocabulary definitions, entity resolution, data governance: that's their specialty. The Dynamic Layer is different. Getting meeting context into the CRM, and having CRM changes feed back into meeting agendas, means redesigning how the business actually runs. That's not something the data team can accomplish on their own.

    Paul David's factory analogy from the first article applies here. Replacing the steam engine with an electric motor was a technology swap. Rebuilding the factory floor around it was something else entirely. Semantic is the technology swap. Dynamic is rebuilding the factory. That's why it takes longer, and why most organizations never get there.


    When the loop closes

    When all three layers work together, a single loop emerges: read context, reason, act, learn from the result.

    This loop has been discussed in the agent research community for a while. Anthropic's September 2025 Context Engineering guide defines an agent as "an LLM that uses tools autonomously in a loop." Not a single prompt, but something that keeps interacting with its environment and improving. For this loop to close, three things have to exist together: accurate context (Semantic), flow of context (Dynamic), and execution (Kinetic).

    Here’s a concrete scenario:

    In Monday's weekly meeting, the team discusses that "Activation Rate dropped 5% last week." A Conversation Intelligence tool turns that discussion into LLM-Ready Data (Context Source layer). The Semantic Layer of the Ontology clarifies the definition of "Activation Rate," the exact period "last week" refers to, and the segment used as the baseline. The Dynamic Layer connects this context to the live metrics system, and turns the three hypotheses from the discussion into tasks. In the Kinetic Layer, an agent automatically runs the task: "collect the last two weeks of onboarding funnel data and analyze step-by-step drop-off." The results are organized into the agenda right before the next Monday meeting. The team starts the next discussion by verifying last week's hypotheses.

    One full lap. And after that lap, the organization is a little smarter. Next week's conversation starts from last week's conclusions, because the loop actually closed.

    AI plays an important role in this scenario. but it is important to remember one thing: what makes the scenario work is not the model's intelligence, but the connection of context. Without Semantic, "Activation Rate" is not defined. Without Dynamic, meeting context and tasks are detached. Without Kinetic, there is no execution. If any one of the three is missing, the loop breaks.

    And here, Conversation Intelligence from the previous article shows up again. Meetings are the richest input this loop has. If that context isn't captured accurately, everything downstream suffers — the Semantic Layer gets shaky, and the Dynamic Layer follows. The quality of context determines the quality of the loop. That's why accuracy is something we take seriously at Tiro. A bad transcript warps the Semantic Layer, which produces the wrong tasks. If the start of the loop is corrupted, the rest of the layers, no matter how well built, just take the organization rapidly in the wrong direction.


    The next question

    The first three articles covered the front two layers of AI transformation: Context Source and Ontology. When these two are empty, models, agents, and interfaces have no significance.

    In the next article we move up to the next three layers: AI Model, Agentic Workflow, User Interface. We will look at where each layer is in 2026, which combinations actually work, and what order is reasonable when an organization invests in this stack.


    FAQ

    Why is the Semantic Layer alone not enough to count as AI transformation?

    The Semantic Layer can organize a company's vocabulary and produce dashboards. But a dashboard is, by nature, a snapshot. It shows that "the metric dropped" but not "why it dropped or what to do about it." To answer that, context has to flow over time (Dynamic) and decisions have to become real actions (Kinetic). Most AI transformation initiatives stop at Semantic and leave the other two layers empty.

    How is a Knowledge Graph different from an Ontology?

    A knowledge graph stores relationships between entities. It is a static design. Palantir's Ontology is "a structure for representing decisions." Nouns and verbs coexist, state changes over time, and AI can step into that change. Functionally, the knowledge graph corresponds to the Semantic Layer; Ontology is a broader concept that includes the Dynamic Layer and the Kinetic Layer on top.

    How do I figure out where my organization is stuck?

    One simple question. "Were the decisions our team made last week reflected in our AI system this week?" Not the dashboard numbers updating, but the context of those decisions (why we decided, what alternatives we rejected) stored somewhere an AI can read. If the answer is no, you only have a Semantic Layer. The closer the answer gets to yes, the more Dynamic and Kinetic are starting to work.


    Get started

    Share article
    Contents
    Ontology is not a databaseThe three layersSemantic layerDynamic LayerKinetic LayerThe dashboard trapWhen the loop closesThe next questionFAQGet started

    Tiro Blog

    RSS·Powered by Inblog