# Verifying this record This file is written for someone who has been handed this repository and has no reason to trust the person who handed it over. Everything below can be checked without contacting Field Assembly LLC, without network access for the main check, and without taking anyone's word for anything. ## What is being claimed Gathered Work publishes pages about how named institutions handle academic integrity and AI-detection cases. Each page quotes those institutions' own published documents and records the date each quotation was verified. The claim this record makes is narrow and worth stating exactly: > The files in this repository existed, in exactly their present form, no > later than the dates recorded in `anchors/`. Those dates are attested by > parties outside this project's control and could not have been backdated. That is a claim about **when**, not about **whether**. The anchors prove that a page said what it says by a given date. They do not prove the quotation is accurate — that is what the per-page change logs and the source packets are for — and they do not prove who wrote it. Anyone evaluating this record should treat those as three separate questions. ## The one command From the repository root: ``` python3 tools/anchor.py verify --full ``` Requires Python 3 and, ideally, `openssl` (present on macOS and most Linux systems). It runs entirely offline. It takes a few seconds. Optional, for the Bitcoin block detail: `pip install opentimestamps-client`. Without it the command still runs and still checks everything else; it just reports the Bitcoin proofs as present rather than reading their block numbers. ### What a good result looks like ``` what was checked [1/4] Append-only history....... OK 9 entries, 2026-08-28 to 2026-08-30 [2/4] Content manifests......... OK 63 files anchored; ... [3/4] Certificate timestamps.... OK 18 of 18 tokens verify (2 authorities) [4/4] Bitcoin timestamps........ OK 9 of 9 confirmed on Bitcoin VERDICT: PASS ``` `--` rather than `OK` on line 4 is normal and not a fault: proofs stamped within the last day or so are still waiting for Bitcoin confirmation. Anything reading `FAIL`, or any entry under a "problems found" heading, is a real finding and should be explained before the record is relied on. A note on line 2: "working tree differs by N changed" is expected whenever work has happened since the last anchor run. It means the current files have moved on, not that history was altered. If history had been altered, line 1 would fail. ## Checking it by hand, trusting nothing The command above is convenient, but it is also this project's own script. If you would rather not trust it, here is the same check done manually. It takes about five minutes. **1. Confirm a page is covered by an anchor.** Hash any file: ``` shasum -a 256 institutions/auburn.html ``` Find that hash in a manifest, which lists every anchored file: ``` grep anchors/manifests/*.txt ``` The manifest filename is the anchor's timestamp. The file existed by then. **2. Confirm the manifest itself was not swapped.** Each chain entry in `anchors/chain.jsonl` records the hash of its manifest: ``` shasum -a 256 anchors/manifests/.txt ``` That value must appear as `manifest_sha256` in the entry for the same ``. **3. Confirm the history is append-only.** Every entry records `prev_entry_sha256`, the hash of the entry before it. Walk the chain and check each link. Altering any past entry or manifest changes its hash and breaks every link after it, so a single intact chain covers the whole history. **4. Confirm the date with a certificate authority.** Each entry carries two independent RFC 3161 timestamp tokens: ``` openssl ts -verify -digest \ -in anchors/tsa/-freetsa.tsr \ -CAfile anchors/tsa/certs/freetsa-cacert.pem ``` and the same with `-digicert.tsr` and `digicert-cacert.pem`. Expect `Verification: OK`. The CA root certificates are included in this repository deliberately, so these tokens keep verifying on a machine whose system trust store has moved on. If you would rather not use the copies here, fetch the same roots from FreeTSA and DigiCert yourself and compare. **5. Confirm the date against Bitcoin.** Run: ``` ots info anchors/ots/.json.ots ``` It prints lines of the form `BitcoinBlockHeaderAttestation(964451)` followed by the merkle root that block should carry. Look block 964451 up in any block explorer, compare the merkle root, and read the block's timestamp. If they match, the entry hash was committed to Bitcoin by that block, and rewriting that block now would mean redoing every block of proof-of-work built on top of it since. `verify --full` prints all the block numbers for you. ## Limits worth understanding **Resolution is hours, not seconds.** Bitcoin block timestamps are supplied by miners within consensus bounds, so a Bitcoin attestation establishes existence before roughly a given hour, not a given minute. Fine for a claim measured in dates. The RFC 3161 tokens are precise to the second but depend on a certificate authority rather than on proof-of-work. **It proves existence, not authorship or accuracy.** See "What is being claimed" above. **The first chain entry (2026-08-28) is a backfill.** It proves the then-existing files existed as of that date, not as of the earlier dates recorded inside them. Everything anchored after that date carries a near-contemporaneous external anchor. This is stated in `anchors/README.md` too, and is deliberately not glossed over. **Git history is corroboration, not proof.** Commit dates are attacker-supplied and can be rewritten; that is precisely why the external anchors exist. Where git history and the anchors agree, that agreement is meaningful. Where the repository has been rewritten, the anchors are the record that survives. ## Rules for whoever maintains this next - Never edit anything under `anchors/`. It is append-only. A mistake is superseded by a later run, never corrected in place. - Never rewrite git history. Squashing, rebasing, or filtering the repository destroys the corroboration between the commit record and the anchors, and makes the result look worse than the untidied original. - Run `python3 tools/anchor.py run` after each working session, and `python3 tools/anchor.py upgrade` a day later to collect the Bitcoin attestations. An un-upgraded proof is a pointer at a calendar server, not evidence; if those servers disappear before it is upgraded, that proof's Bitcoin leg is lost. - Before any handover, run `upgrade` until nothing is pending, then `verify --full`, and keep the output.