Verify a WORM ledger entry
fix(how-to): add dated Correction callouts to 20 of 28 how-to/ articles, worst ratio of any category — two systemic defects (wrong Doorman A/B/C tier semantics across 5 articles; fictional 4-tier pairing model + /v1/tokens API across 4 articles, real model is 3-role User/Admin/Interface via /v1/invite+/v1/pair), plus fictional CLI commands/routes across 11 more articles for fleet nodes, GIS API, exports, ledger reading, deployment, key rotation, and binary-download auth; several already-self-corrected articles independently re-confirmed accurate
@@ -12,6 +12,8 @@ editor: pointsav-engineering paired_with: verify-worm-ledger.es.md --- **Correction (2026-08-02, verified against canonical `origin/main`):** the `service-fs verify --from/--to` CLI subcommand doesn't exist — `service-fs` has no CLI at all, it's a pure HTTP daemon. `read_since(...)` is not a directly-callable operation either — the real routes are `/v1/append`, `/v1/entries`, `/v1/checkpoint`. The general concepts (C2SP tlog-tiles, Sigstore Rekor anchoring) are real, confirmed in `service-fs/ARCHITECTURE.md` and `ledger.rs`, but the concrete tool commands below are fabricated. **Flagged, not resolved** — needs rewriting around the real HTTP routes. The WORM ledger guarantees that records cannot be modified or deleted after they are written. Verification confirms that guarantee holds for a specific entry: that the hash chain is intact and that no post-write alteration occurred. This guide covers verification using the service-fs API and the standard SHA-256 toolchain — no proprietary tooling is required. For what the WORM guarantee covers and does not cover, see [[worm-ledger-architecture]]. For the storage format, see [[worm-ledger-storage-architecture]].