Every instrument is blind to something.
A failure that reports success costs more than one that crashes. This is a reference for the moment before you claim work is done: you are about to verify through some instrument, and every instrument is structurally blind to something. Look up what yours cannot see.
v3.0.0 · 30 entries · 6 instruments · updated 2026-08-23
How did you verify?
A rendered image
You captured the page and looked at it. 6 known blind spots → exit-codeA command's return status
The command exited zero, so you moved on. 9 known blind spots → http-responseA status code
You requested the URL and got 200. 4 known blind spots → file-on-diskThe file's contents
You read the config, the stylesheet, or the source and confirmed it says the right thing. 5 known blind spots → process-listWhat is running
You checked ps, pgrep, or systemctl status. 3 known blind spots → log-outputLogs and stdout
You read the output and it looked normal. 3 known blind spots →Entries are filed under the instrument that missed the failure, because that is what you know at the moment you need this — not the bug, which is the thing you are trying to find.
From a terminal
curl verifyfirst.dev/screenshot.txt
Every instrument has a plain-text twin at
/<instrument>.txt — no JSON to parse, no JavaScript, readable
in one fetch.
Principles
- Prefer the resolved value over the authored one.
Configuration files record intent. Computed styles, running processes and served bytes record outcome. When they disagree, only one of them is what users experience.
- A check is only diagnostic if it can come out either way.
An observation that returns the same result under both hypotheses has confirmed nothing, however much work it took to produce.
- Capture errors before adjusting values.
Inert and wrong look identical from the outside. One error capture distinguishes them; no amount of parameter tuning does.
- Know your instrument's failure modes before trusting its readings.
A screenshot cannot see time. An exit code cannot see semantics. A cache cannot see freshness. Each is silent about exactly the thing it cannot represent.
- Distrust the fallback that is good enough.
Degradation designed to be invisible to users is equally invisible to the agent verifying the work.
- Report the observation, not the inference.
'The service is active and returned OK' can be verified by a reader. 'It works' cannot.
- Silence is not evidence of success.
A process that hangs, a branch that logs nothing, and a command that was never reached all produce the same empty output as a clean run.
- Check whether you are inside what you are measuring.
Searches that match themselves and teardowns that destroy their own host are the same error: the observer was part of the sample.
Formats
registry.json — everything, structured
registry.jsonl — one entry per line
llms.txt — orientation
/protocol — the short version, for a system prompt