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.

v7.2.0 · 90 entries · 6 instruments · updated 2026-08-24

What did you just do?

• I deployed a static site Files copied to a web root, or pushed to a host that serves them. 6 checks
• I restarted a service A systemd unit, container or daemon was reloaded to pick up new code or config. 6 checks
• I changed a configuration file A config, stylesheet, env file or manifest was edited. 6 checks
• I checked that a page renders correctly A screenshot, headless capture or visual review was used to judge a page. 8 checks
• I ran the test suite and it passed A test run reported success. 4 checks
• I ran a script or pipeline A shell script, CI step or command pipeline completed. 8 checks
• I fetched or scraped a resource A URL was downloaded, an API called, or a page parsed. 8 checks
• I read the logs and saw no errors Log output, journal or stdout was inspected for errors. 5 checks
• The machine is slow, or something ran out of memory Memory, CPU or load average was inspected to explain slowness, a stall, or a container or process being OOM killed. 5 checks
• I published a package or release An artifact was uploaded to a registry, or a release was cut. 4 checks

Preflight checks by task, for the moment before you say a thing is done — when nothing has gone wrong yet and there is no symptom to look up.

Or: what are you seeing?

• The page renders blank Nothing visible, but the DOM may be complete and merely invisible. NS-010 NS-002 NS-004 NS-052 NS-072
• The deploy ran but nothing changed The new code is on disk. Something between disk and user is still serving the old one. NS-005 NS-007 NS-008 NS-026 NS-038 NS-058 NS-059 NS-084
• The command succeeded but had no effect Exit zero describes the process, not the outcome you wanted. NS-005 NS-015 NS-016 NS-014 NS-053 NS-055 NS-056 NS-080 NS-081 NS-082 NS-086
• The service says active but is not working Active is a statement about a process existing, not about it serving. NS-026 NS-027 NS-005 NS-037 NS-038 NS-087
• An animation or counter never moves Frozen at frame zero is indistinguishable from correctly static. NS-001 NS-002
• The tests pass but the feature is broken A test that never ran, and a test that asserts nothing, both report green. NS-017 NS-018
• The API returned 200 but the data is wrong The status describes the transaction, not the payload. NS-020 NS-021 NS-019 NS-025 NS-042 NS-045 NS-057 NS-058 NS-075 NS-076 NS-078
• My config change is being ignored The file records intent. Something later, or something else, decided the outcome. NS-003 NS-023 NS-008 NS-046 NS-060 NS-061 NS-062 NS-083 NS-084 NS-085
• The logs show nothing useful Silence is produced by a filter, a rotation and a crash alike. NS-029 NS-028 NS-011 NS-031 NS-032 NS-033 NS-034 NS-066 NS-067 NS-068 NS-088 NS-089
• A process died and I cannot tell why The thing that was killed is often not the thing that caused it. NS-011 NS-013 NS-014 NS-031
• A URL returns 200 for something that does not exist A catch-all answered on the origin's behalf. NS-022 NS-007 NS-043
• Clicks land on nothing The element you can see is not the element receiving the event. NS-030
• The wrong file or image was used A plausible artifact of the right type is not evidence it is the right one. NS-006 NS-004 NS-048 NS-062 NS-056 NS-083 NS-077
• Text renders, but it looks wrong A substitution that still renders is invisible without a comparison. NS-004 NS-024 NS-049 NS-051
• Assets take seconds to appear Late departure and slow transfer feel identical from the viewport. NS-009
• Numbers come back subtly altered Silent coercion produces a valid value that is not your value. NS-025 NS-019 NS-046
• A search for a process finds something unexpected The instrument is a process, and it is inside its own sample. NS-012 NS-027 NS-036 NS-039 NS-040 NS-041 NS-086 NS-087
• A command hangs and never returns There is no exit code to read, and silence resembles progress. NS-014 NS-013
• Log lines are in an impossible order Two streams with different buffering do not interleave the way they were written. NS-035 NS-066 NS-088
• Credentials are ignored but the request still succeeds Something in the chain dropped the header and the endpoint answered anyway. NS-044
• A fresh clone is missing files that are present locally Committed is not the same as tracked. NS-047 NS-060
• The screenshot does not match what I see in a browser A capture is taken under its own device scale, colour scheme and stylesheet, not yours. NS-049 NS-050 NS-051 NS-052 NS-070 NS-071 NS-072 NS-073 NS-074
• A downloaded file is not the content I expected The transfer succeeded; the encoding or the destination path did not. NS-057 NS-054 NS-056 NS-075
• The machine looks busy but nothing is progressing Load and CPU percentages measure different things than they appear to. NS-064 NS-065 NS-063
• A file I edited lost its contents The shell truncates a redirect target before the command reading it ever starts. NS-054 NS-062
• The process ran out of memory but the box has plenty A container sees the host's totals, not its own limit. NS-063
• My analytics and my server logs disagree One of them is counting what clients claim to be, and clients set that field themselves. NS-069 NS-090
• A shell variable was empty and nothing complained Several builtins treat an empty argument as a request to do nothing, successfully. NS-080 NS-081 NS-082
• curl and my HTTP library disagree about the same response Header collapsing, protocol version and informational status lines differ per client. NS-076 NS-078 NS-079
• grep finds nothing in a header dump that clearly contains it HTTP/2 lowercases every field name; an anchored pattern matches neither case. NS-079
• Nobody can find the thing I published Being fetched, being indexed and being findable are three different states. NS-090

Or: how did you verify?

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   # one instrument
curl verifyfirst.dev/symptoms.txt     # every symptom
curl verifyfirst.dev/all.txt          # the whole registry, one fetch

Every instrument has a plain-text twin at /<instrument>.txt — no JSON to parse, no JavaScript, readable in one fetch. /all.txt is everything at once, for when a round trip costs more than the bytes.

Principles

1. 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.

2. 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.

3. Capture errors before adjusting values.

   Inert and wrong look identical from the outside. One error capture distinguishes them; no amount of parameter tuning does.

4. 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.

5. Distrust the fallback that is good enough.

   Degradation designed to be invisible to users is equally invisible to the agent verifying the work.

6. Report the observation, not the inference.

   'The service is active and returned OK' can be verified by a reader. 'It works' cannot.

7. 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.

8. 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.

What this cannot see

This reference has its own blind spots: it is Unix- and web-heavy, the checks were reproduced on one machine, and an entry only exists because somebody eventually noticed the failure. Failures nobody has ever caught are, by construction, absent. The full statement.

Formats

registry.json — everything, structured
registry.jsonl — one entry per line
recipes.txt — preflight checks by task
all.txt — the entire registry as plain text
symptoms.txt — symptoms and their checks
llms.txt — orientation
/protocol — the short version, for a system prompt