The specification says what a conforming file looks like. It does not say why each field is there, what was considered and rejected, or what the decision cost. These pages are that record — one per structure, written so that a later reader, including a later version of the people who wrote it, can tell a deliberate choice from an accident.
A rationale document is the receipt. It exists so that the next argument about a field starts from what was already decided and why, rather than from scratch.
the magic is PNG's, two version fields rather than one, a CRC over twelve bytes, and why the whole thing is sixteen.
`payload_len` comes first and is a `u32`, why `stream_id` sits in the header rather than the payload, and why the CRC is at the tail.
into segments, why bindings expire rather than accumulate, why the marker is a fixed sixteen-byte pattern wrapped in an ordinary frame, and why segment period is left to the writer.
Each follows the same shape, deliberately:
| Section | What it holds |
|---|---|
| What it is | the structure itself, in one short statement |
| Decision by decision | each field, with the alternatives that lost |
| What was deliberately kept out | proposals rejected, and the rule that rejected them |
| Costs accepted | what the decision costs, stated rather than hidden |
| Not yet justified | the parts that are still assertion rather than argument |
The last two sections are the point. A rationale that only lists advantages is marketing; the cost and the open-ended parts are what make it checkable.
The rules these documents appeal to are the six design rules in §1 of the specification, and a decision that cannot be traced back to one of them is marked as not yet justified rather than quietly kept.