#CN-frame (comparability & normalization)

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

Scope. This CN‑frame Algebra & Normalization Discipline extends A.19 by fixing the governance Standard for CN‑frames, defining a conformance checklist and regression harness, and providing didactic one‑pagers and anti‑patterns so teams can introduce CN‑frames without tool lock‑in. The mandatory pattern structure and authoring discipline from Part E (Style Guide, Tell‑Show‑Show, checklists, DRR, guard‑rails) are applied throughout.

Single‑owner boundary (cite, don’t duplicate). A.19.CN owns the CN‑frame governance card, registry, bridges, and checklist/harness (CN‑Spec, registry, bridges, checklist/harness). It does not own any CHR‑mechanism intensions, term cards, or method taxonomies. Those are owned by the corresponding mechanism patterns (A.19.UNM / A.19.UINDM / A.19.USCM / A.19.ULSAM / A.19.CPM / A.19.SelectorMechanism)**. Evidence/backing is owned by C.16; legality gates are owned by G.0. Therefore A.19.CN specifies where the references live, what must be cite‑able for audit, and how governance changes trigger regression — not mechanism semantics.

Reader map (fast navigation).

• “What does NormalizationMethodId/…InstanceId/≡_UNM/NormalizationFix mean?” → A.19.UNM.
• “What is an Indicator / IndicatorChoicePolicy and why NCV ≠ Indicator?” → A.19.UINDM.
• “Why can we trust a normalization / where does calibration or evidence live?” → C.16 (MM‑CHR).
• “What is lawful to compare/aggregate / what is MinimalEvidence?” → G.0 (CG‑Spec).

A.19 established a substrate‑neutral picture:

#Keywords

• CN-frame
• CN-Spec
• chart
• comparability modes
• normalization refs
• indicator policy refs
• Γ-fold governance
• registry
• bridges
• CL/loss notes
• WLNK discipline
• conformance checklist
• SCR/RSCR harness
• RSG admission hooks.

#Relations

#Content

#Context

A.19 established a substrate‑neutral picture:

• a CN‑frame = (Context‑local) CharacteristicSpace (CS) + chart (coordinate patch + units) + a referenced Normalization mechanism (UNM) pinned from CN‑Spec.normalization. Any semantics of admissibility, invariants, and ≡_UNM is owned by the UNM owner (see A.19.UNM);
• operators (subspace, product, pullback/pushforward) and comparability (coordinatewise vs normalization‑based (normalize‑then‑compare));
• RSG touch‑points: role readiness (RSG states) are certified against CS via checklists over observable characteristics;
• entity/relational mixtures across CN‑frames via minimal schemas and bridges.

Terminology guard. CN‑frame is the lens (I); CN‑Spec is the governance card (S) that fixes admissible charts/normalization references/comparability/Γ‑fold for that lens in one U.BoundedContext; CN‑Description is the didactic surface (D) with worked examples and anti‑patterns. Mechanism‑level term cards (e.g., NormalizationMethod, NormalizationMethodInstance, NCV, ≡_UNM, IndicatorChoicePolicy) are owned by the corresponding A.19. patterns and are only cited here.

Lexical guard (map/Map, by reference). Follow the lexical discipline owned by A.19.UNM: avoid introducing new normalization tokens that use “map/Map/mapping” (because …Map is a Part‑G method‑type kind). In normalization contexts prefer normalize / transform / re‑parameterize. Legacy tokens (including retired κ‑notation) are handled via alias docking (F.18); A.19.CN applies this rule and does not redefine it.

A.19.CN makes this operational and auditable.

#Problem

Absent a governance layer, four failure modes recur:

1. Chartless numbers. Measures move between teams without units, reference states, or declared normalization → illusory comparability.
2. Hidden normalization flips. Re‑parameterisations (e.g., normalising by batch size) silently alter meaning; trend lines lie.
3. CN‑frame sprawl. Every initiative mints a new “dashboard dimension”; semantics diverge; assurance collapses.
4. Un‑bridgeable reports. Cross‑team roll‑ups average incongruent CN‑frames, violating the weakest‑link (WLNK) discipline from Γ and B.3.

#Forces

#Solution — The CN‑Spec (CN‑Spec) + Registry + Bridges

#The CN‑Spec (comparability & normalization specification per CN‑frame, in one U.BoundedContext)

A CN‑frame is governed by a compact, notation‑free card:

CN‑Spec {
  name              : CN‑frameName                  // local to Context
  context           : U.BoundedContext              // edition/version included
  cs_basis          : [{
    slot_id         : <tech-token>,                 // stable slot id (basis name)
    characteristic  : <U.Characteristic>,          // per A.17 / A.18
    scale           : { type: nominal|ordinal|interval|ratio, unit?: <U.Unit>, bounds?: <… > },
    polarity        : up|down|target-range,        // comparison orientation
    // if needed: missingness?, admissible_domain? (MM‑CHR‑consistent metadata)
  }]
  chart             : { reference_state, coordinate_patch, measurement_protocol_ref }
  normalization     : {
   UNM_id?,                                      // reference to the UNM mechanism; canonical Intension: A.19.UNM
   methods: [NormalizationMethodId],              // UNM-owned tokens; semantics live in A.19.UNM
   instances?: [NormalizationMethodInstanceId],   // UNM-owned tokens; evidence/backing lives in C.16
   method_descriptions: [NormalizationMethodDescriptionRef], // refs only; semantics/corpus live with the semantic owner
   admissible_reparameterizations,                // UNM-owned declarations (opaque here; see A.19.UNM)
   invariants,                                    // UNM-owned invariant tokens (opaque here; see A.19.UNM)
   fix?: <NormalizationFixSpec>                   // UNM-owned fix spec (opaque here; see A.19.UNM)
   }
  comparability     : { mode ∈ {coordinatewise, normalization-based}, minimal_evidence }  // `minimal_evidence` is a gate reference (default: CG‑Spec.MinimalEvidence; see G.0/C.16)
  indicator_policy? : { IndicatorChoicePolicyRef, scope, edition }  // policy ref only; semantics owned by A.19.UINDM
  acceptance        : { checklist_for_admission, window, evidence_anchors } // gates RSG state checks
  aggregation       : { Γ_fold, WLNK/COMM/LOC/MONO choices, time_policy }   // fold tokens only; semantics owned by B.3/G.0 (and the folding mechanism card, if cited)
  alignment?        : { bridges_to_other_contexts, CL_levels, loss_notes }  // optional
  lifecycle         : { owner_role, DRR_links, deprecation_plan }
}

Reading: A CN‑frame is a context‑local lens with declared characteristics and a chart to read them. CN‑Spec pins the references and governance choices needed to make admission, comparability, and safe roll‑ups auditable: the UNM reference for normalization‑based comparability, an optional IndicatorChoicePolicyRef, an explicit Γ_fold, and the admission checklist. Any mechanism semantics (e.g., what ≡_UNM means, or what counts as an Indicator) is owned by the corresponding mechanism pattern and is only cited from here.

Ownership note. CN‑Spec stores only the governance references and declarations. The semantics and term cards for NormalizationMethod*, ≡_UNM, NCV, IndicatorChoicePolicy, and any other CHR‑mechanism vocabulary are owned by the corresponding mechanism patterns (e.g., A.19.UNM, A.19.UINDM) and evidence backing lives in C.16. (Kernel reminder: per A19‑CS‑5, U.CharacteristicSpace carries no hidden normalizations or aggregations.) In A.6.1 terms, UNM_id points to a canonical U.Mechanism.Intension card; the CN‑Spec references that mechanism and does not introduce implicit Transport.

L‑CN‑Spec‑NORM‑IDs (by reference). When CN‑Spec (or its audit trail) needs stable normalization tokens, use NormalizationMethodId/NormalizationMethodInstanceId as specified by the UNM owner (A.19.UNM). Avoid generic “map” nouns and retired κ‑notation (see the A.19.UNM lexical guard); preserve legacy tokens only via F.18 alias docking. If you introduce reference‑typed fields, obey A.6.5 (*Ref reserved for reference fields; *Slot reserved for SlotKinds).

#CN‑frame Registry (per Context)

Each U.BoundedContext keeps a CN‑frame Registry (VR):

• canonical names and editions;
• SoD hooks (who can edit CN‑Spec, who can certify admission);
• deprecation map (what replaces what, when).

#Bridges (across contexts)

Cross‑context reuse occurs only via explicit Alignment Bridges (F.9) between CN‑Specs:

Bridge CN‑frameA@Context1  →  CN‑frameB@Context2
  channel: {Scope|Kind}                 // F.9 (and A.6.1 Transport)
  planes: ReferencePlane(src,tgt)       // C.2.1 (must be recorded)
  CL: {3|2|1|0}
  CL_plane?: {3|2|1|0}                  // only when planes differ
  kept_characteristics: [… ]
  lost_characteristics: [… ]
  transform: {pullback | pushforward | re-scaling | re-binning | … }  // illustrative; use the operator vocabulary owned by A.19/F.9
  extra_guards: {additional evidence / reviewer role / waiver speech-act}

CL policy (reference). CL levels and the penalty Φ(CL) are defined in B.3 (CL is ordinal; do not average). In A.6.1 terms, any cross‑context (or cross‑plane) reuse is declared only via a mechanism’s Transport clause: name the BridgeId and channel (Scope|Kind) and record ReferencePlane(src,tgt); if planes differ, declare the CL^plane regime. Transport is declarative (it does not introduce a U.Transfer edge and does not restate CL ladders or Φ tables). When both scope and describedEntity change, apply the two‑bridge rule (Scope bridge + KindBridge (CL^k)). Penalties from scope/kind/plane route to R/R_eff only (never to F/G). This CN‑Spec may add operational guards per level (e.g., “extra reviewer at CL=1”, “waiver at CL=2”), but it does not redefine the scale or Φ. For episteme‑specific frames, see also B.1.3.

#Conformance Checklist (normative)

Pass these and your CN‑frames are fit for assurance and cross‑team composition.

CC‑A19.D1‑1 (Local scope). Every CN‑frame MUST live inside a declared U.BoundedContext (with edition). Names are local; same label in another Context ≠ same CN‑frame.

CC‑A19.D1‑2 (Units & polarity). Each characteristic in cs_basis MUST declare unit/scale and polarity (↑ better / ↓ better / target range). No unlabeled magnitudes.

CC‑A19.D1‑3 (Chart). chart MUST name the reference state, coordinate patch and measurement protocol (U.MethodDescription) to make numbers reproducible.

CC‑A19.D1‑4 (Normalization references, not redefinition). normalization MUST (i) cite the UNM mechanism (UNM_id?) and (ii) provide the normalization references required by the UNM owner (methods / invariants / fix, and instances when used) so that any normalization‑based comparison is auditable. This pattern does not define what a “NormalizationMethod” is — it requires that CN‑Spec can point to the owner that does.

CC‑A19.D1‑5 (Comparability mode). comparability.mode MUST be either coordinatewise (same chart & units) or normalization‑based (“normalize‑then‑compare” via the declared UNM). Mixed/implicit modes are prohibited. The semantics of ≡_UNM (and what counts as “same class”) is owned by the UNM mechanism card (A.19.UNM); CN‑Spec only pins the references needed to audit the choice.

CC‑A19.D1‑6 (Admission checklist). acceptance.checklist_for_admission MUST be observable and time‑bounded; each datum admitted to the CN‑frame SHALL cite a StateAssertion or equivalent U.Evaluation.

CC‑A19.D1‑7 (Aggregation discipline). aggregation.Γ_fold MUST specify WLNK/COMM/LOC/MONO choices and the time policy (e.g., average of rates vs integral of counts). No free‑hand averages. The legality/semantics of folding is owned by B.3/G.0 (and, when a folding mechanism is cited, by its mechanism owner); CN‑Spec only stores the governance pins.

CC‑A19.D1‑8 (Bridge‑only reuse). Cross‑context consumption MUST cite a Bridge with: (i) channel ∈ {Scope|Kind}, (ii) recorded ReferencePlane(src,tgt), (iii) CL (and CL^plane when planes differ), and (iv) loss notes; coordinate‑by‑name without a Bridge fails. If the data participate in gating/assurance, apply Φ(CL) per B.3; this CN‑Spec does not restate Φ.

CC‑A19.D1‑9 (SoD & roles). Editing CN‑Spec and admitting data MUST be performed by different roles (⊥ enforced): CN‑frameStewardRole ⊥ CN‑frameCertifierRole inside the same context.

CC‑A19.D1‑10 (Lifecycle & DRR). Every CN‑Spec MUST carry an owner role, a deprecation plan, and links to DRR entries for rationale and changes (Part E.9).

CC‑A19.D1‑11 (Anchors & lanes for comparability). Any admission into a CN‑frame that is later used for comparison/aggregation SHALL cite the corresponding A.10 EvidenceRole anchors for each characteristic, with assuranceUse lane tags {TA, VA, LA} and validity windows (where applicable), so that the SCR can report lane‑separated contributions and freshness (B.3). Absence of anchors for a required characteristic renders items incomparable.

CC‑A19.D1‑12 (Notation independence). CN‑Spec content MUST NOT depend on a tool or file format; semantics precede notation (E.5.2 Notational Independence).

CC‑A19.D1‑13 (Lexical guard‑rails). characteristic names and role labels MUST follow the Part E lexical discipline (registers, twin labels; no overloaded “process/service/function”).

#Consequences (informative)

#Rationale (informative)

The CN‑Spec aligns A.19.CN with Part E: it packages Tell‑Show‑Show, Conformance Checklists, and DRR‑backed change, while honouring DevOps Lexical Firewall, Unidirectional Dependency, and Notational Independence so that semantics never depend on tooling. It also operationalises B.3 Trust & Assurance by making CL penalties and WLNK folds first‑class.

#Archetypal Grounding (Tell‑Show‑Show)

Same slots, three arenas; no tooling implied. The examples below use plain-language normalization descriptions as placeholders; any normative use must cite UNM-owned ids/refs (A.19.UNM) and evidence pins (C.16), not invent new terminology here.

#Industrial line — Weld‑quality CN‑frame (AssemblyLine_2026)

• cs_basis: BeadWidth[mm] (target 6.0±0.2), Porosity[ppm] (↓), SeamRate[1/min] (↑ until limit)
• chart: reference jig, fixture ID, torch type; MethodDescription#Weld_MIG_v3
• normalization: affine rescale on gray‑level calibration → invariant = physical porosity
• comparability: normalization‑based (UNM) (calibration tables applied)
• aggregation: WLNK on quality (min‑bound), COMM on counts, time = per‑shift histograms
• RSG hook: WelderRole.Ready requires Porosity ≤ 500 ppm & BeadWidth within ±0.2 mm admitted by this CN‑frame.

#Software/SRE line — Latency CN‑frame (SREProdClusterEU2026)

• cs_basis: P50Latency[ms] (↓), P99Latency[ms] (↓), Load[req/s]
• chart: client vantage, trace sampler v4; MethodDescription#HTTP_probe_v4
• normalization: monotone time‑warp compensation for collector skew; invariant = percentile order
• comparability: normalization‑based (UNM) with declared normalization
• aggregation: MONO on latency (max of mins), WLNK across services
• RSG hook: DeployerRole.Active gated if P99 < declared SLO over the admission window.

#Clinical/episteme line — Trial‑outcome CN‑frame (Cardio_2026)

• cs_basis:
  • slot_id: ΔBP characteristic: BloodPressureChange scale: { type: ratio, unit: mmHg } polarity: down
  • slot_id: AdverseRate characteristic: AdverseEventRate scale: { type: ratio, unit: "%" } polarity: down
  • slot_id: Age characteristic: Age scale: { type: ratio, unit: years } polarity: neutral
• chart: cohort definition; MethodDescription#TrialProtocol_v5
• normalization: case‑mix adjustment (propensity score); invariant = adjusted ΔBP
• comparability: normalization‑based (UNM) (post‑adjustment)
• aggregation: LOC on subcohorts; WLNK on safety outcomes
• RSG hook: EvidenceRole.Validated admission requires CN‑frame acceptance; Assurance pulls CL from any Bridge used.

#Worked mini-schemas (entity/relational mixtures across CN‑frames, informative)

To illustrate how CharacteristicSpace is used in practice, below are simplified schema snippets for three typical CN‑frames: an Operations view (run-time state and action gating), an Assurance view (evidence and cross-context comparison), and an Alignment view (design-time consistency across contexts). These examples mix entity-based and relational Characteristics and demonstrate how normalization and bridge references may appear in a model.

Didactic-only note (no data governance). The “schema/table” shapes below are purely explanatory: they show which references must be cite-able for audit and reproducibility. They are not storage requirements, do not prescribe file formats, and do not define the semantics of NormalizationMethod* tokens (see A.19.UNM / C.16).

#Operations CN‑frame — Run-time gating & enactment

Entity graph view:

Holder (System) ── playsRoleOf ──> Role@Context ── has ──> RCS (slots…) RSG (Role@Context) ── owns ──> State (◉ status) Checklist (of State) ── testedBy ──> Evaluation ── yields ──> StateAssertion Work ── performedBy ──> RoleAssignment Work ── isExecutionOf ──> MethodDescription

In the above, a Holder (a system instance) plays a Role in some Context, which has an attached RCS (a set of slots defining its characteristic space). That Role’s RSG owns various possible State entries (each state could be, e.g., Ready, Waiting, Degraded, etc.). Each State has a Checklist which is tested by an Evaluation process, resulting in a StateAssertion (pass/fail) at runtime. Meanwhile, Work instances (concrete operations) are performed by the RoleAssignment and correspond to some MethodDescription (procedure). The “gate” for Work is that a StateAssertion for an enactable state must exist.

Relational stub: (illustrating how information might be recorded)

In this schema: an RCS snapshot table might log individual coordinate values (VALUE) for each Characteristic (CHAR_ID) in a given RoleAssignment, with their units and scale type noted (to ensure we know what the number means). The StateAssertion ties a RoleAssignment to a state checklist and says whether it passed, including references to any NormalizationMethodInstance or Bridge if cross-context or cross-scale comparisons were involved. The gate logic for enactment can then be a query like: “Is Work W admissible now?” – which joins through ROLE_ASSIGNMENT to find the latest StateAssertion for that RA where ENACTABLE=true and VERDICT=pass.

#Assurance CN‑frame — Evidence freshness & mapped comparisons

Entity graph view:

NormalizationMethodInstance ── appliesTo ──> Characteristic (each instance is a scale‑appropriate, monotone transform within UNM) Bridge (ContextB → ContextA) (Alignment Bridge between contexts, with CL and loss notes) StateAssertion ── uses ──> {NormalizationMethodInstance, Bridge} (if a state comparison crossed contexts)

This view highlights that in the assurance context, we keep track of how we mapped or compared states:

• A NormalizationMethodInstance reference records that an admitted comparison/assertion relied on a declared normalization instance. The admissibility conditions, monotonicity constraints and evidence semantics are owned by A.19.UNM and C.16.
• A Bridge between Context B and Context A (for corresponding roles or states) carries a CL rating and possibly notes on what is “lost in translation.”
• A StateAssertion may use a NormalizationMethodInstance or a Bridge, meaning that assertion was reached by translating data via that instance or comparing across that bridge.

Relational stub:

In this stub, NORMALIZATION_INSTANCE records a mapping instance that has to be accounted for when reconstructing an assertion or comparison. The exact meaning of FORMULA_SPEC/VALIDITY_WINDOW/evidence pins is owned by the UNM and evidence patterns (A.19.UNM / C.16); the point here is that the instance is referenceable so audits can follow it. The Bridge table enumerates official Bridges between contexts (for example, bridging a “Ready” state in an engineering context to “Ready” in an operations context, with CL indicating how fully comparable they are). An ASSURANCE_EVENT log could record when a penalty was applied due to a low-CL Bridge or when an assertion was refreshed or invalidated due to new evidence or time lapse.

#A.19.CN:8.4.3 Alignment CN‑frame — Design-time reuse of states across Contexts

Entity graph view:

Checklist(ContextA.State) ← pull(N) — Checklist’(ContextB.State’) (pull a checklist via NormalizationMethodInstance N) Refinement π : RSG(Role' ≤ Role) (RSG refinement mapping, e.g. Role' is a subtype of Role)

This view covers how design-time alignment happens:

• A Checklist’ for a state in Context B can be pulled via a NormalizationMethodInstance into Context A to become a derived Checklist for a state in Context A. This is effectively what we described in the pull operation: using another context’s criteria in your own space.

• A Refinement π is shown between RSGs indicating Role’ is a specialized role of Role (e.g. a sub-role or a scenario-specific role) and how their states relate (Role’ might have extra states or more granular distinctions). This refinement should maintain that for each state in Role’ that maps to a state in Role, the entails/implication relation holds for enactability.

Relational stub: (illustrating how information might be recorded)

In this stub, RSG_REFINEMENT maps states of a sub-role to states of a super-role, with an ENTAILS flag indicating if being in the sub-state guarantees being in the super-state. Every refinement mapping should ensure at least one enactable state in the sub-role corresponds to an enactable state in the super-role (or else the sub-role would allow something the super-role doesn’t – that’s an alignment lint check). The CHECKLIST_PULL table records that a state from one context has had its checklist pulled into another context via a NormalizationMethodInstance (identified by NORMALIZATION_INSTANCE_ID). This is a design artifact saying “State X in context A is defined by applying normalization instance N to State Y in context B’s criteria.” A version or validity field might ensure we know which edition of the checklist or normalization instance was used.

#Anti‑patterns (and the fix)

#Didactic quick cards (one‑liners teams reuse)

1. Numbers travel with their Context. Always cite Context@Edition.
2. If the normalization is not declared, the trend is fiction.
3. WLNK beats wishful means. Use weakest‑link folds for safety.
4. Admit → Assert → Act. (CN‑frame admission → RSG StateAssertion → Method step).
5. Bridge or bust. Cross‑context = Bridge with CL and loss notes.
6. Steward writes, Certifier admits. (SoD by design.)
7. Charts are recipes. Name the MethodDescription that made the number.
8. Deprecate in the open. CN‑frame cards carry DRR & retirement plans.
9. Keep characteristics few, meanings sharp. Prefer ≤ 7 characteristics per CN‑frame.
10. No tooling names in Core. Semantics first; notation later.
11. Use method/instance IDs; avoid generic “map” nouns. Prefer NormalizationMethodId/NormalizationMethodInstanceId (see the A.19.UNM lexical guard).

#SCR / RSCR Harness (acceptance & regression)

These are concept‑level checks; notation‑agnostic.

#SCR — Acceptance (first introduction)

• SCR‑A19.4‑S01 (Completeness). **CN‑Spec has all mandatory slots; cs_basis include unit/scale/polarity; chart references a MethodDescription.
• SCR‑A19.4‑S02 (Normalization clarity). normalization cites the UNM mechanism (UNM_id?) and provides the normalization references required by the UNM owner (methods / invariants / fix, and instances when used). If instances are referenced in assurance logs, their evidence/backing and validity constraints are handled by the owning evidence pattern (C.16), not by A.19.CN.
• SCR‑A19.4‑S03 (Comparability test). Provide one worked example showing coordinatewise or normalization‑based comparison end‑to‑end (with Evidence Graph Ref).
• SCR‑A19.4‑S04 (Γ‑fold audit). Aggregation rule spells out WLNK/COMM/LOC/MONO choices; reviewer reconstructs result on a toy set.
• SCR‑A19.4‑S05 (SoD). Distinct RoleAssignments for CN‑frameStewardRole and CN‑frameCertifierRole exist; windows do not overlap.
• SCR‑A19.4‑S06 (describedEntity & anchors surfaced). For each CN‑Spec characteristic used in the worked example, cite the corresponding CHR Characteristic name and the evidence anchor(s) (A.10) that make the reading observable in this Context.

#RSCR — Regression (on change)

• RSCR‑A19.4‑R01 (UNM edit). On changing normalization (UNM/NormalizationMethod), flag all downstream Bridges for CL re‑assessment; re‑run example comparisons.
• RSCR‑A19.4‑R02 (Slot surgery/Basis surgery). Adding/removing/renaming slot/basis requires a new edition; old data remain valid for their edition.
• RSCR‑A19.4‑R03 (Chart drift). Updating measurement protocol bumps edition; historic Work keeps old edition link.
• RSCR‑A19.4‑R04 (Fold change). Any change to Γ_fold invalidates cached roll‑ups; re‑compute or mark as superseded.
• RSCR‑A19.4‑R05 (Bridge health). After either side’s edition change, re‑validate Bridge CL and loss notes before accepting Cross‑context data.
• RSCR‑A19.4‑R06 (Deprecation rule). On deprecating a CN‑frame, Registry lists its successor; bridges re‑targeted or retired.

#Interaction summary (wiring to the rest of the kernel)

• A.2 / A.2.5 (Roles / RSG). RSG checklists quote CN‑Spec.acceptance; enactment gates rely on admitted CN‑frame data.
• B.1 (Γ‑algebra). CN‑Spec’s Γ_fold instantiates Γ_ctx/Γ_time/WLNK/MONO choices explicitly.
• B.3 (Assurance). Bridge CL enters the R term; WLNK protects safety roll‑ups.
• C.6 / C.7 (LOG‑CAL / CHR‑CAL). Units, scales, and measurement templates come from CHR; proofs about folds live in LOG‑CAL.

#Minimal CN‑Spec template (copy/paste, informational)

Template note (refs-only). This template shows slot placement for governance. Token semantics for normalization belong to the UNM owner (A.19.UNM); indicatorization semantics belong to the indicatorization owner (e.g., A.19.UINDM); evidence/backing semantics belong to C.16; legality/evidence gates belong to G.0.

CN‑frame: <Name>      Context: <Context/Edition>
characteristics:
  - <CharacteristicName> : <Unit/Scale>  [Polarity: up|down|target-range]
Chart:
  reference_state: <text>
  coordinate_patch: <domain/subset>
  measurement_protocol_ref: <MethodDescriptionId>
Normalization:
  UNM: <UNMId?>
  methods: [<NormalizationMethodId>… ]
  method_descriptions: [<NormalizationMethodDescriptionRef>… ]
  invariants: [<property>… ]           # what ≡_UNM preserves (token semantics: see A.19.UNM)
  fix?: <NormalizationFixSpec>          # canonical representative of the ≡_UNM class (token semantics: see A.19.UNM)
Indicators (optional):
  policy_ref: <IndicatorChoicePolicyRef>
  resulting_indicators: [<IndicatorId>… ] // selection is policy‑defined; NCVs alone do not make an Indicator (see A.19.UINDM)
Comparability:
  mode: coordinatewise | normalization-based
  minimal_evidence: <what must be observed to compare>  # legality/evidence gate surface (see G.0/C.16)
Aggregation:
  fold: <Γ_fold expr>   time_policy: <window, statistic>
  WLNK/COMM/LOC/MONO: <declared choices>
Acceptance:
  checklist: [<observable criterion>… ]
  window: <ISO 8601 interval>
  evidence_anchors: [<Observation/Evaluation ids>… ]
Alignment (optional):
  bridges: [<BridgeId, CL, kept/lost characteristics, extra guards>… ]
Lifecycle:
  owner_role: <Role>
  DRR_links: [<DRR ids>… ]
  deprecation_plan: <short note>

Implementation note (non‑normative): conceptual audit fields. (For implementation completeness only; not part of the CN‑Spec normative surface.) The goal is auditability: any implementation should be able to cite the relevant refs (CN‑Spec edition, evidence anchors, UNM instance refs, Bridge ids) when producing a StateAssertion. The normative semantics of normalization and evidence/backing are owned by the corresponding mechanism and evidence patterns (e.g., A.19.UNM and C.16). A.19.CN does not prescribe storage formats.

#A.19.CN:Close

A.19.CN gives A.19 some teeth: a CN‑Spec you can put on one page, a Registry that stops sprawl, Bridges that carry explicit loss, and a checklist + harness that make comparability auditable. It obeys the mandatory pattern structure of Part E (style, checklists, DRR, guard‑rails) while remaining tool‑agnostic and context‑local.

#A.19.CN:End