How an event gets onto this site

A published event on this site has gone through the same path every time, whether it is a canal grounding that made global headlines or a regional dockworkers’ strike that most people never heard of. The steps are boring on purpose. Boring is what makes a record something you can rely on years later.

Drafting

An event starts as a draft: a YAML file describing what happened, when, where, and who reported it. The draft has to satisfy a fairly demanding schema before it counts as ready for review. A title under 90 characters with no exclamation marks, question marks or em dashes. A summary of 80 to 150 words, written in our own words rather than lifted from a source. A timeline of dated entries, each one citing the sources that support it by id. A severity rating with a stated basis for why that number and not another. A cause section that says plainly whether the cause is official, reported, disputed, under investigation or unknown, and cites whoever made that determination if it is not us.

Casualty figures, when an event has them, may only come from official sources: a government agency, a coroner, an investigating authority. We do not report casualty numbers from a news article’s own count if no official figure exists yet, and we never name a private individual.

Checking the sources

Every official or press source on a draft needs an archive snapshot, usually from the Wayback Machine, taken at or near the time the source was used. A source that goes offline or gets edited after we cite it should not silently change what our record says it supported. A script checks every draft for a working live link and an archive snapshot before it can move forward, and flags anything missing so a human can decide whether to find a snapshot, swap in a different source, or drop the claim.

The gate

Before any record reaches the published archive, it runs through a publication gate: the same set of rules, enforced twice, once in the Python tooling used while drafting and once in the site’s own build. The gate checks that exactly one of “this event has a measurable effect target” or “this event has a stated reason it does not” is set, that dates are in order, that referenced ports, chokepoints and lanes exist in our registry, and dozens of smaller structural rules. A record that fails any of them does not build, whether the failure is a typo or a missing field.

The one step nothing skips

None of the above writes an approval. A record only becomes visible on the live site once a named editor, at an interactive terminal, runs the promotion tool by hand, reviews each record against a written checklist, and types a confirmation. The tool refuses to run from a script, a scheduler or anything other than a real terminal session with a real person typing. This is a rule the project’s own working notes call out explicitly as one not to reopen, and it exists because a research process, however careful, is not the same thing as an editorial decision. The two stay separate here.

Once a record is approved, the timestamp is fixed and the file moves into the published archive. The only way a published record changes after that is through a correction, logged as its own dated entry with a stated reason, never a silent edit.