VP Lattice Jamming Theory LOCK → Derive → Gate — How This Framework Verifies Itself

═══════════════════════════════════════════════

TL;DR

• A theory’s quantitative claims are only as strong as the methodology that produced them. “The numbers match” is not enough — what matters is HOW they were produced.
• This framework follows a strict four-stage pipeline: Input (LOCK) → Derive → Verify (Gate) → Seal
• Every input quantity (definition, parameter, convention) is LOCKED before any derivation begins. Locks are stored in registries (canon_lock, realization_lock, gate_lock, protocol_lock).
• Every conclusion must pass a STACK OF GATES, not a single check: G-SYM symbols, units, dimensions G-LOCK lock integrity, no post-hoc changes G-REG regime compatibility G-RECT rectification-constant integrity G-STR structural invariant preservation G-RCROSS cross-consistency across independent channels G-REP reproducibility (code, inputs, environment) G-NT No-Tuning detection G-NUM numerical stability
• The No-Tuning principle (G-NT) is structural, not aspirational: parameters CANNOT be changed after seeing results. Changes are allowed only via VERSIONING.
• Final outputs are cryptographically sealed via manifest+checksums, so reproducibility is verifiable.
• This methodology is what distinguishes the framework’s claims from post-hoc curve-fitting. Without it, “85 derivations within a few percent of CODATA” could be coincidence; with it, those derivations carry weight.

═══════════════════════════════════════════════

1. Why Methodology Matters As Much As Math

In standard physics presentations, a theory is judged by:

─ does the math close? ─ do the predictions match experiment?

These are necessary but NOT sufficient. A theorist who knows the experimental answers in advance can construct mathematics that “predicts” them retroactively. This kind of post-hoc fitting is not always intentional — researchers can unconsciously adjust definitions, choose conventions, or select parameters in ways that improve agreement, then present the final version as if it were derived from first principles.

In high-stakes scientific work, the question becomes: how do we KNOW the agreement is not constructed? How do we distinguish genuine derivation from clever fitting?

The standard answer is “peer review and replication.” But for non-mainstream frameworks like this one, peer review may not be available, and replication requires that the framework’s procedures be PRE-REGISTERED in a way that allows anyone to follow them and check.

This is what the LOCK → Derive → Gate → Seal pipeline does. It is METHODOLOGICAL INFRASTRUCTURE that makes post-hoc fitting structurally detectable.

┌──────────────────────────────────────────────────────────┐ │ │ │ The methodological claim: │ │ │ │ ─ Standard presentation: “trust me, I derived this.” │ │ │ │ ─ This framework: “here are my pre-registered inputs │ │ (LOCK), here is the derivation procedure, here are │ │ the integrity checks (Gate), here are the sealed │ │ outputs (Seal). You can reproduce all of it.” │ │ │ └──────────────────────────────────────────────────────────┘

This is the article that explains how that infrastructure works.

2. The Pipeline — Input → Derive → Verify → Seal

Every conclusion in the framework follows a one-way pipeline (paper §0.3):

┌──────────────────────────────────────────────────────────┐ │ │ │ Stage 1. Input (LOCK) │ │ — canon_lock (axioms, definitions, │ │ canonical numbers) │ │ — realization_lock (length, time, energy) │ │ — gate_lock (Gate thresholds, definitions) │ │ — protocol_lock (code, seed, environment) │ │ │ │ Stage 2. Derive │ │ — perform symbolic / numerical derivation │ │ — produce intermediate quantities │ │ — produce the final result │ │ │ │ Stage 3. Verify (Gate) │ │ — apply the prescribed Gate stack │ │ — every Gate must PASS │ │ — single FAIL invalidates the conclusion │ │ │ │ Stage 4. Seal (snapshot) │ │ — cryptographic checksums of inputs/outputs │ │ — manifest with version_id, lock_id │ │ — outputs become unalterable for this version │ │ │ └──────────────────────────────────────────────────────────┘

The pipeline is ONE-WAY. Once you reach Stage 4, you cannot go back to Stage 1 and silently change a lock. Any change requires a NEW VERSION of the framework — with its own version_id, its own snapshot, and a clear record of what changed.

This is what makes the framework’s claims auditable. Any reader, with access to the locks and the code, can re-execute Stages 2–3 and check that the same outputs come out.

3. The Locks — What Is Stored and Why

The framework maintains FOUR distinct lock registries (paper §0.3.1). Each has a specific scope and purpose.

(a) canon_lock — axioms, definitions, canonical numbers

This holds the framework’s foundational definitions. Examples from earlier articles:

δ = 1/π² (Part 3, rectification constant) D_anch = 4.854194962126561 pm (Part 4, canonical anchor) a = λ_ref / N (Part 4, VP diameter via realization) N_p = 82 + 7 = 89 (Part 13, proton structural count) m = U_lat / σ_eff (Part 6, mass axiom)

Items in canon_lock cannot be changed without a version bump. They are the “constants” of the framework’s mathematical universe.

(b) realization_lock — operational anchors

The framework’s constants connect to physical units only through specific REALIZATION choices:

λ_ref = 632.99121257859865746 nm (HeNe wavelength, Part 4) N = 1⁰¹² (count, Part 4) Δt = A · a / c_ref ≈ 1.86 × 10⁻²¹ s (lattice tick, Part 4)

These are different from canon_lock because they involve choices about how to MAP framework quantities onto SI units. Changing the realization is allowed only by versioning.

© gate_lock — Gate thresholds

The Gate stack uses specific tolerance thresholds:

ε_R (radius tolerance for [C-82/7–01]) ε_σ (cross-section tolerance for [C-82/7–02]) V_min (survival vector threshold for [C-82/7–05]) τ_C (Coulomb comparison threshold for §14.2.7)

These thresholds are LOCKED IN ADVANCE. A theorist cannot loosen them after seeing results to make a borderline result PASS. If τ_C is locked at 0.5%, then a 0.6% deviation FAILS — even if the theorist would prefer it to PASS.

(d) protocol_lock — code, seed, environment

The framework’s deterministic algorithms (Poisson-gap sampling for the 82-core in Part 13, numerical integrators, etc.) require specific computational protocols:

code version (git hash) random seed (locked, not “random”) compiler / library versions operating system / environment

This makes results bit-for-bit reproducible. Anyone running the same code with the same seed gets the same output.

4. The Gates — What Each One Checks

A conclusion’s admissibility requires PASS on a STACK of Gates, not a single check (paper §1.3.3). The standard Gate namespace:

┌──────────────────────────────────────────────────────────┐ │ │ │ Required Gates (every conclusion must PASS all): │ │ │ │ G-SYM symbol meanings, unit dimensions, │ │ diameter vs radius, no definition collisions │ │ │ │ G-LOCK lock_id matching, registry-snapshot existence, │ │ absence of post-hoc changes │ │ │ │ G-REG regime compatibility │ │ (jamming/non-jamming, linear/nonlinear, │ │ long/short wavelength, boundary/initial) │ │ │ │ G-NT No-Tuning violation detection │ │ (definitions/values/procedures/thresholds) │ │ │ │ G-REP reproducibility │ │ (code/inputs/environment/seed/logs) │ │ │ │ Conditional Gates (selected by claim type): │ │ │ │ G-RECT rectification-constant integrity │ │ (uniqueness of definition location, │ │ ban on re-derivation/re-definition) │ │ │ │ G-STR structural-invariant preservation │ │ (integer decomposition, cancellation rules, │ │ symmetry, sum/difference invariants) │ │ │ │ G-NUM numerical stability │ │ (convergence, sensitivity, repetition stability) │ │ │ │ G-RCROSS cross-consistency │ │ (independent channels, baseline combinations) │ │ │ └──────────────────────────────────────────────────────────┘

A few Gates worth highlighting:

G-SYM (symbol consistency)

This Gate catches errors that would invalidate a derivation regardless of numerical agreement. For example: if “r_p” sometimes means radius and sometimes means diameter within the same derivation, the conclusion has G-SYM failure even if the final number happens to match CODATA. This Gate prevents accidental ambiguity from masquerading as agreement.

G-LOCK (lock integrity)

This Gate verifies that all referenced LOCK items are in the same version, and that no item has been changed AFTER the derivation started. If a parameter was at value X when the derivation began and value X’ when it ended, G-LOCK FAILS. The framework’s claim cannot stand on a moving foundation.

G-NT (No-Tuning)

The most important Gate for scientific honesty. G-NT checks for retrofitting:

─ Were any definitions changed after seeing results? ─ Were any thresholds adjusted to make borderline results PASS? ─ Were any selection criteria added to filter unfavorable outputs? ─ Were any logs tampered with to hide intermediate failures?

If any of these are detected, G-NT FAILS, and the conclusion is invalidated regardless of numerical agreement. This is what makes “85 derivations within a few percent” not equivalent to “85 fits to data.”

G-REP (reproducibility)

The most concrete Gate. Anyone with the locked inputs, the code, and the environment must produce the same outputs. Documentation of inputs, code version, random seeds, environment, and logs must be sealed in the manifest. If a result cannot be reproduced from the seal, G-REP FAILS.

5. The No-Tuning Principle in Detail

The most important methodological commitment of the framework is NO-TUNING — and it is structurally enforced, not aspirational.

What no-tuning forbids:

─ Changing a definition after seeing results.

Example forbidden move: “I locked δ = 1/π² but my derivation produces 186 instead of 1836; let me change δ to 9/π² and try again.” This is forbidden by G-NT.

─ Adjusting thresholds to make borderline cases PASS.

Example forbidden move: “My Coulomb constant has 0.6% deviation but my locked threshold is 0.5%; let me change the threshold to 1%.” Forbidden.

─ Cherry-picking which derivations to report.

Example forbidden move: “Of my 100 derivations, 90 match within 1% and 10 are off by 50%; let me only report the 90.” Forbidden — the 10 must be documented as failures.

─ Hidden re-derivation of locked quantities.

Example forbidden move: “δ = 1/π² is locked in §3, but I’ll re-derive δ in §13 with a slightly different convention to make my chain work.” Forbidden by G-RECT.

What no-tuning permits:

─ Introducing new definitions for new contexts (with their own locks). ─ Documenting borderline failures honestly. ─ Issuing a NEW VERSION with adjusted definitions and re-running everything.

The version-bump path is explicit: any change requires (i) a new version_id, (ii) re-running all locked derivations under the new convention, (iii) documenting what changed and why. This creates a paper trail. Tuning becomes visible.

This is exactly why Part 14 (the m_p/m_e π² convention problem) exists. Both Form A (algebraic) and Form B (reporting) are written into the paper. The π² gap is acknowledged. The framework documents the issue rather than tuning around it. THAT is the no-tuning principle in action.

6. Why This Methodology Helps the Reader

A reader of this series might naturally ask: how should I evaluate the framework’s many quantitative agreements? Is it fitting, or is it derivation?

The methodological infrastructure answers this in three ways:

(a) Pre-registration of inputs.

Every derivation in this series referenced quantities locked in earlier parts: D_anch in Part 4, r_p as CODATA input, δ = 1/π² from Part 3, the 82+7 structure from Part 13. These were all locked BEFORE the derivations of α_em (Part 11), K_C (Part 12), or m_p/m_e (Part 14) were performed. The reader can verify this from the paper’s lock_id metadata.

(b) Gate stack as integrity check.

The numerical agreements are not the only output. Each conclusion comes with PASS / FAIL labels for each Gate. A 0.04% match for m_p/m_e (Form B) is one thing; a 0.04% match that PASSES G-SYM, G-LOCK, G-REG, G-NT, G-REP is a much stronger statement. The Gate stack tells the reader what kind of agreement they’re looking at.

© Reproducibility of derivations.

Every numerical result in this series can be reproduced by running the framework’s code with the locked inputs. The Python verification snippets in Parts 10, 11, 12 are simplified versions of this — anyone can paste them into a Python interpreter and check. The full paper provides scripts for the more elaborate calculations (Poisson-gap sampling for the 82-core, the 8 stability conditions, etc.).

┌──────────────────────────────────────────────────────────┐ │ │ │ For the reader, the practical consequence: │ │ │ │ ─ You don’t have to trust the author. │ │ │ │ ─ You can verify any specific claim by: │ │ (i) reading the locked input in canon_lock │ │ (ii) re-running the derivation script │ │ (iii) checking the Gate stack output │ │ (iv) comparing the seal hash to the published │ │ manifest │ │ │ │ ─ Disagreement with the framework’s conclusions becomes │ │ a specific, technical disagreement — not a vague │ │ “I don’t believe it.” │ │ │ └──────────────────────────────────────────────────────────┘

7. What’s Honest About This Approach

The methodology does not guarantee correctness. The framework could still be wrong — its axioms could mismatch reality, its rectification constants could be artifacts of a specific construction, its π² gap (Part 14) could indicate a deeper structural problem.

What the methodology DOES guarantee is INTEGRITY OF PROCESS. The reader can be confident that:

─ Inputs were not adjusted to fit results. ─ Definitions were stable across the derivation chain. ─ Thresholds were not relaxed for borderline cases. ─ Failures were not hidden. ─ Outputs are reproducible from the published locks and code.

This separates “the framework might be wrong” from “the framework’s evidence might be fabricated.” The first remains an open scientific question. The second is structurally precluded.

For a non-mainstream framework that cannot rely on traditional peer review, this kind of methodological transparency is one of the few credible ways to establish scientific seriousness. The framework chooses to invest in it heavily — every chapter ends with explicit LOCK/Gate notes — at the cost of being more verbose than typical physics papers. The verbosity is a feature, not a bug.

8. What’s Next

Part 17: Bridging to Standard Quantum Mechanics

The next article connects this framework’s lattice picture back to the language of standard quantum mechanics. The proton is a 82+7 discrete object here; in QM it is described by a wavefunction. The two pictures look incommensurable, but they are not — and Part 17 walks through how the framework’s structural quantities map onto QM’s operators, observables, and matrix elements. This is the bridge that makes the framework’s results readable to a reader trained in standard physics.

═══════════════════════════════════════════════

Reference (full paper, code, data): https://doi.org/10.5281/zenodo.17932567 https://jamming-physics.org

Series index (all 18 parts): see Part 1.

Physics #VPTheory #LatticeJamming #MathematicalPhysics

ScientificMethodology #Reproducibility #NoTuning #PreRegistration