What is Coherence
Nearly every enterprise AI deployment reasons out of one vendor's schema. Coherence starts somewhere else: an ontology of one part of your business, tied to the code and documents that prove it, that your people and your agents can both reason over.
We build the platform now. Before that we delivered the projects it exists because of. Core migrations, compliance programmes, system consolidations, mostly in banks and mostly under a deadline somebody else set.
A few years ago I was on a core replacement with a hard cutover date. Halfway through, someone from risk asked a reasonable question. Which of our controls survive this move, and which ones quietly stop working?
Nobody in the room could answer it. The controls were written down in a policy document, implemented in stored procedures nobody had opened in years, and owned by people who had left. We got there in the end. Interviews, a spreadsheet, four weeks. What we handed over was a slide, and the slide was wrong by the review after next.
Then someone asked the question everyone is asking now: where does AI go in this?
The wrong answer is to point a language model at the policy folder and hope its answers agree with the code.
Ungrounded AI is just faster guessing.
This is the first of a series on what Coherence actually is and does. The parts after it take the platform a layer at a time: how source material gets in, what the ontology is and why its shape is fixed, and what becomes computable once it exists.
The pattern is everywhere
ServiceNow, Microsoft, SAP. Every one of them now ships AI that claims to reach across systems. And every one of them reasons out of the schema it owns. What sits outside that schema arrives as a lookup, never as a first-class thing. Your CRM vendor will understand customers better than it understands your ledger, permanently, and not by accident.
Celonis, arguing their own case, put the problem better than we would: "a living, system-agnostic model is the missing layer for Enterprise AI." They are right about the direction. This series is about how that model gets built, where it lives, and what acting on it means.
There is a second half, and it bites first. Producing a confident paragraph about your estate is now nearly free. Checking one still takes a person who holds the whole picture. Menlo Ventures put 96 cents of every enterprise-AI dollar in 2025 into copilots and agents. More claims produced, no more capacity to check them. Faros AI, across 22,000 developers, found senior review queues had tripled.
We have no CRM to defend and no ERP to sell, so the layer we reason out of is the one nobody currently owns. Your ERP holds the record for resources. Your CRM holds it for customers. What none of them holds is what those things mean together.
The inversion, which is the whole of it
Here is the distinction that decides everything else, and it is worth slowing down on.
Every layer in a modern estate models what exists. Your catalogue models the tables that exist. Your architecture tool models the applications that exist. Your service estate models the controls somebody wrote down. All of that is true, useful, and none of it models what is required to exist: the obligation that stands whether or not any system implements it, tied to the passage of law that requires it.
That inversion is why a gap becomes something we hand you rather than something you go and discover.
It also explains the one architectural neighbour worth naming. An operational object layer is genuinely powerful and we don't compete with it. But in that design an object type exists because a dataset backs it. Which means the obligation with no data behind it cannot appear at all. The gap is invisible by construction, and no amount of query sophistication reaches it.
What Coherence is
An ontology of one domain (law, obligations, processes, systems, data, and what every field means in the domain's own terms), with each link tied to the evidence that proves it. Four steps, and the third is the one people ask about.
Read. Schemas, code, procedures, registers, live databases, where they already sit. The database connectors read schema, not rows. Nothing is entered by hand.
Type. Every fact becomes a thing of a known kind (an obligation, a process, a system, a control, a data concept, a risk), tied to the exact line that proves it. No evidence, no entry.
Sign. Extraction runs automatically and audits itself. Your experts resolve what it flags, and publishing a domain is their sign-off. The signature stays inside your organisation.
Answer. Agents answer from the signed ontology. Every claim carries its source, and what is missing is declared rather than filled.
Out of that, three products, all resting on the same property: the ontology is what an answer can be wrong against. Governed answers. Ask the estate anything, and where the evidence runs out it says so instead of improvising. Generated deliverables. Specifications, assessments, impact analyses, letters, chaptered, every chapter naming its sources. Governed change. Modernization run as chartered initiatives through two human gates to cutover, with what ships writing itself back so the ontology can't go stale as the estate moves.
What this changes
Coherence doesn't replace your catalogue, your architecture tool, your GRC suite or your object layer. Each governs its category well. We are the specification layer above them, and a narrow claim is the only honest kind.
What changes is that questions about the estate get computed instead of assembled. Take a permitting practice we modelled end to end, and one of the questions we put to it: what is missing from this project file?
A tracker shows four items marked pending. The ontology returned four absent permits and, for one of them, the finding no tracker can make. The request is not late. It is structurally rejected: filed without two permits it depends on, so the clock was never running. It is back at zero. It also noticed that an earlier approval in the file rests on a permit that expired months ago, so its basis is void; a keyword search would have found that approval and read it as valid. And it read one authority's own history, 96 days against a statutory 30 on every file, as a systemic bottleneck rather than an isolated delay.
That is the difference between reporting a status and being able to act on it. And notice what did the work: the ontology, not search.
Absence is the part that surprises people. Because the kinds of thing are fixed and every connection is named, an obligation with nothing enforcing it is a rule coming back false. Nobody has to notice it.
And it stays current because it gets used. When a change ships through the platform, the same step that records the deployment writes what it built back into the ontology.
One boundary, and it is the one to press us on. That loop closes in the ontology, not in your systems. We show that a file is sitting with an authority and for how long. Not what the official does next. Writing into live systems is roadmap, and so is enforcing what an agent may do at runtime.
What's next
The theory is clean. Real estates are a mess. Next: how the source material actually gets in, and what the platform refuses to guess.
The permitting estate is modelled on synthetic material: real cadastral numbers and real deadlines, no client data. Effort and timing figures in this series are design targets validated per engagement, not warranties. In most markets we have no clients yet, which is exactly why the first step asks for no trust.
This site uses cookies
We use essential cookies for the site to function and analytics cookies (Google Analytics) to understand how you use it. Analytics cookies are only activated with your consent. We do not track you across other websites. Your data is stored in the EU and processed in accordance with GDPR. Read our Privacy Policy
