ibl.ai Agentic AI Blog

Insights on building and deploying agentic AI systems. Our blog covers AI agent architectures, LLM infrastructure, MCP servers, enterprise deployment strategies, and real-world implementation guides. Whether you are a developer building AI agents, a CTO evaluating agentic platforms, or a technical leader driving AI adoption, you will find practical guidance here.

Topics We Cover

Featured Research and Reports

We analyze key research from leading institutions and labs including Google DeepMind, Anthropic, OpenAI, Meta AI, McKinsey, and the World Economic Forum. Our content includes detailed analysis of reports on AI agents, foundation models, and enterprise AI strategy.

For Technical Leaders

CTOs, engineering leads, and AI architects turn to our blog for guidance on agent orchestration, model evaluation, infrastructure planning, and building production-ready AI systems. We provide frameworks for responsible AI deployment that balance capability with safety and reliability.

Back to Blog

Can an Ontology Become Your Last System of Record?

Jaione AmigotOctober 14, 2026
Premium

A semantic layer becomes a system of record only when it originates state that exists nowhere else — and most never do, because they project over source systems that stay authoritative. This post gives four tests, one verified case where a semantic layer genuinely holds the record, two where it does not, and the custody question that outlasts the architecture.

The Short Answer

An organizational ontology becomes a system of record only when it originates state that exists nowhere else. Most semantic layers never do — they project over source systems that remain authoritative, and that is the right design for most enterprises. The decision that outlasts the architecture is custody: on ibl.ai you own all the code and the data, self-hosted inside your own perimeter, model-agnostic across any LLM, with no per-seat pricing.

The sharper version of the argument goes further: that the ontology grows into the last system of record, meaning the semantic layer stops being a view over your CRM, SIS and ERP and becomes the layer that matters.

That formulation is not an industry term — it is a claim we are putting to a test here.

It does happen. It is documented, in a shipping product, and we quote the documentation below. But it happens under specific conditions, it is not the default, and in regulated recordkeeping it mostly cannot happen at all.

This post gives the four conditions, one verified case where a semantic layer genuinely holds the record, two where it does not, and an honest answer about our own ontology — which is read-only, and therefore not a system of record.

Is the AI model or the ontology the durable asset in enterprise AI?

The ontology, and the model layer's own numbers are the reason. Stanford HAI's 2026 AI Index reports that performance on SWE-bench Verified "rose from 60% to near 100% in a single year," and that as of March 2026 Anthropic's top model led the leading Chinese model by just 2.7%.

A capability that converges that fast, across that many providers, is not a moat. Anything you build that depends on one specific model is a thing your competitor can buy the same afternoon.

What does not converge is the formal map of your own organization: its entity types, its relations, its permissions, and the accumulated decisions recorded against them.

That half of the argument is already made and we are not relitigating it here. See The Model Is a Commodity. The Operating System Is the Moat for the operating-system version, and The Model Is the Commodity. The Context Layer Is the Moat for the data-access version.

Why AI Agents Fail Without an Ontology covers why the ontology has to exist before the agents.

This post is the narrower follow-on, about the claim none of those make: that the map becomes the territory.

What would have to be true for an ontology to become a system of record?

Four conditions, and a semantic layer has to satisfy all four rather than one. "System of record" is not a compliment paid to the most-used system; it is a specific property about where state originates and who answers for it.

Test What it asks Typical semantic layer
1. Origination Does state get created here first, with no upstream source? No — every value traces to a source system
2. Authority When this layer and the source disagree, which one wins? The source wins; the layer rebuilds
3. Duty Does retention, legal hold and audit attach to this copy? No — the duty sits on the originating system
4. Survivability If the sources were decommissioned, would the record survive? No — a projection dies with its inputs

A layer that fails all four is a cache with good manners. That is not an insult — a well-governed projection is exactly what most agent deployments need, and it is far cheaper to operate than a ledger.

But it means the sentence "our ontology is the system of record" is usually false, and is worth checking before anyone builds a retention policy on it.

Where has a semantic layer actually become the system of record?

In Palantir Foundry, for state created through the Ontology's own write path — and the product documentation says so plainly, which is why this is the strongest evidence for the claim rather than the weakest.

Palantir describes the Ontology as a layer that "sits on top of the digital assets integrated into the Palantir platform (datasets, virtual tables, and models) and connects them to their real-world counterparts" — a semantic and kinetic model of the organization, objects and links plus actions and functions.

So far, a projection. The interesting part is the write path.

Palantir's documentation for action types states that "any changes made to objects, property values, and links will be committed to the Ontology when the user takes the action," and that "the most up-to-date version of object data with user edits incorporated will be captured in an object type's writeback dataset."

Read that against test 1. An approval, an override, a reclassification taken as an Ontology action originates in the semantic layer. There is no upstream CRM row it was copied from. For that slice of state, the ontology is where the record lives.

This is the honest version of the "last system of record" claim, and it is narrower than the slogan. The semantic layer becomes authoritative for the decisions taken inside it, not for the master data it mapped.

Where has the ontology not become the system of record, and probably will not?

Two places, and both are more common than the Palantir case: read-only analytical graphs, and regulated recordkeeping.

The Gates Foundation's Strategic Intelligence Platform is the clearest read-only example at scale.

The published write-up describes an enterprise knowledge graph spanning 25+ years of organizational data and over $7 billion in annual grant disbursements, rolled out in 2026 to roughly 4,000 employees.

Its architecture is a cross-system semantic layer that agents traverse at query time, unifying four source systems and exposed over the Model Context Protocol so people reach it from the chat clients they already use.

A curation pipeline populates the graph from those sources. The sources stay the systems of record.

That is not a shortcoming. It is the correct design for a retrieval problem, and it keeps the retention duty where the regulator and the auditor already expect to find it.

Regulated recordkeeping is the harder boundary.

The SEC's amendments to the electronic recordkeeping requirements for broker-dealers, compliance date 3 May 2023, offer an audit-trail alternative. It requires, in the SEC's own words:

  • "a complete time-stamped audit trail" covering "all modifications to and deletions of a record or any part thereof"
  • "the date and time of actions that create, modify, or delete the record"
  • "if applicable, the identity of the individual creating, modifying, or deleting the record"
  • whatever else "will permit re-creation of the original record if it is modified or deleted"

A graph that rebuilds nightly from upstream tables cannot satisfy that for the records it merely reflects. The system that originated the write can.

HIPAA's designated record set works the same way: the duty attaches to the record the covered entity maintains, not to a derived index of it.

So the realistic end state for most enterprises is not one ontology replacing the systems of record.

It is an ontology that is authoritative for the decisions taken in it and a projection for everything else — which means the boundary between those two has to be drawn deliberately, not discovered during an audit.

Is ibl.ai's own ontology a system of record?

No, and saying otherwise would be selling a property we did not build. The ibl.ai organizational ontology is read-only by design.

The repository is MIT-licensed and describes itself as an on-premise knowledge layer that makes an organization's existing systems — PeopleSoft, Snowflake, Canvas, Salesforce and others — queryable by AI agents over MCP, with no data extraction, no VPN to our cloud and no third-party infrastructure holding your data.

It ships 22 pre-configured system integrations, enforces read-only access through a safety suite that runs before any connection is made, and scopes every query to the caller's identity through role configuration and JWT-based identity.

It deploys as containers inside your network.

Under the four tests above, that is a projection: it originates nothing, the source wins every disagreement, the retention duty stays upstream, and it dies with its inputs.

Which is what you want from a layer whose job is to let agents reason over systems you already run, described further in The Semantic Layer AI Agents Need.

The moment an agent is allowed to write is the moment this changes, and that is a different engineering problem with a different risk profile — the one we examined in Agents That Only Read Are Demos. Origination is not a feature you enable; it is a duty you accept.

If the ontology does become authoritative, who owns it, and what happens at exit?

This is the question the slogan skips, and it is the only one whose answer compounds. Note what it is not: a claim that a competitor cannot deploy on-premise. Palantir's Ontology is a real product, and sovereign and on-premise deployment is a real option from multiple vendors.

The axis that separates them is custody, and it has three parts.

Do you receive the source code? Running software in your own data center is not the same as holding it. With ibl.ai you receive the full source under a perpetual license, so the ontology's schema, its write path and its audit surfaces are things you can change rather than request.

Does the data ever leave? The ibl.ai ontology queries your systems in place. Nothing is extracted into a vendor-side index that becomes its own compliance surface, which is the distinction we drew in What Is Sovereign AI?.

What survives the contract? If the semantic layer has become authoritative for a class of decisions, then losing it is losing records, not losing a subscription. Ask what you hold on the day the relationship ends: an export, or a running system. That answer should be settled at procurement, not discovered at renewal.

And the pricing has to match the shape of the asset. A layer the whole organization reasons over cannot be billed per employee without punishing the exact adoption that makes it valuable — which is why ibl.ai is usage-based against a budget cap you set, with no per-seat pricing.

The standards half of this is deliberately boring, and that is the point: the vocabularies are old and stable.

RDF 1.1 Concepts and Abstract Syntax has been a W3C Recommendation since 25 February 2014, and SHACL, the Shapes Constraint Language for validating RDF graphs against conditions, since 20 July 2017.

A model you swap quarterly sits on top of a formalism that has not moved in nine years.

How should an enterprise draw the line between its ontology and its systems of record?

Draw the origination boundary first, before any agent ships. Everything else follows from that line.

  1. List what the ontology will originate. Approvals, classifications, overrides, agent decisions — the state with no upstream row. That list, and only that list, is what your ontology is a system of record for.
  2. Write the retention and audit rule for exactly that list. If a regulator would ask you to re-create one of those records, the obligation is now yours, not your CRM vendor's.
  3. Keep everything else a projection, explicitly. Label it. A derived graph that nobody mistook for a ledger is a safe asset; one that drifted into being treated as a ledger is a liability.
  4. Settle custody before scale, not after. Source code, data location, and what you hold at exit. Deploy on Agentic OS inside your own perimeter if the answer has to be "we hold all of it."

Start with the slice that drives one real decision, as we argue in How to Build an Organizational Ontology, and let the boundary move outward as deliberately as it was drawn.

1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.

Frequently Asked Questions

Can a knowledge graph be a system of record?

Only for state that originates inside it. A knowledge graph assembled from source systems is a projection: the source wins any disagreement, the retention duty stays upstream, and the graph cannot survive the loss of its inputs.

A graph that captures decisions taken through its own write path is authoritative for those decisions.

Does Palantir's Ontology hold authoritative data?

For edits made through action types, yes. Palantir's documentation states that changes to objects, property values and links are committed to the Ontology when the user takes the action, and captured in the object type's writeback dataset.

That state originates in the semantic layer rather than in a source system.

Is the ibl.ai ontology read-only?

Yes. The MIT-licensed ibl.ai ontology at github.com/iblai/ontology is an on-premise knowledge layer that makes existing systems queryable by agents over MCP, enforcing read-only access before any connection and extracting no data out of your network.

It is a knowledge layer, not a ledger.

Why does owning the ontology matter if the model is interchangeable?

Because the model converges and the ontology accumulates. Stanford's 2026 AI Index puts the gap between Anthropic's top model and the leading Chinese model at 2.7% as of March 2026, so nothing built on a specific model is defensible.

The formal map of your own entities, relations and permissions cannot be re-bought.

Can an on-premise ontology satisfy SEC or HIPAA recordkeeping duties?

Only for records it originates and preserves itself. SEC Rule 17a-4's audit-trail alternative requires a time-stamped trail of every modification and deletion, the identity of the individual responsible, and enough information to permit re-creation of the original record.

A nightly projection of upstream tables does not meet that for the records it reflects.


Sources, all read for this post: Palantir's definition of the Ontology from its Ontology overview and the writeback behavior from its action types overview; the SWE-bench Verified figure and the 2.7% March 2026 model gap from Stanford HAI's 2026 AI Index report; the Strategic Intelligence Platform's scope, source-system count and employee count from its published write-up; the audit-trail alternative and the 3 May 2023 compliance date from the SEC's own summary of the amendments; the standards dates from RDF 1.1 Concepts and Abstract Syntax and SHACL; and the license, integration count and read-only enforcement from github.com/iblai/ontology. One thing was dropped: the sentence that prompted this post — "the future of enterprise AI is a sovereign ontology deployed on-prem that grows into the last system of record" — circulates without attribution, and repeated searches for it verbatim and in fragments found no author, venue or date. It is therefore treated here as an argument to test, not a quotation, and it is not attributed to anyone. A HIPAA citation was also left as prose rather than a link, because the HHS guidance page did not return a readable response in this session.

Why does owning the AI stack matter?

ibl.ai is the agentic AI platform where you own all the code and the data. You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.

  • You own all the code and the data

    Full source code under a perpetual license, running on your infrastructure. Not API access to someone else's platform — the stack itself is yours.

  • Model-agnostic

    Run any LLM — Claude, GPT, Gemini, Llama, Command, or your own fine-tune — and switch providers without rewriting the platform.

  • No per-seat pricing

    Usage-based billing against a budget cap you set. Cost tracks what your organization actually uses, not how many people you employ.

  • Deploy anywhere

    Your cloud, your VPC, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity.

1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University.

ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.

See the ibl.ai AI Operating System in Action

Discover how leading universities and organizations are transforming education with the ibl.ai AI Operating System. Explore real-world implementations from Harvard, MIT, Stanford, and users from 400+ institutions worldwide.

View Case Studies
Work with our team

Pilots, deployment, and full ownership

Most enterprise engagements are one-time, not subscriptions. You integrate ibl.ai with your own data, deploy it on your own infrastructure, and the engineering hours scale with the work — so the price tracks the scope, not your headcount.

Start here

Pilot

from $15K

fixed scope · fixed timeline

A time-boxed proof of value on your real data — not a slide deck.

Best for: Teams that want to see ibl.ai working before committing.

  • Deployed on your infrastructure or our cloud
  • 1–2 production agents wired to a slice of your data
  • One integration (LMS / SIS / SSO / data source)
  • Weekly working sessions with our engineers
  • Pilot fee credits toward a full engagement
Scope a pilot
Most common

Integration & Deployment

$25K – $80K

one-time · not a subscription

Full deployment integrated with your data and systems. Engineering hours scale with scope.

Best for: Organizations rolling ibl.ai out across a department, campus, or business unit.

  • Platform deployed in your VPC, on-prem, or air-gapped
  • Integrated with your data + identity (SSO / SAML)
  • Multiple custom agents built to your workflows
  • Engineering hours proportional to scope
  • You own the data · run any LLM you choose
Plan a deployment
Full ownership

Codebase Transfer + Custom AI Engineering

Custom quote

perpetual license · you own the stack

We transfer the full source code. You own and self-host the entire platform — outright.

Best for: Organizations and enterprises that benefit from perpetual ownership and sovereignty.

  • Complete source-code transfer + perpetual license
  • Dedicated AI engineering team on your roadmap
  • Custom agents, models, and integrations to spec
  • Air-gapped capable · zero vendor lock-in
  • Family-owned, New York–based long-term partner
Talk about ownership
You own the code and data Run any LLM — Claude, GPT, Gemini, Llama Family-owned & operated from New York, NY