REVISION LEDGER / PUBLIC MEMORY

CORRECTIONS

If a technical claim, source relationship, explanation, or meaningful public statement changes, the correction should leave a trail. Quietly replacing the past with the improved version makes archives cleaner and institutions dumber.

POLICY / MATERIAL CORRECTIONS

What belongs in the ledger.

A material correction is a change that affects what a reasonable reader could conclude: factual claims, technical mechanisms, quantities, source attribution, scope, safety boundaries, public project state, or meaningful interpretation presented as supported.

When one occurs, the ledger should preserve the date, affected page, previous claim or wording in enough detail to identify it, corrected version, reason for revision, and the evidence or source trail that justified the change.

Rule: corrections should make reconstruction easier, not merely announce that something somewhere became “more accurate.”

POLICY / ROUTINE EDITS

Not every comma needs a tribunal.

Spelling, layout, accessibility, broken links, responsive behavior, code cleanup, and other changes that do not alter the substantive meaning can be handled as routine revisions. Significant interface or security fixes may still be noted when they explain how a public surface changed.

This distinction keeps the correction ledger useful instead of turning it into a raw Git log wearing a tie.

LEDGER STATUS / TECHNICAL CONTENT

No material technical corrections logged yet.

The current technical primers are still early and deliberately narrow. Source Trails were added so readers can inspect authoritative starting material behind several explanations. That expansion is a provenance improvement, not a correction to a known false technical claim.

When a material technical correction appears, it will be recorded here rather than silently disappearing into the newest page version.

2026-08-22 / COPY REVISION

Guestbook beta label typo corrected.

Affected surface: The Wall / Guestbook.

A small public-facing label typo in the first guestbook deployment was corrected during inspection. The guestbook remained explicitly labeled as a local beta, with browser-local persistence rather than falsely implying shared global storage.

Impact: copy only. No change to persistence behavior or privacy boundary.

2026-08-22 / PROVENANCE EXPANSION

Briefings gained authoritative source trails.

Affected surfaces: Briefing Room and Source Trails.

Six technical primers were connected to authoritative starting material from LIGO/Caltech, MIT OpenCourseWare, PubMed/NIH literature, NIST, OpenTelemetry, and NASA. This did not replace a known false claim. It made the evidentiary exits visible and gave readers somewhere better to continue than “trust the glowing website.”

Impact: stronger provenance and easier independent inspection.

FUTURE ENTRY FORMAT

A correction should be reconstructable.

The template below is intentionally boring. Boring is useful here. Nobody should need detective fiction to determine what changed.

01 / IDENTIFY

What changed?

Date, page, section, previous wording or claim, and the corrected version.

02 / EXPLAIN

Why did it change?

Error type, new evidence, changed source, scope correction, calculation correction, or clarification.

03 / TRACE

What supports the revision?

Source trail, measurement, calculation, test result, interview correction, or documented operating change.

ARCHIVE PRINCIPLE

Being corrigible is stronger than pretending to have arrived correct.

Cyberdelia is being built in public enough that revisions are inevitable. The standard is not never changing. The standard is making meaningful changes inspectable and refusing to convert yesterday's confidence into today's amnesia.

MATERIAL TECH CORRECTIONS00Inspect source trails