OTO

OTO, Ontology-To-Operations: from enterprise meaning to running agents. Published by Cynergis.

See it running: the guided demo walks through the Studio over a knowledge graph OTO built for a sample insurer. The story and the documentation are at oto.cynergis.org.

Names. The command, the import name and the repository are oto. The distribution is oto-kg, because oto was taken on the package index. Two namespaces, one tool: what you type is oto.

OTO builds a temporal knowledge graph from your own documents and conversations, then serves it to a natural language agent.

It is domain agnostic. You declare your domain vocabulary in one config file. OTO compiles your curated graph into a queryable store, and refuses to build if the graph uses vocabulary you did not declare.

What is core, and what is a pack

The core is the knowledge graph's lifecycle with its tools, the estate and the reified model it is described in, and the deploy of the graph, because what is deployed is the graph. Everything else is a pack: an ontology with the tools that work on it, loaded only when a project composes it. An architecture framework is a pack plus an adapter, and a pack of the registry rather than of the engine (ADR-0008): CALM today (calm@cynergis), C4 when someone needs it, so a framework is swapped by installing a pack, never by changing the engine, which ships none. Work, data, policy and the domain model are packs the same way, and leave the engine for the registry in turn (ADR-0010), the domain model (ddd@cynergis) first. A domain vocabulary is a pack of the registry too (ADR-0011): the engine ships one vocabulary, oto-core, its own schema, and no other; the estate (portfolio, product, software-architecture), the reified model (architecture, with oto arch and arch_context in its own code) and every other domain are installed per project (oto pack add <name>, or /plugin install <name>@cynergis), and oto init --ontology <name> composes them from the installed pack. An ontology is made in a workspace of its own, a pack in the making (oto pack new), and a knowledge project derives its vocabulary from the packs it composes and does not edit it (ADR-0012). What someone builds on the graph, the software factory first, is a use case and lives in a repository of its own (ADR-0007, Cynergis/oto-factory). ADR-0006 records the line; oto --help prints it.

What makes it different

Most retrieval systems answer "what does a document say". OTO answers "what is true now", and shows why.

• Bi-temporal facts. OTO separates when a fact was recorded from when it was true.
• Supersession, never overwrite. A correction retires the old fact and keeps it queryable.
• Provenance on every fact. Each node and edge cites its source.
• An integrity gate. The build fails on undeclared vocabulary, so the model cannot drift.
• A versioned vocabulary. oto ontology check says what a schema change breaks, and how many nodes and edges it touches, before you ship it. Classes declare typed attributes, so "how many open claims" means the same thing on every node.
• Recorded reasoning. Every class carries the question it answers and who confirmed it, so the model is reviewable and "validated" is a count rather than an opinion.
• Questions that run. The competency questions a vocabulary exists to answer are written once, in the engine's pattern language, and run: every term must be cited by one, every ontology's sample must answer them, kg_ask answers one with the rows or the gap, and the build renders each as SPARQL so a reader with standard tools asks the same thing.
• Briefs that block. What an agent must know before a task is a brief: the questions it must be able to answer. kg_brief implement-step STEP=... is READY with the facts, or BLOCKED by name with the gaps, before a line is written.
• Shapes that gate. Cardinality, required attributes and policy rules are declared beside the terms, evaluated by the engine before a change enters the graph, and written as SHACL that a test holds to the same verdicts.
• Rules that explain themselves. Declared rules derive the facts a person would infer and flag what a policy forbids. A derived fact is marked in every answer and explained down to the documents it rests on; it is never written into the graph.

In a repository, a change enters main by one of three routes, decided by what the pull request carries (ADR-0013): confirmed by the person who made it in their Claude session, it merges on its own; drafted by the pipeline from documents, it waits for one review, given in a preview of the graph; drafted from transcripts, it merges when five guardrails hold. One check, oto route, enforces the route.

Status

Early development. The engine was extracted from a working private system that holds 1,918 nodes and 3,640 edges across about 100 documents, and is developed here.

Install

The engine is not on a package index; it installs from this repository.

The repository is public: uv and pip clone it like any other git dependency, with no credential. A workflow that installs the engine from a private fork instead sets the secret OTO_ENGINE_TOKEN (see repository mode below).

The extras name what a machine needs beyond the stdlib engine, and they combine inside the brackets. all is every one of them; a machine that only serves needs none.

This is the beginning of the README. Read the rest at the original. Read the full README ↗