Method

The design space is finite. In dimension D there are 2^(2^D) designs and nothing else, so a claim about designs is a claim about a finite list, and the honest way to settle it is to walk the list. That one fact sets the method used on every page here: enumerate rather than sample, produce every number twice, pin every formula to something literally drawn, publish the scripts, and label each claim with what was actually established rather than with how sure it feels.

Every claim below carries a tag, on the convention the other pages use. Proved means a proof is given or restated here; Verified means recomputed from scratch for this page, not proved; Conjecture means neither.

Exhaust, do not sample

A design is a subset of the 2^D corners of the parity cube, so dimension D holds 2^(2^D) of them: 4, 16, 256, 65536 at D = 1..4. Designs related by a symmetry of the cube draw the same shape, and quotienting by the hyperoctahedral group B_D of signed permutations leaves 3, 6, 22, 402 classes. (Verified three independent ways in the core, and Verified again here by an independent orbit walk in lab/cubic/cubic.py, which reproduces all four.)

That is small enough to be brutal with. Where another project would test a formula on the named examples, the sweep here runs every design in the dimension: all 256 in 3D, all 65536 in 4D. A statement quantified over designs is then a finite check rather than an induction, and a counterexample cannot hide in the part of the space nobody drew — a real risk in this family, where the fraction of classes that are nameable as a level-set or an axis pin tends to zero, so almost every design is a compound nobody has drawn. (Proved in the core.)

Enumeration does run out. Past D = 4 the design count outgrows any list, and the counting moves to the Burnside average, which needs only the cycle counts of the group and never builds an orbit. That is the one place the method changes shape: from checking every object to proving a formula and evaluating it. See the bijection page, where the class count is proved equal to the number of NP-equivalence classes of Boolean functions, uniformly in D. That this count is the OEIS entry A000616 is Verified there, not proved, and cannot be otherwise.

Every closed form is pinned to a render

The standing rule for a counting formula is that it is never checked only against another formula. It is checked against an array built cell by cell from the parity rule and summed, with no arithmetic in common.

This is not a slogan; it is the shape of the test suites. The fill-class census compares its closed form against an independently rendered array for every design it censuses, at every side n = 1..12, and raises on any disagreement. The second generator behind the worked example below builds the n^D grid and counts. In the shipped code the same pattern holds: pkgs/mrlyrs/mrlymath/src/formulas carries the fill engine and its hexagonal projection formulas, and their tests compare each closed form against a rendered cell — fill_matches_rendered_sum against a built array, pro_and_cut_match_census against an actually projected one. (Verified: cargo test -p mrlymath was run for this page and passes, those two among its 246 unit tests.)

A formula proposes; the render disposes. Everything downstream — dimensions, polynomials, densities — inherits its credibility from that comparison.

What a sequence has to survive

The sequence ledger states the standard in full and records how each entry met it. In short, a sequence ships only with two independent generators that share no code and no method, a b-file diffed against both over the widest range they can reach, an adversarial re-verification by a second reader who reruns from the published directory and invents their own checks, and a novelty pass against a local OEIS dump at several windows, shifts and transforms plus the live entry where it matters.

The standard earns its cost by catching things. Re-verification of one entry found the cross-reference for 27^n wrong in the research notes — quoted as A001024, which is 15^n — and corrected it to A009971, powers of 27. (Verified: both entries fetched from the live OEIS for this page, A001024 reading "Powers of 15" and A009971 "Powers of 27".) Another entry passes on its terms, b-file, closed form and novelty, and still ships marked defective, because its draft's own program block seeds the grid one level too high and so skips a term; the data was right and the generator printed was not. Neither error is visible to a reader who only checks that the numbers look plausible.

One engine, then a census

The organizing move is to write one script that reads a design's invariants off its definition, then sweep it over the whole space, rather than to derive a formula per named family. The named designs stop being special cases and become rows.

The fill law is what makes this possible. With E = ceil(n/2) and O = floor(n/2) the number of even and odd residues available to one coordinate, a design F fills

fill(F, n) = sum over c in F of E^(D - w(c)) * O^(w(c))

cells of the n^D grid, w(c) being the number of odd coordinates of the corner c. (Proved: a cell is filled exactly when its parity vector is a filled corner, and for a fixed corner each coordinate independently has E or O admissible values, so the corner contributes that product; distinct corners contribute disjointly. The level-L fill is this raised to the L, proved in the core from the Kronecker product.) The law takes a design as data, so one implementation covers the entire space — it is the engine in pkgs/mrlyrs/mrlymath/src/formulas/counting.rs and the engine behind every census in the lab.

Three censuses run on that principle, and their honesty is uneven in a way worth stating plainly. lab/census/fillclasses/census.py sweeps 58 designs across bases 2 and 3 and dimensions 2 and 3, validating each cell by cell and checking its orbit counts against a Burnside average; it reproduces its stored output byte for byte on rerun. (Verified: rerun for this page, the 59-line csv identical to the stored copy.) lab/census/coprime/general.py measures 763 designs against a predicted coprime density and flags none. (Verified: 763 design lines across its four result files, of which 522 are spanning and so inside the density claim and 241 are degenerate and excluded by construction; every per-case summary reports zero flagged.) But that OK verdict is numerical agreement inside a flat tolerance at a shallow level, not a proof — the deepest level is capped, and the solid half of that census is the exact finite-level identity, not the limit. lab/cubic/cubic.py is the sweep behind the next section.

The three tags

The tags are a claim about evidence, not about confidence.

• Proved. A proof is given or restated on the page, and the reader can

follow it without running anything. The design count, the fill law, the bijection onto Boolean functions up to NP-equivalence.

• Verified. Recomputed from scratch, usually more than once and usually

including a route that shares no method with the first. Some claims can never be more than this: that a particular OEIS entry counts what we say it counts is a fact about the entry, checkable against its stated definition and its terms, not provable from our side.

• Conjecture. Neither — a fitted pattern or a limit with a proved mechanism

and an unclosed step. The coprime densities are conjectures with proved Euler factors. The count of isotropic classes as a function of D is a formula fitted to eight terms, and it is tagged as such even though it looks inevitable.

A claim that cannot be re-established does not ship. Material inherited from the research notes is retagged on arrival, and the parts that could not be reproduced were dropped rather than softened.

Worked example: the odd-side fill polynomial

One theorem, taken through the whole procedure.

Theorem (Proved). Fix a dimension D and a design F with popcount p = |F|. At odd side n = 2k-1, the fill is an integer polynomial in k of degree at most D whose coefficient of k^D is p — so the degree is exactly D for every non-empty design, and only the empty one falls short. Proof. At n = 2k-1 there are E = k even residues and O = k-1 odd ones, so the fill law reads fill(F, 2k-1) = sum over c in F of k^(D-w(c)) * (k-1)^w(c). Each summand is a product of D linear integer factors, hence a monic integer polynomial of degree D in k; a sum of p of them is an integer polynomial whose k^D coefficient is p, and it is identically zero exactly when p = 0.

Corollary (Proved). Popcount is invariant under cube symmetry, so the leading coefficient — and with it the fractal dimension — is a class invariant. The lower coefficients are not. Parity flips are symmetries of the infinite tiling but not of the truncation to n cells, so members of one class can fill differently at a fixed side; the polynomial in the table below belongs to the canonical representative, the smallest code in the class.

Corollary (Proved). The coefficient vector fixes the fill at every side and every level — the ledger's sense of two designs drawing the same fractal. The D + 1 polynomials k^(D-w) * (k-1)^w are linearly independent — setting k = 0 kills every term but w = D, then dividing by k and repeating kills the rest in turn — so the polynomial determines how many filled corners carry each Hamming weight, which is the popcount profile that fixes the fill at every side and every level. That is the same lemma the fill-class identity rests on in the ledger, and it makes the number of distinct polynomials in dimension D equal to Prod_{w=0..D} (1 + C(D,w)), which is the closed form of A129824.

Verified. Two generators sharing no code and no method: one sums the closed form over filled corners and interpolates with exact rational arithmetic, the other builds the n^D grid cell by cell, tests each cell's parity vector, and fits by finite differences. Both were run over every design — all 4, 16 and 256 at D = 1, 2, 3 — and agree term for term at k = 1..8. The closed-form sweep extends to all 65536 designs at D = 4; in every dimension the polynomial fitted on k = 1..D+1 predicts the true fill out to k = 10, the coefficients come out integral, and the leading coefficient equals the popcount with no exceptions. Distinct polynomials number 4, 12, 64, 700 at D = 1..4, which is A129824 at index D (fetched live for this page: offset 0, terms 2, 4, 12, 64, 700, ...). The lower coefficients split 4 of 6 classes at D = 2, 20 of 22 at D = 3 and 400 of 402 at D = 4, independently reproducing a caveat the fill-class census records; the leading coefficient splits no class anywhere. A third route agrees: the stored fill-class census, written separately, carries the level-1 fill at n = 1..12 for each 3D class representative, and its six odd columns match both generators on all 22 rows. Scripts and log in lab/cubic/.

The full 3D table, one row per class, ordered by popcount. (Verified as above.)

The two ends are classical and forced. mrly_001 has one filled corner and fills k^3, the cubes; mrly_255 is the solid cube of side 2k-1 and fills (2k-1)^3, the odd cubes. (Proved by the theorem, both endpoints; Verified against the live OEIS for this page — A000578, a(n) = n^3, and A016755, a(n) = (2n+1)^3.) The Menger sponge is one interior row, mrly_023, filling 4*k^3 - 3*k^2; at n = 3, which is k = 2, that reads 20, and the celebrated dimension log(20)/log(3) is one evaluation of an ordinary row. Two rows are identical: mrly_015 and mrly_027 are distinct symmetry classes — different shapes, related by no cube symmetry — that carry the same polynomial and so fill identically at every side and level. The two classifications cut across each other rather than refining one another — a polynomial can be shared by two classes, and fill is not constant within one — so the 22 classes carry 21 distinct polynomials while the 256 designs carry 64. (Verified.)

The research notes state this theorem for D = 3 alone, with a proof sketch and a check to k = 6 on the 22 class representatives. What is added here is a proof valid in every dimension and the sweep over every design.

Not claimed. The other twenty polynomials have not been through the novelty procedure — no dump grep, no shifted windows, no live search — so nothing is asserted about whether they already sit in the OEIS under other names. They are the output of a sweep, not a claim of new sequences, and they are printed here in that spirit.

Where the scripts live

Each result on these pages has a directory in the lab holding its generators, its stored output, and a RUN.txt recording the commands, the comparisons, and the failures — including the ones that did not resolve in the project's favour. The rule is the one that directory opens with: prose without the scripts is a claim, not a result.