OTO
oto

The Verifier

An answer is only worth citing if something refused the wrong ones. The Verifier is the part that refuses and measures: the deterministic gates in the engine, the bench and the feedback loop, the two skills that audit the agent's work, and the validation agents that check a graph for completeness and coherence.

Ships today
the gatesprivacy scan, the ontology, the merge, the check, apply by name, the build's refusal, the publishability scan
bencha gold set with recorded provenance, ablations, an embedding baseline or an honest unmeasured
feedbackwhat a reader said about an answer, recorded with a name and promoted into a test
2 skillsevaluate runs the loop; vet-provenance audits every citation against the corpus
rulespolicy findings on every build, listed by oto query policy
Planned, in this order
coherence agentfirst: contradictions and gaps within a graph, and across the graphs of the mesh
coverage agentthen: the questions a domain must answer, against what the graph can answer
Start here
The gates
A refusal, in the complete tutorial
oto bench

The gates, in the order a fact meets them

Ingestthe privacy scan blocks a document that carries personal data; a new version of a file is announced, never silently replaced
↓
The ontologya class or relation the vocabulary does not declare cannot enter; a vocabulary change is diffed against the accepted baseline and its breakage counted
↓
The mergea changed fact is refused: it is a supersession or a mistake; a new id with an existing name is flagged
↓
The checkblocking problems, contradictions, gaps, personal data; a fact without evidence is a gap; an overwrite without a supersession record is a contradiction
↓
Apply and buildapply needs a name and a note; the build is a compiler, refused if the graph uses what the ontology does not declare
↓
Publishthe publishability scan refuses an ontology, a pack or a store that carries a deny term

The gates lists each one in the engine's words.

Determinism is a contract

Given the same inputs, the engine produces the same build. No model is needed to build or to answer. That is what makes the gates trustworthy: a refusal is reproducible, a passing build is reproducible, and a test can assert either. The judgment steps happen outside the engine and enter through the gates like anything else.

The bench, and feedback

oto bench start --project claims        # a gold question set, with who wrote it recorded
oto bench validate --project claims     # refused while the provenance is blank
oto bench run --project claims --ablations
oto feedback record --project claims --question "..." --verdict wrong --by "<who>" --expected "..."
oto feedback promote --project claims

Every report prints where the questions came from before the numbers, and the threats to validity after them. --ablations runs with the graph off and with time off, to show each pillar defends the metric it claims to. What a reader says about an answer becomes a gold question the next run measures. Evaluate is the skill that runs this loop.

The validation agents

The gates check a fact. The validation agents check a graph. Two are planned, coherence first, and neither is built yet:

  • Coherence, first. Within a graph: entities that are one thing under two ids, relations that contradict, facts whose validity windows overlap. Across the mesh: the same thing said differently in two domains' graphs.
  • Coverage, then. A domain has questions it must answer, recorded at the interview. The coverage agent asks each one through the query tools and reports which the graph answers, which it answers without a source, and which it cannot.

Both are agents in the sense of the Agent: they propose findings, and a named person decides. Their findings enter as feedback and become tests.

The coherence agent, first

It runs over a built graph and reports, in this order, what a person should look at:

  1. Two ids, one thing. Entities whose labels or aliases resolve to each other, or whose summaries say the same thing, under different ids. The merge flags a suspect at proposal time; the agent finds the ones that got through, across documents and across time.
  2. Contradicting facts. Two current facts about one entity that cannot both be true: a deductible of 500 and of 750 with overlapping validity, a role that both performs and does not perform a procedure.
  3. Windows that overlap. A superseded fact whose valid_to is after its successor's valid_from, or a chain of supersessions with a gap in it.
  4. The mesh. The same entity in two domains' graphs said differently: the claims graph and the organisation graph disagreeing on who owns a procedure.

Each finding names the entities, the documents, and the sentence that supports each side, and is recorded with oto feedback record so that the fix, when a person makes it, becomes a test. The agent never edits the graph. Its skill will ship with the engine plugin; the mesh check is OTO, over several graphs.

Its pages

The gates. bench and feedback in the reference. evaluate and vet-provenance. Rules.