Governance: No-Tuning / LOCK / Gate

Governance: No-Tuning / LOCK / Gate: FAIL and INCONCLUSIVE are contagious: nothing downstream may cite them. Three rules, one machine: how things change, what may enter, what may conclude. The 89/82 legitimately tracks mₙ>mₚ (gravity), not Coulomb. Grade [F] forced.

FAIL and INCONCLUSIVE are contagious: nothing downstream may cite them. Three rules, one machine: how things change, what may enter, what may conclude. The 89/82 legitimately tracks mₙ>mₚ (gravity), not Coulomb.

Declaration of global top-level rules

All definitions, all derivations, all numerical results, all comparisons, and all extensions in this document obey three global top-level rules: No-Tuning, LOCK, and Gate. A global top-level rule means that no section in the document is allowed to treat these rules as exceptions or ignore them partially. These rules are the minimal conditions for structural consistency and conclusion admissibility. A violation of any of the three rules is treated as an event that immediately revokes admissibility of the result produced in the violating sentence (or section).

Declaration of No-Tuning (ban on post-hoc adjustment)

No-Tuning is the global rule forbidding “changing inputs after seeing the result so that the conclusion matches a desired target.” No-Tuning forbids the following four categories.

1. Post-hoc change of definitions: changing symbol meanings (e.g., diameter/radius), object definitions (e.g., cell/core/shell), unit interpretations, or inclusion/exclusion boundaries after seeing results.
2. Post-hoc change of input values: changing canonical inputs, operational anchors, constants, thresholds, tolerances, or protocol parameters after seeing results.
3. Selection bias: presenting only runs/settings/data that strengthen the conclusion. If selection is necessary, the selection rule itself must be pre-registered and locked as a LOCK item.
4. Post-hoc change of verdict rules: changing Gate decision expressions, thresholds, cross-channel layout, or PASS/FAIL conditions after seeing results.

No-Tuning is not “no change ever” but “no post-hoc change inside the same version.” Any change is allowed only as a new version. If a change occurs, all artifacts produced after the change belong to a new LOCK identifier, while conclusions produced before the change remain assigned to the previous LOCK identifier. This structurally blocks retroactive reinterpretation of evidence for past conclusions.

Declaration of LOCK (canonical freezing and single source)

LOCK is the set of items that do not change within the same version once fixed. LOCK is the canonical baseline referenced by all derivations and all verifications, and it obeys the following principles.

1. Single source of truth (SSOT): LOCK items are defined only at a specific location (or registry entry) inside the document. Re-defining the same item in another section is forbidden.
2. Identifier-based attribution: every derived result and every Gate verdict must carry the identifiers of the referenced LOCK items. A conclusion is attributed not to “content” alone but to “content + LOCK identifiers.”
3. Version-up only: changing a LOCK item occurs only by creating a new LOCK, not by editing an existing one. New LOCK items have new identifiers and do not change evidence of existing conclusions.
4. Category separation: LOCK is stored in separated categories according to its role; items of different roles are not locked together.

At minimum, this document separates LOCK into the following four categories.

• canon_lock: axioms/definitions/symbols/units conventions and canonical numeric inputs.
• realization_lock: length/time/energy fixed by operational anchors (unit realization) and derived values.
• gate_lock: Gate types, decision expressions, thresholds, tolerances, cross-channel layouts, and output conventions.
• protocol_lock: execution environment, seed policy, input formats, log schemas, and artifact-generation conventions.

The purpose of LOCK is not only “to freeze values,” but to fix exactly one place where each definition lives across the whole document. A derivation without LOCK loses provenance, and a verification without LOCK loses decision legitimacy.

1.4 Declaration of Gate (admissibility verdict)

A Gate is the verdict device that grants or revokes conclusion admissibility of a derived result. Gates obey the following rules.

1. Output format fixed: the Gate output is expressed only as one of PASS, FAIL, or INCONCLUSIVE.
2. Pre-registration: the decision expression, thresholds, tolerances, cross-channel layout, and log format must be fixed in gate_lock before results are produced.
3. Verdict precedence: results with FAIL or INCONCLUSIVE do not have conclusion admissibility and cannot be used as premises later.
4. Stack allowed: a conclusion may need to pass a stack of multiple Gates; the stack order and composition must be pre-registered.
5. Logs required: a Gate verdict must record logs of inputs, computation, intermediate metrics, and outputs; logs must follow the format fixed by protocol_lock.

Gate does not perform justification “because it matches.” Gate decides only whether pre-registered conditions are satisfied. Conclusion admissibility is granted only by PASS; interpretation content is constrained by LOCK and the derivation scope.

1.5 Coupled structure of the three rules (global precedence)

No-Tuning, LOCK, and Gate are not independent; they form a coupled structure.

1. No-Tuning governs how LOCK and Gate are created and changed. It forbids changing LOCK or Gate after seeing results.
2. LOCK governs the canonicity of inputs to derivations and Gates. LOCK does not change within the same version, and every derivation and Gate references LOCK.
3. Gate governs conclusion admissibility of derived results. PASS is necessary for admissibility; FAIL/INCONCLUSIVE forbid use as evidence.

Therefore, the following hold globally.

• A derived result without fixed LOCK does not have conclusion admissibility.
• A verdict without pre-registered Gates cannot grant conclusion admissibility.
• Post-hoc changes of definitions/inputs/thresholds/protocol are No-Tuning violations, and the results immediately lose conclusion admissibility.

1.1 No-Tuning rules and prohibited actions

1.1.1 Definition of No-Tuning

No-Tuning is the global rule forbidding “after seeing outputs, retroactively adjusting inputs/definitions/procedures/verdict criteria so that the outputs become the desired shape.” Here “outputs” include numerical values, tables, figures, logs, statistics, derived theorems, or Gate PASS/FAIL verdicts. The scope of No-Tuning is fixed to the following four layers.

1. Definition layer: symbol meanings (e.g., diameter/radius), object definitions (cell/core/shell), unit meanings, inclusion/exclusion criteria, averaging/projection conventions.
2. Input layer (LOCK): canonical numeric inputs, operational anchors (unit realization), critical thresholds, tolerances, protocol parameters, seed policy.
3. Derivation layer: closure choices, algorithm choices, boundary/initial condition choices, selection of calculation paths (intermediate steps).
4. Verdict layer (Gate): decision expressions, thresholds, cross-channel layout, PASS/FAIL rules, log schema.

No-Tuning does not forbid change itself; it forbids post-hoc change within the same version (same LOCK identifier set). If a change is necessary, it is allowed only as a version-up (new LOCK identifiers).

1.1.2 List of forbidden actions

Forbidden actions judged as No-Tuning violations are categorized as follows. If any category applies, the artifact immediately loses conclusion admissibility.

(A) Definition tuning

1. After seeing a result, changing the meaning of diameter/radius or cell geometry (cube/sphere, etc.) so that the same number is reinterpreted as a different geometric quantity.
2. After seeing a result, using the same symbol (e.g., δ, Φ) with different meanings in different sections, or swapping meanings so that the derivation chain is effectively altered.
3. After seeing a result, changing inclusion/exclusion criteria (e.g., which paths are counted as throats, which contacts are counted as effective contacts) so that numbers move toward a desired target.
4. After seeing a result, changing averaging/projection/rectification conventions (angular averaging, amplitude squared, axis choice, etc.) so that rectification constants or event rates change.

(B) Value tuning

1. After seeing a result, changing canonical inputs (anchor length, reference radius, rectification constants, etc.) to match a target number.
2. After seeing a result, changing operational anchors (reference baselines/values fixed in unit realization) or reinterpreting the same anchor so that length/time/energy scales change.
3. After seeing a result, changing critical thresholds or tolerances (e.g., shifting a threshold to turn FAIL into PASS).
4. After seeing a result, changing the seed or sample count, repeatedly re-running “until PASS appears,” and keeping only the favorable run.

(C) Closure/model tuning

1. After seeing a result, swapping closures or changing internal closure choices (e.g., representative path selections) so that numbers move closer to a target.
2. After seeing a result, changing boundary/initial conditions so that conclusions change, yet describing it as “verification of the same conclusion.”
3. After seeing a result, swapping algorithms (e.g., throat estimation, graph construction, relaxation rules) without declaring a LOCK version-up.

(D) Gate tuning

1. After seeing a result, changing Gate decision expressions, thresholds, cross-channel layouts, or PASS/FAIL rules.
2. Relaxing Gates when a result is FAIL, and strengthening Gates when a result is PASS, so that conclusions are kept only in a desired direction.
3. Swapping metrics used in Gate decisions or changing metric definitions while still describing it as the same Gate without a gate_lock version-up.

(E) Selection/reporting tuning

1. Selecting and presenting only cases where PASS occurred among multiple data/runs/samples, omitting FAIL or INCONCLUSIVE.
2. Choosing a “representative” run or removing “outliers” after seeing results without a pre-registered selection rule.
3. Removing negative results obtained under the same conditions from reports/logs by labeling them “unnecessary.”

(F) Protocol/code tuning

1. After seeing a result, modifying code (algorithms/constants/definitions) without updating the identifiers that bind the modification to a LOCK version.
2. Changing the execution environment (library versions, compile options, RNG implementation, etc.) without recording it in protocol_lock.
3. Changing log formats or recorded fields so that unfavorable metrics are not recorded.

(G) External-justification tuning

1. Using external standard frameworks/numbers as justification and retroactively adjusting internal definitions/inputs/closures to force agreement.
2. Adopting justification sentences as conclusions, such as “because it agrees, the internal axiom is justified” (agreement is recorded only as a Gate item).

1.1.3 Format of allowed changes (exceptions): version-up only

There is no rule that treats No-Tuning as an exception inside the same version. Allowed changes exist only in the form of a version-up. A version-up holds only when all of the following conditions are satisfied.

1. Issue a new LOCK identifier: create a new lock_id for the registry (canon_lock/realization_lock/gate_lock/protocol_lock) that contains the changed item.
2. Fix a change log: record the reason for change (what changed and why), the before/after items, and affected derivation/verification items as change_log.
3. Full re-derivation and re-verification: conclusions after the change must be regenerated from scratch under the new registry version and re-judged by the full required Gate stack.
4. Preserve past conclusions: artifacts produced before the change remain assigned to the old lock_id and are not retroactively edited.
5. Seal snapshots: seal registry_snapshot/manifest/checksums as a new release so that evidence of post-change results is physically frozen.

Therefore, “allowed exceptions” are not exceptions inside the same version, but only procedures for creating a new version.

1.1.4 Violation verdict and FAIL labels

A No-Tuning violation is recorded in the Gate system as a FAIL label. FAIL labels decompose the violation type, and multiple labels may be attached to one artifact. The label system is fixed as follows.

1.1.5 Handling rules when a violation occurs (propagation of FAIL labels)

When a No-Tuning violation is confirmed, handling rules are fixed as follows.

1. Quarantine: failed artifacts and their dependent derivatives are removed from the “candidate conclusion” list and quarantined as FAIL (state change; not deletion).
2. Generate a FAIL report: create a fail_report that includes violation type (FAIL labels), relevant registry identifiers, relevant artifact paths, timestamp, and evidence of mismatch.
3. Forbid evidence use: FAIL artifacts cannot be used as premises/evidence later; sentences premised on FAIL artifacts cannot be promoted as conclusion sentences.
4. Constrained recovery paths: to restore admissibility, one must either (i) fully revert to the pre-violation state, or (ii) promote the change as a version-up and perform full re-derivation and re-verification under a new lock_id. Partial modifications inside the same version are not recognized as recovery.
5. Maintain sealing consistency: the FAIL state and recovery attempts must appear as a continuous release record in manifest/checksums/registry_snapshot. Deleting or tampering with FAIL records is treated as an additional violation (FAIL-NT-LOG and FAIL-NT-RETRO).

1.2 Three LOCK types and SSOT

1.2.1 Definition of LOCK and SSOT

LOCK is the convention that fixes baseline items once so that they do not change within the same version. Its purpose is (i) to fix exactly one location of evidence, (ii) to make dependencies traceable, and (iii) to structurally block post-hoc adjustments (No-Tuning). SSOT (Single Source of Truth) means “the definition and value of the same item exist at exactly one location (one registry entry) across the whole document.” If SSOT holds, each section only references registry items instead of redefining them. If SSOT breaks, the same term is used with different meanings, or the same value is interpreted under different definitions, and derivation and verification cannot simultaneously hold.

LOCK is separated into three types by role.

1. canon_lock: locks axioms/definitions/symbols/units/canonical inputs.
2. realization_lock: locks physical scales and derived quantities fixed by unit realization (operational anchors).
3. analysis_lock: locks analysis procedures used in derivation and verification (closures, estimators, algorithms, verdict composition, log schemas).

The three LOCKs have different roles and must not be mixed. For example, adjusting canonical definitions via unit realization, or treating an analysis procedure as if it were a canonical definition, is treated as a violation of the LOCK structure.

1.2.2 Definition of canon_lock (canonical freezing)

The canon_lock fixes items constituting the canonical baseline of the document. It contains only “fundamental units/meanings” and “baselines that must not move in later derivations.” canon_lock includes:

1. Axioms: properties of VP, infinite rigidity (Stone), full packing, jamming-regime separation, etc.
2. Definitions: objects (cell/core/shell/throat/path), operational definitions of event and event rate, diameter/radius meanings, and the non-overloading rule.
3. Symbols/Units: unit dimensions of each symbol, dimensionless notation conventions, and symbol-collision rules.
4. Canon inputs: numeric inputs adopted as canonical (reference radii, anchor lengths, rectification constants and where they are defined), together with their meanings.
5. Invariants: invariant conditions that cannot be violated (fixed diameter/radius meaning, fixed inclusion/exclusion criteria of definitions, unit-dimension consistency).

Items in canon_lock are not derivation targets: they are not re-estimated or re-calibrated elsewhere in the document. canon_lock is an input to later derivations, and later derivations must output results without changing canon_lock.

1.2.3 Definition of realizationₗock (unit-realization freezing)

The realization_lock contains items obtained by realizing a dimensionless (or internal-unit) world into physical units through operational anchors. It locks realization results, not definitions. realization_lock includes:

1. Operational anchors: list of anchors used for realization and how anchors are fixed (input formats, measurement/record formats, channel layouts).
2. Primary scales: first outputs of realization such as the length scale a and time scale Δ t, with identifiers of where/how they are computed.
3. Derived scales: quantities derived from a and Δ t (e.g., unit energy U_lat) and identifiers of where they are used.
4. Realization invariants: meaning locks and cross-consistency conditions preventing reinterpretation of the same a under different meanings.
5. Cross-consistency spec: if consistency across independent channels is required, include channel lists and identifiers of the consistency decision configuration (decision expressions/thresholds themselves are fixed in analysis_lock).

realization_lock is not a tuning tool. It is a sealing of outputs produced by fixed operational anchors and fixed analysis procedures. Changing realization_lock implies changing anchors or analysis procedures and must be treated only as a version-up.

1.2.4 Definition of analysisₗock (freezing derivation/verification procedures)

The analysis_lock fixes procedural choices used in derivations and verifications. It locks the points where post-hoc tuning is easiest (closure choice, algorithm choice, verdict composition, log schema), implementing No-Tuning structurally. analysis_lock includes:

1. Closures: definitions and selection rules when multiple closure candidates exist; include inputs/outputs/failure modes.
2. Estimators/Metrics: formulas/procedures/normalizations/averaging conventions for throats, paths, distributions, invariants.
3. Algorithms: steps/parameters for graph construction, relaxation, search, thresholding, sampling, bootstrap/resampling (if used).
4. Gate-stack composition: which conclusions require which Gate stack (composition and order).
5. Thresholds/Tolerances: fixed thresholds and tolerances deciding PASS/FAIL; cannot move post-hoc (movement is version-up only).
6. Log schema: fields recorded for inputs, intermediate metrics, outputs, exceptions, fail labels, and environment info.

analysis_lock seals “how the calculation was performed.” Even under the same canon_lock and realization_lock, if analysis_lock differs then derived results and Gate verdicts can differ. Therefore the analysis_lock identifier must appear in every conclusion sentence.

1.2.5 SSOT implementation rules (registry unification)

SSOT is implemented not as a writing rule but as a file/registry structure. The SSOT rules are fixed as follows.

1. Single location of definitions: items of canon_lock, realization_lock, and analysis_lock are defined only in their registry files; the main text only references item names.
2. Item identifiability: every item has (i) name, (ii) unit, (iii) meaning (including diameter/radius), (iv) value or definition, (v) scope, and (vi) change history.
3. Dependency direction: realization_lock and analysis_lock may reference canon_lock items, but the reverse direction (promoting realized outputs into canon inputs) is forbidden.
4. No duplication: duplicates of the same item are not created in other files; references only are allowed, consisting of item name and lock_id.

SSOT violations are recorded as “definition collision” or “value collision,” and the artifact loses admissibility.

1.2.6 Change procedure (versioning and re-verification)

LOCK changes are allowed only as version-ups, not as edits inside the same version. The version-up procedure is fixed as follows.

1. Specify the change target: declare whether the change belongs to canon_lock/realization_lock/analysis_lock, and identify the item name and scope.
2. Create a new version: issue a new lock_id for the registry where the change occurs; the old lock_id is preserved and not edited.
3. Fix a change log: record before/after items, change rationale, impact scope (dependent conclusions), expected failure modes as change_log.
4. Update the dependency graph: mark all derived results and verification procedures that reference the changed item as re-computation targets.
5. Full re-derivation: regenerate all relevant derived results from scratch under the new lock_id combination (including intermediates).
6. Full re-verification: re-run the full required Gate stack for regenerated results to re-judge PASS/FAIL/INCONCLUSIVE.
7. Seal snapshots: create and seal the frozen copy of the used registries (three LOCKs), the manifest, and the full checksums as registry_snapshot.

Conclusions produced before the version-up remain assigned to the old lock_id combination, and conclusions produced after the version-up are assigned to the new combination. Mixing results across different lock_id combinations into a single conclusion is forbidden.

1.3 Gate & PASS.rules

1.3.1 Definition of Gate and verdict output

Gate is the verdict device that grants or revokes conclusion admissibility for derived artifacts. Gate does not describe an artifact as “true/false”; it decides only whether pre-registered conditions are satisfied. Gate output is fixed to:

• PASS: all pre-registered decision expressions and thresholds are satisfied.
• FAIL: one or more pre-registered decision expressions/thresholds are violated.
• INCONCLUSIVE: the decision expression cannot be applied due to insufficient or ambiguous inputs/logs/range/regime conditions, or the expression is applicable but minimal conditions for admissibility are not satisfied.

If the Gate output is FAIL or INCONCLUSIVE, the artifact does not have admissibility, and derived conclusions premised on it cannot have admissibility (dependency propagation). Admissibility is granted only by PASS.

Example (NON-LOCK calibration)

As a concrete example of how an external “inversion” claim can be structured without tuning any VP LOCK inputs, Appendix K reconstructs the mean free path of air from macroscopic acoustic and transport data. This appendix serves only as a methodological calibration of the reconstruction pipeline; it is not used to set any VP constants.

1.3.2 Classification of Gates (taxonomy and purpose)

Gates are classified by “what they decide.” The classification is fixed in analysis_lock; each Gate carries its inputs, decision expression, thresholds, log schema, and failure labels. Gate taxonomy is composed along three axes (target axis, function axis, stack axis).

(A) Target axis: what is decided

1. Semantic Gates: decide consistency of symbol meanings, unit dimensions, diameter/radius meanings, and object definitions (cell/core/shell/throat/path).
2. Lock-integrity Gates: decide consistency of referenced lock_id values, existence of registry snapshots, and absence of post-hoc changes.
3. Regime Gates: decide whether the scope (dimension/boundary/initial/scale window) satisfies pre-registered regime conditions.
4. Structure Gates: decide preservation of discrete-structure invariants (integer decompositions, cancellation rules, symmetries, sum/difference invariants).
5. Numerical Gates: decide convergence, sensitivity, repetition stability, log completeness, and reproducibility of computation paths.
6. Cross-consistency Gates: decide whether the same conclusion is maintained across independent channels/baselines/input combinations.
7. Reproducibility Gates: decide whether the same package can be re-run with the same conventions to reach the same verdict.
8. Anti-tuning Gates: decide whether post-hoc tuning occurred (definition/value/procedure/threshold changes, selection bias, log tampering, etc.).

(B) Function axis: how admissibility is decided

1. Qualification Gates: Gates that allow/forbid creation of a conclusion sentence itself. If a qualification Gate does not PASS, the conclusion sentence cannot be generated.
2. Limitation Gates: Gates that fix the scope/limitations of a conclusion. PASS fixes a scope; FAIL shrinks the scope or revokes admissibility.
3. Decomposition Gates: Gates that record where a result broke down (semantic/regime/structure/numerical/cross-consistency/reproducibility/No-Tuning) as labels.

A single Gate may serve multiple functions, but the function role(s) must be declared in gate_lock.

(C) Stack axis: Gates operate as stacks

A conclusion must pass a stack of Gates rather than a single Gate. A stack includes “Gates that must pass first” and “conditionally executed Gates.” Stack order and conditions are pre-registered in analysis_lock. The purpose of the stack is:

1. to prevent passing numerical Gates while semantic definitions are unstable,
2. to prevent packaging regime-violating results as cross-consistency,
3. to prevent describing results without reproducibility/snapshots as conclusions,
4. to block No-Tuning violations early rather than only at the end.

1.3.3 Gate ID system (standard Gate list and roles)

Gates are called by identifiers (gate_id), and a gate_id encodes taxonomy and purpose. The following list is the standard Gate namespace used throughout this document (additional Gates extend the same convention).

(A) Global base Gates (common to all conclusions)

• G-SYM: symbol meanings/unit dimensions/diameter–radius meaning consistency.
• G-LOCK: lock_id match, registry-snapshot existence, absence of post-hoc changes.
• G-REG: regime condition compatibility (dimension/boundary/initial/scale window).
• G-REP: reproducibility (code/inputs/environment/seed/logs/artifacts) and equivalent verdict.
• G-NT: No-Tuning violation detection (definitions/values/procedures/thresholds/selection/log tampering).

(B) Structure/rectification/procedure Gates (selected by claim type)

• G-RECT: rectification-constant integrity (rectification conventions, unique definition location, ban on re-derivation).
• G-STR: structural-invariant preservation (integer decomposition, cancellation, symmetry, sum/difference invariants).
• G-NUM: numerical stability (convergence, sensitivity, repetition stability, log completeness).
• G-RCROSS: cross-consistency (independent channels, baseline/input combinations).

(C) Extension-regime Gates (used only in optional routes)

• G-ANISO: anisotropy (rotation-drive input locking, direction-distribution stability, per-direction reproducibility).
• G-SOC: event-definition locking, existence of scale windows, robustness of distribution diagnostics.
• G-PATH: bottleneck/path sensitivity, alternative-path stability, invariance under throat-definition changes.
• G-CAP: throughput-ceiling definition uniqueness, acyclicity of ceiling derivation, regime-compatible scaling.
• G-UP: scale-up convention locking, proxy meaning (including non-use ranges), extrapolation failure conditions.

1.3.4 Standard fields for Gate records (log schema)

Every Gate verdict is recorded as a log with standard fields. The log format (JSON/YAML/CSV) is fixed in protocol_lock, while field meanings are fixed as follows.

1. gate_id: Gate identifier.
2. gate_version: Gate-definition version (including the analysis_lock identifier).
3. lock_refs: referenced lock_id list (canon/realization/analysis).
4. scope: applied scope (regime ID or condition expression).
5. inputs: inputs used in the Gate decision (file paths, parameters, summaries).
6. metrics: decision metrics (arrays/summary statistics/intermediate artifacts).
7. thresholds: thresholds/tolerances (reference to pre-registered values).
8. result: PASS/FAIL/INCONCLUSIVE.
9. fail_labels: cause labels for FAIL/INCONCLUSIVE (multiple allowed).
10. artifacts: list of generated artifacts (reports/figures/tables/logs) paths.
11. timestamp: execution timestamp.

Gate records must be sealed by inclusion in the snapshot (manifest/checksums/registry_snapshot). Unsealed Gate records do not grant conclusion admissibility.

1.3.5 Definition of PASS.rules (sentence-admissibility rules)

PASS.rules is the rule set that fixes “which Gate combination must PASS in order to allow which sentence format as a conclusion.” PASS.rules is included in analysis_lock and cannot be modified after seeing results. PASS.rules has two layers.

1. Claim-type layer: classifies conclusions by type and fixes the required Gate stack for each type.
2. Sentence-template layer: fixes allowed conclusion sentence formats and forbidden sentence patterns.

The purpose of PASS.rules is simultaneously to block (i) unpassed results flowing into sentences and (ii) passed results inflating into over-interpretation.

1.3.6 Standard classification of claim types

Claim types used in PASS.rules are fixed as follows. Each type defines the range of allowed sentences; statements outside that range are forbidden.

1. CT-DEF: declaration of definitions/axioms/conventions (LOCK items). Not a derivation/Gate target; attributed only by lock_id.
2. CT-DER-FORM: derived form (equation structure, relations, invariant forms). Declares relations without numerical substitution.
3. CT-DER-NUM: derived numbers (single values or a canonical list). Declared with units/meaning (including diameter/radius).
4. CT-DER-RANGE: derived ranges (intervals, bounds, conditional ranges) with regime conditions.
5. CT-STR: structural conclusions (integer decomposition, cancellation rules, symmetries, coordinate structures) with structural invariants.
6. CT-REAL: unit-realization conclusions (derive a, Δ t, etc from operational anchors) including cross-consistency Gate.
7. CT-XCROSS: cross-consistency conclusions (consistency across independent channels) with channel layouts and thresholds.
8. CT-REP: reproducibility conclusions (re-run the same package to reach the same verdict) with reproducibility logs and checksums.
9. CT-LIM: limitation/non-scope conclusions (where it applies and where it breaks) with FAIL/INCONCLUSIVE cause labels.

1.3.7 Standard sentence templates conditioned on Gate PASS

The table below fixes, for each claim type, the required Gate stack and the allowed conclusion-sentence format. In the table, “required” means necessary to generate a conclusion sentence, and “conditional” means required only for that type.

1.3.8 Forbidden conclusion-sentence patterns (short)

PASS.rules fixes forbidden patterns as well as allowed templates. Forbidden patterns are fixed as follows.

1. No-Gate conclusion forbidden: numerical/law statements without Gate identifiers or verdict status (PASS/FAIL/INCONCLUSIVE).
2. No-regime universalization forbidden: scope expansion expressions such as “always/all/universal” without regime conditions.
3. Post-hoc justification forbidden: verdict-neutralizing expressions such as “because it agrees, it is true” or “it fails Gate but is correct by interpretation.”
4. No-LOCK attribution forbidden: re-stating definitions/values/thresholds/procedures without lock_id attribution.

1.3.9 Standard PASS.rules file template (machine-readable)

PASS.rules is included in analysis_lock in a machine-readable form. Below is a standard template (key names and structure are fixed).

pass_rules:
  - rule_id: PR-CT-DER-NUM-001
    claim_type: CT-DER-NUM
    claim_id: (internal claim identifier; e.g., CL-13-05-mp)
    scope: (regime id or condition expression; e.g., global | regime:R1 | condition:...)
    requires:
      gates_pass:
        - G-SYM
        - G-LOCK
        - G-REG
        - G-NT
        - (optional) G-NUM
      locks_present:
        - canon_lock
        - realization_lock
        - analysis_lock
      snapshot_required: true
      manifest_required: true
      checksums_required: true
    allows_sentences:
      - template_id: ST-CT-DER-NUM-01
        pattern: "[LOCK:{canon_id,real_id,ana_id}][DER:{der_id}][GATE:{gate_stack_id}] {Q} = {value} {unit}."
        requires_fields:
          - Q
          - value
          - unit
          - canon_id
          - real_id
          - ana_id
          - der_id
          - gate_stack_id
    forbids_sentences:
      - "Sentence asserting a numeric conclusion without a Gate tag"
      - "Sentence declaring universal scope without regime conditions"
      - "Post-hoc justification or verdict-neutralization sentence"
    on_fail:
      verdict: "revoked"
      label_prefix: "FAIL-PASSRULE"
      propagation: "propagate along dependency_dag"

In the template above, requires.gates_pass is a necessary condition to generate a conclusion sentence, and allows_sentences fixes the admissible sentence format. The snapshot/manifest/checksums requirements fix “evidence sealing” as a necessary condition for conclusion admissibility.

1.8 No-Tuning Audit

1.8.1 Degrees-of-freedom ledger

The framework's quantitative outputs depend on the following inputs only:

1. Mathematics (no DOF): π; integers up to 7; closed-form rectification constants α=2/π, δ=1/π². (The 89/82 count is a gravity/mass-sector ratio, not an EM/Coulomb factor; see the §14.2 correction.)
2. Geometry (no DOF): canonical cell = cube; canonical core =82; canonical shell =7; canonical reduction integer 5π for the Higgs channel.
3. Single empirical anchor (1 DOF): λ_ref=632.99nm, used to fix a once.
4. Universal constants (0 DOF): h, and the SI-defining anchor value c_ref. Crucial distinction: the framework separately derives an emergent lattice propagation speed c_env=√(K) from the stiffness postulate (§11.6) and shows it coincides with c_ref. Only c_ref (the SI anchor) enters as an input here; the emergent c_env is an output. These are logically distinct quantities that happen to agree — which is precisely why c²=K is a verifiable claim rather than a circular definition (see §1.9 A1).

No per-particle calibration, no fitted coupling, no tunable exponent enters anywhere. The total tunable DOF count is therefore exactly one, and it is exposed in step 3.

1.8.2 N-invariance check

A common source of hidden tuning in lattice models is letting predictions depend on the lattice size N. The dimensionless predictions of this paper are explicitly N-invariant:

Confirmed by the released code; no N enters the closure equations.

1.8.3 Self-falsification protocol — five-line check

Any reader who suspects hidden tuning can verify the no-tuning claim in five lines of Python:

import math
mp_me = 6 * math.pi**5
mH_over_Ulat = 1.0 / (5*math.pi)
r_p_fm = 4.852620477e-12/(6*math.pi**6)*1e15   # = D_anch/(6 pi^6), predicted proton radius
print(mp_me, mH_over_Ulat, r_p_fm)
# 1836.1181..., 0.063662..., 0.841251...  (CODATA r_p = 0.8414 fm; alpha_em is NOT here:
# the 4*pi*(11-...) closed form is COINCIDENCE/NON-EVIDENCE per S14.5 and is excluded by its own rule)

There is no fitted coefficient anywhere in the right-hand sides. The closure is structural.

Companion geometric-count check (front-loaded from Part II in v0.5.0; single source here).

For the framework's geometric counts — verifiable in 30 seconds with no external library:

import math, itertools
pi = math.pi
# rectification constants
assert abs(2/pi - 0.6366197724) < 1e-9   # alpha = 2/pi
assert abs(1/pi**2 - 0.1013211836) < 1e-9 # delta = 1/pi^2
# lattice counts
cnt = lambda k: sum(1 for p in itertools.product(range(-4,5),repeat=3)
                    if sum(c*c for c in p)<=k)
assert [cnt(k) for k in (2,3,6,9)] == [19,27,81,123]
# Legendre three-square theorem: R^2 = 7 is empty
assert cnt(7) == cnt(6) == 81
# C_3 decomposition: 6-point cyclic ring sums to zero
diag = [p for p in itertools.product((-1,1),repeat=3)]
six = [p for p in diag if p not in ((1,1,1),(-1,-1,-1))]
assert tuple(sum(p[i] for p in six) for i in range(3)) == (0,0,0)
# forced integer 6 in m_p/m_e = 6 pi^5
mp_me_measured = 1836.152673426  # CODATA
assert abs(mp_me_measured/pi**5 - 6) < 2e-4
print("ALL PASS - five geometric facts verified, no fitted knob touched.")

Copy-pasted into a Python interpreter, this returns ALL PASS or an AssertionError pointing to the failed claim: if a reader's run prints anything other than ALL PASS, the framework is wrong and the reader has found a real error, not a presentation issue.

1.8.4 The forced-coefficient test

A tuning workflow would have used the residual to migrate the coefficients by an arbitrarily small amount: 5π→ 4.98π (force Higgs to zero residual), 6π⁵→ 6.0001π⁵ (force mₚ/mₑ exact to one part in 10⁴), etc. The shifts required are tiny — well within any "fitting freedom" a tuning workflow would silently exercise. This paper does not. The coefficients are kept at their clean geometric values, and the small residuals (-0.40% Higgs, -19ppm mₚ/mₑ, -0.018% rₚ) are reported openly. (The once-quoted Coulomb -0.43% is excluded from this list: §14.2 reclassified it as overfit, and §14.5 bars the αₑₘ closed form from evidential use.) This refusal to migrate is itself a structural signature: it is what distinguishes a derivation from a fit.

1.9 Reviewer Doubt Trails (anticipated objections, resolved or flagged)

This section traces the most natural reviewer objections through to their current status. Each item is either resolved ([F]{}/[H]{}) with a pointer to the resolution, or flagged open ([O]{}) with the specific evidence that would close it.

A1. "Is the speed of light just plugged in?"

Resolved [F]. The framework distinguishes two speeds: the SI-defining anchor c_ref (used, like h, as an external constant) and the emergent lattice propagation speed c_env=√(K), which is derived (not posited) from the unbounded-stiffness postulate of the pre-structure lattice. The non-trivial content is that c_env comes out equal to c_ref; the framework does not assume this, it shows it (§11.6). The apparent circularity ("c in, c out") dissolves once the two are kept distinct: the input is c_ref, the output is c_env, and their agreement is a result. Moreover the dimensionless ratios (Rₚ/L_q, mₚ/mₑ, etc.) use neither. See §W.4 prong A.

A2. "The electron 1-second is suspiciously round."

Partially resolved [H]+. Two independent load-bearing paths converge to Tₑ≈ 1 s under the anchor: (B) the released reproducible code, and (G) the canonical geometry. The geometry path (G) is itself triangulated three ways — small-lattice direct count, Tₑ∝ N² scaling invariance, and the three-fold canonical (5-of-6) structure. The earlier full-physics simulation evidence is downgraded to historical-consistency (code not in the public bundle). See §12.

A3. "Could the small residuals (0.4%) just be coincidences?"

A4. "What is 89/82 doing in the Coulomb constant?"

A5. "Why a single anchor at 632.99 nm specifically?"

Partially resolved [H]. Any single sub-micron length that fits the canonical-cell admissibility window (§6.4, RCROSS validation) would do; 632.99 nm is the He–Ne laser line because it is the most reproducible sub-micron length in metrology. The choice is operational, not theoretical: any other anchor in the window predicts the same dimensionless ratios.

A6. "Is the simulation in the AQD bundle independently audited?"

Flagged [O]. The bundle ships with checksums (sha256) and a self-validation harness (validate_bundle.py), but external independent re-execution by another group has not yet occurred. This is a social-process gap, not a content gap.

A7. "Gravity is treated separately. Why?"

Resolved [F]+[O]. The cap mechanism is derived (§17.4 four-wall theorem); the absolute magnitude 9.80665m/s² is honestly an external anchor (back-substituted in App G). This separation is isomorphic to the standard-physics hierarchy problem: a force law fixes shape, not coupling magnitude.

A8. "Does this framework forbid anything?"

B1. "Where is the narrow-sense prediction of an unmeasured constant?"

Candidate-committed [O] (status unified v0.5.0). A concrete narrow-sense, falsifiable optical prediction is now pre-registered: the light propagation angle χ(λ) of §10.9, with committed numbers in §10.9.1 (χ(632.99nm)=89.9378^(∘), χ(532.0nm)=89.8248^(∘) at the canonical D_anch; hypersensitive, 0.03% in D ⇒>1^(∘) in χ). What remains open — and keeps this item [O]{} — is (a) the experimental protocol (including the observation-coexistence conditions of §10.9.2) and (b) the measurement itself. Earlier wordings of this item ("no narrow-sense prediction", "the most important open item") and the contrary wordings of §3.4 / the v0.4.1 history ("answers B1") are both replaced by this single status: numbers committed, measurement outstanding.

B2. "What about cosmological observables?"

Open [O]. The cap mechanism gestures toward a connection with cosmological constant / dark-energy scales (see App F), but this is currently at the suggestive-coincidence level, not a derived result.

C. The HYP tier

A small number of claims (e.g., the unbounded-stiffness postulate; the equivalence of λ_C and L_q) are inputs in the present framework, not outputs. They are listed in canon_lock and are kept explicit so that revising them remains a single, locatable operation.

Meta-lessons for the next AI/human reviewer

1. Read the scorecard first. Don't get lost in the lock formalism (§0–3) before knowing what is being claimed.
2. Separate (G/S/M) provenance. A claim resting on G alone is much stronger than one resting on M alone; the ledger in §W.5 keeps this visible.
3. Track which DOI version you are reading. The version DOI is in the title page; the concept DOI is at the Zenodo page sidebar.
4. Distinguish "no prediction yet" from "no falsifier." The framework has falsifiers (see §1.10); it has not yet made a narrow-sense forward prediction. Both facts are honest.

1.10 Falsification Criteria

The framework is designed to be falsifiable in four specific ways. The criteria below are what would force a structural revision (not a parameter tweak).

Kill criterion 1 — hidden knob.

If any reader can show that a published prediction (e.g., mₚ/mₑ=6π⁵) is actually free of a coefficient that we silently fitted, the no-tuning claim collapses. This is what the five-line Python check in §1.8.3 is designed to make falsifiable in finite time.

Kill criterion 2 — geometric fix moves under repetition.

Rₚ/L_q=2/π, σ/L_q²=4/π, α=2/π, δ=1/π² are claimed as fixed geometric outputs. If a re-derivation under the same canonical cell yields a different value, the geometric layer is wrong.

Kill criterion 3 — new constant disagrees.

Whenever a not-yet-measured constant comes within range of measurement, the framework should be able to commit to a value before the measurement, not after. As of v0.5.0 one such commitment is publicly recorded: the light-angle table of §10.9.1 (χ(633)=89.9378^(∘), χ(532)=89.8248^(∘), with the D-distribution spread as the stated width). If a competent measurement of the visible-light transverse angle against a lattice/anisotropy axis falls outside the committed window, the rotating-quantum picture of light is falsified. This criterion is therefore "armed"; it remains unused only in the sense that the measurement has not yet been performed.

Kill criterion 4 — velocity cap fails.

The cap mechanism (§17.4) predicts a specific velocity-driven pressure law and a height-independent (Beverloo-type) steady flow. A controlled experiment that exhibits clean 1/R² dependence without a saturation onset, at scales where the cap should be active, would falsify the gravity portion of the framework.

What we do not call falsifiers.

The following are not legitimate falsifiers: (i) "the closure has a 0.4% residual" — the residual is reported openly and is part of the deliverable; (ii) "no external group has replicated" — this is a social-process gap, not a falsifier; (iii) "the theory is unfamiliar" — unfamiliarity is not a counter-argument.

Demarcation from pseudoscience.

A short checklist against the standard pseudoscience patterns: