#A.CHR-SPACE — CharacteristicSpace & Dynamics hook

Pattern A.19 · Stable Part A - Kernel Architecture Cluster

Informative (navigation only). This subsection is a didactic index for human readers. It introduces no new norms and does not change semantic ownership.

#Keywords

• state space
• CharacteristicSpace
• dynamics
• state model
• RSG.

#Relations

#Content

#Reading path for engineer-managers

Informative (navigation only). This subsection is a didactic index for human readers. It introduces no new norms and does not change semantic ownership.

When to use this path. You need to review a CHR-enabled plan or audit, or coordinate engineering work across teams, without deep-diving every CHR mechanism up front.

Step 1 — Measurement vocabulary: what is measured, and what “comparable” can mean.

• A.17 — canonizes the technical anchor Characteristic (and retires near-synonyms such as “axis/dimension/feature/property/metric” from normative Tech register).
• A.18 — CSLC discipline (Characteristic / Scale / Level / Coordinate) as the metrology of interpretability, comparability, and lawful aggregation.
• C.16 (MM‑CHR) — the measurement substrate (U.DHCMethodRef, U.Measure, U.Unit, U.EvidenceStub) and the conservative baseline of direct comparability (“same template”). C.16 makes coordinates auditable; it does not define CHR mechanisms.

Step 2 — Ontology and contract surfaces the CHR suite operates on.

• This pattern A.19 — U.CharacteristicSpace and the dynamics hook: the base ontology of measurable coordinates and their spaces.
• A.19.CN — CN‑frame / CN‑Spec: the governance card for normalization and comparability routing, indicator policy, aggregation routing, and acceptance; it explicitly points to C.16 for evidence/backing and to G.0 for legality gates.

Step 3 — Legality gates and mechanism shape (what to check when numbers appear).

• G.0 (CG‑Spec) — the legality gate for numeric operations and comparisons (SCP, ComparatorSet, MinimalEvidence, Γ_fold, crossings/plane pins). CHR mechanisms cite CG‑Spec; they do not duplicate it.
• A.6.1 / A.6.5 — the mechanism norm‑form (U.Mechanism.Intension) and slot discipline. Read once so the structure of each mechanism owner pattern (slots, operators, laws, admissibility guards, audit anchors) is predictable.

Step 4 — The CHR suite boundary and the P2W seam.

• A.19.CHR (CHRMechanismSuite) — focus on:
  • A.19.CHR:4.1 (published objects),
  • A.19.CHR:4.2.1 (CHR SlotKind lexicon),
  • A.19.CHR:4.2.2 (canonical mechanism targets),
  • A.19.CHR:4.5 (suite protocols — order/optionality live here, not in mechanisms[]),
  • A.19.CHR:4.6–4.7.2 (P2W planned-baseline hook and the plan-item shape),
  • A.19.CHR:7 (suite conformance checklist).
• A.15.3 — SlotFillingsPlanItem (planned baseline discipline: planning vs enactment).
• E.18 (E.TGA) — how to express the actual pipeline/flow graph (including crossings) while keeping suite and plan artefacts refs‑only.

Step 5 — The six CHR mechanism owner patterns (read one at a time).

Each mechanism below owns its U.Mechanism.Intension card and assumes the measurement-lawfulness base from A.17/A.18 and C.16.

1. A.19.UNM — normalization (CV→NCV, ≡_UNM, TransportRegistryΦ).
2. A.19.UINDM — indicatorization (policy-bound indicator selection; no “NCV ⇒ indicator” shortcut).
3. A.19.USCM — scoring (SCP-first; no implicit UNM).
4. A.19.ULSAM — lawful aggregation (explicit Γ_fold; ordinals are not averaged).
5. A.19.CPM — comparison (set-valued outcomes; no silent scalarisation/totalisation).
6. A.19.SelectorMechanism — selection kernel (set-returning; dominance/portfolio defaults are policy-bound).

Step 6 — Specialization and reuse.

• E.20 — how to use specializations of mechanisms (⊑ / ⊑⁺) without breaking SlotKind meaning or introducing hidden inputs; consult this whenever you see project‑ or domain‑specific variants of the CHR mechanisms.

Fast review entry points.

• If you are reviewing a plan: start from A.19.CHR:4.6–4.7.2 (planned baseline hook + plan item shape) and A.15.3 (what a planned baseline may/may not contain).
• If you are reviewing semantic drift: start from A.19.CHR:4.2.2 (canonical targets), then use E.10 (suffix discipline) and F.18 (alias docking) to preserve public continuity while fixing terminology.
• If you are reviewing conformance: start from A.19.CHR:7 (suite checklist), then consult the relevant A.19. checklist(s) for mechanism-level conformance; use E.19 for the review protocol.

Non‑duplication note. This pattern defines U.CharacteristicSpace and the typing hook U.Dynamics.stateSpace. It reuses the canonical measurement concepts (U.Characteristic, CSLC terms) from A.17/A.18 and remains notation‑neutral about storage/IDs.
This pattern is intentionally not a second semantic owner for CHR mechanisms: it may use CHR‑mechanism terms when talking about comparability and certification, but it does so strictly by Tell + Cite to the corresponding A.19.<MechId> mechanism‑owner patterns.

Single‑owner rule (Normalization & CHR mechanisms referenced here). This pattern MUST NOT be a second semantic owner for CHR‑mechanism vocabulary.

• Normalization vocabulary + admissibility (UNM artifacts: UNM, NormalizationMethod, NormalizationMethodDescription, NormalizationMethodInstance, NCV, ≡_UNM, NormalizationFix; κ‑retirement; “map vs Map” lexical guard) are owned normatively by A.19.UNM.
• Indicatorization vocabulary + admissibility (UINDM artifacts: IndicatorChoicePolicy, Indicator, IndicatorSet, indicatorization as a policy step; “NCV ⇒ indicator” prohibition) are owned normatively by A.19.UINDM.
• Other CHR mechanism vocabulary referenced here (e.g., scoring / aggregation / comparison / selection terms) is owned normatively by the corresponding mechanism‑owner pattern in the A.19.<MechId> family (e.g., A.19.USCM, A.19.ULSAM, A.19.CPM, A.19.SelectorMechanism).
• Evidence/calibration backing for normalization is owned by C.16 (MM‑CHR).
• CN‑frame surface wiring (how CN‑Spec references normalization/comparability by fields/refs) is owned by A.19.CN (CN‑Spec).
• Vocabulary extension rule. If this pattern needs a new normalization / indicatorization / scoring / aggregation / comparison / selection term, it SHALL be introduced in the corresponding mechanism‑owner pattern first, then cited here (Tell + Cite). A.19 SHALL NOT mint new CHR‑mechanism vocabulary.

Terminology pointer (informative; do not duplicate). When A.19 uses normalization or indicatorization terms below, it uses them by reference to A.19.UNM / A.19.UINDM and C.16. This pattern only constrains how such artifacts are cited when doing state‑space comparability, embeddings, and certification.

Reader map (informative).

• If you need the meaning of UNM, NCV, ≡_UNM, or NormalizationFix / NormalizationFixSpec: see A.19.UNM.
• If you need the meaning of IndicatorChoicePolicy / indicatorization: see A.19.UINDM.
• If you need the CN‑Spec field/Ref wiring (CN_Spec.normalization, CN_Spec.comparability.*): see A.19.CN.
• If you need evidence/calibration backing for normalization or scoring legality: see C.16 (MM‑CHR).
• If you need cross‑context alignment mechanics: see F.9 (Alignment Bridge) and the Transport discipline (A.6.1).

#Intent & Scope (Normative)

Intent. Establish a kernel‑level state‑space type—U.CharacteristicSpace—so that any holon’s state changes (e.g., a system’s condition or a role’s readiness) can be formalized as trajectories in a space of declared Characteristics with chosen Scales. For epistemes, state is governed by ESG; F–G–R are assurance coordinates, not a state space. This gives every U.Dynamics model a well‑typed stateSpace and enables formal state certification (using RoleStateGraph checklists) instead of narrative stage transitions.

Scope. Pattern A.19 defines:

• the type U.CharacteristicSpace as a finite product of slot value sets (per A.18),

• the slot construct for each factor (a pairing of a Characteristic with a chosen Scale),

• minimal structural overlays (optional order, topology, metric hooks) that downstream patterns may attach to a space, and

• the hook U.Dynamics.stateSpace : CharacteristicSpace – i.e. the requirement that any dynamics model declare a CharacteristicSpace for its state space (typing only).

A.19 does not introduce any new measurement aspects, composite metrics, or normalization semantics (owned by A.19.UNM, with evidence/calibration under C.16 (MM‑CHR)), and it does not define how dynamics evolve over time or any predictive laws (see A.3.3 for dynamics semantics). The focus here is purely on the structure of state spaces and their comparability.

Lexical guard (“map”). Follow the normalization lexical discipline owned 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 (“carrier”). In kernel prose, Carrier (capitalized) names U.Carrier (a symbol bearer). Do not use “carrier” for set‑theoretic supports; prefer ValueSet/underlying set. A.19 therefore uses ValueSet(slot) for the set that supplies values to a slot.

#Context (Informative)

FPF’s kernel already standardizes what is measured (a Characteristic, per A.17) and how it is measured (a Scale with units, via the CSLC Standard in A.18). We also have a measurement substrate (U.DHCMethodRef, U.Measure) to handle individual observations. What has been missing for modeling dynamics is a canonical “Context” in which multiple Characteristics can co-exist so that complex states (with many aspects) and their trajectories are well-typed and comparable. Without a formal CharacteristicSpace, teams either hard-code ad-hoc vectors (often with inconsistent assumptions) or fall back to informal lifecycle stories (“phases” or stages) that contradict the kernel’s open-ended, non-linear evolution paradigm. The Architectural patterns (A-cluster) expect that U.Dynamics.stateSpace will be a set of declared Characteristics each with a declared Scale. Pattern A.19 delivers exactly this capability, leveraging the CSLC measurement discipline without reinventing any arithmetic or unit-handling logic.

#Problem (Informative)

• P1 — “Feature vector” drift. In practice, teams often assemble state vectors or “feature” lists with implicit or mismatched units and scales. Without a formal space, one coordinate’s value can’t safely be compared or combined with another’s (e.g. mixing degrees Celsius with percentages). CSLC guarantees consistency per Characteristic, but a bundle of multiple “characteristics” remains under-specified if we lack a unified space definition.

• P2 — Lifecycle bias. Absent a formal state space, system change tends to be described in terms of fixed stages or phases (design phases, maturity levels, etc.). This conflicts with FPF’s open-ended stance: in FPF a role’s state model (RSG) allows re-entry and refinement of states rather than one-way lifecycle stages with an “end.” We need a space model that treats evolution as continuous movement, not a one-directional sequence.

• P3 — Incoherence across CN‑frames. Different modeling “CN‑frames” (architecture vs. epistemic vs. operational) often choose different sets of qualities to measure (different sets of characteristics). Later, however, we may need to compose these models or project one into another. Without a kernel notion of how one state space can be a subspace of or embedded in another, any integration of models will be ad hoc and error-prone.

• P4 — Relational measurements. Some Characteristics are inherently relational (e.g. a Coupling between two components, or Distance between points). Naïvely forcing such traits into a single-object feature vector loses critical information (arity, symmetry). The kernel already distinguishes single-entity vs multi-entity Characteristics (A.17); we must preserve that distinction in the state space so that a relational metric isn’t treated as an intrinsic one by mistake.

• P5 — The geometry temptation. When defining a state space, it’s tempting to assume or inject additional structure (ordering of states, topologies for continuity, metrics for distance) as if inherent. But the kernel must remain minimal and domain-neutral: it should not smuggle in analysis methods or domain-specific norms under the guise of geometry. Any such structure should be added explicitly by specialized patterns, not baked into the core definition of a space.

#Forces (Informative)

• F1 – CSLC integrity at scale. When combining multiple measurements into a state, we must uphold the CSLC discipline for each component: each coordinate has a defined Characteristic, Scale type, unit, and (if applicable) polarity. We need to do this without redefining or duplicating that single-characteristic integrity – the multi-dimensional space should simply enforce CSLC per slot.

• F2 – Transdisciplinarity & lexical clarity. The state space framework must work for quantitative physical metrics (ratio scales, continuous units), qualitative assessments (ordinal scales, tiers), and mixtures thereof. It must not be biased toward one domain’s notion of measurement. At the same time, to avoid confusion, the lexicon must remain canonical: we use Characteristic (not “axis/dimension”) as the formal term for a measured aspect, regardless of domain, per A.17’s naming convention.

• F3 – Arity and semantics. Lifting various Characteristics into a unified space should not obscure their nature. If a Characteristic is defined as a relation (multi-entity property), the state space must represent it appropriately (e.g. as a coordinate that is a tuple or a symmetric relation) rather than flattening it into an unrelated scalar. Entity-specific vs relational properties must remain clear in the space’s structure.

• F4 – Minimal core, extensible further. The kernel should provide only the bare essentials: a carrier for state with proper typing. It should be possible to impose additional structure like order, topology, or metrics if and when needed by downstream theories, but these must be optional overlays. The core space definition should be minimalistic to allow broad use, yet capable of extension for advanced needs.

• F5 – Composability of spaces. We need well-defined operations to project a state space to a subspace (dropping some Characteristics), embed one space into a larger space (mapping coordinates from one context to another), and take products of spaces (combining different state spaces into a joint space). These operations are crucial for composing sub-models, comparing alternatives, or aligning different “CN‑frames” (for example, linking an architectural model’s state space with a metrics model’s space). The approach must support such composition in a principled way.

• F6 – Alignment with RSG (state machines). In FPF, formal state certification is done via checklists on RoleStateGraphs (A.2.5). Our state space concept must complement that: i.e. the state of a holon remains an intensional concept (defined by criteria), but those criteria are evaluated against the measurable coordinates in a CharacteristicSpace. The design must allow checklists to map observed coordinates to named states and enable re-certification as states evolve, rather than locking states into a static progression.

#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 (or key) that can be used in data structures or APIs. These basis names should be treated as technical identifiers (machine-readable tokens); 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-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 (or key) that can be used in technical notations and interfaces. 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 normalizations or aggregations). A CharacteristicSpace itself carries no implicit normalizations or formulas for combining coordinates. It is a descriptive structure, not a scoring mechanism. Any computation that combines or transforms coordinates (e.g., normalizing, indicatorizing, scoring, Γ‑folding, comparing, or selecting) must be defined outside the core space—typically as an explicit CHR mechanism step and cited from its designated mechanism‑owner pattern (A.19.UNM, A.19.UINDM, A.19.USCM, A.19.ULSAM, A.19.CPM, A.19.SelectorMechanism).
  Normalization semantics and admissibility are owned by A.19.UNM; evidence/calibration backing is owned by C.16 (MM‑CHR).
  In particular, any handling of polarity (which way “better” is), weighting, or cross-slot aggregation happens in those external mechanisms/policies, not inside the space definition. The space provides the raw coordinates; the logic to interpret or aggregate them is added by domain‑specific layers with explicit disclosure of how it’s done.

• 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.

#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/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 support particular needs (like making dominance, continuity, or distance reasoning possible) in models that require them. 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 higher-level theories layer on 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 obligation: the dynamic model can only produce states (and trajectories of states) that lie in 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 axis 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 live, 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/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)

Owner 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, or comparability claim over a CharacteristicSpace SHALL be evaluated on quotients by ≡_UNM (or on explicitly Normalization‑fixed charts), not on raw labels. Design rule — read invariants, not labels. Any checklist, acceptance predicate, or comparability claim that depends on representation choice (chart, unit, reference plane, or normalization route) 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/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/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/parameters) and its declared domain of applicability.
2. Bound expansion. Any acceptance predicate/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 & commutation. If a metric is used together with NormalizationFix, the specification MUST state (a) the maximum tolerated measurement/calibration error and (b) whether d commutes with the NormalizationFix (or provide a disclaimer and additional guard if it does not).

#State Spaces & Comparability

Memory hook: We compare only what lies in the same space (or is translated into a common space via a declared mapping), and we only certify a holon’s state based on observable coordinates in that space (using a defined checklist). Anything else is just storytelling.

To make state-space reasoning practical across different contexts and models, this section provides the key operators and criteria related to CharacteristicSpaces:

1. Space operations – how to derive a Subspace, establish an Embedding, or form a Product of spaces. These enable us to restrict a space to fewer slots, to map one space into another (with unit conversions, etc.), or to combine spaces (e.g. for composite models).

2. Comparability regimes – two allowable ways to compare states: (a) coordinatewise, which requires strict sameness of space and units; or (b) normalization-based, which uses declared transformations to reconcile differences. We define when each applies and how to apply it properly.

3. RSG integration – how formal state certification (via checklists in a Role’s state graph) ties into the CharacteristicSpace: ensuring that whenever we declare a system “Ready” or “Degraded”, it’s based on snapshot coordinates in a space. We also outline how to push or pull state definitions along space embeddings (so different contexts can translate states).

4. Archetypal examples – “worked mini-schemas” illustrating typical usage in complementary CN‑frames (Operational, Assurance, Alignment). These examples show minimal models mixing entity and relational slots, how data might be structured, and how cross-context alignment works in practice.

Terminology note: We often denote a CharacteristicSpace abstractly as CS. Formally, one can describe a CS as a tuple ⟨I, basis⟩ where I is the index set of slots and basis is the set (or ordered list) of slot_i pairs. When a CharacteristicSpace is attached to a specific Role in a specific Context (see A.2, A.2.5), we may call it an RCS (Role CharacteristicSpace) – essentially the state space for that role’s state machine within that bounded context. Individual states of a role live in an RSG (RoleStateGraph, A.2.5), and a StateAssertion is a certified claim that at a given time window, the holon’s RCS coordinates satisfy the checklist for a particular state.

#CS Operators (notation-neutral, context-local)

To support model composition, we define operations on CharacteristicSpaces in a notation-independent way (so these can be implemented in any tooling or notation). All these operations are assumed to occur within a single context (within one U.BoundedContext) unless otherwise noted:

#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/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:

Embeddings are defined within a single U.BoundedContext (i.e., both CS₁ and CS₂ are in the same context). Using an embedding across contexts requires an Alignment Bridge (see F.9) and MUST be declared via the relevant mechanism’s A.6.1 Transport clause (BridgeId + channel + ReferencePlane(src,tgt) + any CL^plane; no implicit crossings).

Normalization declaration duties (MUST): Each cited NormalizationMethodInstanceId MUST satisfy the declaration/admissibility obligations owned by A.19.UNM (incl. method‑class token and validity window). If such normalization artifacts are used for gating or assurance, their evidence/calibration backing and waiver rules are governed by C.16 (MM‑CHR). In other words, you cannot assume one context’s space fits into another’s without an explicit Bridge; any attempt to do so must treat it as a cross‑context alignment with potential loss.

#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 state label like "Ready", "Authorized", "Degraded", etc., in an RSG is an intensional category (defined by a checklist of conditions – see A.2.5). Determining whether the states of two holons are comparable (e.g. whether one is “better” or “worse” than the other in some multi-criteria sense) depends on where their state coordinates live and how we map those coordinates to a common basis. There are two admissible comparability regimes in FPF:

#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. The two holders’ state snapshots lie in the exact same CharacteristicSpace (and, if relevant, the same RCS attached to a Role in a given Context). It’s not enough that they have similarly named characteristics; they must share the actual defined space (same slots with same definitions).

• Scale congruence. For each slot being compared, the scale type, unit, and polarity orientation are identical. For example, if comparing temperature readings, 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.

• State-definition congruence. The states or status labels themselves must be defined in terms of the same checklist criteria applied in the same space. In other words, if we are comparing whether one system is “Ready” and another is “Ready”, both instances of “Ready” must derive from the same formal definition (same thresholds, same checklist logic) over those coordinates. If one context’s "Ready" means something different, you cannot assume they correspond.

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).

• Threshold band inclusion: If states are defined by meeting certain thresholds (e.g. State Y means all metrics above specific levels), then we might say x ≼_coord y if x meets every threshold 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 exceeds those thresholds.

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/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 landing in a common, well‑typed space.

If the normalization crosses context boundaries (i.e., CS₁ and CS₂ are in different bounded contexts), then by FPF policy this mapping MUST be treated as a formal Alignment Bridge (F.9) with an associated congruence‑loss (CL) level and MUST be declared via the relevant mechanism’s A.6.1 Transport (BridgeId + channel + ReferencePlane(src,tgt); no implicit crossings). In such cases, any conclusions drawn carry an assurance penalty per B.3 (Φ(CL)).

Auditability. Each cited NormalizationMethodInstanceId used for comparison SHOULD be transparent via its referenced description/edition (per A.19.UNM). Evidence/calibration backing and waiver discipline are owned by C.16 (MM‑CHR). The key here is that no comparison is magic – if values differ in scale or context, the normalization route and its limitations must be explicit.

Mnemonic: “Never compare before you land both points in the same well-typed space.” In other words, always map measurements to a common basis (same CharacteristicSpace and units) before attempting to say one state is ≥ or ≤ another. Directly comparing raw numbers from different scales or contexts is not allowed.

#RSG touch-points — State certification via CS

To connect the abstract concept of a space of metrics with the operational concept of states (like “Ready” or “Degraded”) in a Role’s lifecycle, we introduce a certifier function that evaluates state predicates against coordinates:

certify(Role, Context): Snapshot( RCS[Role,Context], Window ) ──→ {StateAssertion}

This is a conceptual sketch: given a snapshot of all relevant coordinates for a Role (in its RCS) over some time window, the certifier produces a set of StateAssertions that are deemed true in that window. Each StateAssertion claims that the holder is in a particular state (e.g. “Ready”) during the window, backed by evidence.

5.2.3.1 From CS snapshot to StateAssertion (design → run). Each possible state s in a Role’s RSG has an associated Checklist (s) – a design-time artifact (see A.2.5 §8.1) which is a predicate defined over the RCS’s coordinates (and possibly other contextual observables). For example, a state “Degraded” might have a checklist like “[temperature < 50 °C] AND [pressure > 5 bar] for 10 minutes”. When the system is running, we take an Observation of the current coordinates (a snapshot of the RCS at a given time or over a time window) and evaluate the checklist. A StateAssertion(holder, s, Window) is then a record that the checklist for state s has been satisfied by the observed data in that interval. In other words, it’s a certified evaluation that “state s holds true for this holon at this time.” Only observable, measurable facts go into these predicates (no subjective judgments), and each assertion is traceable to the specific evidence (observations) that support it. The Role’s Green-Gate Law (A.2.5 §8.4) then says that a Role can proceed with an enactment (e.g. performing work) if and only if there is a StateAssertion showing the holon to be in an enactable state at that time. This connects measurement to action: you can only act if you have evidence you’re in the right state to act. Evidence kind & window. Every StateAssertion SHALL record evidence_kind ∈ {observation, prediction}, the window [t_from, t_to], and, if prediction, the horizon Δt relative to the observation base. Use of prediction in enactment gates is permitted only under the DYN/TIME constraints captured in CC‑A19.17–A19.18; otherwise a fresh observation is required.

5.2.3.2 Translating state definitions across embeddings. If we have an embedding ι: RCS₁ ↪ RCS₂ (for example, RCS₁ is a subspace or a different version of RCS₂), we might want to reuse or compare state definitions between the two. There are two directions to consider:

• Pulling a checklist (reuse state criteria from a larger space in a smaller space): Given a checklist defined on RCS₂ (the larger or target space), we can pull it back via the normalization map N of the embedding to get a predicate on RCS₁. This derived checklist (Checklist₂ ∘ N) lets us apply the RCS₂’s state definition to a holon that only has RCS₁ measurements. This is useful when a consumer context wants to evaluate whether a producer (with fewer characteristics or different units) meets the consumer’s state definitions. Essentially, the consumer asks: “If I map the producer’s metrics into my space, does it satisfy my state criteria s?”
• Pushing an assertion (honor a producer’s certified state in a larger space): If a holon has a StateAssertion for state s’ in RCS₁, can we treat it as evidence for state s in RCS₂? This is only valid under a strict condition: the checklist for state s in the larger space, when composed with the normalization mapping N, must logically imply the checklist s’ in the smaller space (or vice versa, depending on which state corresponds to which). In practice, this often requires a proof of refinement: that meeting state s (in big space) guarantees state s’ (in small space), or that state s’ (in small) is sufficient for state s (in big space) given the normalization translations. If that condition is met (or a policy waiver is granted in lieu of proof), then an assertion in the smaller space can be pushed up to count as an assertion in the larger space. This mechanism allows, for example, a component’s certified state to satisfy a system-level state requirement, provided the relationship is formally established.

5.2.3.3 Certification interface (pointer). Operational interface examples and minimal data stubs are informative and live in A.19.CN (“Certification Interface Example”). Pattern A.19 only constrains conceptual obligations; no storage/ID scheme is mandated here.

(In summary, embeddings not only allow numeric comparability, but also allow state definitions and certifications to be systematically translated between contexts, ensuring consistency in how we interpret “Ready”, “Failed”, etc., across different models.)

#Cross-context comparability & assurance hooks

When comparing states or metrics across different bounded contexts (different “context of meaning”), additional rules apply to maintain semantic integrity:

#A.19:5.2.4.1 Direction & loss (Bridges).

Suppose we want to claim that “Holon X in Context B is in state Ready as defined in Context A.” This requires an explicit Alignment Bridge declaration that maps the RCS of (Role, Context B) to the RCS of (Role, Context A) (or maps State B to State A). Such a Bridge (see F.9) will specify the correspondence of Characteristics (and the necessary NormalizationMethods under UNM) and a congruence‑loss (CL) level indicating how much fidelity is lost in translation. Critically, these Bridges are one-directional mappings unless explicitly made bidirectional. Just because we can interpret B’s state as an A-state does not mean we can go the other way without another mapping. The Bridge makes the mapping and any loss explicit. Without a declared Bridge, cross-context state comparisons or substitutions are not valid – there is no implicit global state space. The statement above, for instance, would only hold if we have something like “Bridge B→A (with defined NormalizationMethods) such that X@B can be viewed in A’s terms.” The direction matters: “B satisfies A’s Ready” does not imply the converse unless another bridge (A→B) is defined.

#A.19:5.2.4.2 Confidence penalties for mapped comparisons.

Whenever a normalization-based comparison crosses Contexts (via a Bridge), assurance MUST apply the penalty Φ(CL) as defined in B.3 (CL is ordinal there). For episteme‑specific compositions, B.1.3 instantiates the same policy. This pattern does not restate the scale or Φ; it defers to B.3. For example, a safety argument that relies on a cross-context comparison might need to downgrade its certainty or include an extra safety margin. This penalty MUST be declared as part of the assurance argument for the comparison (stating the Bridge used and its CL), so that the Φ(CL) discount can be reasoned and applied. No implementation‑level storage format or identifier is mandated by this pattern.

#A.19:5.2.4.3 Declare “incomparable” when appropriate.

If for some critical Characteristic there is no valid NormalizationMethod to translate measurements between two contexts (e.g. the scale types are fundamentally different, or the measurement’s meaning doesn’t carry over), then the framework insists that we declare the states or metrics incomparable rather than attempting any fudge. No comparison should ever default to “close enough by name” or other heuristics. For instance, if one context measures “User Satisfaction” qualitatively and another quantitatively, and no monotonic mapping can be justified, one must simply say a user satisfaction state in context A cannot be compared to one in context B. Mark it incomparable and avoid any misleading conclusions. This rule guards against the natural temptation to compare things just because they have the same label or general intent, when in fact their measurement basis is different.

#Certification pipeline (Minimal, Normative)

Canonical evaluation chain (notation‑neutral):

raw coords → Normalize (UNM.NormalizationMethodInstance) → Quotient / NormalizationFix → (optional) Indicatorization (via IndicatorChoicePolicy) → (optional) Order/Distance overlay → Evaluate Checklist → StateAssertion → Green‑Gate

Strict distinction. Steps may be co‑implemented, but are logically distinct and MUST be referenceable in assertions (NormalizationMethodInstance/UNM name or formula, overlay kind). A gate is invalid if any required step lacks a current, valid referent (e.g., expired NormalizationMethodInstance edition).

#Operator library (notation‑neutral)

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

States/criteria transport: Pull (pull checklist via embedding/NormalizationMethodInstance), Push (push assertion along embedding with proof/waiver), Indicatorize (apply IndicatorChoicePolicy to select Indicators), Align_B (cross‑context alignment via Bridge with CL), Fold_Γ (admissible aggregation/accumulation per B.1, with WLNK/MONO constraints).

OP‑1 (Normative). If Align_B is used in gating, the Bridge used and its CL MUST be declared in the assurance argument; the corresponding Φ(CL) penalty is applied per B.3. Silent cross‑context reuse is forbidden. (A.19 does not mandate any storage/ID scheme.)

#Conformance Checklist (normative) — CC‑A19

Formality anchors & operational segregation (normative). A.19 aligns with C.2.3 Unified Formality Characteristic (F). The legacy tier labels T0/T1/T2 are deprecated; speak F directly and treat operations separately (see E.10 for registers). — F-Surface (recommended F ≥ F3). Obligations are declarability and arguability: the author can name the CharacteristicSpace (basis/slots as (Characteristic, Scale) pairs), state the comparability regime (coordinatewise or normalization-based), and express a state’s checklist in observable coordinates. No storage formats, IDs, or operational provenance are required. — F-Predicates (F ≥ F4 when predicate-like). As above, plus explicit slot/NormalizationMethod names and stated overlays (order/metric). When acceptance conditions are written as typed predicates over coordinates, declare F ≥ F4. Remains notation-neutral and storage-agnostic. — Operational bindings (not part of F). When automatic checking/assurance is required, use A.19.CN / C.16 / B.3 for IDs, validity windows, waivers, and logs. These raise R/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/unit from CS₂’s. The cited instances MUST satisfy the admissibility/declaration obligations owned by A.19.UNM (incl. monotonicity w.r.t. polarity, validity window, and method‑class token) and, when used for gating/assurance, MUST be evidence‑backed per C.16. (Identity suffices where scales are identical.) CC‑A19.2a. Scale‑class guard (by reference). The scale‑class requirements for admissible normalizations are owned 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/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-context state comparison or substitution MUST cite a corresponding Alignment Bridge (F.9) with an explicit CL (congruence-loss) level. If such a Bridge is used in an assurance or decision-making context, the model MUST apply the appropriate confidence reduction (Φ(CL) penalty per B.3) to reflect the loss. Cross-context comparisons without a Bridge (i.e. assuming equivalence by name or convention) are forbidden.

Certification & enactment
CC‑A19.6. Every StateAssertion MUST identify at least: the specific state being asserted (by name), the associated checklist or criteria set (by name), and the observation window. Furthermore, if the evaluation involved cross‑space mapping, it MUST declare which NormalizationMethod(s) or Bridge were applied. This ensures the decision can be examined in review; A.19 does not mandate any storage/ID scheme.

CC‑A19.7. The Green-Gate enactment rule (A.2.5) SHALL be enforced: a transformative action (U.Work) by a RoleAssignment is only allowed if there exists a contemporaneous StateAssertion showing the holon in a state that is marked enactable. If a StateAssertion has been translated from another context or space, it is valid for gating only if it was obtained through declared Embeddings/Bridges (no untracked inferences). This ensures no work is done under an unverified or mis-mapped state condition.
CC‑A19.8. All Checklist definitions for states MUST be formulated in terms of observable predicates on the RCS (and known context events) – no hidden workflows or implicit time sequencing inside a checklist. A checklist should read like a static predicate (even if it’s about a duration of some condition). If temporal order or multi-step processes are involved in achieving a state, those must be modeled via explicit Methods/Work or via an aggregation logic (e.g., using the Γ (Gamma) patterns in B.1 for process sequencing), rather than being baked into the state’s definition. Use of Indicators in any checklist MUST cite an IndicatorChoicePolicy edition; treating any NCV as an Indicator without policy is forbidden.

Anti‑drift
CC‑A19.9. If a NormalizationMethod/UNM or a state checklist is updated or calibrated differently in a new version, previous StateAssertions MUST NOT be retroactively modified. One must close out or mark the old assertions with their valid time window and start issuing new assertions under the updated definitions. In other words, historical records remain as they were (tied to the definitions at that time), and any change in criteria results in a new context or version for future assertions. This prevents retroactive truth-changing and maintains integrity of historical data.
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. All used method‑class tokens for cited NormalizationMethodInstanceId(s) MUST be named in the bounded context’s glossary (per the taxonomy owned by A.19.UNM). Do not restate the class taxonomy here.

Metric discipline & calibration (MET) CC‑A19.14. If a distance overlay is used, acceptance predicates/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/acceptance checks MUST carry max tolerated error and, where claimed, a Lipschitz bound for the NormalizationMethod composition in use. CC‑A19.16. Cross‑CN‑frame inputs SHALL name the normalization transform and its validity window; expired transforms are invalid for gating unless waived explicitly.

Dynamics & time (DYN/TIME) CC‑A19.17. Every temporal guard MUST specify the window [t_from, t_to] and evidence_kind ∈ {observation, prediction}; if prediction is used for gating, the conditions in § 5.2.3.1 (Evidence kind & window) MUST hold. CC‑A19.18. Any dynamics map Φ_{Δt} used in comparison/gating MUST be non‑expansive (Lipschitz ≤ 1) under the declared distance overlay and commute with NormalizationFix; otherwise observation is required.

Certification (CERT) CC‑A19.19. StateAssertions MUST state the current NormalizationMethod/UNM and overlay artifacts used (by name or formula) and the evidence_kind; assertions relying on expired NormalizationMethod/UNM are invalid for gating unless an explicit Waiver SpeechAct is declared per policy. (A.19 imposes no requirement on IDs or storage.) CC‑A19.20. The certification pipeline steps (Normalize (UNM.NormalizationMethod); Quot/Fix_normalization; overlay; evaluate; assert) are logically distinct and MUST be reconstructable in argument/review; collapsing steps without clearly stated referents violates A.19. (No specific persistence format is implied.)

Operators (OP) CC‑A19.21. Use of Align_B in gating MUST declare the Bridge used and propagate CL into assurance (B.3). Cross‑context comparison without a Bridge is forbidden. (No requirement to store an ID is imposed by A.19.)

#Anti‑patterns → safe rewrites

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

• “Same label ⇒ comparable.”
  ✗ Assuming Ready@contextA ≥ Ready@contextB just because both states are called "Ready".
  ✓ Explicitly normalize and bridge contexts: Define an Alignment Bridge (B→A) and appropriate NormalizationMethods for the underlying metrics. Then compare by first translating one state’s coordinates (compute N(x) as NCVs in the target space) and using ≼_coord on the result.

• “Compare before landing.”
  ✗ 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 = workflow.”
  ✗ 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/UNM 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.

#A.19:End