Ask two departments what a "customer" is and you will get two answers. Sales means anyone who has signed. Support means anyone with an open account. Finance means anyone who has been invoiced. People cope; they learn which meaning applies where. Agents do not, unless someone tells them.
That is what an ontology is for. It describes your business in your own terms: the kinds of thing that exist (customer, ticket, service, contract), and how they relate (a customer raises a ticket; a ticket concerns a service). A knowledge graph then fills that description with your actual records. With both in place, an agent can follow a question from a complaint to the service, the contract and the change that caused it, rather than guessing at connections from text.
The problem with ontologies
Ontologies have a reputation for being worth it and never finished. Building one traditionally needed a specialist, a modelling tool and a series of workshops in which the specialist translated what the business people said into something the tool would accept. The people who knew the business were one step removed from the model of it, and every change went through the same queue.
So we asked a simple question: what if the person who knows the business could describe it, and an agent did the translation?
Ontology Studio
In Camaan, the ontology pages are now a studio, with Kai, our builder agent, beside them. You describe your work in plain words, and Kai proposes the types and relationships. In our own end-to-end test, run against a real model, a plain description of an IT service desk became four types, Customer, Ticket, Service and Support agent, and three relationships: a customer raises a ticket, a ticket concerns a service, and a ticket is handled by a support agent. Asking to "add service level agreements" then extended it, and the page updated as Kai wrote.
Three rules keep this safe for someone who is not a modeller:
- Propose before writing. Kai shows what it intends to create and waits for the person to approve it, unless told to go ahead.
- Never overwrite. Kai adds to an ontology; it does not replace or redefine types that are already there.
- Plain words. The conversation stays in business language. The person never has to know what a relationship type is called in a schema.
Every write is an action like any other in Camaan, so it is decided by your rules and signed into the audit ledger with who approved it.
Filling the graph
A model of the business is only useful once it holds the business. Camaan fills the knowledge graph from three kinds of source.
Records
Tables from your systems, held or federated in the lake engine, are mapped onto the ontology's types, with lineage from each source to every answer built on it.
Documents
The knowledge base reads the files organisations actually keep, not just this year's Office documents: old Word and PowerPoint files with their speaker notes, spreadsheets with macros (values only; macros never run), multi-page scans, whole mailboxes with every attachment, and engineering drawings in DXF and DWG. Scans are read by OCR that runs on your own servers in twelve writing systems, including Devanagari, Arabic, Chinese and Japanese, Korean and Cyrillic. Entities and relationships drawn from text stay linked to the passage they came from.
Code
Source code is parsed, not guessed. Python, JavaScript and TypeScript, SQL, COBOL, shell scripts and configuration files are read by parsers into the same graph, and prose that mentions a function or a table is linked to it. For a bank migrating a mainframe, that means the policy document, the COBOL program and the table it writes can sit in one picture.
Rules first, models second
Relationships in a knowledge graph are where errors hide. A loose extractor will happily connect two things because they appeared in the same sentence. We extract deterministically first. Where a model is needed, a specialised decision model can propose a relationship, and it is accepted only above a confidence threshold, with a general language model as the fallback. The rule we follow is the same one we apply to arithmetic: use a model for judgement, and only where the cheaper, checkable method cannot decide.
One picture for everything
The ontology is not a side project. It is how the rest of the platform agrees on what things are. Agents answer in your terms and follow relationships rather than infer them. Scenarios ask the same question the same way against the same types, so recurring reports repeat. Digital twins model assets and how they connect using the same types. And when you install an offer from the marketplace, its industry knowledge maps onto your ontology rather than arriving with its own.
Try it on one process: describe one area you know well, such as a service desk, a claims queue or a maintenance backlog, in a paragraph. Let Kai propose the model, correct it twice, and see how close the result is to how your team actually talks.
Product details describe Camaan as of November 2026.