OTO

Documentation

OTO, Ontology-To-Operations: from enterprise meaning to running agents. The oto command is its engine. It builds a temporal knowledge graph from your own documents and conversations, gates every fact through a declared ontology, keeps its date and its source, and serves the graph to people and to agents. It is free while OTO is in beta, Apache-2.0, and needs no model to build or to answer a query. An agent asking in your own words brings its own.

Most of these pages are generated from the engine at release v0.6.1, so they cannot drift from what the terminal prints. The tutorials were run before they were published; the output on them is the engine's.

Start here

  • Getting started: install the plugin in Claude Code, have the agent build a graph from a folder of documents, see it in the explorer, ask it, correct it, measure it. Thirty minutes, run for real before it was published.
  • The engine in ten minutes: oto alone at a terminal, through uvx, from a pack to a cited answer.
  • Install in Claude Code: the marketplace, the engine plugin, a pack, the query tools as an MCP server.
  • FAQ: whether a model is needed, where your data goes, private registries, what free means.

OTO

The solution, then its four parts:

  • OTO, the product: What OTO is, its four parts, how a team uses it from a folder of documents to answers, who does what at each step, and where each part's pages are.
  • The Knowledge Graph: One graph per domain, built and served by oto. What ships today, what is planned, where to start.
  • The Agent: The skills an agent loads in Claude Code to read, interview, propose, curate, answer and write from the graph. What ships today, what is planned, where to start.
  • The Verifier: Every gate a fact passes, the bench that measures the answers, the feedback loop, and the validation agents. What ships today, what is planned, where to start.
  • The Studio: The face of the graph: the explorer and the reader today, a domain's own views, and OTO Studio. What ships today, what is planned, where to start.
  • The explorer and the reader: The two views the engine ships, what each shows, when to use which, and how a domain gets a view of its own.
  • The product lifecycle in the Studio: Envision, Discover, Design, Build, Operate, Realize. What each phase puts in the graph, and what the Studio shows for it, on a sample insurer's product.
  • A graph per domain, and the mesh: Why there is one graph per bounded context, how ontologies let them join, and what the mesh is that OTO builds over them.
  • Knowledge shipped like code: A graph lives in a git repository. A push ingests, an agent authors on a branch, the pull request is the gate, the merge deploys.

Tutorials

One complete loop, then three short ones that build on it:

  • From a document to a cited answer: The complete loop on one real document. Ingest it, survey it, propose its facts, pass the gates, build, ask. Every output below is what the engine printed.
  • A correction made in conversation: Someone says a figure changed. Capture it as a dated source, supersede the old fact, and ask what was true before.
  • Ask the graph: Every question the graph answers, at the terminal and over HTTP, with what each one is for.
  • Your vocabulary becomes a pack: Accept the vocabulary, export it as an ontology, wrap it in a pack, and install it in Claude Code for the next team.

Examples

Where OTO is used and how, one page per domain:

  • Claims operations at a motor insurer: Procedures, roles, coverages and the claims that move through them, with what changed and when.
  • The software estate: Systems, components, interfaces, data, environments, and the decisions behind them, written down once and re-read by the next spec.
  • A product through its lifecycle: Envision, Discover, Design, Build, Operate, Realize. One graph per product, and the same graph for an internal tool.
  • Report automation in an investment firm: An analyst and an agent define a report, discover its data, and hand it to a factory that builds, tests and runs it. The graph is the contract.
  • How an organisation works: Units, roles, processes, policies, systems and measures, so that a question about who does what gets one answer.
  • A professional services engagement: Scope, deliverables, governance, sessions, decisions and the work that follows, so that what was agreed is what is delivered.

Concepts

One page per section of the engine's architecture document, in its order:

Guides

Reference

  • The command line: every command, verb and option, from the engine's own help, and where to use each.
  • Skills: the ten playbooks an agent loads when the task matches.
  • Changelog: the releases.