Assertions

Derived from what, exactly

• ✓The project's own language files, for every label a person reads.
• ✓The laid-out tree, for anything about arrangement.
• ✓The application's own read-out, where it publishes one.
• ✓And a derived set names what it derived from, because an expectation nobody can trace is one somebody will eventually “fix” by editing the number.

Falsifiable, or it is not an assertion

A check that cannot fail is worth exactly as much as the one that never ran — which is the same defect this project's verdict exists to expose, one layer down. So an expectation that no input could falsify is refused rather than counted.

A read that timed out is a reading

Not a value, and not a default that looks like data. It is recorded as the thing that did not arrive, and it reaches the summary as unobserved — which is the only honest place for it.

A failing step carries its diagnosis

The tree as it was, the element's facts, and what its patterns read at the moment the expectation did not hold. Which is what a reader would otherwise write a throwaway script to find out, on a window that has since closed.

And the machine is compared to itself

The store a case writes through is fingerprinted before the run and compared after it, so the promise that a run leaves the machine as it found it is asserted on the path most likely to break it rather than stated in a readme.