Prologue (how to use this document)

Prologue (how to use this document): A LOCK is never edited — it is only ever reborn as a new version. Every sentence carries a qualification, and hypotheses cannot be promoted after the fact. The key rectification constants are α=2/π and δ=1/π². Grade [H] hypothesis.

A LOCK is never edited — it is only ever reborn as a new version. Every sentence carries a qualification, and hypotheses cannot be promoted after the fact. The key rectification constants are α=2/π and δ=1/π².

Purpose of the chapter

This chapter declares the writing conventions for the entire treatise. The declaration covers: (i) the purpose of the chapter, (ii) the artifacts that the chapter and the document must output, (iii) the definition of internal traversal routes, and (iv) the one-way flow LOCK → derive → Gate that every claim must follow.

The exposition binds a single backbone (volume particle, infinite rigidity, full packing, jamming, throats, event rate, unit realization, cross-validation) into one skeleton. This skeleton keeps the same form throughout the document: it does not redefine the same items in other sections, nor does it repeat the same derivation to inflate “support.”

This chapter does not repeat the rules in narrative form. Items declared here will only be referenced later; the same content will not be re-expanded in prose.

Outputs

The outputs of this treatise are fixed as the following four bundles.

1. Canonical (LOCK) bundle: axioms, definitions, symbol/unit conventions, operational anchors (reference points for unit realization), pre-registered thresholds and verdict rules, and the dependency (ordering) structure among them.
2. Derived bundle: propositions, theorems, numerical results, scaling relations, ratio invariants, and dependency trace tables, obtained from the LOCK by allowed transformations only.
3. Verification (Gate) bundle: the set of verdict conditions (PASS/FAIL/INCONCLUSIVE) used to evaluate derived results, cross-validation channels, sensitivity/robustness checks, failure-mode definitions, and verdict logs.
4. Reproducibility (artifact) bundle: code, input files, environment information, seeds, logs, data, outputs (figures/tables/numerical summaries), hashes/checksums, manifests, release tags, and change logs.

Artifacts are cross-referenced inside the document; no single artifact qualifies a conclusion by itself. Numerical results must always carry both a LOCK provenance and a Gate verdict.

Definition of traversal routes

This treatise provides internal traversal routes that reorder the same body text for different purposes. A route is not advice about who should read what; it is a formal classification of possible paths along the document's dependency graph.

• Route A (definitions→derivations→verification): fix axioms/definitions/symbol conventions, then derive the key numbers and scaling relations, and attach verdicts via the corresponding Gates.
• Route B (unit realization→cross-validation→reproduction): fix operational anchors and realization procedures first, decide self-consistency via cross-channels (e.g., RCROSS), then seal conclusions with reproducibility-package logs and manifests.
• Route C (numbers→provenance back-trace): start from a specific number (length/time/mass/force, etc.) or invariant, trace backward along the derivation chain up to the LOCK items and Gate verdicts, and verify acyclicity and lock status.

The three routes share the same body; no route adds extra assumptions. Routes differ only in order and emphasis.

0.4 Declaration of the LOCK → derive → Gate flow

All conclusions in this treatise are generated only through the one-way flow LOCK → derive → Gate. Each stage is fixed to the following role.

(1) LOCK

LOCK is the set of items that, once fixed, are not modified or “corrected” later within the same document. LOCK includes axioms/definitions/conventions/operational anchors/thresholds/verdict rules, and records the dependency ordering among LOCK items. Changing a LOCK is not an “edit”; it exists only as a new version. Existing conclusions remain bound to their original LOCK version.

(2) Derivation

A derivation starts only from LOCK items and applies the permitted transformation rules and explicit closure rules to produce a predictable form. A derivation terminates in one or more of: (i) numerical values, (ii) scaling relations, (iii) ratio invariants, or (iv) verifiable decision expressions. Replacing definitions, reinterpreting units, or shifting reference points during a derivation is not allowed; if needed, such changes must be handled only by LOCK versioning.

(3) Gate

A Gate is a verdict device that assigns admissibility to a derived result. Gates include pre-registered thresholds, cross-validation channels, sensitivity checks, and failure-mode conditions. Gate outputs are restricted to PASS/FAIL/INCONCLUSIVE, where INCONCLUSIVE means deferral of a conclusion. Results with FAIL or INCONCLUSIVE verdicts are not used as evidence in later sections; to enable their use, a LOCK change or an additional pre-registered Gate is required.

(4) Form of conclusion sentences

In this treatise, every sentence that states a number or law must carry three elements: (i) identifiers of the LOCK items providing provenance, (ii) an identifier summarizing the derivation chain, and (iii) identifiers of the passed Gates (or verdict status). Statements without these three elements are treated as unclassified text, not conclusions, and are not promoted as evidence in later sections.

0.1 Claim Levels

0.1.1 Definition of claim levels

In this document, a “claim” means the qualification under which a sentence or an equation block is stated. The qualification is fixed to the following three classes.

1. [F] Fact: Includes definitions, axioms, symbol/unit conventions, LOCK-frozen inputs, and results that have been reproduced after passing the required Gates. In this white paper, [F] is used only as an internal baseline; retroactively promoting [H] to [F] is not allowed.
2. [H] Hypothesis: Includes closures, idealizations, approximations, model choices, and choices of computational procedures. An [H] must include all three of (i) the list of assumptions, (ii) the resulting prediction (in an observable form), and (iii) the scope of validity (regime condition). An [H] lacking these three elements is not recognized as a claim.
3. [V] Verification: A record of how an [H] prediction was tested. A [V] must include (i) method, (ii) results (numbers/figures/tables), (iii) reproducibility information (inputs/seed/environment/error), and (iv) a verdict (PASS/FAIL/INCONCLUSIVE). An [H] without [V] is not promoted to evidence.

These three are a classification of sentence qualification and are applied uniformly regardless of the magnitude of the statement. A section may contain a mixture of [F]/[H]/[V], but only as separated labels; mixing (reinterpretation of definitions, shifting baselines, post-hoc correction) is forbidden.

0.1.2 What this document claims (claim list)

This document takes responsibility for the following claims. Each item is decomposed in the main text into [F]/[H]/[V] components; conclusions are not stated without their decomposition.

(C1) Fundamental constituents of space and a rigidity axiom

The basic unit of space is the volume-particle (VP), and the VP has the property of an internally incompressible “Stone.” This property is declared as infinite rigidity (incompressibility) and is used as the starting point of all rigidity/propagation/threshold logic.

(C2) Full packing and the existence of a jamming regime

VPs form a lattice/packing structure that fully fills space. The structure is separated into a jamming regime (a rigidity network spans the domain) and a non-jamming regime (no rigidity spanning). The boundary of “propagable/non-propagable” is defined as a jamming-regime verdict and is implemented as a Gate.

(C3) Fixation of geometric rectification constants

This document claims that rectification constants are determined under a specific geometric averaging/projection convention. The key rectification constants are α=2/π and δ=1/π². They are derived at a single location, then locked (LOCK), and later sections only reference them (no re-derivation). These constants recur in event-rate rules and in chained derivations of length–time–mass/force scales.

(C4) A canonical length scale (anchor) and determinism of derived geometry

This document places an “anchor length” D_anch as a canonical (CANON) LOCK input. Once the anchor is fixed, derived geometric quantities such as r₀=D_anch/2 are claimed to be determined deterministically. In addition, the “proton radius” rₚ=rproton is treated as a separate CANON LOCK input, and in combination with the anchor it becomes a key branching point for event-rate and mass derivations.

(C5) A separately locked rotation-drive length scale

For rotation-driven jamming experiments, this document defines a rotation-drive length unit ℓ_rot and records its value as a LOCK item. ℓ_rot must be locked “by definition”; changing it after observing results is judged as tuning and is forbidden. It is used as a standard experimental input for anisotropy, spin indices, and throat-distribution changes.

(C6) Operational definition of quantum events and canonical event rates

This document operationally defines an “event” in a form that is observable/loggable, and claims that event rates can be described by canonical rules combined with rectification constants. For the electron and proton, canonical event rates are presented as separate definition–derivation chains. A chain acquires conclusion status only through the coupling of (i) LOCK inputs, (ii) derivation rules, and (iii) Gate verdicts.

(C7) Fixing the VP length a and the time tick Δ t via realization

This document claims a procedure to realize length/time defined in a dimensionless (simulation) world into SI units. The outputs of this procedure are

and both values are recorded in the REALIZATION LOCK. The procedure also includes the condition that cross-validation collapses immediately unless the diameter/radius meaning and the cell geometry (e.g., cube) are locked together.

(C8) Definition of the lattice unit energy Uₗat and derivation of mass scales

After a is fixed, this document defines the unit energy directly exposed by one lattice cell (length a), U_lat, and derives mass scales from it. Mass is described in the form of a “geometric resistance” (effective cross-section / effective-length integrals). The document includes the numerical results that the proton mass mₚ and electron mass mₑ are obtained as

with the requirement that LOCK provenance, derivation chain, and Gate verdicts accompany the results.

(C9) Internal derivation (absolute scale) of the charge-interaction force scale

This document claims that the absolute scale of a “charge-interaction force” can be derived internally from lattice units (length, time, energy) and a geometric attenuation convention. Agreement with external numbers is not treated as justification but only as a Gate verdict item; if the verdict fails, no conclusion status is granted.

(C10) Conditional extensions (anisotropy, SOC, jets/tubes, throughput ceiling)

This document includes conditional extensions such as anisotropy (rotation drive), throat networks, SOC amplification, stream-tube/jet-like concentration, and throughput-based upper bounds. Here “jet” is not a borrowing of the fluid-mechanics term; it means a pattern in which event flux concentrates along specific directions of a backbone/throat network (17.2). Atmospheric/oceanic jets or astrophysical jets are mentioned only as examples of possible correspondences; no external theory, numbers, or equations are used as evidence. All extensions are conditional claims ([H]) with declared regimes and closures, and they acquire independent conclusion status only within the range where the designated Gates pass.

0.1.3 What this document does not claim (non-claim list)

The following items are fixed as explicit non-claims for which this document does not take direct responsibility.

1. Unverifiable proclamations: Ultimate-reality proclamations, value judgments, or metaphysical conclusions that cannot be decided by observation/logging/reproduction are not stated as [F].
2. Complete reconstruction of external systems: This document does not re-prove external theory frameworks end-to-end, nor does it import them as justification. External texts are mentioned only in a limited manner, e.g., as a correspondence table or a “non-use” declaration.
3. Universalization across all regimes: Results that depend on initial/boundary conditions, dimension, protocol, or seed are not stated as universal laws.
4. Justification of post-hoc correction: Changing definitions, baselines, locked values, meanings (diameter/radius), or verdict thresholds after seeing results is not justified. If a change is necessary, it exists only as a LOCK version-up.
5. “Agreement implies truth” leaps: Agreement with external numbers is not used to declare axioms/definitions “true.” Agreement is recorded only as a Gate PASS condition or as an error-budget report.

0.1.4 Scope and non-scope (regime declaration)

The scope of this document is specified as a set of defined regimes. A regime is designated by a combination of the following elements, and each PART states its own regime on its first page.

1. Dimension: the space dimension in which calculations/simulations/graph definitions are carried out (2D/3D, etc.), and explicit separation of how dimensionality affects conclusions.
2. Boundary conditions: closed/open system, driven/undriven, fixed/free boundaries, and a declaration of which quantities are conserved or not under the chosen boundary.
3. Initial conditions: declaration and log fixation of initial settings (near/above/below jamming, defect distribution, occupancy, spin distribution, etc.).
4. Scale window: declaration of the applicable scale window (long/short wavelength, quasi-static/dynamic, linear/nonlinear, etc.).
5. Protocol: procedural choices such as rotation drive (e.g., ℓ_rot input), percolation/throat definitions, sampling/averaging methods.

The non-scope range is fixed as “regime elements are undefined, or they are defined but judged as FAIL or INCONCLUSIVE by Gate.” In addition, if the diameter/radius meaning is not locked so that the same number can be interpreted as different geometries, the result is automatically classified as out-of-scope (no conclusion status).

0.1.5 Examples of prohibited interpretive sentences (short)

The following types of sentences do not have conclusion status and are not allowed even as [H] (reasons: non-verifiability, over-generalization, post-hoc justification, missing regime declaration).

1. “Because this number matches, the entire axiom system is true.”
2. “Because it appeared once under one setting, it holds under all conditions.”
3. “Even if we change the definition (diameter/radius), the conclusion will be the same.”
4. “The Gate says FAIL, but the interpretation is correct.”
5. “It must hold intuitively even without verification.”

0.2 Reader guide: required route vs optional route

0.2.1 Definition of a route

A route is an ordering convention that preserves the direction of internal dependencies (LOCK items → derivation chain → Gate verdict). Routes are fixed to two types.

• Required route (core derivations): consists of the minimal chain of canonical definitions/geometry/events/unit-realization/mass–force outputs that is repeatedly used throughout the document. Outputs of the required route are never modified in later extension sections; an extension can only add on top of required-route outputs.
• Optional route (extensions): includes additional regimes and additional closures such as anisotropy (rotation drive), SOC amplification, stream-tubes/jets, throughput ceilings, and scale-up (macroscopic application). Optional-route results do not strengthen or weaken the conclusion status of required-route results; they exist as independent conclusions only within the range where their own Gates pass.

0.2.2 Composition of the required route (core derivations)

The required route is composed of the following step bundle. Each step requires internal completion of “LOCK fixation → derivation → Gate verdict.”

1. Canonical convention step: lock symbol/unit conventions, diameter–radius meaning, canonical inputs (anchor length, reference radius, etc.), and the non-overloading rule.
2. Axiom step: lock infinite rigidity (Stone), full packing, and the existence of a jamming regime.
3. Rectification-constant step: unify the derivation location of geometric rectification constants (e.g., α=2/π, δ=1/π²) and lock them.
4. Core-geometry step: combine canonical lengths and canonical radii to derive core geometry (radius ratios, area ratios, invariant ratios) and judge by Gate.
5. Discrete-structure step: define core/shell structures (e.g., core integer structure, shell cancellation structure) and judge required structural invariants (sum/symmetry/cancellation rules) by Gate.
6. Event step: give an operational definition of an event (quantum event), derive canonical event rates for electron/proton, and judge by Gate.
7. Unit-realization step: realize and lock the length scale a and time tick Δ t (operational anchors) with cross-consistency, and judge by Gate.
8. Mass/force step: from unit energy and geometric resistance (effective cross-section / effective-length integrals), compute mass scales (electron/proton/other mass scales) and force scales, and judge by Gate.

0.2.3 Gate types that the required route must pass (declaration)

The required route has PASS of the following Gate types as an admissibility condition. Gate thresholds/decision expressions/log formats are locked in the corresponding sections.

1. G-SYM (symbol/unit consistency Gate): decides symbol meanings (including diameter/radius), unit dimensions, and absence of definition collisions.
2. G-LOCK (lock integrity Gate): decides that referenced LOCK items are fixed under the same version and show no post-hoc changes.
3. G-REG (regime compatibility Gate): decides valid ranges of jamming/non-jamming, linear/nonlinear, long/short wavelength, boundary/initial conditions.
4. G-RECT (rectification constant Gate): decides uniqueness of the definition/derivation location of rectification constants and internal consistency (including prohibition of re-derivation/re-definition).
5. G-STR (structural invariant Gate): decides preservation of required invariants of discrete structure (sum/symmetry/cancellation rules).
6. G-RCROSS (cross-consistency Gate): decides mutual consistency across two or more independent channels in unit realization.
7. G-REP (reproducibility Gate): decides reproduction under the same conventions (code/inputs/environment/seed/logs/outputs).

0.2.4 Composition of the optional route (extensions)

The optional route adds the following extension bundles on top of required-route outputs. Each extension bundle has its own LOCK and its own Gate.

1. Anisotropy extension: locks rotation-drive input (e.g., ℓ_rot) and derives direction-dependence of orientation distribution/fabric/throats.
2. SOC amplification extension: locks event-cluster (avalanche) definitions and amplification coefficients, and derives distributions/scale invariance/pinning conditions.
3. Stream-tube/jet extension: derives stability of flux-concentration paths, alternative paths, and bottleneck cascades in throat networks.
4. Throughput ceiling extension: locks throughput definitions at the unit-cell level and derives scaling of the ceiling.
5. Scale-up (macroscopic application) extension: locks μ–m–M scale-conversion conventions and regimes, and derives macroscopic proxies.

0.2.5 Gate types that the optional route must pass (declaration)

The optional route presupposes PASS of all required-route Gates, and additionally requires PASS of the following Gate types.

1. G-ANISO (anisotropy Gate): decides lock integrity of rotation-drive input, statistical stability of direction distributions, and per-direction reproducibility.
2. G-SOC (SOC Gate): decides fixation of event definitions, existence of scale windows, and robustness of distribution diagnostics.
3. G-PATH (path/bottleneck Gate): decides minimum-cut/alternative-path sensitivity, bottleneck-cascade stability, and invariance under throat-definition changes.
4. G-CAP (capacity/throughput Gate): decides uniqueness of throughput definition, acyclicity of the ceiling derivation, and regime compatibility of the scaling.
5. G-UP (scale-up Gate): decides lock integrity of scale-conversion conventions, meaning of proxies (including non-use ranges), and failure conditions of extrapolation.

0.2.6 Concept mesh (hub map) and mandatory pre-reads (added v0.5.0)

The body's sections are non-monotonic by design (Forced / Mechanism / Calibrated / Open / Methods). The mesh below states, for each concept, where to start, where the load-bearing derivation lives, where the numerical verification lives, and where the honest limits are recorded.

0.3 Pipeline: “Input(LOCK)→derive→verify(Gate)” + file/registry overview

0.3.1 ASCII

All conclusions in this treatise follow the following one-way pipeline. The pipeline proceeds only in the order Input (LOCK) → Derive (derived) → Verify (Gate) → Seal (snapshot).

+----------------------------------------------------------------------+
|  (A) Input (LOCK)                                                     |
|      - canon_lock : axioms/definitions/symbols/units/canonical numbers |
|      - realization_lock : length/time/energy fixed by unit realization |
|      - gate_lock : Gate definitions/thresholds/decision forms/cross-ch.|
|      - protocol_lock : code/input/seed/environment/log schema          |
+---------------+------------------------------------------------------+
                | (LOCK is read only from a single source: SSOT)
                v
+----------------------------------------------------------------------+
|  (B) Derive (derived)                                                 |
|      - derived_claims : propositions/theorems/numbers/ratio invariants |
|      - derived_tables : tables (including intermediate calculations)   |
|      - derived_figures : figures (scripts + parameters included)       |
|      - dependency_dag : LOCK->derived dependency graph                  |
+---------------+------------------------------------------------------+
                | (Derivation uses only LOCK items + permitted transforms)
                v
+----------------------------------------------------------------------+
|  (C) Verify (Gate)                                                    |
|      - gate_stack : stack of Gates (ordering included)                 |
|      - gate_inputs : inputs/data/logs used for verification            |
|      - gate_outputs : PASS/FAIL/INCONCLUSIVE + evidence metrics        |
|      - cross_checks : cross-channel consistency (RCROSS, etc.)          |
+---------------+------------------------------------------------------+
                | (Only PASS results acquire conclusion admissibility)
                v
+----------------------------------------------------------------------+
|  (D) Seal (registry_snapshot)                                         |
|      - registry_snapshot : frozen copy of registries used in release   |
|      - manifest : file list/roles/version/hash references              |
|      - checksums : per-file hashes (sha256, etc.)                      |
|      - release_tag : release identifier (version/date/change summary)  |
+----------------------------------------------------------------------+

0.3.2 SSOT

The registry is the file set that physically implements “where a definition is fixed” across the entire document. The registry is the single source of truth (SSOT): derivation code and verification code are allowed only to read it, never to modify it. Re-defining the same item outside the registry is forbidden.

The registry is composed of the following four types.

1. canon_lock: axioms/definitions/symbols/units, canonical numeric inputs, diameter/radius meaning, and object definitions (cell/core/shell, etc.).
2. realization_lock: length/time/energy/mass scales fixed by operational anchors (unit realization) and their derived quantities.
3. gate_lock: Gate types, decision expressions, thresholds, tolerances, cross-channel layouts, and PASS/FAIL/INCONCLUSIVE output conventions.
4. protocol_lock: execution environment, seed policy, input-file formats, log schemas, figure/table generation conventions, and naming rules.

0.3.3 Artifact package tree (overview)

The reproducibility package has the following top-level tree. The role of each directory is fixed, and creating duplicate files of the same role in a different location is forbidden.

bundle_root/
  registry/
    canon_lock.(yaml|json|toml)
    realization_lock.(yaml|json|toml)
    gate_lock.(yaml|json|toml)
    protocol_lock.(yaml|json|toml)
    symbols_table.(csv|tex)
    units_table.(csv|tex)
  derived/
    claims.(tex|json)
    tables/
      *.csv
      *.tex
    figures/
      *.pdf
    dag/
      dependency_dag.(json|dot|pdf)
  gate/
    gate_stack.(yaml|json)
    reports/
      gate_report_*.json
      gate_report_*.tex
    logs/
      *.log
      *.csv
  scripts/
    build_derived.(py|sh)
    run_gates.(py|sh)
    make_figures.(py|sh)
    utils/
  data/
    raw/
    processed/
  snapshot/
    registry_snapshot/
      (complete frozen copy of registry/)
    manifest.(json|yaml|csv)
    checksums.(txt|json)
    release_tag.(txt|json)

In this tree, snapshot/registry_snapshot/ is the frozen copy of the registry used in the release, preserving provenance of past conclusions even if registries are later versioned.

0.3.4 Overview of the manifest (file-list specification)

The manifest is the document that fixes, as a list, “all files included in the package.” The manifest has the following fields (the format is fixed to one of JSON/YAML/CSV; field names are kept identical).

1. path: relative path from the bundle root.
2. role: functional category of the file, e.g., registry, derived, gate_report, script, data_raw, data_processed, figure, table.
3. content_type: text/tex, application/pdf, text/csv, etc.
4. producer: producer identifier, e.g., manual, script:make_figures, script:run_gates.
5. depends_on: list of dependency input paths (empty list if none).
6. lock_version: registry-version identifiers referenced by the file (e.g., canon_lock_id, realization_lock_id).
7. hash_ref: key referencing an entry in checksums (e.g., a sha256 value or checksum index).
8. bytes: file size in bytes.

The manifest fixes “what is included” and serves as a reference point to immediately detect omission/duplication/substitution.

0.3.5 Overview of checksums (content-identity specification)

Checksums are the hash list used to verify the content identity of all files in the bundle. The checksum rules are fixed as follows.

1. Algorithm fixed: the default algorithm is sha256. Additional algorithms may be listed, but sha256 must be present.
2. Target fixed: all files under bundle_root/ are included. If exclusions are necessary, an exclusion-list file (checksum_exclusions) is created and itself included in checksums.
3. Notation fixed: either “HASHPATH” per line or a JSON key-value format.
4. Linking fixed: each file references a checksum entry through the manifest field hash_ref; i.e., the manifest and checksums cross-reference each other.

Checksums decide not “same file name” but “same content,” sealing integrity of Gate reports and derived results.

0.3.6 Overview of registryₛnapshot (frozen evidence)

The registry_snapshot is the directory that preserves, as-is, the registries referenced by a specific release. It serves the following purposes.

1. Reproducibility: even if registries are updated later, the evidence of past conclusions (axioms/definitions/thresholds/operational anchors) can be restored identically.
2. Dependency fixation: which LOCK version a derived result depended on is physically fixed (in combination with the lock_version fields).
3. Branch management: versioning occurs only by creating new registries (never by editing old ones), preventing mixing of old-version and new-version conclusions.

The registry_snapshot resides under snapshot/registry_snapshot/ and is sealed by inclusion in the snapshot manifest and checksums.

0.3.7 Minimal schema (common fields for registry files)

Even if registry file formats differ, they share the following common fields.

1. lock_id: unique identifier of the registry.
2. created: creation time (string).
3. scope: regime/protocol identifier to which the registry applies (default global).
4. items: list of locked items (each includes name, unit, value or definition, description, and source path).
5. invariants: invariant conditions enforced by the registry (e.g., diameter/radius meaning, unit dimensions, non-overloading rules).
6. change_log: change history (appended only on version-up).

The common fields make “what the file locks” machine-readable and fix the input interface of derivation/verification scripts.

Foundations — Notation, Axioms, and the Closure System

These three sections define the lattice, the vocabulary, and the 1:1 semantic mapping used everywhere below; read them once, then consult as needed.

0.5 Common misreadings and why they fail (read before the body; front-loaded from Part II in v0.5.0)

This section anticipates the misreadings most likely to appear in a first-pass review and explains why each one fails.

Misreading 1: "They fit π-powers to data"

Misreading 2: "82, 89 are arbitrary lattice counts"

Misreading 3: "Single anchor is just hidden parameter count"

Misreading 4: "The framework predicts gravity from GM/R²"

Misreading 5: "The simulation bundle is just calibration"

Misreading 6: "Annihilation-driven inflow is hand-waving"

Misreading 7: "If the framework is right, why has nobody else found this?"