The mechanic
Freeze, check, generate, seal
The mechanic below is the design. The deterministic half runs today — see our own report at /proof — and the rule-pack engine is phase one, so steps 02 and 03 are written as what they will do, not as what they already do. This page is for the evaluator asking whether there is anything here beyond a model call.
- 01
Freeze
A capture is hashed with the volatile capture timestamp excluded.
We fetch the current state of an asset — markup, headers, media references, structured data — and hash it. The capture timestamp is deliberately excluded from the hashed input, because it changes on every run and would otherwise make every capture unique.
The consequence is the point: two runs over an unchanged site produce an identical seal. If the seal moves, something in the asset moved, and the diff says which part. This is determinism you re-run rather than trust. You do not have to believe our verdict; you can reproduce it.
- 02
Check
Rule packs will run against the frozen state, not against a live page. Engine in build, phase one.
Checks will execute over the frozen capture, so a verdict is attached to a specific hashed state rather than to whatever the site happened to be serving at the moment someone looked.
The rule loader will enforce a grade-A standard: a rule that lacks a verbatim quote from its source and a date on which that source was checked will not load. It is to be rejected at load time, not flagged later. A finding that cites a rule not in the corpus is a defect in the engine, not a finding about your site — and it will be treated that way.
- 03
Generate
Where a check fails, an instrument will produce a compliant new artifact. Instruments in build, phases one and two.
We do not edit the customer’s site. Where a check fails, the instrument will write a new artifact — an authorization record, a captioned video, a corrected block of copy, a structured-data document — and hand it to you or your agency to publish.
That is a deliberate architectural choice, not a limitation we are apologising for. It keeps us out of your CMS and out of your publishing path. It keeps us out of Business Associate territory, because holding and mutating a practice’s patient-facing assets is a different legal posture from producing a record the practice publishes itself. And it keeps us out of the structural shape a regulator has already penalised: an automated system that reaches into a third party’s site and asserts the result is compliant.
- 04
Seal
What was checked, at which tier, on which date.
The seal records the hashed state, the rules that ran, the tier each verdict was reached at, and the date. It is a receipt for a specific examination, not a certificate about your organisation.
A gate that examined nothing fails rather than passes. If the rule pack did not load, if the capture was incomplete, if a check could not reach a verdict — the result is a failure requiring attention. Silent passes are the failure mode that makes automated assurance worthless, so the default is inverted.
Tiers
Publishing the tier instead of a single score
A single confidence number hides the only thing that matters: how the verdict was reached. A deterministic file check and a model’s opinion about tone are not the same kind of statement, and averaging them into one figure destroys the distinction. So every check carries its tier, and the tier travels with the finding.
- Deterministic
- Same input, same verdict, every time — no model in the loop. This is the only tier where the word “verified” is literally true.
- Bounded
- Formal reasoning over a bounded policy. Sound only for what the policy models, so we say “checked against”, never “guaranteed”.
- Advisory
- Model judgement. Genuinely useful for direction, never used as a pass/fail gate.
The honest consequence is that some of what we report is weaker than you might want, and we say so on the finding itself rather than in a footnote. A check that cannot be re-run to the same answer is not verification, and we do not use the word.
Boundaries
What the seal does not do
The seal cannot cover generated prose. Language-model inference is not deterministic under load: batch size varies with server load, and the kernels involved are not batch-invariant, so identical requests can return different completions with temperature held at zero. Thinking Machines recorded Qwen3-235B producing 80 unique completions across 1,000 identical requests (September 2025).
Seal-and-compare therefore transfers cleanly to structured artifacts — schemas, tokens, layouts, records — and does not transfer to prose. Rather than pretend otherwise, generated prose is verified by property assertions: statements that must hold about the output regardless of wording, such as the presence of a required disclosure, the absence of a prohibited claim, or a reading level within a stated band. Those assertions are checkable and re-runnable. The exact sentences are not, and we do not seal them.
Read the parts that can be argued with
The catalogue lists every check with its source, the date that source was last checked, and the tier. The proof page publishes this site’s own results, produced by the same mechanic described above.