The evidence model

Proof of measurement, never a health certificate.

Dormouse proves a narrow claim, on purpose: the checking happened on schedule, the results were recorded, and the record has not been altered. It never claims your vendor is safe or your program is compliant, because no honest tool can. Auditors trust the narrow claim precisely because it is narrow, and because they can verify it without trusting anyone.

The reader-friendly walkthrough of the mechanisms lives at How the proof works. This volume covers the parts an operator or a skeptical reviewer will ask about next.

Snapshots, the chain, the sweep.

Snapshots are content-addressed. Every fetched page is stored under the SHA-256 hash of its exact bytes, so "here is what the page said that day" can be re-verified byte for byte, forever.

The trail is chained. Every check, including failures, not-modified responses, and rebaselines, is an entry whose hash covers its own contents plus the hash of the entry before it. Editing or deleting any past entry breaks every hash after it.

The sweep recomputes everything. dormouse verify re-hashes the snapshots, confirms every observation references a real snapshot, and walks the chain from the first entry to the head. Any party holding the database can run it and get the same answer.

Two additions close the quiet loopholes.

An unkeyed chain proves ordering and internal consistency, but someone holding the database could, in principle, rewrite history and recompute every hash to match. The chain key closes that: entries are chained with a secret key, so a rewritten trail cannot be made to verify by anyone who does not hold it. Keep the key outside the database, and back it up separately: a restored database without its key cannot be proven, only read.

The anchor closes the other loophole, truncation. Verification records the chain head it saw, and every later verification confirms the trail still ends in a history consistent with that head. A trail quietly rolled back to an earlier, cleaner state stops matching its own last anchor.

And because the claim invites the test, here is the machine catching a cover-up on a copy of a real database, a recorded failure rewritten as a success:

The rollback attack, deleting the newest entries to end history on a cleaner day, fails the same way against the anchor. Both demonstrations live on How the proof works.

The coverage number is a calculation, not a vibe.

For each target, the window and the check interval imply how many checks were owed. Coverage is successes against that expectation, capped at one hundred percent, alongside the success rate, the longest gap between successful looks, and staleness. A target added moments ago owes nothing yet, so its first success counts as full coverage rather than a misleading zero.

Silence is treated as a finding in its own right. A watchdog raises an alert when a source goes dark past its staleness window, because a coverage gap is exactly the thing an auditor would find later. Failed checks never advance the baseline, so when a source recovers, the comparison runs against the last state actually seen and nothing that happened during the outage is missed.

One file to back up, one key to guard.

All state lives in a single SQLite file. dormouse backup takes a consistent copy that is safe to run while checks are in flight, and the copy can be verified independently, key in hand, on any machine. The chain key travels separately, ideally in your secret store, never inside the database it protects.