# Editing standards for this site

How post-publication edits are recorded. The aim is honesty about what
changed and accessibility of prior versions, because the writing here
makes arguments about binding records.

## Edit tiers

Decide which tier an edit falls into *before* making it. When in doubt,
go one tier up.

1. **Typo / formatting.** Spelling, hyphenation, punctuation, whitespace,
   broken markup. No note. Commit message is enough.

2. **Clarification.** Rewording for readability without changing the
   argument or any factual claim. One dated bullet under `## Updates`
   at the bottom of the post.

3. **Correction.** A factual claim was wrong. Always noted. The bullet
   says what the prior version claimed and what it now says. Never
   silently correct.

4. **Substantive.** Anything that changes the argument, the framing,
   the recommendations, the voice in a way a careful reader would
   notice, the structure (added/removed sections), or any conclusion.
   Always noted, **and** the prior version is snapshotted to
   `versions/v{N}-{YYYY-MM-DD}/` before editing.

A single editing pass that mixes tiers is treated at the highest tier
present. Don't bury a substantive change inside a clarification commit.

## The Updates section

Every post that has been edited carries an `## Updates` section at the
end. Each entry:

- starts with the date (`YYYY-MM-DD:`),
- describes the change in one or two sentences,
- for corrections, gives the prior and current claims explicitly,
- for substantive edits, links the prior snapshot.

## Snapshotting prior versions

Before any substantive edit, run:

    ./snapshot.sh writing/<post-slug>/ vN

The helper:

- copies the current rendered `index.html` to `versions/vN-{today}/index.html`,
- prepends a banner identifying it as an earlier version with a link
  back to the canonical URL,
- prints what to do next.

Snapshots are static. They are not re-rendered by `build.sh`. They are
the binding record of what was published at that point in time.

The canonical post stays at its original URL. The current version is
always the live one. Versions are numbered v1, v2, … in publication
order. v1 is the initial publication.

## Front-matter

Posts with prior versions carry these YAML keys:

```yaml
revised: 2026-05-20         # most recent substantive revision
revisions-link: ./versions/ # link to the versions index
```

The template surfaces them as "revised YYYY-MM-DD · earlier versions"
next to the byline.

## What this is not

This is not a certification scheme. It records what was claimed when.
It does not say any version is "right." It makes the chain inspectable.