Open tools for the day someone asks you to show — not tell — what your AI system did. Prevent with ratified policy. Detect when the verified system changes. Prove where every answer came from.
# Prevent is shipped today — install it from PyPI
$ pip install onedoor
Every AI deployment has a sunny-day story: the demo works, the dashboard is green. Then comes the other day — a transfer that should have been refused, an answer citing a document that says the opposite, an auditor asking: what exactly happened, and how do you know? On that day a log is testimony — something your system says about itself, in a form it can quietly change. That day requires evidence: records made before the question was asked, in a form a stranger can check without trusting you.
Observability takes the demo meeting. Evidence takes the deposition.
Different questions, one discipline: a record at every step — from the evidence an answer rests on to the authorization an action required — each checkable by someone who doesn't trust us. Use one alone, or all three together.
Where it fits in a typical AI stack — one picture →
A policy engine for agent actions. Define caps, bounds, and undo windows; ratify a version; every action is then checked against that ratified snapshot — allow, review, or refuse — and every verdict names the exact policy version that decided it.
Change-evidence monitoring. The system you audited on Monday is not automatically the system running on Friday. onewatch keeps verifiable baselines so that when something underneath you changes, you hold a record that it did — evidence, not a feeling.
Forensic provenance for retrieval pipelines. A receipt at every stage — source bytes, cleaning, chunking, retrieval, assembly, the model call — so an answer traces to the exact passage that produced it, and every step can be re-derived from the records alone.
The rules oneproof enforces are not proprietary behavior — they follow a published protocol. AADP, the Agent Action Decision Protocol, specifies per-action authorization for AI agents: how an action is described, how a decision is made against ratified policy, and what record the decision leaves behind.
It is an individual-submission Internet-Draft at the IETF, with a public interoperability fixture and independent external review — so an implementation you write is checkable against the same text as ours.
If a feature is planned, it is labeled planned. If a number comes from a worked example, it is labeled a worked example. Nothing on this site describes what we hope the tools will do as if they already do it.
Receipt chaining, signing, and anchoring exist as options you turn on deliberately — and every claim about them travels with that sentence. A default you didn't choose is not a guarantee you hold.
A verification can come back verified, contradicted, or couldn't check — and couldn't-check is never rounded up to verified. A checker that only ever says yes is a decoration.