A claim about the system names the target that proves it, or it is not a claim

The repository’s rules record three ways a careful engineer arrives at a confident, well-formed, wrong statement, and each is worth knowing by shape because none announces itself:

• An empty result read as absence. A search returned nothing because it was scoped to the wrong root, or used a flag the tool does not have, or ran against a dump that truncates. “Not found” became “does not exist”, and once it was written down, a later reader acted on it.
• A real result about the wrong target. Two files with near-identical names and identical behaviour; the first of several matches taken as the only one; a test whose justifying comment described a code path the function never executes. The conclusion was right, the evidence was about something else, and a green suite concealed the gap precisely because nothing misbehaved.
• A correct reading of a stale artifact. A consumer’s type error against an emitted declaration file hours older than the source; a stored document validated against a schema that had moved on; a running process holding a module graph the disk no longer matched. Each looked like a logic defect and was a photograph of an earlier world.

A fourth shape is quieter still: a mechanism that shipped and was never watched working, behind a suite that passed because every test supplied what the mechanism was supposed to resolve. Nothing was wrong with any test. The gap was nobody’s failing test, so it was invisible.

• Rules in: a claim names its target. “Verified at this path, which is the module the consumer actually imports” is auditable by the next reader; “verified” is not.
• Rules in: an empty result is believed only after the search has been shown to find something it must find, and only after the running system has been asked directly where that is possible.
• Rules in: the artifact is dated before the logic is diagnosed. An emitted file, a stored record and a live process each lag their source, and one stat settles more than an hour of reading.
• Rules in: a checker carries a self-test that plants the defect it exists to catch and asserts detection, then asserts the same tree reports clean once the defect is removed. A checker whose discovery matches nothing reports a clean repository and a broken checker identically.
• Rules in: a run that passes its assertions while the backend logged a fatal error is a false pass, and a lane that never printed a verdict scores as inconclusive, never as “no failures”.
• Rules in: a mechanism that cannot be verified now gets a durable record saying so, with what would prove it and what a failure would mean, instead of a green suite and silence.
• Rules out: promoting a capability on the word of a curated map or a file name. Maps lag the code and say so in their own headers; a file name is not evidence of anything.
• Rules out: narrowing a test, weakening an assertion or relabelling a failure to make a check pass. Suppression is never presented as repair.
• Rules out: a checker that matches almost nothing. Rejected because it trains readers to skim, which costs more than the findings it produces.

• A security property you rely on (tenant isolation, role ceilings, the last-owner floor, non-disclosing refusals) has a black-box probe over real HTTP behind it, not only a unit test of the guard function. A unit test proves the guard rejects; only a request proves the guard is on the path an attacker takes.
• When a capability is described as shipped, there is a running application or a scenario you can be pointed at. When it is described as implemented, you are told that no application uses it yet. You are never told a planned thing exists.
• The same conventions are open to your application. The dogfood application’s own lanes are built on the framework’s dependency-free testing spine and reach the application purely as an external client, which is the shape any application’s lanes can take.
• Verification in Wildo is proportional and named: implemented, statically verified, behaviour verified and runtime proven are four different claims, and a report says which one it is making.