Version. 0.2
Supersedes. v0.1 at record c942fe1, which stands as a sibling, unaltered.
Changes from v0.1. Two, both found by the executing session at v0.1's filing. The rule gains its missing precedence: v0.1 stated the rule for the executing session but the hazard is created at kickoff, and it did not say what happens when a kickoff and the record disagree. It now does — the record wins, and the session halts rather than proceeding on either. And one citation is corrected: v0.1 said CR-2026-159's v0.2 and v0.3 both denied that anything about the work changed. v0.2 does; v0.3 does not, and is in fact the version in that series that came nearest to drawing the distinction this note asks for.
Date. 2026-07-31
Author. Claude.ai (drafting session). Operator: Marvin Percival.
Status. Standing. Applies to every versioned document a session executes from.
Occasion. Identified by the executing session at the filing of CR-2026-159 v0.4, which was the first bump in that CR's series to change how the build runs rather than how the document reads.
The record's filing discipline is siblings, never overwrites: a revised document is filed under the next version and the prior version stands untouched. For a document that is read — a manifest, a findings report, a scoping note — a superseded sibling is history, and preserving it is the point.
**For a document that is executed, a superseded sibling is not history. It is a live instruction set that no longer matches the decision.**
CR-2026-159 is the worked case. Versions v0.1 through v0.3 differ from each other only in prose. v0.4 changed behaviour: it removed an Operator confirmation gate at Checkpoint A that the charter had already made unnecessary. A session opening v0.1, v0.2 or v0.3 by filename would halt for a gate that no longer exists, wait for an Operator who has not been asked for anything, and report a checkpoint the current decision does not contain.
The hazard is self-propagating. Each version carries a kickoff block naming its own path, so a session that starts from a stale sibling is told by that sibling that it has the right document.
Before executing any versioned document, confirm it is the highest version present in the record. One directory listing. If it is not, stop and open the highest.
A version bump that changes behaviour is named as such in its own changes-line. The distinction between reads differently and runs differently is the one an executing session needs, and only the drafting session knows it at the time of writing.
In the worked case: CR-2026-159 v0.4 states it explicitly. v0.2 denies it — "neither altering the work." v0.3 comes closest to getting it right, opening "One, in an instruction rather than a rationale", which flags the change as instruction-level rather than denying that anything changed. (v0.1 of this note cited v0.2 and v0.3 together as stating the opposite. That was wrong about v0.3, and unfair to the one version in the series that reached for the distinction this note asks for. Corrected at v0.2.)
The kickoff block names a version, never a bare document. A kickoff that says "execute the CR" inherits whichever file the session happens to open.
When the kickoff and the record disagree, the record wins — and the session halts rather than proceeding on either. (Added at v0.2. v0.1 stated the rule for the executing session but left precedence implicit, which is a hole: the hazard is created at kickoff, not at execution. Three of CR-2026-159's four versions carry kickoff blocks naming themselves, so an Operator pasting an older one would send a compliant session to a stale document — and that session's own directory listing would then contradict the instruction it was handed.)
Why the record wins. The build list states the project's standing posture plainly: the highest-numbered version is always the truth. A kickoff block is a fossil of a past decision; a directory listing is current state. This note applies that settled principle to a new case rather than introducing one.
Why the session halts rather than silently taking the highest. A mismatch is cheap to resolve and might be deliberate — an Operator may want an older version re-run for comparison. Proceeding silently on the highest would override an intent nobody stated. The halt is charter §6 A-5 in shape: a conflict between an instruction and the standing discipline, which stops and queues. One message resolves it.
Nothing is edited retroactively. Superseded versions stay exactly as filed. The record's precedent for supersession is a marker in the new version — as the manifest does for its superseded entries — not an edit to the old one. This note follows that.
Ordinary archival is unaffected. The versioned-document archival discipline governs how superseded documents are kept. This note governs only the moment before execution, and only for documents that are executed.
The charter is F-4 — its own amendments are Operator acts. This is a working discipline that sits under it, not a change to its authorization classes, so it files as a standing note. If the Operator wants it in the charter proper, that is his to decide at cadence; it is recorded here as a queue-free candidate rather than a decision entry, because nothing is blocked either way.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — standing note — superseded versions of executable documents — v0.2 — 2026-07-31 A document that is read has history. A document that is executed has only a current version.