OTO · Ontology-To-Operations · open and free

Knowledge, compiled.

The right information, from the right domain, at the moment of decision.

OTO, Ontology-To-Operations: from enterprise meaning to running agents. OTO compiles what your organisation already knows into a mesh of curated knowledge graphs, one per domain, under the same discipline that makes code trustworthy. People and agents get the right information with the evidence behind it, and the opportunities scattered knowledge hides come into view.

Get started with OTO Read the story Ontology to operations The documentation

Compiled, not collectedthe build refuses what the ontology does not declare

Dated and citedwhen it was true, when it was recorded, which document

Curated by named peoplenothing enters on the agent's word alone

One graph per domaincompounding into the mesh, seams explicit

Ithe problem

The daily dig

Every piece of work in an enterprise begins the same way: someone goes looking for what the organisation already knows. An engineer hunts for the design decision behind the system she is about to change. An analyst follows a procedure that lives in one wiki, references data defined in another, and depends on a policy written by a team he has never met.

The engineerpicks up a task and hunts for the design decision behind the system she is about to change.

The analystfollows a procedure in one wiki, with data defined in another, under a policy from a team he has never met.

The product managerneeds the requirements, the API schema, the infrastructure diagram, and the reason a choice was made two years ago.

Everyonedigs through tools, tickets, shared drives, and, when all else fails, colleagues. The memory lives in people's heads.

IIthe cost · IIIthe false fix

What scattered knowledge costs, and why centralising it fails

The cost is not the lost hours, though the hours are enormous. It is what never happens: the insight that never forms because no one can hold the product decision, the operational trend and the policy constraint in view at once; the change made on an incomplete picture; the incident whose root cause was information that existed but was not present at the moment of decision.

Enterprises know this, so the last decade filled up with knowledge hubs. Pour uncurated data into one place and you get a monolith of content that grows fast and decays faster. And the danger increases: a messy drive announces its own unreliability, a polished hub invites confidence.

Wrong data, acted on confidently, is more dangerous than no data at all.

IVthe insight · Vthe answer

Code is the best-kept knowledge. Bring its mechanism to knowledge itself.

Where in any enterprise is information most stable, most structured, most rigorously defined? In running code. Every concept named, every relationship explicit, nothing ambiguous survives compilation; reviewed before it is accepted, tested before it is trusted, versioned so its history is never lost. That is not an accident of software. It is the mechanism of software.

The highest-quality way to capture knowledge is a knowledge graph built on an ontology: every item given the meaning it carries in the organisation, connected to everything related, each connection itself defined. Structured like code, and more valuable than code, because the meaning is explicit.

The primary artefact of an application is no longer its code. It is the knowledge graph. The code is how the graph executes.

ontology-to-operations · the claim

From enterprise meaning to running agents

A knowledge graph that only sits there is a library. OTO's is built to act. The ontology is the contract between what the enterprise means and what its agents do: every class and relation declared with its reason, every fact dated and cited, and, in the same graph, what can be done, on which entity, through which tool.

1MeaningThe ontology: the classes, relations and rules of a domain, the reason each exists and who confirmed it. Every fact is checked against it.

2KnowledgeThe graph: facts compiled from documents and conversations, each with its date, its source and the sentence; refused when they break the contract.

3OperationsActions declared in the graph and bound to the entities they act on; an agent carries them out, and the response is written back as evidence. Specs and code are written from the graph, not beside it.

That is where this is going: an ontology that carries flows as well as actions, so a process is a graph that runs, with every step's evidence recorded through the same gates. It is why the Agent, the Verifier and the Studio are one system rather than a viewer on a database.

Meaning declared once. Knowledge compiled from it. Action carried out from the same graph, with its evidence written back.

IXthe system

OTO: four parts, one pass

OTO is more a system than a single tool. The Agent reads and proposes, the Verifier refuses what it should, the Knowledge Graph is compiled and served by the engine, and the Studio is where people see it. You use all four; take one away and the others lose their point.

shipping · v0.6.1The Knowledge GraphOne graph per domain, built and served by oto. Every fact dated and cited; a changed fact superseded, never overwritten; a compiler that refuses what the vocabulary does not declare.the Knowledge Graph →

shipping · plugin, 10 skills, 14 toolsThe AgentThe skills an agent loads in Claude Code, or in the harness you prefer: it reads the documents, interviews you about the vocabulary, proposes every fact with its sentence, answers with the source and the date. It proposes; it never applies.the Agent →

shipping · gates, bench, feedbackThe VerifierEvery gate a fact passes, the bench that measures the answers, the feedback loop that turns a reader's verdict into a test. The validation agents are planned, coherence first.the Verifier →

alpha · explorer and reader shipThe StudioThe explorer and the reader today, and a pack's own views. OTO Studio, the portal shown below and in alpha, for discovering a domain, validating a graph and seeing one truth in two faces.the Studio →

the engine of the Knowledge Graph

The engine, `oto`

oto is the command you install, the engine under every part: a folder of documents and conversations in, a gated, dated, cited graph out, served to people through the explorer and to agents through the query tools. Deterministic, Apache-2.0, no model needed to build or to answer. It ships as a plugin for Claude Code, where it is tested, with the skills that know how to do the work; the skills are plain files and the tools a standard MCP server, so another harness can load them, and more are being tested.

Get started with OTO The engine in ten minutes The tutorials GitHub uvx --from "oto-kg @ git+https://github.com/Cynergis/oto" oto --help

VIIthe way of working

Teams build graphs the way they build code

A graph starts as files in a git repository. The agent extracts and correlates; named people curate; the pull request is the gate; the build is a compiler that refuses what the ontology does not declare; the deploy ships the graph to where it is served. Seven steps carry a project from a folder of documents to a cited answer, and the colour of each says which part does it.

the Knowledge Graph, by the enginethe Agentthe Verifierthe Studio

1
Ingestdocuments into a corpus, each one a dated sourceoto ingest --project kb
2
Surveywhat the documents talk about, before any class is namedoto survey --project kb
3
Interviewthe vocabulary, with the question each class answers and who confirmed itoto ontology rationale --strict
4
Proposean agent reads each document and writes its facts as a proposal, each with the sentence it came fromoto draft <slug>, or the build skill
5
Curatethe proposal enters through four gates: the merge, the check, the diff, apply by nameoto curate apply --by <you>
6
Buildthe compiler: refused if the graph uses what the ontology does not declareoto build --project kb
7
Serveto people through the explorer, to agents through the query toolsoto serve --project kb --http 8765

The end-to-end journeys run every one of these on a clean machine. The gates say what each step refuses.

the Studio · the product lifecycle

From Envision to Realize, in the Studio

A product moves through six phases, and every phase is a set of facts in the same graph: the problem and its opportunity, the personas and their journeys, the bounded contexts and the system design, the components and their tests, the runbooks and the incidents, the value realised against the target. Nothing is a document beside the product; everything is the product's graph, read in the Studio. What ships today, and what the Studio adds →

Envision
Discover
Design
Build
Operate
Realize

Envision: the problem statement and the opportunity, as facts with their sources — **Envision** the problem and the opportunity, stated and sourced.

Discover: a user journey told as an arc, tied to its persona and realised by use cases — **Discover** personas, journeys, use cases, requirements, policies.

Design: the system map, the product in its world with the actors and the external systems — **Design** business processes, bounded contexts, the context map, the system design.

Build: acceptance tests in given, when, then form, each passing — **Build** platform, components, integrations, agents, tests, evals.

Realize: value realised against the target, rolled up from the lifecycle graph — **Realize** outcomes against targets, the value realised, the go-forward decision.

The Design phase in detail: the architecture

Design is where the architecture lives, as facts: the bounded contexts and how they relate, the system in its world, the decisions with their status, the components with the requirements each implements, the stack and the resources each binds to.

Bounded contexts of the product, each core, supporting or generic, with its use cases — **Bounded contexts** each a boundary where one model and one language hold.

The system map: the product in its world with actors and external systems — **System map** the product in its world, actors and external systems.

Design decisions as architecture decision records, each with its status — **Decisions** architecture decision records with their status.

Components to build, each implementing its requirements — **Components** each implementing its requirements, on one wall.

Stack and resources: environments and the resources each module binds to — **Stack and resources** the environments and the resources each module binds to.

VIthe compound

From graphs to a mesh

One knowledge graph per domain, each with its ontology, its rules and its provenance, with explicit seams between them. Graph by graph they compound into the enterprise knowledge mesh: the connected knowledge of the whole organisation, which people read in Studio and agents ask through the concierge.

A question travels straight to the knowledge that answers it, no hierarchy in between, and everything that flows carries its meaning, its evidence, and its date.

A bounded context's knowledge graph in OTO Studio: 141 nodes and 247 facts, every one citable by id — **Studio** a bounded context's knowledge graph on the sample organisation, every fact citable by id.

The claims business workflow end to end, across six bounded contexts — **The workflow** a loss is reported, the claim is settled, across six contexts.

The oto explorer with an entity open: its status, dates, source and connections — **The explorer** an entity with its status, dates, source and connections.

VIIIthe generalisation

Everything becomes a graph

Product teams are only the beginning. Teams that own policy express policy as a graph, every rule connected to what it governs. Platform teams express infrastructure as a graph that generates the code that creates the environments. A domain starts from an ontology and installs as a pack: the ontology, the skills that know how to use it, the views that show its graph.

insuranceauto-claimsMotor vehicle claims: policy, coverage, claim, incident, handling, money in and out.ontology auto-claims@2 organizationorganization-processHow an organization works: units, roles, processes, policies, systems and measures.ontology organization-process@1 professional-servicesprofessional-servicesEngagements: scope, deliverables, governance, sessions, decisions and the work that follows.ontology professional-services@1 softwaresoftware-architectureSoftware estate: systems, components, interfaces, data, environments, decisions and risks.ontology software-architecture@5

Browse the catalog · in Claude Code: /plugin marketplace add Cynergis/oto-registry

open and free

Open and free.

OTO is open source and free, and stays so: the engine is Apache-2.0, and the ontologies, packs and skills in the catalog come with it. Everything on this site runs from the repository: clone it, run the journeys, build a graph of your own documents, and tell us what broke.

Use itInstall the plugin in Claude Code, or your preferred harness, have the agent build a graph from a folder of documents, see it, ask it, correct it. Thirty minutes, run for real before it was published.getting started →

Test itEvery path a person or a team takes, as runnable commands, on a clean machine.the journeys →

ContributeWe are looking for contributors: an ontology for a domain you know, a view, a skill, a bug with a document that reproduces it. A sign-off, no licence agreement.how to contribute →

Follow itReleases are tagged and described; the docs on this site are generated from the release they name.the changelog →

Xthe transformation

Every graph makes the next one more valuable.

Every connection makes every agent smarter. And the daily dig simply ends.

Get started with OTO The engine in ten minutes The repository on GitHub uvx --from "oto-kg @ git+https://github.com/Cynergis/oto" oto --help