One Jubilee Is Not Enough — Debt Returns After the Pour#

Bug c103 found that structural debt from reorganization compounds until a periodic reset — a clean break separating one era from the next — becomes unavoidable. The Floor Model was that reset, and it was performed: every Matheo paper’s public copy was poured from HELL and stamped with one uniform mmv5 release marker.

Roughly two months later, the first substantive revision of a floored paper (b16, RiskyMAD) re-posed the exact question the pour was meant to settle: what do we call the revised paper?

That is the finding. Having celebrated a Jubilee once does not make the next one unnecessary. The reset did not eliminate the debt-generating process; it zeroed a counter that immediately began counting again. This is not a failure of the Floor Model — it is the Floor Model working exactly as designed, and it is the first in-project evidence that resets must be periodic rather than one-off.

That distinction is not a footnote. It is the whole difference between the Shabbat pattern and the Jubilee System, and a skeptic could read c103 as saying “reorganize properly once and you are done.” c104 is the refutation, produced accidentally, by the infrastructure of the project that formalizes the claim.

HELL Entry Summary (bugc104)

Field	Value
BugID	bugc104-one-jubilee-is-not-enough
HELL Class	Structural Debt Recurrence (direct consequence of the c103 fix)
Parent	bug c103 — the Floor Model was the reset whose after-effects this bug records
Lesson	A structural reset zeroes the debt counter; it does not remove the process that increments it. Debt resumes accruing the moment the reset completes. Therefore resets must recur on a schedule, and the incremental-maintenance pattern (Shabbat) cannot substitute for them — nor they for it.
Theological Equivalence	The Jubilee System’s periodicity claim (every 50 years, not once) is exactly what this bug observes at project scale. One debt cancellation does not end inequality forever; drift resumes on day one. A single celebrated Jubilee that is never repeated is indistinguishable, after enough time, from never having held one.
Technical Keywords	floor pour, release marker vs maturity code, FileID stability, scheme coexistence, decoupled axes, debt meter, periodic reset
Status	Documented, not resolved. b16 follows the b19 precedent (below). No new scheme introduced. The series-wide re-pour is deferred.

The five tensions#

Each is real, and none is anyone’s mistake. They are what the decoupling costs.

The release marker looks like a version number. Per DD b15 §2, mmv5 means which website release, not how mature. But it is spelled like a version, so a newcomer reading b16-form-riskymad-mmv5 reasonably infers maturity and infers wrong. This is precisely the information inequality c103 named: navigable to insiders, opaque to newcomers.
The two axes diverge, by design, and the gap widens. True maturity lives in HELL: b19 is at PPv1, b16 is being promoted to OOv1, others remain at MMv3. The floor says mmv5 for all of them. The decoupling is correct and deliberate — and every promotion widens the gap it has to explain.

Two layout schemes already coexist, with the pour as the boundary between them:

Paper	Layout	Era
b16	version subdirectories: `hell/mm/b/16/mmv1/`, `mmv2/`, `mmv3/`	pre-pour
b19	flat file, stability code in the filename: `hell/mm/b/19/b19-sgir_…-ppv1_2026.rst` (+ `si/`)	post-pour

Neither is wrong. Their coexistence in one hell/mm/b/NN/ namespace is the debt. Any b16 revision must pick one and thereby deepen the inconsistency in one direction or the other.

Every revision re-poses the naming question, and the answer must be re-derived from DD b15 + AHA/matheo-floor-pour.md + the b19 precedent each time. That re-derivation cost is the debt, and it is paid per revision, by whoever happens to be holding the paper.
The FileID is load-bearing, so renaming is expensive. b16-form-riskymad-mmv5 appears 68 times across 16 files, including scripts/gen-matheo-floor.py, scripts/build-matheo-pdfs.sh, the floor-plan HTML, the series reflist, two committed PDFs, and four public pages (crisis/wagers, crisis/science, crisis/see-the-problem, buy-in/campaign/intro-gofundme). Renaming costs 68 edits and risks orphaning a live page; not renaming costs opacity. There is no free option — exactly c103’s result, recurring.

Why this is evidence for periodicity, not against the Floor Model#

The tempting misreading of c103 is: the mess was caused by not having reorganized properly; reorganize properly and the mess is gone. Under that reading, one Jubilee suffices and its recurrence is superstition.

c104 tests that reading against the record and it fails:

The pour was done properly (uniform marker, deterministic script for b19, a written spec in DD b15, a written procedure in AHA/matheo-floor-pour.md).
Debt resumed anyway, within ~2 months, at the first revision.
The debt is not of the same kind as before. c103’s debt was broken links. c104’s debt is a widening gap between a frozen public marker and a moving private maturity. A reset does not stop debt; it changes what the debt is made of.

The two patterns are therefore not substitutes and never were:

Pattern	Handles	Instance here
Shabbat (6:1, continuous)	drift between resets	per-paper pour scripts; the b19 precedent applied case by case
Jubilee System (periodic, discontinuous)	the phase transition the drift eventually forces	the MMv5 pour (done); a future series-wide MMv6 pour (not yet)

Running only Shabbat means the marker/maturity gap grows without bound until the public series is unreadable to anyone who did not watch it being built. Running only Jubilee means the intervals are chaos. The claim under test — at civilizational scale and here — is that a healthy system needs both, and that the Jubilee interval is finite.

Note

The falsifiable part. This bug predicts that the mmv5 marker becomes untenable as maturity diverges, and that a series-wide re-pour becomes cheaper than continuing to explain the decoupling. A rough trigger: three or more papers standing at OOv1 or above while the floor still reads mmv5. Today the count is two (b19 at PPv1, b16 at OOv1 pending). If the count passes three and a re-pour still does not pay, this bug is wrong and the decoupling is stable indefinitely — which would be evidence against the periodicity claim, and should be recorded as such. This bug is the meter, not the alarm.

What was decided for b16 (2026m07d15)#

Recorded so it can be reconstructed, per LLoL’s instruction to document rather than resolve, and not to introduce a third scheme:

Question	Decision
Floor FileID	Unchanged: `b16-form-riskymad-mmv5`. It is the address, not the version. Rejects the `b16-form-riskymad-mmv6`-alongside option, which would have left the superseded page live and publishing a contradictory headline under a second indexed URL.
Where the revision lives	HELL, following b19’s scheme (flat file, stability code in the filename), not b16’s own historical subdirectory scheme. Aligning to the newer precedent rather than inventing a third.
Stability level	OOv1 (OperatesOddly — minimal viable product, sort of working). Not PPv1: b19 is a deposited preprint; b16 is not there yet.
Directory move on promotion?	No. `hell/mm/` is the MockupModels area, and b19 sits there at PPv1. Promotion changes the stability code, not the path. There is no `hell/oo/` or `hell/pp/`.
Series-wide re-pour	Deferred. Explicitly not now. See the falsifiable trigger above.
Authority	`AHA/matheo-naming-and-versioning.md` (written with this bug), which points at DD b15 (the pour spec), `AHA/vvn-composition.md` (the VVN grammar), and `AHA/matheo-floor-pour.md` (the procedure).

Read by Audience#

For everyone: Cleaning your house once does not mean it stays clean. That is obvious for houses and somehow controversial for institutions. This is the project’s own filing system demonstrating it, two months after a thorough clean-up, in writing, with a date.

For producers and maintainers: mmv5 on a floor copy is a release tag, not a maturity claim. Do not rename it when a paper matures. Put the new version in HELL with the stability code in the filename (b19’s pattern) and re-pour the floor body. If you are about to invent a third layout, stop and read AHA/matheo-naming-and-versioning.md first.

For researchers and formal auditors: The interesting claim is the periodicity one, and it is falsifiable — the trigger condition is stated above with a number in it. The weakness to attack: two months and one revision is a very short baseline, and n=1 project is not a sample. The observation is offered not to be believed, but to be checked.

Related: bug c103 (the reset whose consequences this records); DD b15 (the pour spec); AHA/matheo-naming-and-versioning.md (what we actually do).