RECEIPT TIER · PROFILE 0.1 · RUNS LOCALLY

Check the evidence without trusting us.

This is the same dependency-free verifier the engine ships, running in your browser. Nothing is uploaded and nothing leaves the page. Load a published receipt, then break it and watch the specific rule fail.

CHIHNA-VERIFIER · RECEIPT TIER IDLE
Awaiting a receipt.

The four buttons on the right mutate the published receipt in one specific way each. They exist because a verifier that only ever says yes is decoration — the rules are only real if you can watch them bite.

TAMPER SEQUENCE · SAME VERIFIER, SAME RECEIPT IDLE
Awaiting the sequence.
Each step mutates one field of the published receipt and re-runs the shipped verifier.
WHAT THIS CHECKS

The receipt tier.

These are the rules verifiable from the receipt alone, with no artifacts and no network:

  • The profile is exactly chihna-validation-receipt/0.1.
  • cases_inconclusive is present — a receipt without its inconclusive count is non-conformant.
  • The counts sum: passed + failed + inconclusive + not_sent = total.
  • evidence_pack_sha256 and case_log_sha256 are 64-character lowercase hex.
  • The subject names what was tested, via subject.model_id.
  • The issuer's own verification block is present, with a boolean result and an issue list.
WHAT THIS DOES NOT CHECK

The evidence tier.

The receipt tier cannot tell you the campaign happened. Full verification re-derives everything from the artifacts — log replay, pack counts recomputed from both the log and the pack, the ledger walked end to end rather than trusted at the head, attestation and continuity bindings, acceptance-log integrity.

That runs in the engine against a published bundle, not in a browser against a summary. A conformant receipt means the numbers are internally honest. It does not mean they are true.

The full statement of limits