The documentation, and what belongs in each part

Four kinds of writing live here. They are separated on purpose: a reader who wants to know what a program means should never have to read what a benchmark did on someone’s laptop, and an experiment that later turned out wrong should never be able to quietly change the language.

1. The specification — specification/

What the language is. Normative. If the compiler disagrees with it, one of the two is a bug and the disagreement gets recorded.

The three parts follow one language standard, specification/STYLE.md: the rule, then its consequence — nothing else. A page carries no ADR references, no rationale, no history and no implementation status; those live in the decision records, the changelog and the roadmap, and are not repeated there.

2. The decisions — specification/adr/

Why the language is that way. One decision per record, numbered D1…Dn so it can be cited, with the reasoning that settles it and, where a number decided it, that number. A record states the decision as it stands today: no story of how it was reached, no version that built it, no progress.

Start at the ADR index: every live record, what it decides, and whether it is built (yes, no, or partly: with what is missing).

When a later decision changes a record, the record is updated in place: the rule is rewritten to what holds now, with a one-line Changed by ADR-MMM Dn note under it. A decision withdrawn altogether is removed, with one sentence saying what is done instead. When a group of records is replaced by one record that states all their decisions in their current form, the old records move to history/adr/ and no live file cites them (scripts/check-adr-refs.py enforces it).

The route to a decision is history: the archive’s README maps each archived decision to the live one, git log shows how a live record changed, and ../CHANGELOG.md and the notes below hold what was built, tried and measured.

3. The notes — this directory

What was tried, measured and learned. The laboratory notebook. Nothing here is normative and nothing may depend on it to know what a program means.

This is the right home for the detail the specification must not carry: the method, the machine, the false starts, the measurement that overturned an intuition.

Closed notes — history/

The same notebook, kept but no longer current. A note moves here once its question is answered (the ADR it fed now carries the decision) or its subject is withdrawn — never for age by itself. The method and the measurement are still true and still cited by ADR number from wherever they are used; only the question the page was written to answer is no longer open.

4. The history — ../CHANGELOG.md

What changed, when, and what it cost. Per release. A correction to an earlier claim is recorded here as well as in the record it corrects.


The rule of thumb

If deleting a sentence would change what a correct Nikaia program is, it belongs in the specification. If it would only change whether you agree with the language, it belongs in an ADR. If it would only change how much you trust the number, it belongs in the notes.

This site is open source. Improve this page.