Notation, Terminology, and Scale Hierarchy

Notation, Terminology, and Scale Hierarchy: Even the notation of a unit is a locked field, not a habit. Canonical scales have definitions; realized scales have values — the registry keeps them from trading places. Scientific notation is fixed to the form x× 10ⁿ.

Even the notation of a unit is a locked field, not a habit. Canonical scales have definitions; realized scales have values — the registry keeps them from trading places. Scientific notation is fixed to the form x× 10ⁿ.

Purpose and top-level principles

This chapter fixes, under a single registry system, the symbols, units, and scales (length/time/mass/energy/force, etc.) used across the entire document, and structurally prevents the same item from being defined twice or assigned conflicting meanings across different sections. The conventions of this chapter act as the highest-precedence rules for the whole document. That is, any derivation, number, table, figure, or log that violates the symbol/unit/scale registry conventions fixed here cannot qualify as a conclusion.

Priority of symbol–unit–scale registries (conflict resolution order)

When a symbol/unit/scale conflict occurs, there is no rule that “patches” the conflict by interpretation. Conflicts are judged by Gate; if the verdict is FAIL or INCONCLUSIVE, the corresponding artifact loses admissibility as a conclusion. The precedence order used for conflict judgment is fixed as follows.

1. Priority 1: Symbol Registry The meaning of a symbol has the highest priority. Here, meaning includes (i) the entity/object the symbol refers to (cell/core/shell/throat/path, etc.), (ii) the geometric meaning (diameter/radius, center/surface, cube/sphere, etc.), (iii) the measurement convention to which the numeric value is bound (which definition of length it belongs to), and (iv) the admissible operations (sum/product/integration, etc.). Assigning a unit or a scale value before the symbol meaning is locked is forbidden.
2. Priority 2: Unit Registry Units are subordinate to symbol meaning. The unit registry fixes, for each symbol, the dimension (length/time/mass/dimensionless, etc.), the notation system (SI vs internal dimensionless, including mixing-prohibition rules), and the conversion policy. If a unit conflicts with the symbol meaning (e.g., assigning time to a symbol defined as length), the unit is automatically invalid and the conflict is judged as FAIL by Gate.
3. Priority 3: Scale Registry The scale registry has meaning only after symbol and unit are locked. Scales are fixed by separating (i) canonical scales and (ii) realized scales. Canonical scales lock definitions (what the scale is), while realized scales lock the numerical values as sealed by operational anchors and procedures. No rule permits moving the numerical value of a scale to match a target outcome.

Therefore, changing a symbol meaning (priority-1), changing a unit (priority-2), or changing a scale value (priority-3) because “the number does not match” is forbidden within the same version. Change exists only via versioning (a new LOCK).

Single source of truth (SSOT) and separated storage of registries

Symbols/units/scales are stored in separate registry files, and each registry functions as SSOT. The SSOT implementation rules are fixed as follows.

1. The meaning of a symbol exists only in the symbol registry.
2. The unit dimension and notation rules of a symbol exist only in the unit registry.
3. The definition and numeric attribution of a scale exist only in the scale registry.
4. Body sections do not redefine registry items; they refer to them by item name and lock_id.
5. Duplicated definitions/units/numbers outside registries are forbidden; upon detection, they are judged as conflicts.

Separated storage is a structural device to prevent “definitions (meaning)”, “units (dimensions)”, and “numbers (scales)” from retroactively adjusting each other.

Standard fields of the symbol registry (sealing meaning)

The symbol registry contains the following standard fields for each symbol. The presence of these fields is mandatory; if a field is missing, the corresponding symbol is judged unusable.

1. symbol: the symbol string (e.g., a, D_anch, r_p, stringℓ_rot, etc.).
2. entity: the entity/object the symbol refers to (e.g., cell length, core radius, shell coordinates, critical throat thickness, etc.).
3. geometry_meaning: geometric meaning (diameter/radius, center–surface, cube/sphere, axis/plane, etc.).
4. definition: a definition sentence or equation (optionally with an identifier).
5. allowed_operations: admissible operations and combinations (e.g., whether integration is allowed, what averaging convention applies, whether absolute value/square is allowed).
6. scope: scope of applicability (a regime identifier or a condition). Use outside scope is forbidden.
7. notes: conflict-prevention notes (distinguishing similarly spelled symbols, prohibiting reinterpretations, etc.).

The symbol registry forbids “the same notation used with different meanings.” A single symbol cannot carry multiple meanings; if needed, symbols must be split and each meaning locked as an independent entry.

2.5 Standard fields of the unit registry (sealing dimensions)

The unit registry contains the following standard fields for each symbol.

1. symbol: linked 1:1 to the symbol field in the symbol registry.
2. dimension: dimension (length/time/mass/dimensionless, etc.) or composite dimensions if required.
3. unit_system: notation system (e.g., SI vs internal dimensionless), together with whether mixing is allowed.
4. unit_name: unit notation (e.g., m, s, fm, pm, etc.). The notation itself is locked.
5. conversion_policy: conversion policy (allowed/disallowed; where conversions may be performed).
6. consistency_checks: rules for dimensional-consistency checks (identifiers or checklist items).

The unit registry is valid only under the “meaning-first” precedence. Therefore, the unit registry does not modify symbol meaning, and unit conflicts are not resolved by unit reinterpretation.

2.6 Standard fields of the scale registry (separating canonical vs realized)

The scale registry records scales by separating canonical and realized entries. The standard fields are as follows.

1. scale_id: scale identifier (e.g., S-L-a, S-T-dt, S-L-Danch, S-L-rp, S-L-lrot, etc.).
2. symbol: the symbol to which the scale is bound (linked to a symbol-registry entry).
3. kind: one of canonical, realized, or derived.
4. definition: the definition equation (canonical) or the output equation (realized/derived).
5. value: the numerical value (mandatory only for realized/derived). For canonical, this field is left empty.
6. unit_ref: unit-registry reference (binding to a unit dimension).
7. anchor_ref: operational-anchor reference (mandatory only for realized). It identifies which anchor and which procedure sealed the value.
8. dependencies: a list of dependencies (other scales, anchors, procedures). Circular dependency is forbidden.
9. scope: scope of applicability (a regime identifier or a condition).

In the scale registry, realized is not “a measurement” but “a sealed result value fixed by an operational anchor and procedure,” and derived is a computed result obtained from locked scales. A derived entry does not modify or replace a canonical entry.

2.7 Conflict verdict and versioning procedure (no interpretation)

Symbol/unit/scale conflicts are not repaired by interpretation, and are handled by the following rules.

1. Conflict detection: multiple meanings for the same symbol, unit-dimension mismatch, mismatch between scale definition and numeric attribution, ambiguous diameter/radius meaning, mixed cube/sphere interpretations, etc.
2. Verdict: conflicts are judged only as FAIL or INCONCLUSIVE by Gate, accompanied by conflict-type labels.
3. Isolation: any artifact containing the conflict and any artifacts derived from it are removed from the pool of admissible conclusions (this is a status transition, not deletion).
4. Versioning: to resolve a conflict, a new lock_id must be issued for the relevant registry (canon/realization/analysis). Under the new lock_id, (i) fix the conflicting item, (ii) update dependencies, (iii) re-derive all dependent results, (iv) re-judge all required Gates, and (v) seal a snapshot.
5. No mixing: building one conclusion by mixing symbol/unit/scale entries from different lock_id combinations is forbidden.

Therefore, sentences of the form “the same value can be read with another meaning” do not qualify as conclusions in this document. If the meaning is not uniquely locked, the value is not a conclusion.

2.1 Symbol / unit / object standards

2.1.1 Scope of the standard

This subsection fixes the global standards for (i) symbols, (ii) units, (iii) objects, and (iv) scales used throughout the document. The purpose is to structurally prevent: the same spelling being used with different meanings; the same meaning splitting into multiple notations; unclear unit dimensions; and mixed geometric meanings such as diameter vs radius. The standards fixed here are not redefined later; instead of restating them, later sections refer only to the corresponding registry entries (item name and identifier).

2.1.2 Symbol standard (notation rules)

Symbols are fixed across the whole document by the following conventions.

(A) Fonts and entity types

1. Scalars are written in italic: a, r₀, r_p, ℓ_rot, Δ t.
2. Vectors are written in bold italic: x, v, n.
3. Matrices/tensors are written either as bold capitals or by a double-struck rule: M or T. In this document, bold capitals are the default.
4. Sets are written in calligraphic style: V (VP set), E (event set), G (graph).
5. Functions are written in roman: Gate(·), Rect(·), Hash(·).

(B) Indices and subscripts

1. Entity indices are written as integer subscripts: i, j, k.
2. Component indices are written as Greek letters or coordinate subscripts: α, β or x,y,z.
3. Object-label subscripts are written as roman abbreviations: r_p (proton core radius), ℓ_rot (rotation-driven length).
4. Regime/scope subscripts are written in roman: a_sim (internal unit), a_real (after unit realization).
5. Averaging/aggregation notation is fixed to an overbar: X denotes only a result produced by a pre-registered averaging operator. The averaging operator is locked in analysis_lock.

(C) Reserved Symbols

To prevent symbol conflicts, the following reservation rules are fixed.

1. Canonical input scales are written as D_anch, r_p, ℓ_rot, etc., and symbols used for canonical inputs are not reused with other meanings.
2. Unit-realization scales use a, Δ t as base symbols, and a and Δ t are not reused with other meanings (e.g., area or acceleration).
3. Diameter/radius meaning is locked in the symbol field geometry_meaning; a single symbol cannot mean both diameter and radius.
4. Dimensionless numbers refer only to entries whose unit field specifies dimensionless, and dimensionless notation does not permit unit mixing.

2.1.3 Unit standard (dimension and notation rules)

Units are assigned only after symbol meaning has been locked. The unit standards are fixed as follows.

(A) Separation of unit systems

1. Canonical units: used at the stage where meaning is locked (not values). Canonical units may be recorded as internal dimensionless or internal length/time units; in that case the unit registry locks unit_system=internal.
2. Realized units: used after numeric values are fixed via operational anchors. Realized units are locked as unit_system=SI, and notation m, s with sub-prefix forms is allowed.
3. No mixing: internal and SI units are not mixed within a single equation or a single table. If mixing is required, the conversion step itself must be separated as an independent derivation item and the input/output units of the conversion must be locked.

(B) Mandatory dimension field

Every symbol must have a mandatory dimension field in the unit registry.

1. Length dimension: L
2. Time dimension: T
3. Mass dimension: M
4. Energy dimension: E
5. Force dimension: F
6. Dimensionless: 1

If the dimension field is empty or conflicting, the symbol is judged unusable.

(C) Prefix notation and fixed scientific notation

In realized units, length and time may use prefixes, but the notation rules are fixed.

1. Only prefix forms approved in the unit registry may be used.
2. Scientific notation is fixed to the form x× 10ⁿ.
3. Significant-digit and rounding rules follow the rule locked in analysis_lock. Post-hoc changes are forbidden; changes are allowed only by versioning.

2.1.4 Object standard (object dictionary and meaning lock)

An object specifies “what a symbol refers to” and acts as the highest-level criterion. Objects are fixed in an Object Registry with the following conventions.

(A) Object ID and minimal fields

Every object has an object ID and the following minimal fields.

1. object_id: e.g., OBJ-VP, OBJ-CELL, OBJ-CORE, OBJ-SHELL, OBJ-THROAT, OBJ-PATH, OBJ-EVENT.
2. name: a human-readable object name.
3. definition: the object definition (including defining equations if needed).
4. geometry_meaning: the geometric meaning of the length symbols carried by the object (diameter/radius/gap/thickness/lattice constant, etc.).
5. state_fields: state variables of the object (if any), locked as a list.
6. allowed_maps: admissible mappings to other objects/observables (only allowed transforms are listed).
7. scope: regime scope.

(B) Standard definitions of core objects (minimal declarations)

Core objects that must appear in this document are fixed as follows.

1. Volume particle (VP), OBJ-VP: the fundamental unit composing space. VP properties and admissible rules are locked in the axioms/definitions of canon_lock.
2. Cell, OBJ-CELL: the reference domain used to bundle a set of VP. Cell geometry (e.g., cube cell, spherical visualization cell) is locked by the geometry_meaning field; a single cell symbol cannot simultaneously refer to different geometries.
3. Core, OBJ-CORE: the object defining the central structure. The radius/diameter meaning of the core length symbol must be locked.
4. Shell, OBJ-SHELL: the structural object outside the core. Shell-coordinate sets, cancellation rules, survival vectors, etc., are locked together with procedures in analysis_lock.
5. Throat, OBJ-THROAT: a microscopic bottleneck element in global connectivity. A throat thickness/gap/threshold symbol requires geometry_meaning, and the critical-throat estimator is locked in analysis_lock.
6. Path, OBJ-PATH: a global transfer path made of connected throats. Path-selection rules and alternative-path rules are locked in analysis_lock.
7. Event, OBJ-EVENT: the minimal observable/loggable event unit. Event definition is locked in canon_lock; event-rate estimation and aggregation are locked in analysis_lock.

2.1.5 Scale hierarchy for length/time/mass (hierarchy registry)

A scale hierarchy separates “what is an input,” “what is a derived result,” and “what is a realized output,” and locks the classification. Length/time/mass share a common structure.

(A) Hierarchy types

Each scale is classified as one of the following types.

1. CAN-INPUT: canonical input. Meaning and value are locked in canon_lock.
2. CAN-DERIVED: canonical derived. Derived from CAN-INPUT; derivation rules are locked in canon_lock or analysis_lock.
3. REAL-PRIMARY: primary outputs of unit realization. Locked in realization_lock by operational anchors and realization rules.
4. REAL-DERIVED: realized derived. Derived from REAL-PRIMARY and locked derivation rules; results are recorded in realization_lock or a derived registry.
5. OBS-REF: observational reference. A reference obtained from an observation protocol; the meaning and protocol of the observation value are locked in analysis_lock.

(B) Standard entries for the length-scale hierarchy

The length-scale hierarchy contains the following standard entries. The existence of these items is enforced in the registry (whether a value is present depends on the type).

(C) Standard entries for the time-scale hierarchy

The time-scale hierarchy contains the following standard entries.

(D) Standard entries for the mass-scale hierarchy

Even when a number named “mass” appears, the mass-scale hierarchy fixes which internal definition that number comes from.

2.1.6 Prohibition of symbol reuse (no overloading)

Symbol reuse (overloading) is a global prohibition rule in this document. “Overloading” refers to any case where at least one of the following holds.

1. The same symbol is bound to different objects (OBJ-*).
2. The same symbol has different geometric meanings (diameter/radius/gap/thickness/lattice constant, etc.).
3. The same symbol has different dimensions (L, T, M, 1, etc.).
4. The same symbol simultaneously has different hierarchy types (CAN-INPUT vs REAL-PRIMARY, etc.).
5. The same symbol is subjected to different averaging/aggregation conventions (e.g., different averaging operators for X).

A need for overloading is not accepted as a justification. If meanings differ, symbols must be split. Symbol splitting follows these fixed rules.

1. Object-subscript split: if the same spelling is maintained, attach an object-label subscript (e.g., r_p, r₀, r_cell).
2. Regime-subscript split: if regimes differ, split with a regime subscript (e.g., a_sim, a_real). However, even then the meaning and dimension must remain identical.
3. Full split: if meaning and dimension differ, change the spelling itself and fix a purpose subscript (e.g., δ_rect vs δ_gap).

If symbol overloading is detected, the corresponding artifact is judged FAIL by the symbol Gate and loses admissibility as a conclusion. Overloading is not resolved by “interpretation” within the same version; if a registry entry must be modified, it is permitted only via versioning.

2.2 CANON inputs (canonical)

2.2.1 Definition of canonical inputs

Canonical inputs (CANON inputs) are the set of inputs treated as starting points of evidence throughout the document. A canonical input must satisfy all of the following properties simultaneously.

1. Meaning lock: what the item means (object binding, geometric meaning such as diameter/radius, inclusion/exclusion criteria) is fixed uniquely.
2. Unit lock: its dimension and unit notation are fixed. Items that require units have their units locked.
3. Value lock: if a value is given, it is fixed (including accuracy/significant-digit rules).
4. Scope lock: the applicable regime scope (global vs specific regimes) is fixed. It cannot be referenced outside scope.
5. SSOT: canonical inputs exist only in a single location in the canon_lock registry. The body does not redefine them and refers only to item name and identifier.

Canonical inputs are not “targets to be derived.” They are derivation inputs, and replacing a canonical input by a derived result, or retroactively modifying a canonical input based on a derived result, is forbidden. (Exception, v0.2.1: r_p has since been reclassified as a derived prediction r_p=D_anch/(6π⁶) under LOCK-NU-N, §8.0.5; the value retained in canon_lock is now its +61 ppm cross-check reference. The rule applies to the remaining four items; see the reclassification note in (B).)

2.2.2 List and classification of canonical input items

In this document, the following five items are classified as canonical inputs.

1. D_anch : canonical anchor length (representative length of the anchor cell).
2. r_p : canonical radius (defined as the proton core radius).
3. π : the circle constant (dimensionless).
4. δ : a rectification constant (dimensionless).
5. ℓ_rot : rotation-drive length (reference canonical input).

Because these items have different roles, canonical inputs are further classified as follows.

• CANON-PRIMARY: primary canonical inputs whose values and units are fixed (e.g., physical lengths/radii).
• CANON-CONST: canonical constants whose values are globally fixed (dimensionless constants).
• CANON-REF: reference canonical inputs used only in specific regimes (not automatically promoted to required inputs of the core chain).

2.2.3 Meaning lock for each item (object binding and geometric meaning)

For canonical inputs, “meaning” must be locked before “value.” The object binding and geometric meaning of each item are fixed as follows.

(A) D_anch : canonical anchor length

D_anch is defined as the representative length of OBJ-CELL (cell) or a canonical geometric object treated as equivalent to the cell. The geometric meaning of D_anch (diameter/radius/edge length) is fixed uniquely in the geometry_meaning field of canon_lock. Because D_anch is the canonical anchor, no section may reinterpret its meaning and replace it by a different geometric quantity. If a radius-like derived quantity is needed, it is introduced only as a derived definition with a separate symbol, for example

Here, r₀ is a derived symbol, and it is usable only after the meaning lock of D_anch is satisfied.

(B) r_p : canonical radius (core radius)

r_p is defined as the radius of OBJ-CORE (core). r_p is locked as a radius and cannot be reinterpreted as a diameter. The value of r_p is locked as a canonical input value; the unit is locked as length. The unit notation is fixed to one of the registry-approved prefix forms (e.g., fm). r_p is used as an evidence starting point in core geometry and event-rate derivations; changing r_p or replacing it by a different meaning is forbidden within the same version. r_p status. Under LOCK-NU-N (§8.0.5), r_p is a derived prediction r_p=D_anch/(6π⁶)=0.84125 fm, not a free canonical input; the forced (2/π)λ_(C,p)=0.8412 fm is its +61 ppm cross-check. Accordingly r_p is exempt from the “not derivable” rule of §2.2.1, and the proton mass built on it (§13.4) is a prediction, not a calibration. (Reclassified in v0.2.1; see the version-history appendix.)

(C) π : the circle constant

π is dimensionless and its value is globally fixed. Since π is a defined constant rather than a measurement, no section may estimate or adjust π. π is used in rectification constants and geometric ratios, and every derivation that uses π refers to it only as a canonical constant.

(D) δ : rectification constant

δ is defined as a dimensionless rectification constant. The definition of δ is fixed in a single location as

This definition is locked in canon_lock; later sections do not re-derive δ. Recomputing δ from a different averaging or projection convention in order to change its value is forbidden. The usage of δ is restricted to the defined form; if another rectification constant is needed, it must be separated as a new symbol and locked as a separate entry.

(E) ℓ_rot : rotation-drive length (reference canonical input)

ℓ_rot is defined as a length input used in rotation-drive regimes. Its geometric meaning is locked as a diameter (no diameter/radius mixing). ℓ_rot is classified as follows.

• CANON-REF: ℓ_rot is referenced only in specific extension regimes (rotation drive / anisotropy / spin indicators, etc.).
• Not part of the required chain: ℓ_rot is not automatically promoted to a required input of the core chain (canonical → event → realization → mass/force).

Therefore, replacing ℓ_rot by D_anch, or redefining the meaning of D_anch from ℓ_rot, is forbidden. If promotion is required, the versioning procedure of 2.2.6 must be followed.

2.2.4 Value/unit lock (standard notation and significant digits)

Value and unit notation of canonical inputs are locked by the following rules.

1. D_anch, r_p, and ℓ_rot are locked as length dimension (L).
2. π and δ are locked as dimensionless (1).
3. If a value is provided, it is fixed either in standard scientific notation (x× 10ⁿ) or in a fixed-point notation as specified in the registry.
4. Significant-digit / rounding rules are fixed in analysis_lock under numeric_format, and do not change within the same version.

If a value for ℓ_rot is provided (e.g., ℓ_rot=lrot), its diameter meaning and unit (e.g., pm) must be locked simultaneously. Recording a value without locking meaning is not allowed.

2.2.5 Reference rules for canonical inputs (usage rules in the body)

Canonical inputs are used in the body only under the following rules.

1. The body does not redefine canonical inputs. It refers only to the canon_lock item names (e.g., D_anch, rp, pi, delta, l_rot) and lock_id.
2. Every equation/table/figure/log that uses a canonical input must also reference the corresponding meaning lock information (geometry_meaning, entity, object_id).
3. Any section that requires a canonical input must declare the regime scope together. For example, ℓ_rot may be referenced only in rotation-drive regimes; unconditional reference in global sections is forbidden.
4. When π and δ appear together in the same section, δ must always be used by referencing the definition δ:=1/π², and may not be treated as an independently adjustable constant.

2.2.6 Change procedure (versioning and re-verification)

Changing a canonical input is not allowed within the same version. Changes are performed only via versioning, under the following fixed procedure.

1. Specify the category of change: a canon_lock item change (canonical input change).
2. Issue a new canon_lock lock_id. The previous lock_id is preserved and is not modified.
3. Fix a change log that records, before/after, (i) meaning (entity, geometry_meaning, object_id), (ii) value, and (iii) unit.
4. Mark all derived results that depend on the changed item as targets for regeneration in the dependency graph.
5. Re-run the required Gate stacks and re-judge PASS/FAIL/INCONCLUSIVE for all affected results.
6. Seal the new version with a registry snapshot, manifest, and checksums.

In particular, promoting ℓ_rot to a required input, or modifying the meaning of D_anch by coupling it with ℓ_rot, is a change of the canonical-input structure itself and therefore requires versioning and full re-verification.

2.3 REALIZATION inputs

2.3.1 Definition of REALIZATION inputs

REALIZATION inputs are the set of items fixed to realize an internally described world (dimensionless or internal length/time units) into external units (length/time). REALIZATION inputs are included in realization_lock and do not change within the same lock_id. REALIZATION inputs are not “canonical inputs”; they are treated as “realization outputs” or “reference anchors used for realization.” Therefore, REALIZATION inputs must simultaneously lock (i) meaning (what length/what time), (ii) unit, (iii) numeric value, and (iv) procedural attribution (which reference channel and which verdict rule sealed it).

2.3.2 Internal coordinates and realization map (length/time conversion)

Define internal coordinates as follows.

• Internal length coordinate: x (dimensionless or internal unit), with base unit treated as “1”.
• Internal time coordinate: t (dimensionless or internal unit), with base unit treated as “1”.

The realization map is fixed as

where x is realized length (length dimension) and t is realized time (time dimension). Accordingly, internal velocity v and realized velocity v are related by

In this relation, a/Δ t is the fundamental scaling factor with dimension (length/time), and fixing this factor is the core of realization.

2.3.3 Meaning lock for a (realized length scale)

a is the realized primary length scale. The meaning of a is fixed as follows.

1. a is defined as the fundamental diameter of a volume particle (VP).
2. The geometric meaning of a is locked as a diameter and is not reinterpreted as a radius.
3. The dimension of a is locked as length (L), and the unit system is locked as SI.
4. The numerical value of a is locked in realization_lock as

   

If a radius is needed, introduce a separate derived symbol

rₐ is a derived quantity; it is not a device to alter the meaning of a.

2.3.4 Meaning lock for Δ t (realized time tick)

Δ t is the realized primary time tick. Its meaning is fixed as follows.

1. Δ t is defined as the scaling factor that converts one unit of internal time t into realized time t (Eq. (realization_map_xt)).
2. The dimension of Δ t is locked as time (T), and the unit system is locked as SI.
3. The numerical value of Δ t is locked in realization_lock as

   

Δ t is not identified with an algorithmic time step used for numerical stability. If an algorithmic step exists, it is locked as a protocol parameter in analysis_lock and kept distinct from Δ t. Δ t is used only as the fixed scaling factor of the realization map ((realization_map_xt)).

2.3.5 Meaning lock for c_ref (reference speed constant for realization)

c_ref is a reference speed constant used during realization. Its meaning is fixed as follows.

1. c_ref is defined as a constant of an external reference channel used to fix the realized speed unit a/Δ t.
2. c_ref is locked with dimension (L/T) and unit notation m/s.
3. c_ref is recorded in realization_lock together with both a “value” and a “reference-channel identifier.” Locking only a value without the channel/procedure is not allowed.
4. c_ref is not identified with an internally derived propagation indicator (e.g., a particular value of internal speed v). The internal propagation indicator is a derived result; c_ref is a realization reference. Their connection is made only via the realization scaling factor a/Δ t in Eq. (realization_map_v).

Therefore, if c_ref is adopted as a realization input, the realized speed scale is fixed as

This fixing is valid only when the meaning locks of a, Δ t, and c_ref all hold simultaneously.

2.3.6 Lock rules for REALIZATION inputs (nature of realized values)

REALIZATION inputs (a, Δ t, c_ref) are locked by the following rules.

1. Simultaneous meaning–unit–value lock: for all three items, (i) object binding, (ii) geometric meaning (diameter/radius, etc.), (iii) dimension and unit notation, and (iv) numerical value must be locked simultaneously.
2. SSOT: realized values exist only in a single location in realization_lock. The body refers only to item name and lock_id.
3. Procedural attribution: a, Δ t, and c_ref must carry which reference channel / which cross-consistency / which thresholds sealed them. This procedural information cross-references the Gate composition and protocol conventions in analysis_lock.
4. No reinterpretation: reinterpreting a as a radius, replacing Δ t by an algorithmic step, or retroactively identifying c_ref with an internal derived indicator is forbidden within the same version.

If any of the above rules is violated, the realization map ((realization_map_xt)) collapses; the corresponding artifact loses admissibility as a conclusion.

2.3.7 Change procedure for realized values (versioning and full re-judgment)

Changing realized values (a, Δ t, c_ref) is not allowed within the same version. Changes are performed only via versioning, under the following fixed procedure.

1. Specify what changes: identify whether the change is in a/Δ t/c_ref, and whether it changes (i) meaning, (ii) unit, (iii) value, and/or (iv) reference channel/procedure.
2. Create a new realization_lock: issue a new realization_lock_id. The previous realization_lock_id is preserved and not modified.
3. Fix a change_log: lock the before/after items (meaning/unit/value/channel identifier), the reason, and the list of affected derived quantities.
4. Update dependency graph: mark all derived quantities that depend on a or Δ t (length/time/velocity scaling factors, energy scale, mass scale, force scale, etc.) as regeneration targets.
5. Full re-derivation: regenerate all related derived artifacts from scratch (including intermediate artifacts) using the changed realized values.
6. Full re-judgment: re-run Gate stacks from scratch, including cross-consistency, lock integrity, reproducibility, and No-Tuning violations, and re-judge PASS/FAIL/INCONCLUSIVE.
7. Sealing: seal the new version by generating and freezing registry_snapshot, manifest, and checksums.

Conclusions prior to versioning belong to the previous realization_lock_id combination; conclusions after versioning belong to the new combination. Mixing results across different realization_lock_id values in one conclusion sentence is forbidden.

2.4 Preventing confusion between diameter/radius/cell geometry

2.4.1 Purpose

This subsection locks (i) standard definitions of diameter/radius/cell geometry, (ii) standard notation rules, (iii) allowed derived-conversion rules, and (iv) an immediate-FAIL policy for ambiguity/conflict detection, in order to structurally prevent a length symbol from being used interchangeably as a diameter, a radius, or a cell representative length (edge/diameter, etc.).

2.4.2 Standard definitions: radius and diameter

In this document, “radius” and “diameter” are fixed by the following definitions. Definitions are locked in the geometry_meaning field, and a single symbol cannot carry both meanings.

(A) radius

A radius is defined as the distance from a chosen center (or reference point) to a chosen boundary (or reference boundary surface). Radius symbols follow these conventions.

1. Use r in the symbol name: r₀, r_p, rₐ, etc.
2. Lock geometry_meaning as radius.
3. A radius is not defined via the conventional relation “half of a diameter.” It is defined directly together with the object definition; its relation to diameter is connected only via a separate derived definition.

(B) diameter

A diameter is defined as the distance between two opposite boundaries (or reference boundary surfaces) of the same object. Diameter symbols follow these conventions.

1. Use D in the symbol name: D_anch, Dₐ, etc.
2. Lock geometry_meaning as diameter.
3. A diameter is not defined via the conventional relation “twice a radius.” It is defined directly together with the object definition; its relation to radius is connected only via a separate derived definition.

(C) Radius–diameter linkage (derived definitions only)

The linkage between radius and diameter is permitted only as derived definitions as follows.

Equation (rd_relation) does not mean “converting symbol meaning” but “deriving a new symbol.” That is, if D is locked as a diameter in a section, then when a radius is needed one must introduce a new symbol r:=D/2 and use it; within that section, D must not be used as if it were a radius. Likewise, if r is locked as a radius, then when a diameter is needed one must introduce a new symbol D:=2r; within that section, r must not be used as if it were a diameter.

2.4.3 Standard definition: cell and cell geometry

In this document, a “cell” is the reference domain that bundles a VP set and is defined as an object. A cell must lock “which geometry it uses” together with the cell definition; a cell length/cell radius/cell diameter is unusable if cell geometry is not locked.

(A) Required fields of the cell object

The cell object OBJ-CELL must include the following mandatory fields.

1. cell_id: cell identifier.
2. cell_geometry: cell-geometry type.
3. cell_length_symbol: the symbol used as the cell representative length.
4. geometry_meaning: geometric meaning of the representative length (edge length, diameter, radius, etc.).
5. definition: definition of the cell and the representative length.
6. scope: applicable regime.

(B) Standard list of cell geometry types (enumeration)

Cell geometry type is locked as one of the following enumerated values.

1. CELL-CUBE: the cell is a cube, and the representative cell length is defined as an edge length.
2. CELL-SPHERE-VIS: the cell is used as a sphere for visualization or auxiliary definition, and the representative cell length is defined as either a diameter or a radius (exactly one is chosen and locked).
3. CELL-OTHER: if a geometry other than the above two is used, the geometry definition (boundary, representative length, measurement convention) must be fully specified and locked with additional fields.

(C) CELL-CUBE

For a cube cell, the representative length is defined as an edge length.

1. The representative-length symbol of a cube cell may be written as L_cell or D_anch, etc., but regardless of the spelling the geometry_meaning must be locked as edge.
2. To introduce a “radius” or “diameter” for a cube cell, it must be introduced only as a derived symbol. For example, to connect a cube diagonal or an equivalent visualization sphere, the connection rule must be fixed either in analysis_lock (procedure) or canon_lock (definition), and the derived symbol must be created separately.

Interpreting a cube cell representative length as a radius or a diameter is forbidden.

(D) CELL-SPHERE-VIS

For a spherical cell, the representative length is defined as exactly one of diameter or radius; the two are not used simultaneously.

1. If the representative length is defined as a diameter: use symbol D_cell and lock geometry_meaning=diameter.
2. If the representative length is defined as a radius: use symbol r_cell and lock geometry_meaning=radius.
3. If both diameter and radius are needed, introduce a separate symbol connected by the derived definition (Eq. (rd_relation)).

2.4.4 Confusion-prevention rules (lock rules)

This subsection locks confusion-prevention rules as follows. Violations are judged immediately as FAIL.

(R1) Mandatory meaning lock

Before a length symbol is used, it must simultaneously carry the following three fields.

1. object_id (which object's length)
2. geometry_meaning (diameter/radius/edge/gap/thickness, etc.)
3. dimension (length dimension)

If any of the three is missing, the symbol is unusable and any equation/table/figure/log that contains it is judged immediately as FAIL.

(R2) Single-meaning principle for the same symbol (no overloading)

The same symbol (same spelling) may carry only a single triple (object_id,geometry_meaning,dimension) across the whole document. Once the same spelling appears with a different triple, the conflict is not repaired by interpretation and is immediately FAIL.

(R3) Explicit derived conversion principle (no implicit conversion)

Diameterleftrightarrowradius conversion, cubeleftrightarrowsphere mapping, and representative-lengthleftrightarrowderived-length conversion are permitted only through explicit derived symbols.

1. “Using D as if it were r” or “using r as if it were D” is forbidden.
2. “Changing the cell representative length into diameter/radius/edge depending on context” is forbidden.
3. If a conversion is needed, a new symbol must be introduced, and the new symbol must be registered in the registry together with the conversion equation.

(R4) No cross-mixing of diameter/radius/cell geometry

Within the same section, the following mixes are forbidden.

1. After locking a cell representative length as edge, using the same symbol as diameter or radius.
2. In a cell locked as CELL-CUBE, assigning a CELL-SPHERE-VIS diameter/radius definition to the same symbol without an explicit derived definition.
3. Treating different cell geometry types as if they were the “same cell” and composing them within one derivation chain.

2.4.5 Immediate FAIL policy upon confusion detection (Gate verdict)

Detection of confusion (ambiguity/conflict) is performed by Gate; upon detection the verdict is immediately FAIL. The verdict is independent of interpretation and depends only on the integrity of definitions/locks.

(A) Immediate FAIL conditions

If any of the following holds, the verdict is immediately FAIL.

1. RD-AMB (radius/diameter ambiguity): the registry does not determine whether a symbol is radius or diameter (missing or multiple geometry_meaning).
2. RD-CONFLICT (radius/diameter conflict): the same symbol is used as radius in one place and as diameter in another.
3. CELL-AMB (cell-geometry ambiguity): the cell geometry type (CELL-CUBE/CELL-SPHERE-VIS/CELL-OTHER) is not locked.
4. CELL-CONFLICT (cell-geometry conflict): the same cell representative-length symbol is used as a representative length under different cell geometry types.
5. IMPLICIT-CONV (implicit conversion): Dleftrightarrow r conversion or cubeleftrightarrowsphere mapping is performed implicitly in an equation/table/figure/log without a derived symbol.
6. DIM-MISMATCH (dimension mismatch): a symbol locked as length is used with a different dimension, or unit notation changes without an explicit conversion step.

(B) FAIL labels (standard labels)

The FAIL labels for confusion verdicts are fixed as follows (multiple labels are allowed).

(C) Propagation rule for immediate FAIL

If FAIL occurs, the following immediately hold.

1. The artifact containing the failing equation/table/figure/log loses admissibility as a conclusion.
2. In the dependency graph, all derived artifacts that use the failing artifact as input lose admissibility in a cascading manner.
3. FAIL is not resolved by “editing text”; resolution exists only via versioning (registry modification followed by full re-derivation and re-judgment).

2.4.6 The only path to resolve confusion (versioning)

The procedure for resolving confusion is fixed as follows.

1. Identify the location of the conflicting items (symbol meaning / cell geometry / unit / derived definition) in the registry.
2. Issue a new lock_id for the relevant registry (canon_lock or analysis_lock or realization_lock).
3. Modify items so as to remove the conflict (symbol splitting, enforcing a single geometry_meaning, enforcing a single cell geometry type, adding derived symbols, etc.).
4. Regenerate all related derivations under the modified lock_id combination and re-judge all relevant Gates.
5. Seal the new version with a registry snapshot, manifest, and checksums.

Interpretation or sentence editing within the same version is not accepted as confusion resolution. Confusion is a definition/lock problem; without changing definitions/locks, confusion remains.