isomesh — findings ledger

Started: 2026-08-11 · Append-only. Entries are never deleted, only re-tiered when new evidence arrives — with the old verdict left visible.

This is the project's epistemic state: what we believe, how strongly, and on what evidence. It exists because this project has already been wrong six times in ways that would have silently propagated into code, and because the research corpus contains several published figures that failed verification. A belief with no recorded falsification method is not a finding, it's a preference.

Machines

Every measured figure in this repo comes from one of these two, and machine-specific figures say which (the README and demo pages lean on this block by reference; added at D-003, sourced from docs/research/2026-08-13-measured-comparison.md).

How to use this file

• Before acting on a "known" fact, look for it here. If it's not here, it hasn't been checked.
• When a measurement contradicts something written down, that's an entry — the contradiction is the finding, not an inconvenience.
• Falsified entries stay. They're the most valuable rows, because they tell you which sources to distrust, not just which facts.
• Every entry names how it could be shown wrong. If you can't write that line, you have an opinion.
• An experiment that was run and reverted is an entry too — Part 4b. The verdict line is the point: a variant that was built, measured and put back is the most expensive thing to rediscover, because nothing left in the tree records that it was ever tried.

Index

611 entries — 130 falsified, 390 measured, 52 verified, 18 open, 21 experiments. Regenerate with scripts/findings_index.sh; CI fails if this is stale.

When this file splits

Stated in advance, so the decision is not made under pressure by whoever is holding it when it becomes unbearable. At 500 entries or 600 KB, whichever comes first, FINDINGS.md becomes the index plus Parts 5 and 6 — the method rules and the how-to — and Parts 1 through 4 move to findings/ split by axis, not by date: findings/correctness.md, findings/performance.md, findings/sources.md, findings/method.md. Date order is how the file grew and is useless for lookup; nobody has ever wanted "everything we learned in August".

Two things do not change at the split. The index stays generated — scripts/findings_index.sh gains the directory and keeps one table across all files, because an index per file is four places to look and therefore none. And entry numbering stays global: M-231 keeps its identifier wherever it lives, since every cross-reference in the backlog, the archive and a year of commit messages names it by number and a renumber would silently break all of them.

The index above carries the current count; it is generated, so it cannot drift from the file.

Confidence tiers

Never cite an R or F claim as justification for a design decision without saying which tier it is.

Glyphs, from 2026-08-17. A new ### entry opens with its tier glyph before the id — ### 🔬 M-324 — … — and 🧊 stands in for 🔬 when the measurement's finding is a null: no effect, and that is the result. Emoji are reserved for rows that carry news, so they stay a signal rather than decoration. A result that moved an open question, died instructively as a pre-registered prediction, or survived a targeted literature search that came back empty earns a > 🎉🎊🔥✨🏆 **DISCOVERY** 🏆✨🔥🎊🎉 blockquote directly under its heading, and the banner must say which of those it claims; a banner on a routine row devalues every other banner in the file, so routine confirmations and expected timings stay austere. scripts/findings_index.sh parses the glyph and fails loudly on any entry-shaped heading it cannot index (the M-277 class, now guarded). Rows older than this date carry no glyph and are not retrofitted.

Part 1 — Falsified

The most valuable section. Each row includes where the wrong belief came from, because provenance predicts the next error.

✗1 — "Surface Nets produces substantially fewer triangles than Marching Cubes"

Believed because: stated in this repo's own implementation brief, and near-universal folklore. Falsified by: A-004 measurement, then derivation, then independent numeric check. What's true instead: on a closed manifold surface meshed on the same grid, both counts are pinned by Euler's formula:

V_sn = V_mc + χ            F_sn = F_mc + 2χ

Exactly, at every resolution. V_mc = C (one vertex per crossed grid edge), F_sn = 2C (two triangles per crossed edge), F = 2V − 2χ on any closed triangulated manifold. The middle step is a combinatorial identity worth naming on its own: surface cells = crossed edges + χ.

Consequence: Surface Nets' case must rest on quad connectivity and inner-loop cost, not output size. In M-001 the count columns are a checksum with a predicted value, not a result. Would be shown wrong by: any closed-manifold pair on the same grid where the difference ≠ 2χ. Legitimately breaks at: boundary-clipped meshes (incoming at G-001 chunking — expect the assertion to fail there and do not "fix" it), A-013 welding, Marching Cubes vs Marching Cubes 33 differing in χ. A-013 landed and sharpened the welding clause (M-48): a weld lowers V_mc only where a grid sample lands on the isosurface, which is a sampling accident rather than a property of welding — measured at 48 of 654 vertices on sphere at 25³, and zero at 17³ and 33³ and on four of the seven fields entirely. So the identity is not broken by A-013 existing; it is broken by a field that happens to touch a lattice point, and by chunking.

✗2 — "You can have a manifold mesh or an intersection-free one, not both"

Believed because: folklore, repeated in several secondary sources. Falsified by: literature review round 1. Manson & Schaefer 2010 achieved both. ODC (2024) measured Manifold Dual Contouring at 100% of models self-intersecting against ODC at 0 of 1500. Consequence: guaranteed intersection-free extraction is on the table, which is the premise under A-009 and the runtime-convex-decomposition opportunity.

✗3 — "Every interior Surface Nets vertex has four neighbours"

Believed because: written into isomesh's own module docs before measuring. Falsified by: A-004. Measured max degree 10 — higher than Marching Cubes' 9. Method rule earned: a doc comment the test suite disproves is worse than no doc comment.

✗4 — "Dual Contouring is absent from the home-still corpus"

Believed because: distill_search returned nothing. Falsified by: catalog_read on 10.1145_566570.566586 — present, with zero Qdrant chunks. Root cause: 342 documents are readable but invisible to distill_search. Method rule earned: presence in the corpus is decided by catalog_read / catalog_list, never by search. Any claim of absence made from a search result is unfounded.

✗5 — "naga_oil is the shader composition path for Bevy"

Believed because: it was, and it's the name everyone knows. Carried into this project's premise. Falsified by: naga_oil's last release is v0.18, 2025-06-26 (14 months stale), and Bevy 0.19's own release notes say they will "port our existing internal shaders to use WESL, and endorse it as the shader language of choice for Bevy." Consequence: GPU-002 uses a ~40-line preprocessor; WESL revisited when shader count justifies it.

✗6 — "Mesh shaders aren't reachable from inside Bevy"

Believed because: an imprecise claim made in this project's own speed analysis. Falsified by: wgpu v28 shipped Features::EXPERIMENTAL_MESH_SHADER; Bevy 0.19 pins wgpu 29.0.3; WgpuSettings.features requests it at device creation and RenderDevice::wgpu_device() -> &wgpu::Device gives raw access. What's actually true: wgpu's maturity is the blocker, not Bevy. Experimental, redesign issue open, no browser support, Metal status contradictory (see O-5).

✗7 — "CBT 5.78 → 0.40 ms is from Dupuy 2020"

Numbers confirmed. Attribution wrong — it's the Unity SIGGRAPH 2021 talk. Method rule earned: verify the source separately from the number. A correct figure with a wrong citation propagates as an uncheckable claim.

✗8 — Velo3D "93M vertices / 31M faces"

Unsupported. No primary source located. Removed from the catalog rather than softened.

✗9 — "Marching Cubes' cost inside the volumetric loop was never measured" / "navmesh rebuild cost was never measured"

Both false. Dong 2018 measured meshing at 76.5–89.6% of the pipeline; van Toll 2012 measured navmesh rebuild. Both were asserted as gaps in this project's v2 catalog and corrected in round 1. Method rule earned: "nobody measured X" is a claim requiring the same evidence as any other.

✗10 — "glam should be the internal math library from day one"

Believed because: stated in this repo's architecture doc. Refined by: the agent at I-001. The core took libm only; glam is deferred to A-007, where the 3×3 solve is the first thing that actually needs matrix math. Why the refinement is better: the public API is arrays, so glam was never load-bearing; deferring it means the crate carries zero exposure to glam's ~quarterly breaking releases until it buys something. Consumers need no conversion impls either — glam::Vec3::from([f32; 3]) already exists.

✗11 — "Plain Marching Cubes has ambiguous faces and produces holes"

Believed because: stated in this repo's own implementation brief (Stage 2, "Plain Marching Cubes has ambiguous faces and produces holes"), carried into BACKLOG.md's A-002 acceptance criterion, and near-universal folklore about Marching Cubes. Tested by: validate_table() (marching_cubes/mod.rs:319), which checks all 256 cases structurally, and the assertion assert_eq!(report.face_disagreements, 0) at marching_cubes/tests.rs:30. Result: zero face disagreements, across all 256 cases. What's true instead: holes require two cells sharing a face to disagree about how the surface crosses it. In this implementation a face's segments are a function of that face's own four corner signs and nothing else — the two cells meeting on a face read the same four corners, so they cannot disagree. The property is structural, not empirical, and it falls out of the table being derived at compile time by walking each face counter-clockwise rather than transcribed from a diagram.

The folklore is not wrong about Marching Cubes in general; it is wrong about this Marching Cubes. Lorensen & Cline's original table was transcribed per-case and its ambiguous cases were resolved inconsistently between complementary configurations, which is where the holes came from.

Consequence: A-002's acceptance criterion was unsatisfiable and has been re-scoped. Marching Cubes 33's remaining value is topological agreement with the trilinear interpolant — a genuinely different surface on ambiguous faces, measurable as a χ difference — not crack-fixing. The research is explicit that a game wants consistency over topological fidelity, so the L slot is now spent knowingly rather than against a test that could never go green. Would be shown wrong by: any field producing boundary_edges > 0 from A-001 on a closed field, or any non-zero face_disagreements.

✗12 — "The equivariant vertex rule needs a fast three-plane path with a fallback"

Believed because: BACKLOG.md split it into A-007 ("the three-plane rotation-equivariant rule… falls through to A-008 when the triple product is near zero") and A-008 ("for >3 planes and degenerate cells"), and the brief says "falls back when the triple product is near zero (near-parallel planes)". The crate architecture doc says the same in a third phrasing: "fall back to the regularized normal-equation form only for >3 planes". Tested by: reading the audit doc all three of them cite — docs/research/2026-08-10-adjacent-math-transfer-audit.md:182-219. Result: the audit gives the Tikhonov-adjugate form as the production form and describes it as "branch-free, handles all degeneracies", closing with "no eigendecomposition, no SVD, no iteration, no data-dependent branch". It is a single unconditional path in the source, not a fallback arm.

Worse, the audit's diagnosis of why Dual Contouring pops is the branch itself: Dual Contouring's hard SVD truncation at σ < 0.1 is a discontinuous branch, and over 20,000 trials seeded at the threshold in f32 the rank branch disagreed after a rotation in 454 cases, with ‖f(Rx) − Rf(x)‖ median 2.13 and max 9.10 — a several-cell vertex pop from an infinitesimal rotation. A triple-product threshold is the same construction with a different discriminant, so the split would have reintroduced the exact failure the rule exists to remove.

The measured equivariance residual (f32, coordinates in [0,256], 4000 random cells) also shows the "fast path" is not the accurate one:

Tikhonov dominates Cramer on both tail columns, so nothing is traded away by dropping the three-plane form. The two paths also do not agree to within noise, which means the branch would have been observable in the output.

Consequence: A-007 and A-008 merged into one ticket with one unconditional path. Two requirements the audit states and no ticket had recorded are now in it: magnitude-sorted 3-term dot products (4328/9600 equivariance failures unsorted, 0/9600 sorted — the guarantee does not hold in f32 without this), and the derivation of λ = 0.01 as the value that reproduces Dual Contouring's σ = 0.1 truncation smoothly. The corpus circulates three constants — 0.01, 0.1, and σ=0.1 — and an implementer reading only the algorithm catalog would have picked 0.1. Would be shown wrong by: a measured configuration where the adjugate form is less accurate or less equivariant than the Cramer form, or where det(M + λI) is small enough at λ = 0.01 to matter.

✗13 — "Real::as_f32 is the only narrowing operation in the crate, and the crate itself never calls it"

Believed because: stated in real.rs's own doc comment for as_f32, which frames it as an output convenience — "it exists for consumers writing into an f32 vertex buffer". Tested by: grep -rn "as_f32()" crates/isomesh/src/. Result: three call sites, none of them a consumer and none of them writing a vertex buffer:

All three are the same idiom, f.as_f32() as iN — a float→integer narrowing. Two predate this session, so the doc comment has been false since I-002.

Why this is more than a tidiness point. The doc's framing hides the property that actually matters at these call sites: as_f32 on an f64 is exact only up to 2²⁴, so using it as an integer narrowing step carries a silent lattice cliff. noise.rs knows this and guards with a LATTICE_LIMIT debug assertion; the other two did not, and nothing said they should. See M-18 for where that bites. Consequence: the doc comment corrected in place, and T-008 opened for the one exposed call site. Method rule earned: ✗3's, again — a doc comment the code disproves is worse than no doc comment. Twice now the false comment has been an architectural claim ("nothing calls this", "every vertex has four neighbours") rather than a factual slip, which is the kind that shapes later decisions.

✗16 — "glam 0.32 lands with A-007's vertex solve"

Believed because: stated in four places — CLAUDE.md's crate layout ("Deps: libm today; glam 0.32 joins it at A-007. Nothing else, ever.") and its dependency-justification section, BACKLOG.md's A-007 ticket, BACKLOG_ARCHIVE.md's I-001 note, and ✗10 itself, which deferred glam to A-007 on the grounds that "the 3×3 solve is the first thing that actually needs matrix math". Tested by: reading glam 0.32.1's source before adding the dependency. Result: glam has no scalar abstraction. Mat3 lives in src/f32/mat3.rs and DMat3 in src/f64/dmat3.rs as separate concrete types, lib.rs re-exports per-scalar modules, and there is no generic Mat3<T> and no trait spanning the two. The only pub trait in the crate is FloatExt, a scalar extension trait.

What's true instead: the premise was right and the conclusion did not follow. The solve does need matrix math — but this crate is generic over Real, which spans f32 and f64, and glam's types do not. Using it would mean a bridge trait with two impls forwarding every operation, which is more code than the 3×3 adjugate it would wrap, adds a dependency, and puts two float backends inside one solve — the exact thing the libm justification rejects.

So the 3×3 lives in dual_contouring/solve.rs as a six-entry symmetric matrix over [R; 3], about 40 lines, and the crate stays at one dependency. The "as light as possible" pitch survives A-007 intact. Would be shown wrong by: glam gaining a generic scalar parameter, or this crate dropping f64. Note this is ✗10's second correction. ✗10 moved glam from "day one" to "A-007"; the deferral target was wrong too. The recurring error is reasoning about glam from its reputation rather than its API.

✗15 — "Marching Cubes is unconditionally manifold"

Believed because: every measurement in this repo said so. M-4 contrasts Surface Nets' non-manifoldness against "Marching Cubes' zero at every resolution", the README says "Marching Cubes stays manifold", and the mechanism looked airtight — Marching Cubes places vertices on grid edges rather than one per cell, so the multi-sheet argument that sinks Surface Nets does not apply. SurfaceGate::Closed's own doc comment asserted it. Falsified by: T-005b's marching_cubes_meshes_sphere_unions, on its first run against a fresh proptest seed — during T-006, which is a nice demonstration that the property tests keep working after the ticket that wrote them. Result: a union of three spheres at h = 2/3 gives 2 non-manifold edges and 3 non-manifold vertices on a mesh that is otherwise perfect: closed, χ = 2, one component, consistently oriented, zero boundary edges.

What's true instead: Marching Cubes is manifold when the grid resolves the surface. Where the surface pinches inside a single cell — two lobes of a union meeting at sub-cell scale — the shared grid edge ends up carrying four faces. Refinement fixes it, and sharply:

Consequence: the property suite's gate is renamed from ClosedAllowingMultiSheet to ClosedAllowingUnresolvedTopology and now covers Marching Cubes on generated fields too, because the condition was never about the algorithm — it is about whether the grid resolves the field. The strict gate is still asserted where it is actually true, on the seven reference fields in marching_cubes/tests.rs. The exact counts are pinned in both directions by an_under_resolved_pinch_makes_marching_cubes_non_manifold, following M-4's precedent: the defect is an assertion, not an exclusion, so it fails if it spreads and if it silently disappears. Would be shown wrong by: the same field at h = 2/3 coming back manifold, or any resolved field coming back non-manifold under Marching Cubes. Worth noting for G-001: a chunk boundary is a place where a surface can be under-resolved relative to the chunk it lands in. This is a plausible source of seam defects later.

The counterexample stands; the mechanism was wrong, and A-015 proved it. The falsification condition above — "the same field at h = 2/3 coming back manifold" — is now met, by a change that touched no geometry at all: the union of three spheres reports 0 non-manifold edges and 0 non-manifold vertices once cycles are fanned from a chord-safe apex.

That settles the attribution, because a triangulation cannot repair a pinch. If two sheets genuinely met inside a cell they would still meet however each is triangulated. What was actually happening is the fan chord of ✗17: two cells choosing the same interior diagonal, four faces on one mesh edge. The refinement table above is real but was reading a proxy — refinement changed which sign patterns occurred, not whether the grid "resolved" anything.

The reading of χ was wrong too, and in a way worth keeping: a collided mesh edge is counted once in E while carrying four faces, so E was short by exactly the two collisions and χ was long by two. The old χ = 2 was not a topology measurement. The same fixture now reports χ = 0, genus 1 — three lobes meeting in a genuine handle at that spacing.

Consequence: the property suite's Marching Cubes gate goes back to the strict SurfaceGate::Closed it was waived from, and passes 8,000 generated cases where before A-015 it failed on the first fresh seed. Whether Marching Cubes is unconditionally manifold is now open, not settled — see O-12. Nothing here proves it; only that the one mechanism ever exhibited is gone.

✗17 — "Only the interior test can make Marching Cubes 33 non-manifold, so the face decider alone cannot"

Believed because: it was written down as a prediction in A-002's plan, and the reasoning looked tight. Custodio et al. (2013) §6.2 give exactly one mechanism for Marching Cubes 33's non-manifold edges — "two adjacent voxels that share an ambiguous face have tunnels in the voxel interior" — and tunnels come from the interior test, which A-002 deliberately does not implement. The face decider only re-pairs cut edges; it moves no vertex and creates no new one. Falsified by: every_closed_reference_field_meshes_cleanly_under_the_decider, on its first run. Result: the capped gyroid at 25³ gives 2 non-manifold edges and 3 non-manifold vertices under the decider against plain Marching Cubes' 0, on a mesh with zero boundary edges and zero inconsistently oriented edges. At 17³ and 33³ the two rules agree exactly.

What's true instead — and it is not the decider's fault. Both offending mesh edges carry four faces. Inspected rather than reasoned about: each joins two cut cube edges that lie on a shared cube face but are not connected by a segment there, and each is emitted twice by each of the two adjacent cells. They are fan chords. marching_cubes/table.rs's triangulate fans each cycle from its first edge, and any triangulation of a k-gon that adds no vertices has k − 3 interior chords; nothing local stops two neighbouring cells choosing the same one.

An exhaustive two-cell search settles the attribution. Two cells stacked along z share a face and have twelve samples between them, so all 4,096 sign patterns fit in a loop:

Identical. Plain Marching Cubes has this defect at exactly the same rate. The decider only changes which sign patterns are reached, and on the gyroid at 25³ it happens to reach one.

Consequence: the defect is ticketed against Marching Cubes as A-015, not against Marching Cubes 33, and the fix is a per-cycle centroid vertex — the only chord-free triangulation of a polygon. That breaks ✗1/M-2/M-22's V_mc = C identity and re-baselines every golden hash, which is why it is its own ticket rather than a fix folded into this one. Meanwhile is_closed() is deliberately not the gate in the decider's reference-field sweep, because it folds in manifoldness and manifoldness is owned by the fan; the census is pinned exactly instead, following M-4. Fixed at A-015, and for far less than it looked like it would cost. The obvious repair — a centroid for every cycle of four or more — works and is ruinous: +73% vertices and +74% triangles across the seven reference fields, up to +99.7% on box_exact, because almost every cycle is long enough to qualify. The cheap repair follows from asking which chords can collide rather than eliminating all of them: only a cell containing both of a chord's cut edges can emit it, and two cells share a pair of cube edges only when those edges share a cube face. So a fan is safe when none of its chords joins two edges of one face, and that is a local, const-evaluable test. Measured over all 256 cases and every canonical mask, a safe apex exists for every cycle of length 3–7 and for 48 of the 60 length-8 cycles; only lengths 9 and 12 have none, and plain Marching Cubes tops out at 7. Final cost across the whole golden fixture: one row's counts changed — marching_cubes+decider/gyroid/25, +6 vertices and +12 triangles. V_mc = C is intact.

Would be shown wrong by: the two-cell search returning a different count for the two rules, or the offending mesh edges turning out to be face segments rather than chords. Method note: the prediction was written into the plan before the code ran, which is the only reason this reads as a falsification rather than as a bug that was quietly fixed.

✗14 — "Surface Nets is the cheapest thing in the family and the natural default"

Believed because: this repo's own algorithm catalog states it as the engine verdict — docs/research/2026-08-10-meshing-algorithm-catalog-v2.md:163, "cheapest thing in the family and the natural default" — reinforced by the same folklore ✗1 already corrected once. Tested by: T-006's resolution sweep, cargo bench --bench resolution_sweep. Sphere, f32, single thread, median of 5 timed runs after 2 warm-ups, identical grid and reused output buffers for both algorithms. Raw data committed at docs/measurements/resolution_sweep.csv. Result: Surface Nets is cheaper only below about 48³. The crossover sits between 48³ and 64³, and past it Surface Nets loses steadily and then sharply:

What's true instead: the two curves are not parallel — one converges and the other degrades. Marching Cubes' per-sample cost falls from 21.9 to 4.78 ns as the O(n²) surface term amortises away, then is flat from 128³ on. Surface Nets' is flat at ~9 ns to 128³ and then rises, reaching 13.19 ns/sample at 256³ — a 33% jump from 192³ alone.

Consequence: taken with ✗1, which showed Surface Nets emits 2χ more triangles rather than fewer, both halves of the case for Surface Nets as the default are now falsified by measurement in this repo. What it actually retains is quad connectivity and one vertex per cell — a topology argument, not a cost one. M-001's shootout must not present it as the cheap baseline, and the choice of a default extractor for the game should be revisited.

Would be shown wrong by: a machine where Surface Nets' per-sample cost stays flat to 256³, which would localise this to one cache hierarchy rather than to the algorithm.

Amended again the same day (M-285), and this time the conclusion itself moves. A-023 made emit_quads' axis a const generic — three monomorphisations of one function, same order, byte-identical mesh — and Surface Nets went 693.8 → 224.4 ms at 256³, SN/MC 5.43× → 1.72×, IPC 1.20 → 2.77. At 48³ Surface Nets is now faster than Marching Cubes, 30.7 cycles per sample against 33.1. So the sentence "Surface Nets never wins on Zen 3, at any resolution" is false, and the cost half of the case against Surface Nets as a default is much weaker than this entry says: 1.7× at the largest grid, a win at the smallest. ✗1's half is untouched — Surface Nets still emits 2χ more triangles — so the entry is narrowed rather than reversed, and the residual gap is the cache story of M-286 rather than the algorithm.

Amended 2026-08-16 (M-282), and the conclusion is stronger while every number here is superseded. Measured in one binary and one run on the Ryzen: surface_nets / marching_cubes at 256³ is 5.43× against the 3.72× above, and 3.19× at 16³. Marching Cubes got 1.74× faster between d2ab82a and now while Surface Nets got 1.17×, which is where the widening comes from. The mechanism is also no longer "per-sample cost rises": M-279 measured that the whole family divides on IPC — everything table-driven runs at 3.7–4.2 and everything on DualMesher at 1.20–1.42 — and that the dual's rise with n is a 16% IPC decline on an instruction stream that is flat per sample. And per M-281, the absolute milliseconds in this entry are comparable only against others from the same binary.

Confirmed on a second machine at O-11, and harder — but the crossover is not (M-45). On an AMD Ryzen 9 5900X, Surface Nets' per-sample cost climbs 37.4 → 49.1 ns over the same sweep, so the falsification condition above is not met: the verdict is a property of the algorithm rather than of one cache hierarchy. The ratio is worse there — 3.72× at 256³ against the M5's 2.65×.

What does not transfer is the sub-claim "Surface Nets is cheaper only below about 48³". That crossover exists on the M5 only because Marching Cubes starts expensive there — 24.99 ns/sample at 16³ — and converges. On Zen 3 Marching Cubes is flat at 13–15 ns from 16³ up, so it has nothing to converge from and Surface Nets is behind at every resolution measured, 2.46× even at 16³. Any statement of the form "Surface Nets wins at small grids" is an Apple-silicon statement.

Narrowed by A-007. Dual Contouring, which shares the dual topology and differs only in vertex placement, shows the same curve: 218.9 ms at 256³ against Surface Nets' 212.5, and the same negative fitted intercept. So the superlinearity is a property of the shared dual engine — its sampling and its strided quad walk — and not of either vertex rule. That is a real narrowing of O-11's search: the suspect is the gather in emit_quads, whose z-stride is n² cells apart.

✗18 — "A hairline seam difference is a crack no weld can close"

Source: this repository — M-73, and transvoxel::cell's own module docs, which say it twice.

"A weld cannot rescue it: welding merges vertices it can see are the same, and these two differ in the last bit." (M-73)

"The weld can close a seam it can see; it cannot invent a shared vertex where the two sides disagree in the last bit." (cell.rs, module docs)

Falsified at R-004 (M-278). "Vertices it can see are the same" reads as bit-identity, and the welder's rule is not that: it is first fit within epsilon, and the one policy is epsilon_for(h) = h · 1e-4. At h = 1/12 that is 8.33e-6 against a worst measured seam disagreement of 1.440e-15 — nine orders of magnitude inside the tolerance, and the 27-cell lattice probe means straddling a bucket boundary does not save it either.

Measured on the two-resolution fixture, offset arithmetic, all five spacings and both LOD pairs: 0 seam-plane boundary edges in all twenty rows under the crate's own weld — including the twelve where a bit-identity merge leaves 63 to 348.

Two things survive, and they are why the M-73 fix was still right.

• A consumer that does not weld gets the crack in full. M-69 is that consumer on the record: "a seam of unshared vertices that a renderer draws correctly and a collider reads as a hole." Sharing by construction is structural; sharing by tolerance is a policy someone can change.
• The weld is not free to lean on. R-001 measured that it can create a non-manifold edge (M-226) and R-002 that its result depends on input order. "The weld will catch it" is a bad thing to design against even when it is true.

And the claim understates the damage in the other direction, in 2 of 12 rows. The offset arithmetic is not always a hairline: on torus at h = 1/12 the widest bit-identity crack is 2.076 cells at LOD 0–1 and 1.053 at 1–2, because a sample perturbed in its last bit crossed zero and the two sides then disagreed about whether an edge was cut at all. That is a hole, not a rounding error, and no weld epsilon short of a cell would close it.

✗19 — "Manifold Dual Contouring's uniform-grid surface is always a manifold"

Source: the paper itself, read at A-022 (V-34). Schaefer, Ju & Warren, §3:

"To create polygons, the algorithm constructs one polygon connecting the vertices associated with that edge in the four adjacent cells. … this surface is always a manifold because the original MC algorithm always constructs a manifold and the dual preserves the topology of the surface."

Unconditional, and at the uniform-grid level — before any octree, any simplification, any clustering.

Falsified at A-022 (M-290). Eight reference fields × three resolutions, no chunking, no weld:

The interesting part is which half of the argument fails. The premise is "the original MC algorithm always constructs a manifold" — ✗15 records that as false in general, so the obvious guess is that the premise is what breaks. It is not: Marching Cubes measures 0 on all 24 configurations here, under both face rules, A-015 having removed the fan chords that made ✗15's counterexample. The premise holds and the conclusion still fails, so what is false is "the dual preserves the topology of the surface".

And the mechanism was already written down in this crate, as something the paper did not claim. manifold_dual_contouring's module docs say the residue is "two crossed edges of one shared face resolving to the same cycle pair", producing four quads on one dual edge, and then: "Schaefer, Ju and Warren separate sheets within a cell and never claimed to handle [this], so this is outside what they guarantee rather than a defect against it." That charitable reading was written while the paper was unobtainable. They do claim it, in one sentence, unconditionally. So the residue is a defect against the paper's stated guarantee and not outside it, and the crate's own docs need the correction — which they now have.

What is not falsified. The paper's contribution is the octree vertex-clustering algorithm and its topology-preservation proofs, none of which this touches. What fails is the one-sentence argument for the uniform-grid base case it builds on, and it fails on noise_cavity only — the field A-002e added because none of the other seven produces a cell with an interior ambiguity (M-208).

Part 2 — Measured here (tier M)