Coherence Ontology Studio

Where the model is built, by your own team, without writing code.

Ontology authoring.

You choose which parts of the business to model. The platform reads your material and proposes what it found. Your experts decide what is correct, and what they confirm is the model.

The output is one part of the business written down once, with the source named behind every statement. It is reusable, and it tells you when it needs attention.

The Studio: the elements and the named connections proposed from the client's own material, each card showing its health and its evidence
the Studio · proposed from your material, confirmed by your expertsclick to enlarge ⤢

The material it parses.

Parsing is deterministic. No language model touches this step, and the same file reads the same way every time.

Policies and rules

Internal policy, external regulation and the controls that enforce them.

Process documents

Procedures, manuals and operating instructions: how the work is described today.

System inventories

Application registers, architecture documents and integration lists.

Database schemas

Table and column definitions, exported from your databases.

Interface specifications

API definitions and message formats, read structurally.

Registers and tables

Risk registers, control lists and inventories kept as spreadsheets.

The build sequence.

Domains first, then extraction into the fixed set of types, then your experts confirm. Only then the optional link down to the systems that implement it.

01 · Scope domainsYou pick what gets modelled: how the work runs, the rules that govern it, who owns what, the systems and the data. Nothing outside that scope is touched.
02 · IngestionThe platform reads your documents and proposes what it found: the things that exist in your business and the connections between them. Every proposal has to fit the fixed set of types, so the result comes out the same shape every time.
03 · ValidateYou accept, correct or reject each proposal. What your experts confirm is the model.
04 · LinkageConnect the code, the database schemas and the interfaces, and each part of the model is matched to the part of the system that implements it. When something changes underneath, everything attached to it is flagged for review.

The checks that run during the build.

What the platform proposes has to survive checking before it can be published. Five controls do the checking, and none of them is optional.

Evidence-only fieldsA field is filled only from text your material supports. Empty means unknown, and the platform does not guess. Where the evidence is indirect, the element is marked for investigation instead.
A grade on every elementA separate audit challenges each element and grades it green, amber or red, with the reason and what would fix it. The grade sits on the card your experts work with.
Targeted questionsWhere a domain is thin, the platform asks your expert specific questions about the gap. The answers are extracted into the model like any other source.
Investigation of disputesAn element in doubt is broken into specific questions and put to the people who know. The thread and its resolution are kept, and a wrong turn can be rolled back.
The publish gatePublishing is the only way into the live model, and the checks are re-run at that moment, on the server. A red grade or an open investigation blocks it.

Keeping the model current.

The checks do not stop at publish. The model records every change made to it, and it flags when the material underneath it changes.

A record of every changeCreate, update, connect and delete all leave a record: what changed, what it replaced, and who or what did it.
Source driftSource files are fingerprinted. When a document changes, everything built on it is flagged for re-review, and a correction your experts already made is not silently overwritten.
Review on demandA review pass reads the whole domain and reports structural gaps, missing connections and thin areas, each as a proposal for your experts to accept or reject.
Proposals onlyYou can ask questions of the domain while you build it, and the answers can carry proposed changes. A proposal is reviewable, and nothing is applied until one of your experts accepts it.
The Studio mid-build: a compliance domain of 93 elements and 327 named connections, each card carrying its grade, with a warning that source material has changed and twenty elements need review
the Studio · a source changed, twenty elements flagged for reviewclick to enlarge ⤢

The other three products.

All four read and write the same model. See the whole platform.

Coherence Explorer

Ask it, and the answer names its sources. Test a change and see what it touches before you commit.

Coherence Change Orchestrator

Any initiative modelled on the transformation map, then driven through two gates to the work packages that land it.

Coherence Compute Engine

The compute under the other three. Nobody opens it directly, and it is what makes the same material give the same answer every time.

See a worked example.

Three are open to explore, or start your own first domain with five documents.

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