Before your company needs AI, it needs a model of itself

Walk into a 120-person company and ask for the sales pipeline. You will get a number. Ask three more people and you will get three more numbers, each from a different spreadsheet, each defended with conviction. One of those spreadsheets is real. The other three are copies, exports, or somebody's private fork from March. Everyone senior knows which one is real. Nothing in the company's systems does.

Now put a frontier AI model in front of that company's documents and ask it the same question. It will answer fluently, with a number, and it will have no idea which spreadsheet it just trusted. That, in one scene, is the state of enterprise AI in 2026: extraordinary intelligence, grounded in nothing.

The failure is grounding, not intelligence

When an AI deployment disappoints a mid-sized company, the post-mortem almost always blames the model. The model was not the problem. The current generation of frontier models can reason through a supplier dispute, draft a board pack, and reconcile a month of invoices. What they cannot do, because nothing has told them, is know which of your systems holds the truth, which person owns which number, and what "the onboarding doc" means when the head of sales says it versus when the head of people says it.

The industry's default answer is retrieval: embed the documents, search by similarity, stuff the nearest chunks into the context window. This helps, and it fails in a specific, predictable way. Similarity search has no concept of authority. It can find four documents that all claim to be the pipeline; it cannot know that the company trusts one of them. It retrieves what was written, with no model of what is true. A company does not run on its documents. It runs on a structure the documents only partially describe, and that structure lives in the heads of about six people.

The fix is to write the structure down.

A model of the company, in plain terms

An ontology is a word with an intimidating history, so here is the plain version: it is a small, accurate, versioned model of what your company actually is. Departments and who reports where. Seats, meaning roles with owners, not just names on an org chart. The entities your business revolves around: clients, suppliers, products, projects. The systems you run and, crucially, which system is authoritative for which number. Metrics with named owners. Processes, as they actually flow rather than as the wiki says they flow.

The figure below is an excerpt of one, with the edges that matter labelled.

In ARX this is the Company Ontology, and it is a first-class object: a typed graph of org units, seats, entities, systems, artifacts, metrics and processes, with edges that carry the semantics. Owns. Reports-to. Authoritative-for. Supersedes. The edge set is deliberately small. The point is not to build a philosophy of your business. The point is to record the two hundred facts that every senior hire spends six months absorbing, in a form a machine can consult on every single question.

Some of those facts appear in no document at all. Which spreadsheet is real. Who actually approves a payment over a threshold, as opposed to who the policy PDF says approves it. Whether "BDL" is a client, a project, or both depending on the sentence. An ontology is where the unwritten company gets written down.

Why curated beats crawled

The tempting shortcut is to infer all of this. Point a system at the document store and the message history, let it cluster, and out comes an organisational graph without anyone spending an afternoon in a workshop. We reject this approach, and the reason is arithmetic. A 300-object ontology that is accurate beats 30,000 inferred objects that are stale, because the ontology is consulted on every question, and its error rate compounds across everything built on top of it. Inference produces plausible structure. Companies do not run on plausible structure; they run on the actual one, including the parts that changed last month when two departments quietly merged.

There is also a boundary worth stating plainly, because the industry's habits run the other way: a company's model of itself belongs to that company alone. In ARX there is no cross-customer ontology, no shared embedding space, no learning transferred between deployments. What one company teaches the system about itself is not an input to anyone else's.

So the Company Ontology is curated, not crawled. Connected systems and the seeded knowledge base propose candidates, and proposals become facts only when a person commits them. Inference suggests; humans decide. The graph is versioned, every revision is attributable, and a reorganisation is an edit with history rather than drift the system silently absorbs. Accuracy is the product. A small graph you can trust completely turns out to be worth far more than a large one you have to second-guess.

What changes when the model knows the structure

The reason to do this work is what it buys you downstream. Three things change.

Retrieval stops being a similarity contest. In ARX, grounding runs as a staged pipeline, and the ontology participates at both ends. Before anything is ranked, the asking seat's permitted corpus is computed from its identity and its position in the graph. We call the invariant Scope-Before-Ranking, and it means content outside a seat's scope is never scored at all, so it can never leak into an answer through a ranking side channel. Then, during candidate generation, the pipeline walks ontology edges: a question touching a client pulls that client's neighbourhood, its processes, its owners, its authoritative systems, into scope. At the fusion stage, authority weighting prefers the source the graph marks authoritative-for the subject. The CRM's pipeline number outranks a stale export of the CRM's pipeline number, structurally, every time.

The figure below sets the two approaches side by side.

Alongside the graph sits the Taxonomy, the company's controlled vocabulary, and it earns its keep on the ambiguity that plagues every internal search. When the head of sales asks for "the onboarding doc," she means client onboarding; when the head of people asks, she means employee onboarding. The taxonomy resolves the reference per seat and per department before the question ever reaches the model, which is why nobody at an ARX company has learned to write careful, lawyer-like prompts. They ask the way they would ask a colleague, and the structure absorbs the ambiguity.

The structure shapes answers on the way out as well. When ARX reports a metric, it names the owner and the source of truth from the graph: the pipeline is the CRM's number, labelled as the CRM's number, owned by the head of sales. Context assembly is deterministic with respect to its inputs, so the same seat asking the same question over the same corpus gets the same grounding. Answers become reproducible, and when one looks wrong, it is diagnosable rather than mysterious: you can see exactly which sources were assembled and why.

Permissions become structural instead of procedural. Most enterprise AI handles access control as an afterthought: retrieve first, filter what the user should not see, hope the filter holds. Deriving scope from the ontology inverts that. A seat's knowledge surface follows from what it is: its department, its role, the processes and entities it owns. When someone changes roles, their scope changes because the graph changed, not because an administrator remembered to update a permission matrix.

Action policy inherits the same vocabulary. Once an AI can act on real systems, sending, updating, invoicing, the question of what it may do has to be answered somewhere. Expressing that policy in ontology terms, which seats may act on which systems and which entities, produces rules that survive personnel changes, because they bind to the seat rather than the person. The policy for the head of finance seat holds through three different heads of finance.

There is a quieter benefit underneath all three: when the model upgrades, the structure holds. The week Fable 5.1 went live in ARX, every deployment got a better reasoning engine inside the same ontology, the same scopes, the same policy. Intelligence became cheaper; the model of the company kept its value.

Infrastructure, not installation

None of this is glamorous work. Building an ontology means sitting with a leadership team and asking questions that sound almost insultingly basic. What are your departments, really? Who owns revenue? Which of these four spreadsheets do you trust? It is closer to civil engineering than to software installation, and that is precisely why it does not happen when a vendor ships a wizard and wishes the customer luck.

This is why we build the ontology with the customer, forward-deployed, before anyone logs in. Modelling a company is a skill, the unwritten facts surface only in conversation, and the graph must be right before anything downstream can be trusted. A company's model of itself is the foundation the rest of the system stands on. Get it accurate, keep it accurate, and the intelligence on top finally has something to be intelligent about.

ARX is the Company AI Operating System built on this idea. The product page covers the whole system.