examples

The software estate

The question people ask: what talks to what, where does this data live, who decided that and why, and what would break if we changed it?

What feeds the graph: architecture documents, decision records, runbooks, the platform wiki, incident reviews, and the specs that engineers and agents write from the graph itself.

What the graph holds

Class	For example
`System`, `Component`, `Interface`	the payments platform, its payment API, the interface a partner calls
`DataStore`, `Environment`, `Repository`	the ledger database; production, staging; the repository that implements a component
`DecisionRecord`, `Risk`, `Runbook`	the decision to move the ledger to Postgres, the risk it retired, how the component is operated
`Team`, `Capability`, `Requirement`	who owns it, what it supports, what it satisfies
`Document`	where each fact is written

Relations say that a component depends_on another, reads_from and writes_to a datastore, runs_in an environment, is owned_by a team and decided_by a decision record; a risk threatens a component and is mitigated_by a decision or a runbook; a decision supersedes an earlier one.

A cited answer

oto query --project platform entity "Payments platform"
oto query --project platform explain datastore.ledger
oto query --project platform neighbors "Payment API" depends_on

The answer to where does the ledger live names the datastore, the decision that put it there, the date, and the document. explain says which of those facts a rule derived, and from what.

Specs and decisions, from the graph

The spec skill writes a product spec or an architecture decision from the graph. Every claim in it cites an entity, a mandatory section says what the graph does not hold, and the decisions it makes are listed in a shape the pipeline turns into DecisionRecord facts. The next spec starts from recorded decisions instead of re-deciding them.

On the OTO front page, the Design phase shows what this looks like in Studio: the bounded contexts, the system map, the decisions, the components and the stack of one product.

How it is used

An engineer joining the team asks the agent what the payment API depends on and gets the components, the datastore and the decision that shaped them.
An architect proposes a change; oto ontology check says which existing edges a vocabulary change would break, and oto curate check says which facts a graph change would contradict.
A platform team treats its internal tools as products: each one has a graph, and the mesh answers across them.

The commands and the skills

oto init --name "Acme Platform" --ontology software-architecture --project platform
cp ~/docs/platform/* platform/inbox/ && oto ingest --project platform
oto rules check --project platform          # the derived facts a rule would add
oto build --project platform
oto query --project platform entity "Payments platform"

Skills: build-knowledge-base, spec, query-knowledge. Concepts: rules and derived facts.