Symbolic AI and LLMs were never rivals. The ontology is where they meet.

For thirty years the field argued about which kind of intelligence was the real one. Symbolic AI, with its ontologies, logic and rules, could explain every step of its reasoning but knew nothing it had not been told by hand. Neural networks, and now large language models, learned everything from data and explained nothing. In an enterprise, the argument is beside the point. A bank does not need a philosophy of mind. It needs a system that reads a hundred thousand contracts, states what they contain as facts, and reasons about those facts in a way an auditor can follow. Neither tradition does that alone. Together, they do.

What a language model cannot give you

A language model is a superb reader and an unreliable witness. Ask it what a mortgage deed says and it will answer fluently, and usually correctly. Ask it the same question tomorrow, in a slightly different phrasing, and the answer may drift. Ask it to combine what it read in the deed with what it read in the appraisal and the land register, and it will produce a plausible paragraph rather than a verified fact. It has no persistent representation of the borrower, the property or the lien, only text about them. It cannot tell you which of three conflicting values is right, because it has no notion of a value being right beyond sounding right.

This is the root of the two habits that have defined enterprise AI so far: extracting fields from documents, and chatting over them. Both stop at the text. Extraction yields numbers without the relations that give them meaning; chat yields prose without the structure that would make it checkable. Neither leaves behind knowledge a process can build on.

What symbolic AI could never populate

The symbolic tradition had the opposite problem. An ontology says precisely what a mortgage is: a lien, held by a creditor, over a property identified by a cadastral triple, securing a loan with a residual capital, ranked against other liens. From that definition, rules follow: which lien is enforced first, when a claim expires, what a valid collateral position looks like. The reasoning is exact and every conclusion has a proof. The difficulty was always the same: someone had to type the facts in. Knowledge engineering did not scale to a servicer's 130 million pages, and so ontologies stayed elegant and empty.

The ontology as the meeting point

Put the two together and each cures the other. The language model reads; the ontology decides what counts as a fact and how facts relate. The model populates; the ontology constrains, validates and reasons. This is what Altilia's semantic layer is: an ontology-based representation of business-process data, shared by every AI application in the organisation, created and populated by agents rather than by hand.

• The ontology defines the entities, their attributes, their relations and the rules that govern them. It is declarative, so domain experts write it without code, and it is versioned, so every fact can be traced to the definition that produced it.
• Constrained decoding forces the model to produce only outputs that fit the ontology's grammar. A value that does not fit cannot be produced; a value that is produced always has a type, a source span or a bounding box.
• Agents populate the ontology at scale: they classify documents, extract entities and hierarchical objects, reconcile them across sources and write them into the knowledge graph with a confidence score and a provenance link.
• Agents also create ontologies. Given a sample of documents and a description of the process, an agent drafts the entities and relations, an expert corrects them, and the draft becomes a versioned ontology that the next agents will populate.

Reasoning over facts, not over text

Once the facts are in the graph, the interesting part begins. An agent asked which liens rank ahead of the servicer's across a portfolio does not search for paragraphs that sound like the answer. It traverses the ontology: from the portfolio to the loans, from each loan to its property, from the property to its liens, from each lien to its rank and registration date, and applies the rule that defines priority. The answer is a set of facts with a path, and the path is the explanation. GraphRAG is the name for this traversal-based retrieval; the ontology is what makes it possible.

The same holds for the rules a language model tends to blur. Whether a claim has expired is not a matter of interpretation once the ontology defines the interruption events and the agent has populated their dates from the notifications. Whether a collateral position is valid is a check, not an opinion. The model's role is to read and to draft; the ontology's role is to make the conclusion deterministic, repeatable and admissible in a credit committee.

“The language model reads. The ontology decides what a fact is. Together they produce knowledge an auditor can follow.”

Why this is different from extraction or chat

Extraction stops at the field: 330 datapoints per case, disconnected. Chat stops at the answer: a paragraph that cannot be checked. Populating an ontology produces a third thing, a persistent, typed, linked representation of the business that every subsequent agent, app and process can use. The credit memo cites it. The reconciliation view reads it. The regulatory assistant answers from it. The distilled model is trained on it. And because it is explicit, the compliance team can replay how any conclusion was reached.

This is also why small models become viable. A few-billion-parameter model distilled on one ontology matches a frontier model on that task, because the ontology has removed most of the ambiguity the frontier model was spending its capacity on. The intelligence moves from the weights into the structure, where it can be owned, versioned and audited.

Where to start

Choose a process whose documents you already understand and write down the twenty entities that matter to it. Let an agent draft the rest from a sample and let your experts correct it. Populate the graph from real files, with human review where the risk sits. Then ask a question that neither extraction nor chat could answer, one that requires following relations across documents. If the answer comes back with a path you can follow, the two traditions have met.