How the material gets in
Coherence reads the artifacts you already have. Part 2 covers the ingestion layer: what it parses, what a connector actually looks at, how meaning gets bound to code, and what leaves the perimeter.
Read Part 1 — What is Coherence.
Walk a technical team through this layer and the same objection arrives about ten minutes in. The head of data puts it plainly: "We already have a lakehouse and a vector store. What does another platform on top of them buy us?" Fair question, and the right one to open with.
A lakehouse and a vector store exist to hold data at scale and retrieve from it quickly. They do that well. Coherence is doing a different job: turning the artifacts that describe a domain into an ontology of it, with the evidence attached.
Take a control. In a document store, a control is a paragraph in a policy PDF. You can retrieve it, summarise it, ask a model about it. In Coherence, that same control is a thing in an ontology, connected to the obligation that mandates it, the capability that carries it, the system it runs on, and the function that implements it. And because the ontology holds what a control needs in order to be real, a control with nothing implementing it doesn't come back as silence. It comes back as a finding, with a severity and a name against it.
This is the second of a series on what Coherence actually is and does. Part 1 covered what Coherence is: the layer that models what is required to exist, not only what does. This part is about how the material underneath that ontology gets in.
What Coherence reads
Coherence ships parsers for the things that describe how a domain works, rather than connectors for the records it holds.
Source code is broken up along its own structure, so what the platform holds is a real function or class at a real location rather than a slice of text. No evidence, no entry. Nine languages, plus the formats that live around them: SQL and DDL, dbt models, protobuf, OpenAPI, CSV, markdown. That precision matters at the far end. When a control's evidence resolves to code, it resolves to a named function in a named file at a named revision, and you can open it.
Database schemas come in through the connectors, and this is the part that surprises people. The connector reads schema, not rows. Tables and columns, foreign keys, constraints, what must not be null, what must be unique, and how the columns relate to each other. Each column becomes its own item in the ontology, attached to the table that holds it.
That distinction has teeth. Take a document-store backend with no referential integrity at the database level. No foreign keys, no constraints, all the validation sitting in application middleware. A regulated operation running on that has a real exposure, because a write that goes straight to the database bypasses every check the application performs. Coherence finds that by finding nothing to find. Compliance that is enforced by the database and compliance that is asserted by application code are different things, and the connector can tell them apart.
Documents come in through their own parser. Process documentation, procedures, and the regulations that govern the domain.
Interface definitions are the cheapest high-value material in most estates, and the most neglected.
One boundary, and it is a boundary rather than an omission. Coherence does not ingest process event logs. Not from your systems, anyway. The seam is defined and nothing is plugged into it. If your question is what actually happened, at volume, in order-to-cash, that is a process-mining product's question and they are better at it than we would be.
What a new source type costs is worth publishing, because "we can ingest anything" is not a claim. We priced it for a document-store backend we had no connector for: a few weeks for the parser, a couple of days for the template that tells the ontology what to look for in that idiom, and those two together get most of the available schema intelligence. Design estimates rather than a delivery record.
It stays bounded because every route in lands the same way. Connectors, live database reads and file parsing all produce the same shape, so everything downstream is indifferent to where the material came from. A new source type is a new parser, never a new contract.
How a link gets made
The material a system produces and the ontology your domain needs are rarely the same thing. What closes that gap is the least conventional thing in the platform.
The industry does it by searching. Take the control, hunt through the code for something that resembles it. Good enough for a demo, and it never stops being a guess, because a control called "customer consent withdrawal" and the function that implements it may share no words at all.
Coherence goes the other way. Because the kinds of thing are fixed, a control already knows what it would look like if it were real. So before any of your material is read, the ontology writes out what it expects to find: the code that would implement this control, the tables that would hold its data, the interface that would expose it, the procedure that would document it. Then your material is compared against that, in both directions, in one calculation.
Three things about that matter more than the arithmetic.
A language model writes those expectations. It never decides the link. The comparison is arithmetic at a threshold fixed in code, so the same material always produces the same links, and you can re-run it in front of somebody.
The expectation is written down and it is falsifiable. A control records in advance which tables it needs, which columns, how critical it is, and what the exposure is if the thing turns out to be missing. So when the code isn't there, the control doesn't quietly score low. It produces a finding that says what was expected and what it costs.
And a concept that matches half your codebase isn't well connected, it's badly written. Those get excluded rather than allowed to hoover up evidence. It is an unglamorous control and it is the difference between a usable ontology and a hairball.
There is one place we tried this and it failed. Lining up two whole different ERPs against each other, rather than a concept against code, similarity is simply the wrong instrument. Two ERPs don't share a vocabulary space. On our migration pilot, brute-force similarity produced three confident one-to-one matches across two entire systems. So that job now runs on four independent signals that have to agree with each other, and no similarity threshold anywhere. We kept the failed rows. They are the evidence for why the rest of the design exists.
Underneath all of it is an unusual assumption: that the documentation lies. Not maliciously. The way every organisation's documentation lies, by describing an intention that was true once. So the platform doesn't assume good documentation. It assumes drifted documentation and checks it against the code.
A match is a candidate, not a fact
Here is the part most platforms are vague about, and being exact about it is the whole reason to trust the rest.
A match, however good the score, is a candidate. It never becomes a fact by being confident. It sits in the ontology as a suggestion, and it stays one.
Confirmed evidence comes from somewhere else. From a parser that read a declaration and can point at the line. From the build loop, when something ships and the platform writes down what it built. From a person deciding. Those are the three, and none of them is a score.
And the two are held as different kinds of connection, not the same connection with a status field on it. Which means a candidate cannot turn up inside a coverage number, a sealed proof, or an answer given to an auditor. There is no flag anywhere that promotes one to the other. Coverage is always reported as two figures rather than one, and a single blended percentage is the easiest number in enterprise software to inflate.
The consequence is uncomfortable and we publish it anyway. On a freshly read estate, the confirmed number is small. Sometimes zero. The suggested number is large. A vendor with an incentive would show you the large one. A coverage claim a buyer can disprove with one query is worth less than a small true one, so you get the small true one, and you watch it grow as declarations land and as work ships through the platform.
What nobody does is approve links. Not because a machine settles them, but because a link isn't a decision. There are thousands of cheap links to find and a few dozen expensive acts to decide, and only the second kind gets a person's name on it.
What every link remembers
Every connection carries the run that produced it. Not a log kept alongside the work. Part of how the write happens, so "where did this come from" is a question you ask the map rather than an investigation you open.
Along with the run: what the score was, what kind of thing settled it, what corroborated it, and whether the deciding actor was a person or a process. That last one exists so a machine's proposal can never turn up three screens later looking like something a human signed off. And provenance that can't be accounted for is treated as a guess rather than promoted for being unrecognised.
Audit is a property of how the writes happen, not a report assembled quarterly.
How the model stays current. Re-reading, not continuous sync. Push code and the changed parts are re-parsed and re-linked, with unchanged material left alone. On a schedule, the platform compares the estate against the ontology and opens findings where they have drifted apart.
The precise claim is that the ontology is kept current by re-reading, and divergence shows up as a finding. It is not a live mirror of your systems. Drift is flagged for a person and never silently repaired. An ontology that quietly rewrote itself to match whatever it last saw would be a liability rather than an asset.
Who can see what
Most enterprise systems handle security at the application layer. Coherence attaches it to the evidence.
Every read and write belongs to a tenant and fails shut without one. No context means no results, never a fall-back to everything. Retrieval carries the caller's clearance, and material with no classification on it is treated as restricted rather than as safe. Scope is checked when the material is read and checked again at audit, so a citation reaching outside the scope in question fails visibly instead of passing quietly.
That last mechanism is the one we would point at if you asked for evidence rather than architecture. On a real pre-contract engagement, on genuine sponsor documents, an output attributed the wrong vendor to a study. It had borrowed the name from a sibling study in the same deployment. The scope check caught it and failed the audit rather than shipping it as a fact. Fixed and verified the same day, and the limit written down: the check works at the level of things on the map, not yet at the level of the surrounding prose.
Nothing here rests on the machine being right. It rests on its mistakes being the kind that surface.
The perimeter
The whole platform is one set of containers, deployed the same way on a cloud VM in your account or on hardware in your building. No managed database, no external vector service, no third-party search cluster. It stands up inside a perimeter in about a day, and what you evaluate is what runs.
One thing leaves: the reasoning call to a language model, carrying the task at hand, to a provider you choose, under terms that exclude training on your inputs. Everything expensive is computed locally. The ontology, the index, your code, your schemas, your documents and the audit trail never leave.
Two things we won't round up. "Nothing leaves" is not the claim; one thing leaves, and we've named it. And because that one thing is a cloud API, this is not an air-gapped deployment. Running the model locally is something we validate per engagement rather than a checkbox on a slide.
The trade-off
None of this is free. This is one more layer in your architecture, one more system your team has to learn, and one more line on the budget.
If retrieval over documents is genuinely all you need, a vector store will do. If you only need a register of what data exists, a catalogue costs less. Coherence starts to make sense at the point where a claim about the estate has to be provable, where what is absent has to be computable, and where the answer has to survive somebody asking how you know.
And the authoring is design work. The parsers are mechanical; the ontology is not. What Coherence takes off your expert is the plumbing. What it leaves them is judgment about what is true and what should change.
The handoff to the ontology. What comes out of this layer is evidence: parsed, traceable back to where it came from, and ready to be bound to something. Part 3 is that something. What the ontology is allowed to say, why its grammar is fixed in code, and what that refusal costs us.
Figures from our own estates are labelled as such. Effort and timing figures in this series, including the connector estimates above, are design targets validated per engagement, not warranties.
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
