test(cliffs): the field is RIGHT - the fine sweep refutes #106's conclusion (#84)

#106 concluded, from the band oracle, that the port's grid-4 cliff-elevation
field is wrong at [1500,1500]'s high bands, and handed over "it lives in the
mountains branch of vulcanus_elev". This sweep was run to quantify that. It
refutes it.

Sweeping `cliff_elevation_0` across [700,900] step 5 under the same
collapsed rule turns each placed cell's orientation into one-sided
constraints on its corners - a crossing at L says "this corner > L, that one
< L" - so 41 levels bracket a corner to the step. Only POSITIVE observations
are used, which is what makes it sound: an absent cliff is ambiguous (the
lava/ore rejections drop whole cells) but a present crossing is not, because
`fixImpossibleCellsSweep` only ever writes 0 and the rejections never touch
the edge registers.

- **996 of 998** two-sided brackets contain the port's value, mean bracket
  width **5.72**, in the worst region.
- The other two miss by **6.7e-4** - the port sits ON a swept level, where
  the strict test yields no observation. The open endpoint, not an error.
- At the disputed-edge corners: **26 of 26** bracketed ones contain it.

So the field is exonerated by direct measurement, and the lattice is
re-confirmed on the way: a wrong sampling site could not put 996 of 998
values inside 5-unit brackets.

**Where #106 went wrong.** It established what the residual is NOT (not
smoothing, not the gate, not the repair, not the rejections, not a boundary
tie) and treated the field as the last man standing - but it never measured
the game's field, only that OUR value sits a median 18.8 from the level.
"Everything else is excluded, so it must be X" is only as good as the list,
and the list was not closed. The lower bound was real; the attribution was
not. Same shape as #88.

What is left: across all 41 levels the game's code is the port's **minus
edges** in **1231 of 1235** disputed cells. The lead is the coverage number
- only 26 of 72 disputed corner slots get a bracket, and 661 of 1,659
corners in range get none, because the game emits nothing beside them. One
chunk at L=790 shows it directly: cell 1634,1706.5 keeps its TIGHT edge
(margin 5.9) and loses its WIDE one (margin 69), and the cell sharing that
wide edge is absent from the game entirely. That points at the
emission/rejection path - stated as a hypothesis, with the control named.

Determinism check: the two fixtures overlap at L=790 and agree 494/494.
Vacuity: shifting the field by 10 fails 3 of the spec's 5 tests.

Item of #84; the issue stays open.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011DckiyMmb4zDPBV8NSyxTg

Author: wormeyman

docs/noise/vulcanus-cliffs-NOTES.md

@@ -1922,3 +1922,66 @@ The obvious next measurement is a **fine level sweep** (e.g. 700..900 step 5 at
 `[1500,1500]`), which brackets the game's cliff-channel value per corner to the
 step and turns "differs by at least 69" into the actual field. It is ~40 runs of
 the same capture, no new machinery.
+
+## CORRECTION: the field is RIGHT - the fine sweep refutes the section above (2026-08-03, #84)
+
+The section immediately above concluded, from `oracle-vulcanus-cliff-bands`,
+that the port's grid-4 cliff-elevation field is wrong at `[1500,1500]`'s high
+bands, and handed over "it lives in the mountains branch of `vulcanus_elev`". The
+fine sweep was run to quantify that. **It refutes it instead.**
+
+`oracle-vulcanus-cliff-fine-sweep` sweeps `cliff_elevation_0` across
+`[700, 900]` step 5 with the same collapsed rule. Each placed cell's orientation
+asserts one-sided constraints on its corners - a crossing at level `L` says "this
+corner > L, that one < L" - so 41 levels bracket a corner to the step. Only
+POSITIVE observations are used, which is what makes it sound: an absent cliff is
+ambiguous (the lava/ore rejections drop whole cells) but a present crossing is
+not, because `fixImpossibleCellsSweep` only ever writes `0` and the rejections
+never touch the edge registers.
+
+| | |
+| --- | --- |
+| corners with a two-sided bracket | **998** |
+| mean bracket width | **5.72** |
+| where the port's value is INSIDE the game's bracket | **996** |
+| worst miss of the other two | **6.7e-4** (the port sits ON a swept level, where the strict test yields no observation - the open endpoint, not an error) |
+| disputed-edge corner slots with a bracket | 26 of 72 |
+| of those, containing the port's value | **26 of 26** |
+
+So the field is exonerated **by direct measurement** rather than by scoring, and
+this also independently re-confirms the `(i*4, j*4)` corner lattice: a wrong
+sampling site could not put 996 of 998 values inside 5-unit brackets.
+
+### Where the earlier reasoning went wrong
+
+The bands fixture established what the residual is NOT (not smoothing, not the
+gate, not the repair, not the rejections, not a boundary tie) and then treated
+the field as the last man standing. But it never measured the field - it measured
+that the port's value sits a median 18.8 from the level at the disputed edges,
+which is a statement about OUR field, not the game's. "Everything else is
+excluded, so it must be X" is only as good as the list, and the list was not
+closed. **The lower bound was real; the attribution was not.** Same shape as #88,
+where the best-scoring model was the wrong one.
+
+### What is actually left
+
+Across all 41 levels, the game's cell code is the port's code **with edges
+removed** in **1231 of 1235** disputed cells - the port finds crossings the game
+does not, and essentially never the reverse.
+
+The lead is in the coverage number: only 26 of 72 disputed corner slots get a
+two-sided bracket, and 661 of the 1,659 corners whose value lies in `[700,900]`
+get none. A corner goes unbracketed when the game emits no entity beside it at
+any level - which is what the lava and ore rejections do to whole neighbourhoods.
+Read one chunk at `L = 790` and the pattern is visible directly: cell
+`1634,1706.5` keeps its TIGHT edge (714.4 -> 795.9, margin 5.9) and loses its
+WIDE one (721.0 -> 875.4, margin 69), and the cell sharing that wide edge
+(`1634,1702.5`) is absent from the game entirely. The dropped crossings sit
+against cells the game did not emit.
+
+That points at the emission/rejection path, not at the field - i.e. back toward
+whether something suppresses a crossing (not merely an entity) in the
+neighbourhood of a rejected cell. Note this is a HYPOTHESIS from one chunk plus
+the coverage statistics; it has not been tested, and the obvious control is
+whether disputed edges are adjacent to rejected cells at a rate above the base
+rate of all crossing edges.

test/fixtures/PROVENANCE.json

@@ -216,6 +216,10 @@
       "factorioVersion": "2.1.12",
       "evidence": "re-captured 2026-07-30 by test/oracle/capture.ts vulcanus-cliff-entities against the installed binary, which pnpm refs:sync --check reported in sync at 2.1.12 at capture time. Supersedes the 2026-07-28 capture, which it reproduced exactly (283/885/409 positions). The re-capture adds each entity's cliff_orientation - see test/cliffOrientationOracle.spec.ts."
     },
+    "oracle-vulcanus-cliff-fine-sweep.seed123456.json": {
+      "factorioVersion": "2.1.12",
+      "evidence": "captured 2026-08-03 by test/oracle/capture.ts vulcanus-cliff-fine-sweep against the installed binary, which pnpm refs:sync --check reported in sync at 2.1.12 at capture time. The Vulcanus region [1500,1500] at 41 values of cliff_elevation_0 (700..900 step 5) with the rule collapsed (cliff_smoothing=0, cliff_elevation_interval=1e6) and the cliffiness gate held open by routing the cliffiness PROPERTY at the literal 1. Each placed cell's orientation asserts one-sided constraints on its corners, so the sweep brackets the grid-4 cliff-elevation field to the step - it MEASURES the field oracle-vulcanus-cliff-bands could only bound from below. Overlaps that fixture at L=790 and reproduces it cell-for-cell (494/494), which is the determinism check. Each case records the cliff_settings the SURFACE reported back."
+    },
     "oracle-vulcanus-cliff-ore-direction.seed123456.json": {
       "factorioVersion": "2.1.12",
       "evidence": "captured 2026-08-02 by test/oracle/capture.ts vulcanus-cliff-ore-direction against the installed binary, which pnpm refs:sync --check reported in sync at 2.1.12 at capture time. Six paired ON/OFF arms that turn the Vulcanus resources off through map_gen_settings.autoplace_controls (size = 0) and regenerate: [1500,1500] at default cliff settings with all resources on, all off, calcite only off and geyser only off, plus [0,0] with the cliff rule collapsed to a single contour at 70 with the gate held open and smoothing off, resources on and off. Each case records the autoplace controls AND the cliff_settings the SURFACE reported back, so every override is proven to have applied, and each dumps the cliffs, the resources and the prototype collision geometry from ONE generated surface so the two populations are never compared across separate worlds."