ATTEST DISPUTE PACK — what this is and is not
============================================

bundle.json    The signed visit record plus every appended review, hash-chained.
media/         The media bytes the record references (when included).
verify_bundle.py  Offline verifier. Run:  python verify_bundle.py bundle.json
verify.html    Zero-install verifier — open in any browser and drop the pack
               files or the .zip itself in. Same checks, pure JavaScript,
               works from file://. Also renders each record's timeline
               (scheduled window, poll coverage, observations).
index.html     Offline record browser — the record verified live in-browser
               with its timeline, a day-by-day strip of the whole window,
               source-by-source corroboration, and any signed
               worker/household/coordinator statements rendered verbatim.
key_rotations.json  Present only if the deployment rotated its signing key:
               the signed pivot receipts — each endorsed by the retiring key —
               that let reviews written under the successor verify. A key that
               appears without a signed endorsement link is rejected, never
               trusted.
verifier_manifest.json  A signed receipt pinning the sha256 of every verifier
               shipped in this pack (verify_bundle.py, verify.html, index.html,
               README.txt). A forged pack that doctors its own verifier to
               print VERIFIED is caught: the manifest names the real bytes,
               and only the deployment's key can sign one.
log_checkpoint.json   Present when the deployment publishes a transparency
               log: a signed Merkle tree head plus an inclusion proof for
               every receipt in this pack — cryptographic evidence that these
               receipts were committed to the deployment's published append-
               only log, in this order. A receipt with a valid signature but
               no log membership still fails: signing a record is not the
               same as committing it. The doc's `chain` list carries up to
               32 PRIOR signed checkpoint receipts — each embedding its own
               `extends` bridge — so two packs exported days apart reconcile
               offline: `attest diff` (and verify.html's compare) walks the
               chain hop-by-hop, proving append-only growth or catching a
               same-size root collision as provable fork evidence.

WHAT A VALID VERIFICATION PROVES
- Every receipt in bundle.json is byte-identical to what was signed: the payload
  hashes to payload_hash, and the Ed25519 signature covers that hash.
- Reviews are anchored to the original receipt's hash and ordered by revision.
- If the deployment rotated keys, the rotation receipts prove the retiring
  key endorsed each successor — records on both sides of the transition
  verify under one signed chain.
- If log_checkpoint.json is present, every issuer-signed receipt in the pack
  proves inclusion in the deployment's transparency log at the checkpoint's
  committed size — the pack cannot carry receipts the log never saw.
- Media files match the sha256 digests recorded in the evidence list (when the
  verifier is run from this directory, it checks media/ too).

WHAT IT DOES NOT PROVE
- Identity. The signature authenticates the record, not who appears in media.
- Attendance or time worked. Observations are events, not presence.
- Absence. A silent window means no events were observed — not that nobody came.
- The worker's device or person. Worker statements arrive through a scoped link;
  they are the worker's account, recorded, not a verified identity.

The private signing key stays with the deployment. The public key embedded in
each receipt verifies this pack; pin against a key you obtained out-of-band
(verify_bundle.py --key <base64>) to rule out a pack that swapped keys.
