How we handle trust

We ship four trust artifacts, none of them cryptographic certificates. They cover what a reader, a researcher, and a regulator actually ask about a local-news source.

1. A public corrections ledger

Every correction lands at /corrections with a diff (what changed), a timestamp, and a link back to the original article. Retracted articles serve a 410 Gone tombstone that points at the correction record. The ledger is the trust artifact — the record of when we were wrong and how quickly we said so.

2. A stamped approval tier — which mostly says “nobody reviewed this”

Every article stores an approval tier, and the honest reading of that tier is the point of this section. There are two kinds of article on this site and they carry very different stamps.

Machine-assembled articles — everything the live desks publish, which is essentially the whole site — are stamped tier1-auto-publish. That tier means exactly what it says: the article published automatically, with no editor in the loop. It keeps saying that for the life of the article, because it records how the article first went live. No machine-assembled article is read by a person before it first publishes, so no reviewer name, no review timestamp and no approval gesture is recorded at publication.

The feeds carry a second field, humanReviewed, and it asks a narrower question about one article: does the version you are reading name a person who approved those exact words? For an article nobody has touched since the template wrote it — nearly all of them — the answer is humanReviewed: false, and the article page prints “Published automatically from public-record data — not yet reviewed by an editor.” It reads humanReviewed: true only where a person stood behind the current wording, which today means an operator who reviewed and committed a shortening (section 5), or a person who approved a roads-desk rewrite.

It is not a badge an article keeps, and that is the part worth knowing before you build on it. The flag describes the most recent version only, so an article a person approved goes back to false the moment an unattended update from the source files a newer version — nobody read that one. In practice you should expect false across the site. If you are auditing us, read the flag on the item in front of you rather than taking it for a property of the site, and read it together with the tier, which answers a different question and never changes.

Hand-written articles — a small number of posts written by a person and reviewed in a pull request — additionally record the approval gesture that cleared them (a cool-off window, a retype-confirm, or a second factor) in their source frontmatter. They are the only articles here whose approval happened before publication; an operator's approval of a shortening happens to an article that is already live, and is recorded on the version and on the corrections ledger rather than in frontmatter.

3. Tamper-evidence on the ingest chain

The public sources we ingest from (SD Department of Labor WARN notices, county permit portals, etc.) land in an append-only table with a SHA-256 hex hash over the canonical-JSON payload. Anyone with the raw ingest row can independently verify the payload wasn't modified after we received it. This is a hash chain, not a signature chain — no keys, no verifier UX. If cryptographic non-repudiation is needed for a specific consumer later, it layers on the same hash columns.

Why not signed cryptographic receipts?

We prototyped Ed25519-signed article receipts in July 2026 and removed them at MVP after a security review — the crypto layer carried more operational surface (key rotation, verifier UX, pkcs8 secret management) than a solo pre-revenue product repays. See the trade-off writeup on GitHub . If MAU crosses ~1k, or a specific enterprise consumer needs signed non-repudiation, the schema is shaped to add signing back without a migration.