Turn judgment into a record.
These tools structure professional review; they do not decide for you. Entries stay in this browser unless you export them.
What a record is for, and why these three
Each tool below turns a judgement you already made into something another person can read. That is the entire function. None of them decides anything, none of them checks anything for you, and a completed record is not evidence that the underlying call was right — only evidence of what you considered, on what basis, and who was accountable.
Why a record and not a memory. The question that arrives months later is never “were you careful?” It is “what did you check, when, and against what?” Recollection cannot answer that and does not age well. A short written record made at the time answers it in thirty seconds.
Why these three. They correspond to the three moments where an AI workflow most often fails in a way somebody else notices: a claim that outran its evidence, information that entered a system it should not have, and a review step that existed on the org chart but not in practice. The three tools sit at exactly those points.
What commonly goes wrong: filling one in after the decision, to paper it over. A record produced to justify a call already made is documentation, not control — and it reads that way to anyone reviewing it later. Build the record while the answer is still open, because that is when it can still change the outcome.
How to start: take a real but low-stakes example, describe it in synthetic terms, and complete one tool end to end. The gaps you cannot fill are the finding — a blank “what the source actually supports” field is telling you something.
Claim verification ledger
When to build one
Whenever a specific sentence is about to leave your hands carrying a fact — a number, a date, a legal proposition, a study result — and someone downstream may act on it. One ledger row per proposition, not one per document.
The fields that do the work
Pinpoint and what the source actually supports are the two that catch real errors. A citation to a sixty-page report is not a citation; a pinpoint is. And writing out what the source establishes, in your own words, is what exposes the gap between the source and the sentence — which is where most defensible-looking claims fail.
What commonly goes wrong
Recording the source you found rather than the source that governs. Commentary is how you discover an authority; it is not the authority. If the row's source is an article about a rule, the row is not finished.
The disposition is the point
Retain, narrow, qualify, remove, escalate. Most rows should not end in “retain” unchanged — if every claim survives contact with its evidence untouched, the ledger is being run as a formality.
Pre-prompt data gate
When to build one
Before the first upload, connector, or prompt in a new workflow — and again whenever the vendor, the plan, the feature, or the purpose changes. Not once per prompt; once per pattern of use.
Why it runs before, not after
Disclosure is the step that cannot be undone. Deleting something afterwards does not establish that sending it was authorized in the first place, and a deletion feature is not a permission.
What commonly goes wrong
Recording the product name instead of the configuration. “We use a major vendor's assistant” is not an answer to what happens to your data — the answer usually differs by plan, by admin setting, and by whether the workspace is enterprise-managed. That is why the field asks for the exact product, plan, and configuration.
How to read the outcome
The gate reports proceed, escalate, or stop on the facts you recorded. It is a completeness check on your own documentation, not a legal conclusion, and “proceed conditionally” means only that you left no required field blank.
Human-oversight control builder
When to build one
Whenever AI output influences triage, ranking, recommendations, approvals, access, or anything touching someone's rights, money, health, safety, or opportunities — including cases where a person still signs at the end.
The three-part test
Oversight is real only if the reviewer has evidence they can inspect, authority to reject, and time to use both. Remove any one and what is left is a signature. The evidence and authority fields exist to make their absence visible on paper.
What commonly goes wrong
Describing the final decision and missing the consequential one. A model that only orders a queue can still decide who waits, and a delay can be the harm. Map what the system actually changes, not the box at the end of the flowchart.
Contest and monitoring are not optional extras
If an affected person cannot find out that a system was involved, or cannot challenge the result, errors are invisible and will not be reported. Monitoring is how you learn about the failures nobody escalates.