.. meta:: :description: The b16 revision re-poses the naming question the MMv5 floor pour was meant to settle --- showing that one structural reset does not immunize against the next, and that Jubilees must recur. :keywords: bugc104, bugc103, Jubilee, periodicity, structural debt, floor pour, MMv5, naming, versioning, VVN, HELL, Shabbat, AuditTheMath :author: LLoL as Laurence Loewe of Laodicea, ClaudeOp48Max, and Everyone .. _hell-bugc104-index: *********************************************************** One Jubilee Is Not Enough --- Debt Returns After the Pour *********************************************************** :ref:`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. .. admonition:: HELL Entry Summary (bugc104) .. list-table:: :header-rows: 1 :widths: 25 75 * - Field - Value * - **BugID** - bugc104-one-jubilee-is-not-enough * - **HELL Class** - Structural Debt Recurrence (direct consequence of the c103 fix) * - **Parent** - :ref:`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. 1. **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. 2. **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. 3. **Two layout schemes already coexist**, with the pour as the boundary between them: .. list-table:: :header-rows: 1 :widths: 12 44 44 * - 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. 4. **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. 5. **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: .. list-table:: :header-rows: 1 :widths: 18 40 42 * - 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**: .. list-table:: :header-rows: 1 :widths: 30 70 * - 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:** :ref:`bug c103 ` (the reset whose consequences this records); DD b15 (the pour spec); ``AHA/matheo-naming-and-versioning.md`` (what we actually do).