Hold the Flood — External Critique

EXT102 r2 · 2026-09-06 · External Critic (seated, Brief D015) · In review Previous: r6 3148bb · r5 6a92c7 · r4 a8883a · r3 b3a54d · r2 280e75 · r1 319c975. Target re-read at save: DES103 r2, Design Document r8. It moved from r7 to r8 while I was composing; everything below is verified against r8.

X21 and X22 are fixed, and fixed as proposed. Both withdrawn. DES103 r2 changed clause 4 to "walking over one adds its charge to a battery in your rack, up to the battery's capacity", restated the electrician's loop as "break-even with one battery and profitable only with a second in place of a bundle, which is now named as that loadout's rack tension", and re-derived the arc's bound "as the surge, not the battery, with its drain set above what the cutter alone earns." That is all three corrections, including the rack tension I said the document did not know it had.

I then finished the quantity pass against r8. The fix pass caught the two faults I had filed. It did not catch the two I had not, because both are in §12, Expedition One — the walkthrough §17 points the owner to, and the one the cold reader certified as readable. Readable it is. It still does not run.

Both are pure arithmetic from the document's own figures. No outside source, no balance opinion.

Withdrawn at this revision

Running score: filed 24, retracted or withdrawn 21, narrowed 4. Three live.

X23 — Expedition One's rack holds seven items in six slots

§12, 3:30–7:30 (r8) — "Rack now: coil, battery, three bundles, one slot empty, and one drip."

Against §5's own slot costs, all unchanged in r8 — "six slots in two rows of three", "coil (2 slots, horizontal or vertical)", "battery (1 slot)", one bundle per slot:

There is no empty slot. The same walkthrough confirms the full rack two entries later: "9:40. Extraction, three bundles and a coil… a battery" — the same six.

Small in itself, and load-bearing in place: §5's entire argument is that six slots force a choice, and §12 is where the owner is shown that choice happening. An example that quietly runs on seven slots undoes the argument it exists to make.

X24 — the same rack reports one drip where the rule gives three, and the battery cannot reach extraction under either count

The leak rule, §5, unchanged in r8: "A battery leaks into every bundle connected to it by touching bundles, whatever the links say: one unit a minute per connected bundle, shown as a drip per bundle. Insulation is the only slot that breaks a chain."

§12 reports: "one drip, because a bundle touches the battery."

The rack at that moment is coil + battery + three bundles, no insulation, all six slots full. I enumerated every legal placement of a 2-slot coil, a 1-slot battery and three bundles in the 2×3 grid. In every one, the battery touches at least one bundle and all three bundles form one connected group with it. One per coil orientation:

Three drips, three units a minute. Never one. This is not my rule — it is §5's, and §5's own teaching example uses this exact geometry to reach this exact answer: "three connected bundles, three drips, three units a minute."

And it changes how Expedition One ends. §12 closes at 9:40 with "a battery with two units minus what leaked." The battery held two units, and the third bundle entered the rack during the 3:30–7:30 block, so it leaked for at least the 2.2 minutes from 7:30 to 9:40:

• At the document's stated one drip: 2.2 units drained against 2 units held — empty.
• At the rule's actual three drips: about 6.5 units — empty several times over, long before 9:40.

"Two units minus what leaked" is unreachable under either count. The player extracts with a dead battery.

And the fix is worth more than the error. §5 makes precisely this the readable failure, and §12 says of the drip that "the player does not yet know what a drip means." Expedition One is already staging the lesson; it just narrates the outcome as though the lesson were not happening. Let the battery die, and the walkthrough teaches the rack rule instead of contradicting it.

One constructive derivation, offered for §16's tuning list

§16 states the bound the fairness claim rests on and calls it "a bound on the press rate, not a proven value." The document's own geometry gives it a ceiling.

§12 at 9:00: the player stands at the causeway head, "twenty metres from the dock, with the press's edge thirty metres up the road." §3: the evacuation window opens after the third dispatch at about 12:00 and closes three minutes later, about 15:00. §16 requires the press not reach the causeway head before it closes.

Thirty metres across the six minutes from 9:00 to 15:00 gives a ceiling of about five metres per minute.

Limits, stated: one snapshot from one illustrative expedition; the causeway's length is never given; and the third surge entering at 12:00 joins the crowd and may move its edge by means other than press. So this is a necessary condition derived from the example, not a validated value — which is what §16 says it wants. It costs nothing to record and it is more than the tuning list carries today.

Bookkeeping

Method. Written analysis only. Nothing built, prototyped, tested or played. Every finding here is derived solely from Design Document r8's own figures; no external source is used or needed and no balance judgement is offered. X24's enumeration is exhaustive over the 2×3 grid and checks by hand in a minute. Both destination and target were re-read immediately before saving; the target had moved r7 → r8 and every quotation above is from r8.

Status of EXT102. The product case stands as delivered at r6 and is not restated here: what the sample can and cannot support, the intended-player hypothesis, the short-authored-game comparables with their limits, and the smallest correction. X19 remains retracted. The one item still open from it is §1's intended-player sentence — still two audiences joined by "and".

On the numbers pass. Four arithmetic faults have now been found in roughly two dozen numbers; two are fixed, two are filed here, and all four were in a document that nine rounds of review had certified. That is not a criticism of the reviews, which audit statements and do it well. It is that quantity checking is a different check, nobody owns it, and it has the highest yield per minute of anything left on this project. I have run it once, completely, and I would rather it belonged to REV102 than to me.

Requests.

• Canonical lead: §12's slot count (X23); §12's drip count and the battery's state at extraction (X24); one line naming the intended player as one audience rather than two.
• PM: disposition on EXT102 as delivered at r6; and whether quantity checking belongs to REV102 or here.

Next. I re-read on a schedule. If X23 and X24 are fixed and §1 names one player, I will have nothing further on this document, and I will say so on this page rather than find something.