Semantic layer mapping (1:1) and the closure system

Semantic layer mapping: No template, no map — meaning transfers only on the registered form. Five duties make a closure usable; missing one makes it noise. Layer: which of L0/L1/L2/L3 it belongs. This chapter fixes, as a single system, the document-wide conventions of “semantic layer mapping (1:1)” and “closure”.

No template, no map — meaning transfers only on the registered form. Five duties make a closure usable; missing one makes it noise. Layer: which of L0/L1/L2/L3 it belongs.

Chapter declaration: the role of semantic layers and closures

This chapter fixes, as a single system, the document-wide conventions of “semantic layer mapping (1:1)” and “closure”. A semantic layer mapping is a convention that separates “what each symbol means” into explicit layers and relates the layers via 1:1 correspondence, while a closure is a convention that explicitly seals choices (decision rules) that are not determined by axioms and definitions alone. These conventions are a prerequisite for all subsequent derivations (stationary constants, events, unit realizations, mass, force, and extended regimes). Any derivation or verification that violates this chapter cannot claim the status of a valid conclusion.

Global principles for 1:1 semantic mapping

Semantic layer mapping is fixed by the following principles.

1. 1 symbol–1 meaning–1 unit: the same symbol has exactly one meaning (object attribution + geometric meaning + admissible operation scope) and exactly one unit dimension across the entire document.
2. Layer separation: a meaning defined in the “definition layer” does not automatically convert when it is used in the “observation layer”. Any conversion must be stated explicitly as a map.
3. 1:1 correspondence: an item in one layer connects to an item in another layer only via 1:1 correspondence. If a 1:N or N:1 relation is needed, it must be decomposed into a new intermediate object and/or a new explicit conversion rule.
4. Locking of maps: mapping rules must be locked in analysis_lock or canon_lock; they cannot be swapped after inspecting results.

Therefore, “meaning jumps” (reinterpreting a symbol without a definition), “unit jumps” (performing a dimensional conversion implicitly), and “object jumps” (retroactively reassigning an item to a different object) are prohibited.

The standard 4-layer architecture

In this document, the semantic layers are fixed to the following four layers. Each item is sealed by a registry entry, and inter-layer movement is permitted only via explicit maps.

1. L0 (primitive layer): primitive objects fixed by axioms/definitions—VP, domain, contact, adjacency, cell, event, etc.
2. L1 (structural/combinatorial layer): discrete structural items—contact graph, backbone, throat, path, integer structures (core/shell), cancellation conventions, etc.
3. L2 (aggregated/observable layer): aggregated observables or computables—counts, distributions, indicators, thresholds, event rates, switch observables, cross-consistency scores, etc.
4. L3 (realization/numeric layer): realized numeric results with units attached (length/time/mass/force, etc.) and the standard reporting format.

Items in L0–L3 are not mixed, and L0 definitions are never modified retroactively by L2 or L3 outputs.

4.4 Standard template for 1:1 semantic mapping

A semantic layer map is a registry entry that must follow the template below. This template must be included in analysis_lock; if it is missing, the corresponding map cannot be used.

semantic_maps:
  - map_id: MAP-L1toL2-THROAT-001
    from_layer: L1
    to_layer: L2
    from_item:
      object_id: OBJ-THROAT
      symbol: delta_gap
      meaning: (gap/thickness/critical throat, single meaning)
      unit_dimension: L (or 1)
    to_item:
      quantity_id: Q-THROAT-DELTAEFF
      symbol: delta_eff
      meaning: (definition of a representative aggregated throat value)
      unit_dimension: L (or 1)
    rule:
      definition: (aggregation rule: mean/median/min-cut-based, etc.)
      algorithm_id: ALG-THROAT-EST-001
      parameters_locked_by: analysis_lock_id
    scope: (regime identifier)
    failure_modes:
      - FM-SCOPE
      - FM-NONUNIQUE
      - FM-NUMERIC
    required_gates:
      - G-SYM
      - G-LOCK
      - G-REG
      - (optional) G-NUM

In this template, failure_modes and required_gates are mandatory fields. A map does not consist of a “rule” alone; its failure modes and verification conditions must also be locked.

4.5 Definition of closure

A closure is a device that seals, as an explicit rule, a choice that is not determined by axioms/definitions alone. A closure has the following properties.

1. Explicit declaration of the choice: a closure states, in sentences and equations, “what is being chosen”. If no choice is needed, no closure should be introduced.
2. Declaration of input/output: a closure declares the types of its inputs and outputs (layer, unit dimension, object attribution). If the I/O types are ambiguous, the closure cannot be used.
3. Scope (regime): a closure can be valid only in a specific regime; that regime must be locked.
4. Built-in failure modes: a closure includes a list of failure modes (undefinedness, non-uniqueness, numerical instability, regime violation, cross-consistency failure, etc.).
5. Gate required: a closure cannot produce conclusions without a Gate judgement. Any conclusion involving a closure requires PASS of the Gate stack assigned to that closure.

4.6 Global principles for the closure DAG (dependency graph)

Closures may depend on other closures, but the dependency must be a DAG (a directed acyclic graph). The closure DAG is fixed by the following principles.

1. One-way: closures have a topologically sortable direction; an output of a later closure cannot retroactively modify an input of an earlier closure.
2. No cycles: cyclic dependencies in which a closure's output determines its own input (directly or indirectly) are prohibited.
3. SSOT: closure definitions exist only at a single location in analysis_lock. The main text never redefines closures.
4. Conclusion attribution: every conclusion involving closures carries the list of used closures (closure_ids) and the DAG version (analysis_lock_id).

The purpose of the closure DAG is to prevent “necessary choices” from being hidden, and to make the impact of each choice traceable to conclusions.

4.7 Standard taxonomy of failure modes

Failure modes are standard labels that record “when this closure/map collapses”. Failure modes are not post-hoc remarks; they are pre-registered items, fixed by the following classification.

1. FM-SYM: symbol/meaning/unit conflict or overloading.
2. FM-SCOPE: regime/scope violation (used outside the declared scope).
3. FM-NONUNIQUE: non-unique solution (multiple solutions without a selection rule).
4. FM-NODEF: undefinedness (missing inputs, or the defining equation does not close).
5. FM-NUMERIC: numerical instability (non-convergence, sensitivity blow-up, iteration inconsistency).
6. FM-XCROSS: cross-consistency failure (mismatch across independent channels).
7. FM-REP: reproducibility failure (cannot obtain the same judgement upon re-run).
8. FM-NT: detection of a No-Tuning violation (post-hoc adjustment).

A failure mode does not mean “the result is unpleasant”; it means “the definition/procedure/judgement does not hold”. When a failure mode occurs, the corresponding conclusion is judged FAIL or INCONCLUSIVE and loses the status of a valid conclusion.

4.8 Why verification is required (closure/map conclusion criteria)

Since semantic maps and closures contain choices, their legitimacy is not granted by external authority but only by passing pre-registered Gates. Therefore, the following become global rules.

1. A closure/map without Gates cannot generate a valid conclusion.
2. A closure/map without defined failure modes cannot be used.
3. A conclusion that does not record the closure DAG version loses its basis and cannot claim the status of a valid conclusion.

The global principles fixed in this chapter—“1:1 semantic mapping”, “closure DAG”, “failure modes”, and “Gate required”—are not re-explained in later chapters. Each later section refers only to the relevant items via its final LOCK/Gate link.

4.1 Meaning-layer mapping: pressure/flux/deficit/charge

4.1.1 Common premise: layers (L0–L3) and the minimal operational record format

All of pressure/flux/deficit/charge defined in this section follow the layered semantic architecture below.

1. L0 (primitive): VP, domain (cell), contact/adjacency, local update (event), etc.
2. L1 (structure): contact graph, boundary set, cut surface, throat/path, core/shell structure, etc.
3. L2 (aggregated observables): counts/indices/rates/slopes (differential forms), including intermediate unitless quantities.
4. L3 (realized numbers): final numbers with physical units attached via length a, time Δ t, energy unit U_lat, etc.

Each quantity is defined only by a 1:1 mapping L1→L2→L3; any transformation that retroactively rewrites the meaning of another layer is prohibited.

In addition, the common operational record (log) used in this section must contain at least the following fields. This record schema is locked in analysis_lock; if any field is missing, the corresponding quantity is judged non-computable.

1. Cell domain: lock D_(square) and the representative length D_anch (cell geometry=CELL-CUBE, meaning of D_anch=edge).
2. Contact graph: lock G_c=(V,E_c) and the contact predicate C(i,j)∈0,1.
3. Event log: lock the event set E, event index e∈E, event time (tick) n(e)∈Z, pre/post configuration identifiers, and the participating VP subset V(e)⊆V.
4. Definition of cut surface/boundary: lock the geometric definition of boundary sets ∂D^(±) or a cut surface Σ (plane/curved surface, orientation normal included).

4.1.2 Standard symbols (type/dimension/unit) and the 1:1 operational definition table

The standard entries of pressure/flux/deficit/charge are locked by the table below. Each row represents one item; an item has meaning only as the tuple (symbol, type, dimension, unit, operational procedure).

The “summary” in the table is not a shortened definition; it lists only the names of the procedures. The complete procedures are fixed step-by-step in the subsections below.

4.1.3 1:1 definition of pressure (boundary compression → cost → pressure)

4.1.3.1 L1 input (structure): boundary and compression operator

In the canonical cell domain D_(square), lock the compression direction as a unit normal n_P. For a cube cell, lock one of the following choices in analysis_lock.

For a compression amount ε>0, define the “compressed domain” by

The domain volume reduction is

Here A_(square) is the cell face area perpendicular to the compression direction; it is usable only when the cell geometry (cube) and the meaning of D_anch are locked.

Define the compression operator C_ε as follows. C_ε includes the boundary displacement and the induced mapping of configurations (coordinate transform).

However, there is no guarantee that Ω_i^((ε)) satisfies the non-penetration / full-packing / local rules after applying C_ε. Therefore the compression operator must always be paired with relaxation (4.1.3.2).

4.1.3.2 L1→L2 map: minimal relaxation cost W(ε)

Define the relaxation operator (composition of local updates) R by

where Ω_i^(ε,rel) must be an admissible configuration that satisfies non-penetration, full packing, and the local rules. Relaxation consists only of compositions of local updates (the local rule in 3.1). The relaxation rules (update selection, termination condition, failure condition) must be locked in analysis_lock.

The relaxation cost is defined only in pre-registered cost units. A cost unit consists of the two components below.

1. Cost unit per one local update: lock as U_lat (energy unit).
2. Cost coefficient: lock a weight ω_upd per local-update type in analysis_lock (the default value may be locked as 1).

Define the minimal relaxation cost for compression ε by

where the minimization is performed under the constraint “return to an admissible configuration”. The minimization rule (search method, deduplication, stopping criterion) must be locked in analysis_lock. If relaxation fails and cannot return to an admissible configuration, then W(ε) is undefined and is recorded as a failure mode.

4.1.3.3 L2→L3 map: definition of pressure P

Pressure is defined by the limit

For a cube cell, using (deltaV_cube) gives

The dimension of P is locked as [E L⁻³], and the unit is locked as U_lat/a³. Here a is the realized length scale and U_lat is the realized energy unit; this unit system must be locked in realization_lock.

4.1.3.4 Failure modes for the pressure definition (undefinedness conditions)

The conditions under which the pressure definition fails (failure modes) are fixed as follows.

1. FM-SYM: the meaning of D_anch (cell edge) or the cell geometry (cube) is not locked.
2. FM-NODEF: relaxation cannot return to an admissible configuration, so W(ε) is undefined.
3. FM-NONUNIQUE: the minimization rule is not locked, so the word “minimum” is not mechanically defined.
4. FM-NUMERIC: W(ε)/ε does not converge stably over a sufficiently small ε range (the convergence criterion itself is locked by Gate).

4.1.4 1:1 definition of flux (cut surface Σ → crossing sign → flux)

4.1.4.1 L1 input (structure): cut surface, orientation, measurement window

Inside the domain D_(square), define an oriented cut surface Σ. The cut surface simultaneously locks the following three elements.

1. geometric definition of the cut surface (plane/curved-surface equation or mesh),
2. the unit normal n_Σ (orientation lock),
3. the area A_Σ (area-computation convention lock).

Define the measurement time window as the tick interval [n₁,n₂), and lock the realized duration by

where Δ t must be locked in realization_lock.

4.1.4.2 L1→L2 map: event crossing sign s_Σ(e)

For the cut surface Σ, define the “side indicator” function σ_Σ(i)∈-1,+1.

The representative-point convention (e.g., center of the occupied region, a selected marker point, etc.) must be locked in analysis_lock.

From the change of σ_Σ between the pre/post configurations of an event e, define the event crossing sign by

By definition s_Σ(e)∈Z, and if an event does not cross the cut surface then s_Σ(e)=0. If the event log does not contain pre/post configurations, then s_Σ(e) is undefined.

In the measurement window [n₁,n₂), define the net crossing count by

Δ N_Σ is a pure L2 aggregate (unitless).

4.1.4.3 L2→L3 map: flux (token flux) J

Flux is defined as a flow of “tokens”. The token size is locked as the VP unit volume a³. Therefore, define the flux by

In this definition, a is the realized length scale, Δ T is defined by (deltaT), and A_Σ is the realized area of the cut surface. The dimension of J is locked as [L T⁻¹], because token volume (length³) divided by area (length²) and time yields a length/time scale.

If a direction-aware flux vector is needed, define

If n_Σ is not locked, then J is undefined.

4.1.4.4 Failure modes for the flux definition (undefinedness conditions)

The conditions under which the flux definition fails (failure modes) are fixed as follows.

1. FM-NODEF: the event log lacks pre/post configurations, or V(e) is missing so that s_Σ(e) is undefined.
2. FM-SYM: the orientation of Σ or the area A_Σ is not locked.
3. FM-SCOPE: the cut surface is not defined consistently with the domain D_(square) (e.g., defined outside the domain or mixing cell geometries).
4. FM-NUMERIC: the representative-point convention is not locked, or the representative-point choice is unstable for the same event, so s_Σ(e) is not reproducible.

4.1.5 1:1 definition of deficit (contact deficit: an operational measure of structural deficit)

4.1.5.1 L1 input (structure): contact degree z_i

In the contact graph G_c=(V,E_c), define the contact degree (graph degree) of each VP i by

If the contact predicate C(i,j) is not locked, then z_i is undefined.

4.1.5.2 L1→L2 map: reference degree z_ref and deficit d_i

Deficit is defined as “shortfall relative to a reference contact level”. The reference degree z_ref is locked in analysis_lock by the rules below.

1. z_ref∈Z_(≥ 0).
2. z_ref may depend on the contact-predicate convention, dimension (2D/3D), and boundary-handling convention; such dependencies are locked as scope.
3. The choice of z_ref must not be changed by post-hoc correction; changes are allowed only by versioning.

Define the deficit of each VP by

Define the cell-level deficit by

D_def is a dimensionless L2 deficit indicator.

4.1.5.3 L2→L3 map: deficit density (optional, if needed)

If deficit is used as a spatial density, fix the following derived definition.

The dimension of ρ_def is locked as [L⁻³]. V_(square) is usable only when the cell geometry (cube) and the meaning of D_anch are locked. Deficit density is an optional derived quantity; whether it is used must be locked in analysis_lock.

4.1.5.4 Failure modes for the deficit definition (undefinedness conditions)

The conditions under which the deficit definition fails (failure modes) are fixed as follows.

1. FM-SYM: the contact-predicate convention is not locked, so z_i is undefined.
2. FM-SCOPE: the scope of z_ref (dimension/boundary handling/protocol) is not locked, so the reference collapses.
3. FM-NONUNIQUE: z_ref moves within the same version or multiple values are mixed.
4. FM-NUMERIC: the contact-graph construction convention is not locked, so z_i is not reproducible.

4.1.6 1:1 definition of charge (shell cancellation → survival vector → sign)

4.1.6.1 L1 input (structure): shell vector set and cancellation convention

Charge is defined as “the sign of the residual directionality left by the shell structure”. For this, define the shell vector set by

The coordinate system, scale (internal unit), and the vector-generation convention (what structural quantity is encoded as a vector) must be locked in analysis_lock.

The cancellation convention simultaneously locks the following.

1. the rule that assigns 6 of the 7 vectors as cancellation terms (e.g., pairwise/quartet grouping) and its fixed ordering,
2. the cancellation criterion (the condition under which two vectors cancel) (inner product/angle/component convention, etc.),
3. the definition of the remaining 1 vector (or remaining sum), i.e., the survival vector.

If the cancellation convention is not locked, charge is undefined.

4.1.6.2 L1→L2 map: survival vector V and sign indicator q

Define the survival vector by

where (survival_vector) is used only as an expression equivalent to “the residual after cancellation terms cancel out according to the locked convention”. If the cancellation terms are constructed explicitly in the actual computation, that construction must be locked in analysis_lock.

Lock the sign-determination axis (charge axis) n_Q by

n_Q must not be chosen after seeing the result; the selection rule must be locked in analysis_lock.

Define the sign indicator by

Here q=0 means “sign-indeterminate or neutral”. Whether q=0 is admissible as a conclusion (allowed/forbidden) is locked by PASS.rules in analysis_lock.

4.1.6.3 L2→L3 map: charge Q and charge density

Lock the charge unit q₀ in canon_lock as

Define charge by

If a spatial charge density is needed, use the derived definition

The dimension of ρ_Q is locked as [Q L⁻³].

4.1.6.4 Failure modes for the charge definition (undefinedness conditions)

The conditions under which the charge definition fails (failure modes) are fixed as follows.

1. FM-STR: the shell-vector generation convention or the cancellation convention is not locked (structure is unspecified).
2. FM-SYM: n_Q or the coordinate-system definition is not locked (direction meaning is unspecified).
3. FM-NONUNIQUE: the cancellation convention admits multiple solutions, so V is non-unique.
4. FM-SCOPE: the shell(7) structure is not defined in the declared regime, yet charge is invoked.

4.2 Closure types, stacks, and DAG rules

4.2.1 Position and purpose of a closure

A closure is a device that seals, as an explicit rule, a choice that is not determined by axioms ([A]) and definitions ([D]) alone. A closure is not an “extra hypothesis”; it is documentation of a selection rule. The existence of closures is fixed by the two reasons below.

1. Resolving indeterminacy: even with the same inputs, the output may be non-unique or multi-valued; a rule is needed to select which solution will be used.
2. Sealing procedures: the output can vary with the algorithm/estimator/boundary handling/normalization; without locking the procedure, the same conclusion cannot be claimed.

Therefore a closure must always include (i) input/output types, (ii) selection rule (assumptions), (iii) scope (regime), (iv) failure modes, and (v) Gate stack. If any of the five elements is missing, the closure is unusable.

4.2.2 Closure types (standard taxonomy)

In this document, closures are classified by “what is being closed” into the standard types below. The type is locked in analysis_lock, and closure IDs follow a namespace that includes the type.

(CL-S) Semantic-map Closure

A closure used when a choice is required in an L1→L2 or L2→L3 map. Examples include choosing the representative value of a throat (mean vs minimum-cut), and fixing how an event aggregation window is defined.

(CL-G) Graph/Path Closure

A closure that seals graph-based choices such as contact-graph construction, critical-throat definition, path selection, backbone selection, and minimum-cut computation. Examples include boundary-node definition, weight assignment, and equivalence rules.

(CL-R) Regime Closure

A closure that seals the scope of applicability: which rules are valid under which conditions (jamming/non-jamming, rotation-driven/non-driven, linear/nonlinear, etc.). Since changing regime conditions can change the conclusion, regime closures are premises of all conclusions.

(CL-N) Numerical Closure

A closure that seals numerical procedures: convergence, termination criteria, sensitivity policies, iteration limits, tolerances, and step policies. This closure exists not to “obtain” a result but to ensure the result is reproducible.

(CL-X) Cross-consistency Closure

A closure that seals cross-consistency rules for judging whether independently constructed channels/baselines/input combinations are consistent with the same conclusion. Cross-consistency closures include choices of thresholds, comparison quantities, and verdict methods.

(CL-P) Protocol Closure

A closure that seals execution conventions: input file formats, log schema, seed policy, environment fixation, etc. Protocol closures are premises of the reproducibility Gate and of snapshot sealing.

4.2.3 Closure ID rules (identifier and namespace)

Each closure is identified by a closure_id. The closure_id format is fixed as

where

• TYPE is one of S,G,R,N,X,P,
• TOPIC is the topic handled by the closure (e.g., THROAT, BACKBONE, EVENTWIN, ANCHOR, RCROSS),
• NNN is a serial number starting from 001.

Multiple closures may coexist for the same TYPE and TOPIC, but within a single conclusion (claim_id) the simultaneously adopted closure for the same topic is restricted to one. If multiple are needed, the topic must be decomposed into distinct topics.

4.2.4 I/O type rules for closures (layer/dimension/object attribution)

A closure must state the types of its inputs and outputs. A type consists of the following four elements.

1. Layer: which of L0/L1/L2/L3 it belongs to.
2. Object attribution (object_id): which object the quantity belongs to (e.g., OBJ-THROAT, OBJ-PATH, OBJ-EVENT).
3. Symbol: the symbol used in the main text (locked to a single meaning).
4. Dimension/unit: dimensionless (1) or physical dimensions (length/time/mass/energy/force, etc.) and unit system (SI/internal).

If the I/O types of a closure are ambiguous, or the same symbol appears with different types, then this is a definition conflict and the closure is unusable.

4.2.5 The “assumptions” field of a closure (explicit selection rules)

The “assumptions” contained in a closure are fixed by the rules below.

1. Assumptions exist only in the form of selection rules. They must record, in mechanically readable sentences, “what was chosen”.
2. Assumptions must not introduce new ontology (e.g., a new continuous field, a new global objective function, axiomatizing a new probability distribution, etc. are outside the scope of closures).
3. Assumptions must have scope (scope). Assumptions without scope are prohibited because they can be misread as global assumptions.
4. Assumptions must not be changed after seeing results. Changes are allowed only by versioning (new analysis_lock_id).

4.2.6 Gate stack (mandatory) and linkage to PASS/FAIL judgements

Every closure has its required Gate stack. The purpose of the Gate stack is to make the choices embedded in the closure necessary conditions for a conclusion to obtain admissible status. The Gate stack is fixed by the following rules.

1. Mandatory base Gates: every closure requires at least G-SYM, G-LOCK, G-REG, and G-NT.
2. Type-dependent additional Gates: depending on the closure type, add the following Gates as needed.
   • CL-S: (if needed) G-NUM
   • CL-G: (if needed) G-STR, G-NUM
   • CL-R: (if needed) strengthened G-REG and/or G-STR
   • CL-N: G-NUM
   • CL-X: G-RCROSS, (if needed) G-NUM
   • CL-P: G-REP
3. Judgement precedence: if any required Gate yields FAIL or INCONCLUSIVE, then any conclusion using the closure cannot obtain conclusion status.
4. Failure-mode labeling: the causes of FAIL/INCONCLUSIVE are decomposed and recorded as failure-mode labels (FM-*) or No-Tuning violation labels (FAIL-NT-*).

4.2.7 Closure DAG rules (no cyclic dependency)

Closures may depend on each other, but the dependency must be a DAG (a directed acyclic graph). The closure DAG rules are fixed as follows.

4.2.7.1 Nodes and edges

Let the closure set be C and denote each closure by c∈C. Define the closure DAG by

where (c_i,c_j)∈E_CL means “closure c_j depends on the output of closure c_i.”

4.2.7.2 Acyclic condition (no cycles)

The DAG condition is fixed as

That is, if a path of the form c₁→ c₂→⋯→ cₖ→ c₁ exists, then that set of closures is unusable.

4.2.7.3 Typical forbidden patterns of cycles

Cycles occur in the representative patterns below. These patterns are fixed as forbidden rules.

1. Threshold–output cycle: a closure output determines a Gate threshold, and that threshold in turn changes the solution selection of the same closure.
2. Channel–consistency cycle: in a cross-consistency closure, the selected channels are re-selected/excluded based on the output.
3. Regime–selection cycle: a regime closure reclassifies the regime using an output indicator, and that reclassification changes closure selection.
4. Post-hoc selection cycle: selecting a “good” solution among multiple candidates using a rule that depends on the output value (a form of post-hoc tuning).

If such a pattern appears, the closure definition is rejected in analysis_lock, and related conclusions are automatically judged FAIL or INCONCLUSIVE.

4.2.7.4 Topological sorting and execution order

If the DAG condition holds, closures have a topologically sortable order. Denote the execution precedence by prec; then

Derivations and Gate executions must follow the prec order. If the order is violated, required inputs do not exist and the result is judged INCONCLUSIVE.

4.2.8 Closure template (standard registry form)

Below is the standard template for recording a closure in the registry. The key structure and fields are fixed; if any required field is missing, the closure is unusable.

closures:
  - closure_id: CL-G-THROAT-001
    type: CL-G
    topic: THROAT
    version: (local version within analysis_lock_id)
    scope: (regime identifier or predicate)
    inputs:
      - layer: L1
        object_id: OBJ-THROAT
        symbol: delta_gap
        dimension: L
        unit_system: internal
    outputs:
      - layer: L2
        quantity_id: Q-THROAT-DELTAEFF
        symbol: delta_eff
        dimension: L
        unit_system: internal
    assumptions:
      - "Define the critical throat on the contact graph via a minimum-cut rule"
      - "The weight convention follows W_THROAT"
      - "Fix the representative value to the minimum-cut representative value (not the median)"
    algorithm:
      algorithm_id: ALG-THROAT-EST-001
      parameters_locked_by: analysis_lock_id
    dag:
      depends_on: [CL-R-REGIME-001, CL-P-PROTO-001]
    failure_modes:
      - FM-SYM
      - FM-SCOPE
      - FM-NONUNIQUE
      - FM-NUMERIC
    required_gates:
      - G-SYM
      - G-LOCK
      - G-REG
      - G-STR
      - G-NUM
      - G-NT
    pass_rules_hook:
      claim_types_allowed_on_pass: [CT-DER-FORM, CT-DER-NUM, CT-LIM]
      claim_types_forbidden_on_fail: [CT-DER-NUM, CT-XCROSS, CT-REP]

In this template, dag.depends_on contains the edge information of the closure DAG, and failure_modes and required_gates are mandatory fields. pass_rules_hook is a declaration connected to PASS.rules, linking “which sentences are allowed when which Gates pass” at the closure level.

4.2.9 Closure stacks and claim attribution

A single conclusion (claim_id) uses one or more closures. This is called a closure stack. The closure stack is fixed by the rules below.

1. A closure stack has an order. The order is determined by topological sorting of the closure DAG.
2. A conclusion must include the closure_ids list. Without it, the conclusion loses its basis and cannot claim conclusion status.
3. If any closure in the stack yields FAIL/INCONCLUSIVE in Gate, then the conclusion cannot obtain conclusion status.
4. Mixing closure stacks from different analysis_lock_id to form one conclusion is prohibited.

4.3 Regime map (scope of applicability)

4.3.1 Definition of a regime

A regime is a coordinate description of “under which conditions which definitions/closures/judgements are valid”. A regime is not expressed as a single sentence (e.g., “rigid regime”); it must be defined as a tuple composed of the values of regime coordinate axes. Fix the regime in the form

Each component is a regime-axis value defined in 4.3.2, and the axes themselves are locked in analysis_lock.

4.3.2 Regime coordinate axes (standard coordinate system)

This section fixes the regime coordinate system to the 9 axes below. Each axis is defined as an enumeration or an operational predicate (indicator function / thresholded index); it is not replaced by “interpretation”.

(A) Dimension axis R_dim

The dimension axis indicates the dimension in which the domain/contact graph/cut surface definitions are performed.

The dimension is locked by object definitions in canon_lock and protocols in analysis_lock, and must not be mixed within one output.

(B) Cell-geometry axis R_cell

The cell-geometry axis indicates the canonical geometry type of the Anchor Cell.

In the canonical regime, only CELL-CUBE is allowed. CELL-SPHERE-VIS is a visualization transform, not a regime-axis value. Visualization transforms are locked only by vis_mode in analysis_lock and do not replace the canonical regime.

(C) Drive axis R_drive

The drive axis indicates which driving condition is included in configuration updates (composition of local updates).

(D) Spanning axis Rₛpan

The spanning axis is defined as an indicator of whether the contact graph connects opposite boundary sets of the domain.

where χ_span(mathfrakJ)∈0,1 is the spanning indicator defined in 3.2. If boundary sets and boundary-node definitions are not locked, then R_span is undefined and the regime declaration itself does not hold.

(E) Bottleneck axis R_(κ)

The bottleneck axis is defined as a binning of the minimum-cut size (or an equivalent bottleneck index).

Fix R_(κ) by the mapping rule

The algorithm used to compute κ_(min) (exact/approximate, weighted/unweighted, boundary handling) must be locked in analysis_lock. If the algorithm is not locked, then R_(κ) is undefined.

(F) Scale-window axis Rₛcale

The scale-window axis indicates “under which internal scale range the output was aggregated/evaluated”. Lock the scale window as a bin of a unitless internal index s.

Here s is a single internal index locked in analysis_lock (e.g., a graph-distance-based length, path-length-based length, lattice-index-based length). The bin thresholds

are locked as thresholds in analysis_lock. Fix the scale window by

Scale-window classification must not be changed after seeing results.

(G) Boundary-condition axis R_bc

The boundary-condition axis indicates the boundary-handling type of the domain.

(H) Initial-condition axis R_init

The initial-condition axis classifies the initial configuration (contact graph/deficit/defect distribution, etc.).

(I) Observation/aggregation axis Rₒbs

The observation/aggregation axis indicates the conventions for event logs and aggregation windows.

4.3.3 Regime IDs and the standard format for regime declarations

A regime is called by a string identifier regime_id. A regime_id is valid only when the values in (regime_tuple) are fixed in the registry. Fix the standard registry template as follows.

regimes:
  - regime_id: R-BASE-001
    coords:
      dim: DIM-3
      cell: CELL-CUBE
      drive: DRV-NONE
      span: SPAN-1
      kappa: KAPPA-GE2
      scale: SCALE-LONG
      bc: BC-CLOSED
      init: INIT-RELAXED
      obs: OBS-EVENT
    allowed_closure_stacks:
      - stack_id: CS-BASE-CORE-001
        closures: [ ... ]
    forbidden_extrapolations:
      - "drive: DRV-ROT"
      - "dim: DIM-2"

If coords is missing or any axis value does not match the registry enumeration, the regime declaration is invalid and the output is judged INCONCLUSIVE.

4.3.4 Allowed closure stacks (regime-wise allow-lists)

A regime carries an allow-list of “allowed closure stacks”. An allowed closure stack includes (i) the list of usable closures, (ii) stack order (topological sorting of the closure DAG), and (iii) additional Gate requirements specific to the regime. Fix the allowed closure stacks by the rules below.

1. Every derivation that generates conclusions under the same regime_id must select and use one of the allowed closure stacks of that regime.
2. Using a closure that is not in the allow-list yields immediate FAIL (regime violation).
3. An allowed stack must satisfy the closure DAG; a stack violating the DAG cannot be registered.
4. Changes of allowed stacks are permitted only by versioning of analysis_lock.

4.3.4.1 Example allowed stack for the base regime (canonical chain)

A minimal allowed stack for the canonical chain (canonical→structure→event→realization→derived) is fixed in the following form (item names are examples; actual use is by closure_id only).

Each closure's I/O types, failure modes, and required Gates follow the closure-template conventions in 4.2. The stack means the following.

• First the regime axes are locked (CL-R-REGIME-001),
• the protocol/logs are sealed (CL-P-PROTO-001),
• the contact graph and boundary definitions are fixed (CL-G-CONTACT-001, CL-G-BOUNDARY-001),
• the rigid backbone (or bottleneck index) is fixed by a selection rule (CL-G-BACKBONE-001),
• the event aggregation map is fixed (CL-S-EVENTMAP-001),
• numerical convergence/stability conventions are fixed (CL-N-CONV-001),
• if realization or cross-consistency is required, a cross-consistency closure is fixed (CL-X-RCROSS-001).

4.3.4.2 Example allowed stack for a rotation-driven regime (extended)

In a rotation-driven regime (DRV-ROT), the following closures are added to (closure_stack_base). A conclusion that does not include the added closures cannot obtain admissible status under a rotation-driven regime.

Here CL-G-ANISO-AXIS-001 is a closure that locks the selection convention of the anisotropy axis / directional distribution, and CL-S-ANISO-MAP-001 locks the 1:1 maps for direction-dependent observables. In a rotation-driven regime, whether ℓ_rot is a reference value (CANON-REF) or a promoted value (CANON-PRIMARY) changes the input items and failure modes of CL-R-REGIME-ROT-001; this attribution is tied to the canon_lock version.

4.3.4.3 Example allowed stack for a non-rigid regime (restricted)

In a non-rigid regime, closures that presuppose the existence of a rigid backbone cannot be used. Therefore the following restriction is included in the regime definition.

In this case, the allowed stack is fixed as

To produce rigidity-related statements under a non-rigid regime, the statements must not be “rigidity conclusions” but “rigidity failure or limit conclusions” (CT-LIM), accompanied by failure-mode labels.

4.3.5 Extrapolation Ban

Regime extrapolation is defined as “describing a conclusion derived and Gate-passed in regime R as the same conclusion for another regime R' with different regime-axis values”. Extrapolation occurs if any of the following holds.

1. Axis mismatch: at least one regime-axis value differs between R and R'.
2. Allowed-stack mismatch: the conclusion uses a closure that is not allowed under R'.
3. Missing regime Gates: the Gates required to justify the transition to R' (regime fit/cross-consistency/reproducibility) were not executed.

Extrapolation is not softened by interpretation; it is handled immediately by the rules below.

4.3.5.1 Sentence rules for the extrapolation ban

A sentence that contains regime extrapolation cannot obtain conclusion status. Fix the sentence rules as follows.

1. Every conclusion sentence must include regime_id. If regime_id is missing, the sentence is judged INCONCLUSIVE.
2. Regime-axis values appearing in a conclusion sentence must match coords of the registered regime. Any mismatch is immediate FAIL.
3. To describe a generalization to another regime, one must present a separate regime_id, the allowed stack, and new Gate judgements for that regime.
4. Outside the declared regime, only limit statements (CT-LIM) are allowed (not conclusions). Limit statements must include the cause labels of FAIL/INCONCLUSIVE.

4.3.5.2 FAIL labels for extrapolation violations

If regime extrapolation is detected, assign the following FAIL labels.

4.3.6 Admissible conditions for regime transitions

A regime transition is recorded as “R→R”' and is allowed only in the two cases below.

1. Refinement within the same axis values: adding a sub-classification within the same regime using a pre-registered axis such as the scale window (R_scale) or observation axis (R_obs). Even then, the sub-regime must be registered with a new regime_id.
2. Parallel presentation of independent conclusions: generating conclusions independently in different regimes and listing them in parallel without mixing. Parallel presentation may require a cross-consistency closure (CL-X-*); whether it is required must be locked in analysis_lock.

To synthesize a regime transition into a single conclusion, the synthesis rule itself must be locked as a closure, and the Gate stack for the synthesis must be pre-registered. A transition without a synthesis rule is treated as extrapolation and is forbidden.

Forced — Results With No Adjustable Content

Everything here follows from geometry, counting, and the rectification integrals of the Read-First decoder. There is no knob: each π is one rotation averaged, each integer a lattice count. This is where the physics is decided.