A.19.CN:8 - 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 A.19.UNM-governed ids/refs (A.19.UNM) and evidence pins (C.16), not invent new terminology here.

A.19.CN:8.1 - 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: a minimum bound only for a declared bottleneck quality model; commutative count addition only for disjoint contributions; time = per-shift histograms
• RSG hook: WelderRole.Ready requires Porosity ≤ 500 ppm & BeadWidth within ±0.2 mm admitted by this CN‑frame.

A.19.CN:8.2 - Software/SRE line — Latency CN‑frame (SRE_Prod_Cluster_EU_2026)

• cs_basis: P50Latency[ms] (↓), P99Latency[ms] (↓), Load[req/s]
• chart: client vantage, trace sampler v4; MethodDescription#HTTP_probe_v4
• Before comparing a client end-to-end reading with a server processing reading, resolve their actual Characteristic and observation basis. Both may use ms yet answer different questions. Keep separate coordinates or obtain readings for the same declared characteristic and basis; a unit conversion alone cannot supply that match.
• normalization: monotone time‑warp compensation for collector skew; invariant = percentile order
• comparability: normalization‑based (UNM) with declared normalization
• aggregation: use a max-of-mins latency fold only when the declared service model justifies it; a WLNK bound needs its own bottleneck model. Neither follows from latency percentiles alone.
• RSG hook: DeployerRole.Active gated if P99 < declared SLO over the admission window.

A.19.CN:8.3 - 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: recombine subcohorts only under the declared population and weighting model; select the law or supported bound for each named safety outcome under its own justified dependency model.
• RSG hook: evidence-use validation of an admission requires CN‑frame acceptance; Assurance pulls CL from any Bridge used.

A.19.CN:8.4 - Worked mini-schemas (entity and relation mixtures across CN-frames, informative)

The three small schemas below show an operations use, an assurance use, and an alignment use. They are explanatory representations, not storage requirements. Each keeps the bearer, system-role kind and assignment, measurement or evaluation result, source-local relation, and evidence use distinct.

A.19.CN:8.4.1 - Operations CN‑frame — runtime gating and enactment

Entity graph view:

System ── classifiedAs ──> SystemRoleKind
System + SystemRoleKind + scope/window ── assignment ──> SystemRoleAssignment
Role-state graph ── lists ──> State
Checklist ── tested by evaluation Work ──> StateAssertion
Work ── performedBy ──> assigned System
Work ── enacts ──> Method

The System is classified under one exact local system-role kind and participates in an obtaining assignment for the stated scope and window. A role-state graph lists states such as Ready, Waiting, or Degraded. Evaluation Work applies the state checklist and supports a StateAssertion. Operational Work may proceed only when the relied-on assertion says that an enactable state obtains; the Work, Method, assignment, and result remain different objects.

Relational stub:

The RCS snapshot keeps the characteristic, value, unit, scale, window, and result identity visible. A StateAssertion separately identifies any normalization instance and any claim that uses a Bridge. An enactment query can therefore ask whether the latest admissible assertion for this assignment has an enactable state and a passing verdict without treating a role label, CN-frame, or Bridge as the acting System.

A.19.CN:8.4.2 - Assurance CN‑frame — evidence freshness and related local meanings

Entity graph view:

NormalizationMethodInstance ── used for ──> characteristic re-expression
F.9 Bridge ── relates ──> exact source and target F.17 cells
ComparisonClaim ── cites ──> normalization instance and/or Bridge-use claim
RelianceClaim ── cites ──> evidence status and assurance limits

The normalization instance identifies the declared re-expression and its validity window. The Bridge identifies only an obtaining relation between two exact local senses. A comparison that relies on either one says so in its own use claim; its evidence and assurance limits remain explicit.

Relational stub:

The tables make an audit path possible without assigning meaning to the table itself. A low-assurance relation, stale normalization instance, or refreshed evidence can be recorded as a distinct event and can reopen only the comparisons that rely on it.

A.19.CN:8.4.3 - Alignment CN‑frame — design-time reuse across local schemes

Entity graph view:

Checklist for target state ← re-expressed by N ─ Checklist for source state
source F.17 cell ── Bridge with direction and loss ──> target F.17 cell
SystemRoleKind' ── stated refinement relation ──> SystemRoleKind

A checklist from one source scheme may be re-expressed for another only through the named normalization instance and, when its local meaning changes, an obtaining F.9 Bridge plus a separate use claim. A stated refinement between system-role kinds records how their state distinctions correspond; it must preserve the entailment needed for enactability rather than relying on similar role names.

Relational stub:

At least one enactable source state must correspond under the stated rule to an enactable target state when that is the promised refinement. The re-expression record fixes the two editions and validity window so later changes can reopen the affected alignment rather than silently changing an old checklist.

A.19.CN:8.5 - Same basis, different holder and timing cases

For this worked case, the receiving comparison cites CN-Spec E7, and its commissioning control requires independent certification of E7’s comparison basis. Alice authored that basis. After her stewardship assignment ends, she receives a certifier assignment and examines E7. The holder condition fails: the later assignment still certifies her own basis.

Bob’s certifier assignment instead overlaps Alice’s stewardship assignment. When Bob neither authored nor materially selected E7’s basis, this local holder condition is satisfied despite the overlap. The receiver must still establish Bob’s authority for E7, the required examination and any stronger organizational-independence condition from the commissioning control. Missing evidence for one of these conditions leaves that dependent certification conclusion open; different names alone do not establish it.

In an ordinary comparison with no independent-certification requirement or claim, Alice may use a sufficiently supported E7 basis and publish the comparison as uncertified. If E8 later changes the compared population or normalization basis, reopen only uses and certification claims depending on that changed basis. Correcting E7’s registry display while its content and evidence stay fixed does not have that effect.