#CharacteristicSpace & Dynamics Hook (A.CHR‑SPACE)

A.19 · Stable · Kernel characteristic-space and dynamics-typing pattern · Part A - Kernel Architecture Cluster

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Type: Kernel characteristic-space and dynamics-typing pattern Status: Stable

Use this when. Use this pattern when the current object is either a declared CharacteristicSpace or a reusable by-value CharacteristicSpacePredicate over that space: characteristics, scales, value sets, coordinate bindings, optional overlays, predicate operators and cuts, comparability boundaries, normalization boundaries, missingness, and the U.Dynamics.stateSpace hook.

What goes wrong if missed. Teams compare raw numbers from different scales, treat dashboards or scores as the space, hide thresholds inside state labels, silently change a predicate use's scope or evaluation window, smuggle method sequences into checklists, or give consumer patterns private space and predicate kinds.

What this buys. One declared space and one recoverable predicate form that make state, threshold, comparability, normalization, and dynamics-typing claims inspectable while leaving each evaluation, result, evidence use, gate, and selection occurrence with its direct owner.

Use A.19 when the current question is the space of characteristics itself: which characteristics are in scope, which scale is bound to each characteristic, what values are admissible, how coordinates are grouped, which optional order, topology, or metric overlays are declared, and where comparability, normalization, missingness, and evidence hooks belong.

#Keywords

• CharacteristicSpace
• U.Dynamics.stateSpace
• state trajectories
• declared Characteristics and Scales
• subspace
• embedding
• product
• structural overlays
• coordinatewise comparability
• role-specific space refs stay outside A.19.

#Relations

#Content

#Problem frame - First use: U.CharacteristicSpace as the EoC (normative primer)

Use A.19 when the current question is the space of characteristics itself: which characteristics are in scope, which scale is bound to each characteristic, what values are admissible, how coordinates are grouped, which optional order, topology, or metric overlays are declared, and where comparability, normalization, missingness, and evidence hooks belong.

First move: name the CharacteristicSpace, then write its basis as slot declarations. Each slot binds one U.Characteristic to one scale and value set under A.17 and A.18; optional overlays and comparability boundaries attach to the space only when declared. U.Dynamics.stateSpace points to a declared CharacteristicSpace; A.19 does not supply the dynamic law, time base, evaluation use, dashboard, score, or portfolio that consumes the space.

Core boundary: A.19 governs the CharacteristicSpace and the reusable by-value CharacteristicSpacePredicate. Consumer patterns may refer to the space, bind the predicate to an exact use, evaluate it, or publish views over either value, but those references, applications, results, descriptions, publication forms, and source-set relations are not second space or predicate kinds.

Informative CHR pointer: when the question moves from the space to normalization, indicatorization, scoring, aggregation, comparison, or selection mechanisms, use the corresponding A.19.<MechId> pattern (A.19.UNM, A.19.UINDM, A.19.USCM, A.19.ULSAM, A.19.CPM, A.19.SelectorMechanism) and A.19.CHR. C.16 carries measurement and evidence backing; G.0 carries admissibility gates for numeric operations. A.19 may cite those patterns, but it does not govern their mechanism vocabulary.

Reader orientation sequence for a CHR-enabled plan or audit, when orientation is needed:

• measurement vocabulary: use A.17, A.18, and C.16 for characteristic, scale, coordinate, unit, measure, and evidence backing;
• characteristic-space object: use this pattern for the declared CharacteristicSpace, basis slots, optional overlays, comparability boundaries, missingness, and U.Dynamics.stateSpace hook;
• admissibility of numeric operations: use G.0 and the relevant A.19.<MechId> mechanism pattern; do not let A.19 become a second mechanism vocabulary;
• suite and planning boundary: use A.19.CHR, A.15.3, and E.18 when a planned baseline, suite slot filling, or transformation-flow structure is current;
• one mechanism at a time: read A.19.UNM, A.19.UINDM, A.19.USCM, A.19.ULSAM, A.19.CPM, or A.19.SelectorMechanism only for the mechanism claim being made;
• specialization and reuse: use E.20 when a project-specific mechanism variant is introduced.

Fast review entries: for a plan, start from the A.19.CHR planned-baseline hook and A.15.3; for semantic drift, start from the canonical mechanism target and then use E.10 and F.18; for conformance, start from the A.19.CHR and relevant A.19.<MechId> checklists, then use E.19 for review protocol.

#Intent & Scope (Normative)

Intent. Establish two composable A.19 values. U.CharacteristicSpace is the declared space of characteristics, scales, value sets, coordinate positions and groups, optional overlays, missingness semantics, comparability boundaries, normalization boundaries, and typing hooks. CharacteristicSpacePredicate is the by-value semantic predicate over declared coordinates in one such space. For dynamics, U.Dynamics.stateSpace points to the declared space so a holon's change can be described as a trajectory in typed coordinates. For epistemes, state remains governed by ESG; F-G-R are assurance coordinates, not an episteme state space.

E.24.UK settlement. U.CharacteristicSpace is retained as the root durable value for a declared multi-characteristic space. CharacteristicSpacePredicate is not a U-kind, relation occurrence, description edition, publication record, evaluation result, or acceptance result. A criterion-description episteme may express the predicate, and a direct consumer may evaluate it, but neither carrier nor result substitutes for the predicate's complete by-value meaning.

The A.19 objects are therefore the declared space and reusable predicate. They are not the filled evaluation, report, score table, dashboard, pattern-quality scale, DRR adequacy scale, FPF-level pillar scale, acceptance result, comparison result, or improvement portfolio that uses them. Scope. Pattern A.19 defines:

• the declared U.CharacteristicSpace value as a finite product of slot value sets under A.18;
• the slot construct that binds one U.Characteristic to one selected scale and value set;
• the by-value CharacteristicSpacePredicate over declared coordinates, including its coordinate and scale bindings, normalization or F.9 Bridge basis where needed, operator or comparator semantics, cut or band, and polarity;
• optional order, topology, and distance overlays that downstream patterns may use when declared; and
• the typing hook U.Dynamics.stateSpace : CharacteristicSpace.

A.19 does not introduce measurement aspects, composite metrics, normalization semantics, comparison or selection work, consumer applicability, evaluation results, evidence relations, or dynamic laws. A.19.UNM governs normalization; A.19.CPM governs comparison; A.19.SelectorMechanism governs selection; C.16 and A.10 govern measurement and evidence provenance; A.3.3 governs dynamics.

Space-and-predicate versus consumer boundary. A consumer reference such as ...SpaceRef designates one declared space. A consumer use of a predicate separately binds its exact U.ClaimScope, relevant A.2.6 U.ContextSlice membership, effective U.ReferenceScheme and reference plane, application or evaluation window, input projection, and direct evaluation operation. Those bindings are not fields of the space or semantic predicate. They may change while the predicate remains the same; conversely, changing a coordinate binding, scale, normalization or Bridge meaning, operator, cut or band, polarity, or governing comparator semantics creates a different predicate even if its wording is coextensional.

A.19.ECS constructs an evaluation CharacteristicSpace for an object kind under improvement. E.21, E.9.DA, E.2.DA, and other evaluation patterns consume declared spaces and predicates for their own evaluated objects. A.19 supplies the reusable values; those patterns supply object-specific applicability, evaluation, result, evidence-use, stop, and receiving-work semantics. Lexical guard (“map”). Follow the normalization lexical discipline governed by A.19.UNM. In this pattern, lowercase map is used only in the mathematical sense, while capitalized Map retains its Part‑G suffix meaning (e.g., DescriptorMap). Do not mint new normalization terminology here.

Lexical guard for value sets. In A.19, the set that supplies values to a slot is ValueSet(slot) or an underlying value set. Do not call that value set a publication form, symbol bearer, source, description, or persistence object.

#Context (Informative)

FPF already standardizes what is characterized through A.17 and how one characteristic is scaled through A.18. Dynamics, evaluation, and comparison additionally need a declared common value space in which several characteristics coexist without losing scale, arity, or meaning. They also need reusable predicates whose semantic components remain recoverable independently of a criterion description, one evaluation occurrence, or one result. A.19 supplies those two values without inventing a generic semantic-locality container or duplicating consumer scope, time, evidence, and result relations.

#Problem (Informative)

• P1 - Feature-vector drift. A list of values with implicit units, scales, missingness, or arity cannot support a sound state or comparison claim.
• P2 - Lifecycle bias. Without a declared space, system change is narrated as one-way stages instead of typed trajectories and separately governed state or classification claims.
• P3 - Semantic-locality collapse. Different claim scopes, context slices, reference schemes, or reference planes may use different coordinate sets or meanings. Treating one umbrella context label as their common identity makes projection and comparison unverifiable.
• P4 - Relational characteristics. A multi-entity characteristic loses arity and direction when flattened into an intrinsic scalar.
• P5 - Hidden predicate semantics. A threshold label or criterion-description edition can conceal the actual coordinate bindings, scale, comparator, cut, polarity, and normalization or Bridge basis.
• P6 - Geometry by implication. An undeclared order, topology, distance, scalarization, or aggregation can silently decide a comparison or selection.

#Forces (Informative)

• F1 - Scale integrity at product size. Every coordinate retains its own characteristic, scale, unit, admissible domain, and missingness meaning.
• F2 - Transdisciplinarity with lexical clarity. Quantitative, qualitative, intrinsic, and relational characteristics must compose without replacing the canonical A.17-A.18 vocabulary.
• F3 - Minimal core with explicit overlays. Order, topology, distance, normalization, scalarization, and aggregation are available only when declared under their owners.
• F4 - Predicate reuse without consumer collapse. One semantic predicate should be reusable across state, comparison, acceptance, selection, and improvement uses, while each use retains its own scope, slice, plane, window, evaluation, result, and evidence relations.
• F5 - Safe composition. Projection, embedding, product, and Bridge-based alignment must preserve exact coordinate and scale meaning and make losses explicit.
• F6 - Ordinary usability. An engineer should be able to state a space and criterion without first creating a publication record, evaluation occurrence, or generic result relation.

#Solution

#U.CharacteristicSpace

#Type signature

Let I be a finite index set labeling a collection of slots. Each slot i (for i ∈ I) is defined as a pair:

slot_i = (Characteristic_i, Scale_i),

where:

• Characteristic_i is a U.Characteristic (with an explicit arity, i.e. either an entity-Characteristic or a relation-Characteristic as defined in A.17), and

• Scale_i is a chosen Scale for that Characteristic (with a specified scale type and unit, per A.18 and the MM‑CHR rules).

Then a CharacteristicSpace (CS) is formally the Cartesian product of all slot value sets:

$\mathbf{CS} = \prod_{i \in I} \mathrm{ValueSet}(\mathrm{slot}_i),.$

In other words, a point (state) in the space consists of one coordinate value for each slot. A state x in CS can be seen as a total function x(i) that picks a value from each slot’s ValueSet (for every i ∈ I, x(i) ∈ ValueSet(slot_i)). By kernel mandate, any U.Dynamics.stateSpace SHALL be bound to some instance of CharacteristicSpace, and all states or trajectories described by that dynamics model MUST lie within that space’s value set. (The actual dynamic laws and time progression are handled in A.3.3; A.19 only defines the state‑space container and its properties.)

#Slot discipline (invariants)

To ensure consistency and comparability, a CharacteristicSpace must obey the following invariants:

• A19-CS-1 (Exactly one per slot). Each slot binds exactly one Characteristic to exactly one Scale (including a specific Unit or kind, if applicable). This mirrors the CSLC clause of “one aspect – one scale”: there are no ambiguous or compound mappings in a single slot. (If a Characteristic can be measured on multiple scales, only one is chosen for a given space; others would require separate slots or a different space.)

• A19-CS-2 (Named basis). A CharacteristicSpace SHALL publish an ordered list of its slots as its basis. Each slot in the basis has a stable identifier that can be used in technical notations or data structures. These basis names should be treated as stable technical tokens (identifier-like); any human-friendly alias or description for a slot should be provided only in the Plain register as a non-normative aid (per E.10). In short, the identity and order of slots in the space are explicit and stable.

• A19-CS-3 (Immutability of meaning). Once a space is in use, the meaning of each slot is fixed. A slot’s (Characteristic, Scale) pair MUST NOT be retroactively altered. If requirements change (e.g. a different scale or a revised definition of the Characteristic), one MUST define a new version of the space (or a new slot) rather than silently changing the existing one. When a space is versioned or a slot replaced, an explicit embedding (mapping from the old space to the new space) should be published to relate historical states to the new coordinates. This ensures past data remains interpretable and prevents semantic drift.

• A19-CS-4 (Arity preservation). If a Characteristic_i is defined as a relation (multi-entity characteristic), then slot i represents a relationship among multiple entities. The coordinate value at such a slot is a tuple (with the appropriate entity types) rather than a simple scalar. The slot’s declaration SHALL indicate the relation’s symmetry or directionality as part of its meaning (this should align with how the Characteristic was originally defined in its template). In essence, relational Characteristics retain their arity in the space, so that we don’t confuse, say, “Coupling between X and Y” with an intrinsic property of X or Y alone.

• A19-CS-5 (No hidden normalization, preference, or aggregation). A CharacteristicSpace carries no implicit normalization, polarity preference, threshold, formula, or aggregation. A CharacteristicSpacePredicate may declare polarity, operator semantics, and a cut or band over that space. Normalizing, indicatorizing, scoring, folding, comparing, and selecting remain explicit operations under their governing patterns; the space declaration itself performs none of them. A.19.UNM governs normalization semantics and admissibility; C.16 governs relied-on measurement and calibration claims.

• A19-CS-6 (Slot meta completeness). Where applicable, each slot SHALL declare admissible_domain and missingness semantics (e.g., codes for missing, censored, not-applicable), consistent with the Characteristic’s Scale and with MM‑CHR. This prevents silent domain drift and clarifies how absent values participate in predicates and comparisons.

• A19-CS-7 (Space-vs-consumer boundary). A CharacteristicSpace publishes only its own slot basis, optional overlays, and typing hooks. Ref-typed consumer fields that point to a declared space, explicit relation kinds between such refs, source-set wiring, interpretive-view organization, and publication metadata are outside the space object and MUST be declared in the consumer pattern or consumer declaration that uses the space. This prevents CharacteristicSpace from being silently widened into ref-position semantics, selector semantics, source-set semantics, publication-form semantics, or interpretive-view semantics.

#Minimal structure hooks (optional overlays)

By default, a CharacteristicSpace has no assumed ordering or metric structure – it is just a Cartesian product of value sets. However, a space MAY declare certain structural attributes as opt-in metadata (i.e. informative annotations that patterns can rely on, but not enforced by the kernel). These optional overlays include:

• Product topology. A topology on the space, typically the product topology when slots that are quantitative (interval or ratio scales) need continuity considerations. Declaring a topology is useful if continuity or convergence arguments are relevant (e.g. to say a sequence of states approaches a limit state). By default, without declaration, no topological structure is assumed on the space.

Lexical note: Here “distance metric” strictly means a mathematical distance function (or a generalized distance such as a pseudometric or quasi-metric) on the state space. This is not to be confused with metrics as performance measures in MM-CHR. In the Tech register, avoid the noun metric; refer to U.DHCMethod or U.DHCMethodRef for measurement templates (see C.16). Any distance overlay on a CharacteristicSpace must not conflict with scale semantics; it is an additional analysis structure, not a redefinition of measurement meaning.

These overlays are entirely optional and have no effect on the core meaning of the space - they exist only to enable particular reasoning such as dominance, continuity, or distance reasoning in models that require it. If needed, they should be added deliberately by an architectural theory rather than assumed. This way, any ordering or metric properties of states are made explicit instead of relying on hidden or default arithmetic. (Rationale: The CSLC and MM‑CHR rules already govern what operations are allowed on each scale; A.19’s approach is to let neighboring theories add an order, topology, or metric when appropriate, so nothing is taken for granted tacitly in multi-dimensional arithmetic.)

#Dynamics hook (typing only)

Any model of change or dynamics in FPF must declare the state space it operates over. Formally, U.Dynamics.stateSpace SHALL be specified as a reference to a CharacteristicSpace. This creates a typing requirement: the dynamic model can only produce states and trajectories of states that belong to the given space. All predicates or predictions in such a dynamics model are understood to quantify over sequences of points in that CharacteristicSpace (with time semantics governed by A.3.3’s time base and laws). Note: A.19 defines only the structure of the state space; it deliberately does not fix any time base or dynamic law. Those remain the responsibility of the dynamics pattern (A.3.3). A.19 simply ensures there is a well-defined space in which states are located, so that dynamics are decoupled from any narrative “stage” and instead treat evolution as movement through this space.

#Lexical discipline (Normative)

In all normative references, definitions, and identifiers related to this pattern, the specification uses the canonical measurement terminology: Characteristic, Scale, Level, Coordinate, CharacteristicSpace, slot, basis. Legacy terms like “axis”, “dimension”, or “point” are forbidden in Technical and Formal registers of the spec (per A.17’s lexical rules). They may appear at most once in explanatory Plain language as mapped aliases to aid understanding (and if used, must be explicitly identified as equivalent to the official terms). In this pattern, we consistently use “slot” or “basis element” (never “axis”) to refer to a component of a space, and “Characteristic” (never “dimension”) to refer to the measured aspect. This lexical discipline ensures clarity and consistency across the framework (see A.17 and C.16 L-rules for the formal policy on terminology).

#Quotients & NormalizationFix (Normative)

Governing-pattern note. ≡_UNM and NormalizationFix are defined in A.19.UNM. This section constrains only how they are cited when used in state‑space reasoning.

Design rule — read invariants, not labels. Any checklist, acceptance predicate, equality check, join, or comparability claim over a CharacteristicSpace that depends on representation choice (chart, unit, reference plane, normalization choice, or label) SHALL be evaluated on quotients by ≡_UNM or on explicitly Normalization‑fixed charts, not on raw labels. Minimal obligations:

1. Name the quotient or fix. If a checklist predicates over a normalization‑variant property, it MUST name the NormalizationFix (including the referenced UNM and the relevant NormalizationMethodInstance(s), by reference) and thus the ≡_UNM class.
2. Declare NormalizationMethod class. Every normalization used MUST name its method‑class token and validity window as defined in A.19.UNM (do not restate the class taxonomy here).
3. Join and equality only on invariants. Equality checks and joins across spaces MUST target invariant forms (the ≡_UNM quotient or a declared Normalization-fixed representation), never raw un-fixed coordinates.

#Metric discipline & calibration (Normative)

Use the weakest safe structure required by the argument (pre‑order → semi‑metric → metric).

• If a distance overlay is declared, any acceptance predicate or KPI defined over a CharacteristicSpace SHALL be non‑expansive (Lipschitz ≤ 1) w.r.t. the published d on the declared domain (raw coordinates or NCVs, as specified), or else state an explicit margin that absorbs any expansion.
• If only an order overlay is declared, any acceptance predicate or KPI SHALL be isotone w.r.t. the declared product order.

Minimal obligations:

1. Publish the metric (if used). If a distance overlay is used, the space MUST publish the distance function d (including any weights and parameters) and its declared domain of applicability.
2. Bound expansion. Any acceptance predicate or KPI that relies on d MUST be shown non-expansive (Lipschitz ≤ 1); otherwise an explicit expansion bound and compensating margin MUST be stated.
3. State error and commutation. If a metric is used together with NormalizationFix, the specification MUST state (a) the maximum tolerated measurement and calibration error and (b) whether d commutes with the NormalizationFix (or provide a disclaimer and additional guard if it does not).

#CharacteristicSpacePredicate (by-value)

Use a CharacteristicSpacePredicate when a threshold, band, region, dominance condition, or composed criterion must remain semantically recoverable and reusable independently of one description or evaluation. Its complete by-value meaning contains:

• the exact CharacteristicSpace and the coordinates read from it;
• each coordinate's scale and value interpretation;
• the identity mapping or exact A.19.UNM normalization instances, and any F.9 Bridge with exact endpoints and declared loss when meanings or planes differ;
• the operator or comparator semantics supplied by A.19.CPM, G.4, or another named direct consumer interface;
• the cut value, band, region, or explicitly composed subpredicates; and
• the polarity that determines which side or region satisfies the predicate.

An arbitrary condition relation is not automatically a coordinate tuple. The predicate use must recover either a direct characteristic assignment already governed for that condition or an explicit projection or Bridge from the condition to the predicate input. When the affected entity differs from the condition's participants, the consuming relation or claim must also recover how that entity and use are related to the projected input.

The predicate owns no applicability, assessment, observation, evidence, or evaluation window. A consumer separately binds the exact U.ClaimScope, relevant U.ContextSlice membership, effective reference scheme and plane, application or evaluation window, input value, and evaluation operation. A dated evaluation is U.Work; its actual operation application binds the predicate and input and returns the direct owner's typed result. A criterion-description episteme can express the predicate, and an assertion episteme can claim an evaluation result, but neither episteme nor result is the predicate.

Predicate identity changes only when its semantic components change. Coextensional wording, notation, carrier, publication, identifier, or description-edition change does not by itself create another predicate. A consumer may evaluate the same predicate in another scope or window without changing the predicate; it may not silently change the space, coordinate projection, scale, normalization or Bridge, comparator, cut, band, or polarity while claiming reuse.

Minimally viable case. For a pump space with batteryVoltage on volts, batteryReady := batteryVoltage >= 24 V has the pump space, voltage coordinate and scale, >=, 24 V, and positive polarity as its by-value meaning. A maintenance check separately binds Pump #37, its claim scope and current slice, the evaluation interval, the measured voltage input, and the direct evaluation result. A different projection such as controller supply voltage is inadmissible unless named; a later description edition with the same semantic predicate does not change it.

#State Spaces & Comparability

Memory hook: Compare only values in the same declared space, or values carried into one common space through an exact mapping or Bridge. Reusing a predicate also requires the same semantic predicate; applying it requires separately stated scope, plane, and window.

This section supplies space projection, embedding, product, and two coordinate-comparability regimes. It does not perform a CPM comparison or a SelectorMechanism selection. A consumer that names a state or category cites the declared space and predicate, then keeps its own scope, evaluation, result, evidence, and work relations.

A CharacteristicSpace may be written abstractly as CS = ⟨I, basis⟩, where I indexes slots and basis is the ordered set of (Characteristic, Scale) bindings. A consumer-specific label for a space does not create another A.19 kind; the consumer instead states the exact role, entity, claim scope, context-slice membership, effective reference scheme and plane, and predicate relevant to that use.

#CS Operators (notation-neutral, reference-scheme-local)

To enable model composition, define operations on CharacteristicSpaces independently of notation. Every operation states its effective U.ReferenceScheme and reference plane. When an endpoint differs in scheme or plane, use an exact F.9 Bridge; no umbrella context value supplies the correspondence.

#Subspace – Projection πS : CS → CS|S.

Given a CharacteristicSpace CS with basis I (slots) and a chosen subset of slot indices $S \subseteq I$, one can form the subspace $CS|_S$ which includes only the slots in S and omits all others. The projection map π_S takes any state x in the original space and projects it onto the coordinates indexed by S, effectively discarding the other coordinates. This operation is straightforward: if $S = {i_1, i_2, … }$, then $CS|_S$ has those slots, and any state in $CS|_S$ corresponds to a state in CS with the other coordinates ignored. Properties: Projection is idempotent (π_S ∘ π_S = π_S) and, if an order or other structure is defined solely on the subspace’s slots, π_S preserves that structure (e.g. it will reflect any order that depends only on slots in S).

#A.19:5.2.1.2 Embedding – Injection ι : CS₁ ↪ CS₂.

An embedding is a structure-preserving injection from one space CS₁ into another space CS₂. It consists of two parts: (a) an injective slot correspondence from CS₁ to CS₂, and (b) (only where needed) cited normalization instances that make the correspondence semantically safe. Formally, let CS₁ have basis I₁ and CS₂ have I₂. An embedding declares an injective function m: I₁ → I₂ that identifies each slot of CS₁ with a corresponding slot in CS₂.

For each slot i ∈ I₁ where the scale or unit differs from the target slot m(i) in CS₂, the embedding MUST cite a NormalizationMethodInstanceId (per A.19.UNM) that re-expresses values from ValueSet(slot_i) into ValueSet(slot_{m(i)}) within the declared invariants and validity window. The embedding does not define normalization semantics; it only references the required instances.

Intuitively, an embedding says: “Any coordinate tuple from CS₁ can be interpreted as a coordinate tuple in CS₂, possibly after converting units or re‑scaling, and without losing any information except what the declared NormalizationMethods intentionally coarse‑grain.” If there is no loss at all (NormalizationMethods are identity or strict conversions), the embedding is essentially an inclusion of one space into a larger one; if there is some information loss (e.g., converting a fine‑grained scale to a coarse one), that loss is explicit in the NormalizationMethodDescription. Locality:

An embedding whose endpoints share semantic interpretation remains local to their declared reference scheme and plane. A cross-scheme or cross-plane embedding requires an F.9 Bridge with exact endpoints, preserved and lost meaning, applicable use, CL value, and any receiving assurance consequence; the relevant A.6.1 operation application cites that Bridge explicitly.

Normalization declaration duties (MUST): Each cited NormalizationMethodInstanceId satisfies A.19.UNM declaration and admissibility obligations, including method-class token and validity window. C.16 governs calibration and measurement backing when relied on. Normalization alone does not license a change of reference scheme, plane, predicate, scope, or evaluation window; each changed boundary needs its direct declaration or Bridge.

#A.19:5.2.1.3 Product – Combination CS₁ ⊗ CS₂ = CS⊗.

The product of two spaces CS₁ and CS₂ is a new space CS⊗ that effectively contains all slots of CS₁ and all slots of CS₂. If CS₁ has index set I₁ and basis slots {slot₁…} and CS₂ has I₂, then $CS⊗$ has index set $I_⊗ = I₁ ⊎ I₂$ (disjoint union) with each slot’s definition carried over from its original space. In practical terms, any state in the product space is a pair (x₁, x₂) where x₁ is a state of CS₁ and x₂ is a state of CS₂ (assuming the two spaces pertain to possibly different aspects or roles). Use cases: Product spaces allow modeling multi-role scenarios or bundling an entity’s state with some environmental or contextual state. For example, one might take a space of internal capability metrics and ⊗ with a space of external conditions to form a combined space for “readiness under conditions.” Note: When combining scores or coordinates from a product space, one must be mindful of scale incommensurability. Cross‑slot aggregation SHALL proceed only via a declared Γ‑fold (B.1) and, where needed, explicitly declared NormalizationMethods; naïve arithmetic is forbidden. The product operation itself doesn’t perform any aggregation; it only sets the stage.

#Comparability of States (two admissible regimes)

A label such as Ready, Authorized, or Degraded is a consumer-side category, not a space or comparison result. Its direct owner states the predicate and evaluation use. Comparing two coordinate states depends on the declared spaces, mappings, scales, and comparison scope; A.19 permits only the following two coordinate regimes.

#A.19:5.2.2.1 Coordinatewise comparability (≼_coord)

Two states can be compared coordinatewise only under strict conditions. Essentially, we require the states to be expressed in the same measurement space, with the same units and scales, and using the same state definitions. Formally, coordinatewise comparison is allowed only if all of the following hold:

• Same space. Both coordinate values lie in the same CharacteristicSpace by value. Similar names, shared storage, or a common model-use label are insufficient.

• Scale congruence. For each slot being compared, the scale type, unit, and polarity orientation are identical. For example, if comparing temperature values, both must be on the same scale (say, °C on a ratio scale with “higher = hotter” orientation). No unit mismatches or differing interpretations can be present.

• Predicate and use congruence. When comparison depends on a category predicate, both values use the same CharacteristicSpacePredicate by value. CPM still states the exact comparison scope, comparator, reference plane, and evaluation window; A.19 does not infer them from matching labels.

When these conditions are met, one can define a coordinatewise preorder over states. Common patterns include:

• Dominance: For a given set of “higher is better” slots, we say state x ≼_coord state y if and only if for every relevant slot a, the coordinate $a(x) \le a(y)$ (after orienting all slots to the declared polarity for that slot). In other words, y is as good or better on all enforced criteria. This defines a Pareto-like ordering (often partial, not total).

• Predicate band inclusion: If states are defined by satisfying declared predicate bands (e.g. State Y means declared coordinates stay above specific levels), then we might say x ≼_coord y if x satisfies every predicate that defines y’s state. For instance, if state y = “High Performance” requires speed > 100 and accuracy > 90%, then x is “no less than y” if x also satisfies those predicates.

By default, no comparability is assumed unless proven. If any of the above congruence conditions fails, one must not fall back to ad-hoc comparisons (like matching by name or normalizing without declaration). Either switch to a normalization-based regime or declare the states incomparable.

#A.19:5.2.2.2 Normalization‑based comparability (≼_normalization)

When two state vectors do not meet the strict conditions for coordinatewise comparison (e.g. they come from different spaces, or the “same” Characteristics are measured on different scales or units), the only sanctioned way to compare them is: normalize, then compare.

Concretely: if we have state x in CS₁ and state y in CS₂, a normalization‑based comparison is permitted only if the model can cite a set of NormalizationMethodInstanceId(s) under a chosen UNM (per A.19.UNM) that lands the relevant coordinates of x into CS₂ (or lands both into a declared common target space). The result is understood as NCVs (or an ≡_UNM quotient class) per A.19.UNM.

Comparability rule (normalize-then-compare). We say x ≼_{normalization} y only if, after applying the cited normalization instances to produce a representation of x in CS₂ (or a common target), the mapped state can be compared coordinatewise under ≼_coord. In other words, we never compare raw x and y; we compare after mapping into a common, well-typed space.

If normalization also crosses reference schemes or planes, the comparison cites an F.9 Bridge with exact endpoints and any CL value, plus the CPM comparison scope and evaluation window. The receiving assurance pattern applies any B.3 consequence; normalization does not silently change meaning or grant comparability.

Inspectability. Each normalization instance used for comparison is recoverable through its A.19.UNM declaration. C.16 governs measurement and calibration backing. If values differ in scale, reference scheme, or plane, the normalization and Bridge choices and their limitations remain explicit.

Mnemonic: Never compare before both values are carried into the same well-typed space; never claim the same predicate, scope, plane, or window merely from matching labels.

#Predicate-use and state-assertion boundary

A.19 defines the space and CharacteristicSpacePredicate; it does not define a state assertion, applicability relation, dated evaluation work, gate, evidence relation, assurance result, or permission to act.

A consumer use recovers: the exact subject or input; any direct characteristic assignment or projection from that subject; the A.19 space and predicate; one set-valued U.ClaimScope; relevant A.2.6 U.ContextSlice membership; effective U.ReferenceScheme and reference plane; application or evaluation window; and any F.9 Bridge. The direct consumer owns the actual evaluation operation and typed result. A.10 provenance, G.11 currentness, measurement backing, assurance, and receiving-work disposition remain separate.

For a Ready claim requiring temperature below a cut and pressure above a cut, A.19 supplies the two declared coordinates, scales, normalization or Bridge basis, operators, cuts, polarity, and conjunction. The state-assertion owner binds the pump, scope, slice, evaluation interval, actual inputs, result, and evidence use. Changing the evaluation interval does not change the predicate; changing either cut does.

Pulling a predicate into another space or pushing an assertion through an embedding requires the exact coordinate correspondence, normalization, and Bridge. If an input projection or semantic correspondence is missing, the current use is incomparable or unevaluable rather than approximately valid.

#Cross-reference-scheme and cross-plane comparability

A comparison across reference schemes or planes is admissible only through an F.9 Bridge that states exact source and target endpoints, preserved and lost meaning, direction, applicable use, and CL when current. The coordinate mapping and A.19.UNM instances are explicit. A reverse comparison needs its own justified direction.

The comparison may reuse a predicate only when the Bridge preserves every semantic predicate component. CPM separately binds comparison scope, comparator, input values, effective reference plane, and evaluation window. A Bridge does not copy scope or time, and a common label does not establish predicate equality.

B.3 or the direct assurance pattern owns any confidence or margin consequence. If a critical coordinate lacks an admissible normalization or Bridge, or if the predicate, plane, scope, or window cannot be held fixed, report the values as incomparable for that use.

#Characteristic-Space Reference Chain

When a consumer pattern evaluates a checklist, StateAssertion, gate, assurance argument, or decision through a declared CharacteristicSpace, keep the space-related references distinct:

raw coordinates -> NormalizationMethodInstance -> quotient or NormalizationFix -> optional indicator choice -> optional order or distance overlay -> neighboring checklist, assertion, gate, assurance, or decision claim

The left side of this chain is A.19-facing: declared space, normalization reference, quotient or fixed chart, and declared overlay. The right side is governed by the consumer pattern. Co-implementation in software or records does not collapse the conceptual references.

#Operator library (notation‑neutral)

Spaces: Sub (projection), Emb (embedding), Prod (product), Quot (quotient by declared equivalence), NormalizationFix (fix to a named chart or edition).

Predicate and assertion transport: Pull (pull a predicate through an embedding and declared normalization), Push (push an assertion with proof or waiver under its direct owner), Indicatorize (apply an IndicatorChoicePolicy), Align_B (align exact reference-scheme or plane endpoints through a Bridge), and Fold_Γ (admissible aggregation under its governing pattern).

OP-1 (Normative). If Align_B supports a gate, comparison, or assurance claim, cite the exact Bridge and CL where current. The direct consumer owns scope, evaluation window, result, and any B.3 consequence. Silent cross-scheme or cross-plane reuse is forbidden.

#Set-view, comparison, and selection boundary

A typed view over a set, ComparisonResultSlot, SelectionSlot, shortlist, archive, portfolio, search-space role, outcome-space role, metric-based neighborhood, and transition-sensitive selection interpretation are consumer objects. They may cite an A.19 space, predicate, order, distance overlay, or transition relation, but A.19 does not define their result, view, comparison, or selection identity. Keep the underlying source set and exact A.19 values recoverable; use A.19.CPM, A.19.SelectorMechanism, the direct view or publication pattern, and the exact transition owner for the consuming claim.

#Archetypal Grounding

System state. A pump readiness use declares temperature, vibration, pressure, and calibration coordinates plus a by-value readiness predicate. The state-assertion or gate owner binds the pump, claim scope, context slice, evaluation window, actual inputs, result, evidence, and permission to act.

Episteme evaluation. A method-description review uses clarity, evidence recoverability, source currentness, and relation precision coordinates. A.19 supplies the declared characteristic space; the evaluation pattern owns the stop condition, rating interpretation, and improvement decision.

Cross-scheme comparison. A built-asset team compares readiness values expressed under different measurement conventions. A.19 requires a common declared space or an exact normalization and F.9 Bridge before coordinate comparison; CPM owns the comparison occurrence, scope, window, and result.

#Bias-Annotation

A.19 corrects feature-vector bias: a list of numbers, labels, or dashboard fields is not yet a CharacteristicSpace. The space exists only when each slot binds a U.Characteristic to a scale and value set with declared meaning, comparability, missingness, and optional overlays.

It also corrects consumer-pattern bias. A.19 owns the reusable space and semantic predicate values. A gate, evaluation, comparison, selector, assurance use, dashboard, or portfolio owns its application, scope, window, result, evidence use, and publication consequences; consuming the A.19 values creates no private space or predicate kind.

#Conformance Checklist (normative) — CC‑A19

Formality references and operational segregation (normative). A.19 aligns with C.2.3 Unified Formality Characteristic (F). Use F directly instead of tier labels such as T0, T1, and T2, and treat operations separately (see E.10 for registers). — F-Declaration baseline (recommended F ≥ F3). Obligations are declarability and arguability: the author can name the CharacteristicSpace (basis and slots as (Characteristic, Scale) pairs), state the comparability regime (coordinatewise or normalization-based), and express a state’s checklist in observable coordinates. No persistence formats, identifiers, or operational provenance are required. — F-Predicates (F ≥ F4 when predicate-like). As above, plus explicit slot and NormalizationMethod names and stated overlays (order or metric). When acceptance conditions are written as typed predicates over coordinates, declare F ≥ F4. Remains notation-neutral and persistence-agnostic. — Operational bindings (not part of F). When automatic checking or assurance is required, use A.19.CN, C.16, and B.3 for identifiers, validity windows, waivers, and logs. These raise R and TA in the trust calculus and do not change F unless the expression form changes (see C.2.3 orthogonality).

The following checklist summarizes the normative requirements introduced by Pattern A.19. An implementation or model conforms to A.19 if and only if all these conditions are met:

Spaces & mappings CC‑A19.1. Any defined Subspace, Embedding, or Product of CharacteristicSpaces MUST explicitly list the involved slots and their metadata (scale type, unit, polarity). No comparability or merging is allowed purely by matching names or assuming correspondence – it must be declared. CC‑A19.2. Every Embedding ι: CS₁ ↦ CS₂ MUST cite a well‑defined NormalizationMethodInstance (per A.19.UNM) for each slot where CS₁’s slot differs in scale or unit from CS₂’s. The cited instances MUST satisfy the admissibility and declaration obligations governed by A.19.UNM (including monotonicity w.r.t. polarity, validity window, and method-class token). When the embedding is used for gating or assurance, C.16 and the governing gate or assurance pattern own the evidence-backed claim. (Identity suffices where scales are identical.) CC‑A19.2a. Scale‑class guard (by reference). The scale‑class requirements for admissible normalizations are governed by A.19.UNM (and must remain CSLC‑consistent per A.18). This checklist item is satisfied by citing a NormalizationMethodInstance whose declared class token meets those requirements; do not restate the taxonomy here.

Comparability CC‑A19.3. Coordinatewise comparability (≼_coord) is permitted only when the states being compared share the same CharacteristicSpace, with identical scale metadata on each compared slot, and using the same state definition criteria. If these conditions aren’t fully satisfied, an implementation MUST NOT attempt direct coordinatewise comparison; it should either apply a normalization‑based method or report the items as incomparable. CC‑A19.3a. Use of Indicators in any checklist or assertion MUST cite an IndicatorChoicePolicy edition. Treating any NCV as an Indicator without a declared policy is forbidden.

CC‑A19.4. Normalization‑based comparability (≼_normalization) MUST be done by first normalizing all relevant coordinates of the source state into the target state’s space via declared admissible NormalizationMethodInstance(s) (see A.19.UNM), and only then comparing in that common space. In other words, two states can be compared under ≼_normalization only by producing an image of one in the other’s space (N(x)) and using ≼_coord on the result. No implicit or “on the fly” conversions are permitted. CC-A19.5. Any cross-reference-scheme or cross-plane comparison cites an F.9 Bridge with exact endpoints, preserved and lost meaning, direction, applicable use, and CL where current. CPM separately declares comparison scope and evaluation window; neither a matching label nor an optional structure supplies them.

Neighboring certification references CC-A19.6. A consumer of a CharacteristicSpacePredicate separately states the subject or input projection, one U.ClaimScope, relevant U.ContextSlice membership, effective reference scheme and plane, application or evaluation window, and any Bridge. These use bindings do not become predicate identity components.

CC‑A19.7. If a Green-Gate or enactment rule uses coordinates from a CharacteristicSpace, the gate pattern and role-method-work pattern govern permission to act; A.19 only requires that any translated state or coordinate claim cite declared Embeddings and Bridges rather than untracked inferences. CC-A19.8. Predicate and checklist definitions use declared coordinates and explicit logical composition. If temporal order or a multi-step procedure matters, use direct method and work patterns rather than hiding the procedure inside the space or predicate. Indicators require an IndicatorChoicePolicy; an NCV is not automatically an indicator.

Anti‑drift CC‑A19.9. If a NormalizationMethod or UNM declaration, space overlay, or state checklist is updated or calibrated differently in a new version, previous StateAssertions are not retroactively modified by A.19. The governing assertion or record pattern closes or versions those claims; A.19 requires only that the old and new space-facing referents remain inspectable. CC‑A19.10. If any critical slot in a comparison lacks an admissible NormalizationMethodInstanceId (per A.19.UNM) to translate that slot between the relevant spaces (within the declared validity window), then the comparison MUST be reported as incomparable. The model must not attempt unofficial workarounds (e.g., name‑matching, silent dropping of the slot, or ad‑hoc coercions). This rule applies even if all other slots have admissible normalization instances, unless a policy explicitly accepts the loss via a declared Bridge with stated limitations.

Quotients & Normalization‑fix (QNT) CC‑A19.11. Equality checks and joins across spaces MUST target invariant forms (on a quotient or declared NormalizationFixed chart), not raw coordinates. CC‑A19.12. If a checklist predicates on a normalization‑variant property, it MUST name the NormalizationFix (which UNM.NormalizationMethod or chart is assumed). CC-A19.13. Every cited normalization method-class token is recoverable from the effective A.19.UNM declaration and reference scheme. A local glossary or model-use structure may aid retrieval but does not supply normalization, scope, predicate, or comparison semantics.

Metric discipline & calibration (MET) CC‑A19.14. If a distance overlay is used, acceptance predicates or KPIs over a CS SHALL be non-expansive (Lipschitz ≤ 1) w.r.t. the published d on the declared domain (raw coordinates or NCVs), or declare a compensating margin; otherwise they SHALL be isotone w.r.t. the declared product order. CC‑A19.15. Any distance used in state or acceptance checks MUST carry max tolerated error and, where claimed, a Lipschitz bound for the NormalizationMethod composition in use. CC-A19.16. Cross-reference-scheme or cross-plane inputs name the normalization and F.9 Bridge plus their validity conditions. An expired mapping is invalid for the current use unless the direct consumer records an admissible waiver.

Dynamics and time CC-A19.17. CharacteristicSpacePredicate contains no predicate window. Each consumer binds its own applicability or evaluation interval; observation, evidence, and source-currentness intervals remain with their direct claims and may not reidentify the predicate. CC‑A19.18. Any dynamics map Φ_{Δt} used in comparison or gating MUST be non-expansive (Lipschitz ≤ 1) under the declared distance overlay and commute with NormalizationFix; otherwise observation is required.

Neighboring certification use CC‑A19.19. StateAssertions that use a CharacteristicSpace must name the current NormalizationMethod or UNM declaration and overlay definitions used; assertion validity, waiver speech acts, evidence kind, and gate validity are governed by the assertion, evidence, waiver, and gate patterns. A.19 imposes no requirement on identifiers or persistence formats. CC‑A19.20. The space-facing references in a neighboring certification use - normalization declaration, quotient or fixed chart, overlay, and coordinate predicate - are logically distinct and must be reconstructable in the argument or review. The neighboring consumer pattern owns evaluation, assertion, gate, assurance, and decision semantics.

Operators (OP) CC-A19.21. Use of Align_B declares the exact Bridge. The comparison, gate, or assurance owner retains its own scope, window, result, and CL consequence. A.19 imposes no persistence-identifier requirement. CC-A19.22. Every CharacteristicSpacePredicate is recoverable by value from its space, coordinate and scale bindings, normalization or Bridge basis, operator or comparator semantics, cut or band, logical composition, and polarity. It is not a U-kind, description edition, relation occurrence, or evaluation result. CC-A19.23. A predicate use identifies the actual input value or governed projection from its condition or subject. An arbitrary relation occurrence, stored record, or matching label is not automatically a point in the predicate's space.

#Common Anti-Patterns and How to Avoid Them

The following are common modeling mistakes (“anti-patterns”) related to measurement spaces, and how to correct them:

• “Same label ⇒ comparable.” ✗ Assuming two Ready labels or two same-named coordinates are comparable across different reference schemes or planes. ✓ Normalize into one declared target space, cite the exact F.9 Bridge, and let CPM state the comparison scope, comparator, plane, and window.

• “Compare before common-space mapping.” ✗ Comparing values directly across different scales, e.g. Drift_A = 5°C vs Drift_B = 5°F as if they were the same. ✓ Normalize to common units first: e.g., apply the Fahrenheit-to-Celsius NormalizationMethod m(T_F) = (T_F - 32) × 5/9 to convert all data to °C, then compare the drift values. Always normalize into one space before comparing magnitudes.

• “Checklist = method sequence.” ✗ Defining a state’s checklist with an implied sequence: “State ‘Ready’ requires doing Step 1 then Step 2…” ✓ Keep checklists declarative: A Checklist should represent a state of the system (a condition) – essentially state evidence – not a sequence of actions. If order or process matters, model that explicitly via a MethodDescription or by using a Γ (Gamma) aggregator for process logic. In other words, state = “Ready” might require conditions A and B to be true (regardless of how you got there), whereas the procedure to get ready (do Step1 then Step2) should be a separate method or playbook.

• “Retro-fix past assertions.” ✗ Going back to edit or reinterpret old StateAssertions after changing a threshold or NormalizationMethod (e.g. “We updated the criteria, let’s ‘fix’ last quarter’s records to match”). ✓ Never alter historical assertions: Leave history as-is. If criteria change, issue new assertions under the new criteria going forward, and if needed, explicitly version the NormalizationMethod or UNM declaration or checklist. Past assertions remain valid for the old version and their time; new ones apply henceforth. This ensures auditability and avoids erasing or rewriting what was true under earlier standards.

C.27 temporal-claim relation.

• C.27 may flag: a rate or rate-change claim that needs base characteristic, scale and unit, time base or sampling window, transformation or finite-difference method, evidence, and admissible use.
• This pattern keeps: CharacteristicSpace coordinate discipline and the measurement-coordinate relation carried with C.16.
• Non-admissible use: derivative-like words such as velocity, acceleration, throughput, cadence, or recovery speed do not make a free characteristic, metric, or measurement template.
• Use boundary: when the interpretation governs the current claim, cite baseCharacteristicRef, the relevant measure reference, sampling window, construction method such as DHCMethodRef, and the C.16 measurement or construction relation reference; C.27 does not define a parallel measurement system.

A.19.ECS object-under-improvement evaluation construction relation.

• A.19 defines CharacteristicSpace as an ontological structure: slots, characteristics, scales, value sets, overlays, and comparability boundaries.
• A.19.ECS governs the construction of one object-under-improvement evaluation CharacteristicSpace for an object being improved. It is used before E.22 and E.23 when no adequate object-under-improvement evaluation exists.
• Existing object-under-improvement evaluation patterns such as E.21, E.9.DA, E.2.DA, and the naming vector inside F.18 are examples of this construction shape for object kinds under improvement. They keep their own coordinate, value-meaning, and stop-condition definitions.

#Consequences

#Rationale

A characteristic space is the minimal object that keeps multi-characteristic claims from becoming loose feature lists. The pattern binds each characteristic to a scale and value set, then lets neighboring patterns consume the declared space for state predicates, thresholds, comparisons, gates, evaluations, assurance, dashboards, and dynamics models.

The separation matters because a threshold or region is not the space, yet its semantic predicate is reusable before and after any one evaluation. A.19 owns that by-value predicate; direct consumers own comparison, acceptance, selection, assertion, evidence, publication, and decision occurrences and results.

#SoTA-Echoing

Measurement and evaluation practice requires explicit variable definitions, scales, units, value ranges, missingness treatment, normalization, and comparability before multi-criteria comparison is meaningful. A.19 adapts that discipline to FPF by treating the characteristic space as the declared ontic object and by moving scoring, indicator choice, normalization, and assurance use to their governing patterns.

Dynamical-systems and state-space practice supplies the useful hook: a dynamics model needs a declared state space, but the state space does not itself define the law, time base, observation model, or intervention. FPF keeps that boundary so that characteristic-space declarations can be reused across system, episteme, evaluation, and architecture work without smuggling consumer semantics into the space.

#C.29 mathematical-lens use relation

If topology, order, distance, product, subspace, embedding, or metric is only a CharacteristicSpace overlay, stay in A.19. If the overlay becomes a mathematical lens used to explain, predict, bridge, assure, publish, compare across reference schemes or planes, or carry a reusable explanation, add the applicable C.29 lens-use result. C.29 does not replace the A.19 space or predicate declaration.

#Source-use basis and currentness

A.19 is primarily internal-kernel doctrine, not an external SoTA-import pattern. The accepted FPF basis for U.CharacteristicSpace is the chain of A.17 for U.Characteristic, A.18 for scale and value discipline, C.16 for measurement and coordinate evidence, A.19.UNM for normalization methods, C.29 when a mathematical lens is used beyond local space declaration, and E.24 for ontic-head and slot-relation discipline.

Currentness is therefore inherited through that chain. Reopen A.19 when any governing pattern in that chain changes characteristic identity, scale semantics, value-set meaning, missingness semantics, normalization admissibility, comparability, bridge discipline, mathematical-lens boundary, or ontic slot discipline. Do not reopen A.19 merely because one consumer pattern adds a new score table, dashboard, evaluation report, certification interface, or portfolio view that uses a declared CharacteristicSpace.

#Relations - Ontic Relations and Consumer Boundary

• Builds on: E.24 for ontic-head discipline, A.6.5 for declaration SlotSpecs, A.17 and A.18 for characteristic and scale discipline, A.2.6 for U.ClaimScope membership over exact U.ContextSlice values, and C.16 for measurement and coordinate claims.
• Coordinates with: A.19.CPM for comparator and comparison scope; A.19.SelectorMechanism for explicit selection conditions; G.4 and other direct consumers for typed predicate evaluation; F.9 for cross-scheme and cross-plane Bridges; A.10 and G.11 for provenance and currentness; and C.2.1 when a predicate description or evaluation assertion is itself an episteme.
• Does not replace: dated evaluation work, actual operation applications and typed results, evidence-use relations, consumer applicability, comparison or selection mechanisms, publication forms, source-set relations, or C.29 mathematical-lens use.

#A.19:End

---

Last Updated: 2026-08-05 — upstream FPF commit 3dbce514 (github.com/ailev/FPF)