#Unified Indicatorization Mechanism (UINDM)

Pattern A.19.UINDM · Stable · Architectural (A) · Normative (unless explicitly marked informative) Part A - Kernel Architecture Cluster

Type: Architectural (A) Status: Stable Normativity: Normative (unless explicitly marked informative) Placement: Part A / CN‑Spec cluster (A.19) / CHR mechanism owner patterns (Phase‑3) Source: FPF / CHR Phase‑3 mechanism owner patterns Modified: 2026‑01‑19

Semantic owner note (Phase‑3 canonicalization): this pattern is the designated single semantic owner of the canonical U.Mechanism.Intension for UINDM.IntensionRef (CHR suite stage indicatorize). This matches the “single‑owner route map” discipline: mechanism‑intension semantics live in A.19.<MechId>. A.6.1remains the owner of the **template** ofU.Mechanism.Intension`.

Canonicalization hook (ID‑continuity‑safe): any other appearances of the UINDM intension (e.g., a legacy grounding stub in A.6.1 or suite prose in A.19.CHR) SHALL be reduced to a Tell + Cite stub pointing to A.19.UINDM:4.1, while preserving the original section headings and their public PatternId:SectionPath IDs for continuity (alias‑dock legacy tokens rather than deleting them). Such stubs MUST NOT restate SlotIndex / LawSet / Admissibility content (no “second center of gravity” via near‑duplicate prose).

• Suite stage: indicatorize (ordering lives only in A.19.CHR:suite_protocols).
• Inputs (conceptual): host U.CharacteristicSpaceRef + CNSpecRef + IndicatorChoicePolicyRef + U.BoundedContextRef, with optional CGSpecRef (+ optional MinimalEvidenceRef override) when the chosen policy is evidence‑gated.
• Output: IndicatorSetSlot = a set of U.CharacteristicRef (chosen coordinates), not measurements.
• Non‑goals: does not normalize, score, compare, aggregate, threshold, publish, or emit telemetry; it only selects a subset under explicit policy.
• P2W seam: concrete edition/policy pins are bound in planned baseline artefacts (A.15.3 + A.19.CHR:4.7.2); executions only record effective refs/pins in Audit.
• Failure mode: tri‑state guard (pass|degrade|abstain); unknown never coerces to pass.
• Quick rule of thumb: if CN‑Spec.indicator_policy is absent → IndicatorizeEligibility = abstain (fail‑closed); if the selected policy is evidence‑gated → CGSpecRef MUST be available and the effective MinimalEvidence MUST be explicit (override or CG‑Spec.MinimalEvidence).

#Keywords

• indicatorization
• indicator set
• IndicatorChoicePolicy
• CN-Spec.indicator_policy
• CHR suite stage indicatorize
• tri-state admissibility (pass|degrade|abstain)
• evidence-gated indicator choice
• Bridge+CL transport visibility
• “no NCV⇒indicator”.

#Relations

#Content

#At a glance (didactic, informative)

• Suite stage: indicatorize (ordering lives only in A.19.CHR:suite_protocols).
• Inputs (conceptual): host U.CharacteristicSpaceRef + CNSpecRef + IndicatorChoicePolicyRef + U.BoundedContextRef, with optional CGSpecRef (+ optional MinimalEvidenceRef override) when the chosen policy is evidence‑gated.
• Output: IndicatorSetSlot = a set of U.CharacteristicRef (chosen coordinates), not measurements.
• Non‑goals: does not normalize, score, compare, aggregate, threshold, publish, or emit telemetry; it only selects a subset under explicit policy.
• P2W seam: concrete edition/policy pins are bound in planned baseline artefacts (A.15.3 + A.19.CHR:4.7.2); executions only record effective refs/pins in Audit.
• Failure mode: tri‑state guard (pass|degrade|abstain); unknown never coerces to pass.
• Quick rule of thumb: if CN‑Spec.indicator_policy is absent → IndicatorizeEligibility = abstain (fail‑closed); if the selected policy is evidence‑gated → CGSpecRef MUST be available and the effective MinimalEvidence MUST be explicit (override or CG‑Spec.MinimalEvidence).

#Problem frame

FPF’s Characterization (CHR) suite treats indicatorization as a distinct mechanism boundary within the CHR suite (authoritative membership: A.19.CHR:4.2). Suite membership is a set (order has no semantics); any intended ordering is expressed only via suite_protocols (A.19.CHR:4.5), under the suite obligations (A.19.CHR:4.3).

Within the canonical suite‑closed protocol, UINDM appears as the indicatorize stage (after normalize, before score/compare/select; optional stages remain explicitly optional per suite_protocols).

UINDM’s job is concept‑level and contract‑bound: it selects an indicator subset over an existing U.CharacteristicSpace under CN‑Spec.indicator_policy, using the suite‑wide SlotKind lexicon to prevent SlotKind drift across the CHR ladder and across SoTA wiring layers. A “subspace view” (if needed) is treated as a derived artefact from the chosen set (see A.19.UINDM:4.2), not as an extra mandatory output of the kernel signature.

#Problem

Engineering teams routinely need to decide “which characteristics count as indicators” for a CN‑frame—before they can score, compare, aggregate, or select. If indicatorization is not given a first‑class mechanism boundary, several failure modes emerge:

• Hidden indicatorization: downstream mechanisms (scoring/comparison/selection) implicitly decide which characteristics matter, making the CHR pipeline opaque and hard to audit.
• NCV conflation: measurability (or “having an NCV”) is treated as sufficient to be an indicator, collapsing the crucial distinction between “measurable characteristic” and “indicator chosen under policy.”
• Drift and non‑determinism: indicator sets vary between teams and contexts without stable edition pins, making comparisons and decisions irreproducible.
• Silent evidence coercion: missing/unknown evidence is implicitly treated as acceptable (“pass”) or collapsed to an empty set, degrading decision quality without visibility.

#Forces

1. Policy primacy vs method freedom. Indicatorization must be governed by explicit IndicatorChoicePolicy, while still allowing multiple method families (e.g., theory‑first, invariance‑driven, evidence‑gated) to be wired later without mutating the mechanism’s signature.

2. Selection‑only vs “semantic alchemy.” UINDM must not smuggle normalization, scaling, polarity flips, aggregation, or scoring inside “indicator choice.” It is a selection mechanism over the host basis, not a transformation mechanism.

3. Context locality vs cross‑context reuse. Indicatorization is slice‑bound; cross‑context indicatorization is permitted only when an explicit Transport clause (Bridge+CL/ReferencePlane) is present—otherwise implicit crossings destroy semantic precision.

4. Auditability vs authoring overhead. Engineer‑managers need to see why an indicator set was chosen and which editions/policies were in effect, but FPF stays conceptual (no data governance, no tool‑enforced metadata). Audit obligations must therefore be minimal yet decisive.

5. Evolvability vs didactic usability. CHR mechanisms must remain evolvable (stable slot lexicon; method specifics in SoTA packs / wiring), while the spec must remain teachable: a reader should find UINDM’s purpose, boundary, laws, guard behavior, and audit obligations in one place.

6. Fail‑closed discipline. Unknown/insufficient evidence must never be coerced into “pass”; tri‑state guards (pass|degrade|abstain) are required to preserve correctness under uncertainty.

7. P2W separation and gate/guard separation. UINDM must expose eligibility and audit pins without turning into (i) a WorkPlanning baseline binder or (ii) a legality gate: planned slot fillings belong to P2W artefacts (WorkPlanning), while GateDecision/GateLog live in gate patterns / WorkEnactment (suite protocols remain mechanism‑steps only).

#Solution

UINDM is the canonical indicatorization mechanism in the CHR suite. It defines:

• a stable mechanism boundary (“indicatorize” is a stage with its own operation and eligibility predicate),
• a stable SlotKind surface (via the suite lexicon),
• a strict selection‑only law set (no implicit UNM; no unit/scale/polarity changes),
• a tri‑state admissibility guard (fail‑closed on missing policy, legality, or evidence), and
• an audit minimum (edition pins + crossing policy ids when transport occurs).

UINDM also preserves the CHR suite obligations by construction: it does not embed GateDecision/GateLog, it does not perform publish/telemetry steps, and it keeps Transport declarative (refs/pins only).

Method semantics (“how to pick indicators”) remain out of suite core: they belong in SoTA packs (G.2) and wiring‑only extension modules (GPatternExtension blocks), while UINDM remains the stable mechanism boundary.

#Mechanism.Intension (normative)

This is the canonical U.Mechanism.Intension for UINDM.IntensionRef and is intended to be cited by CHR suite artifacts and by any wiring layers.

• Scope note: this intension is an instance authored to the U.Mechanism.Intension shape owned by A.6.1. It defines only the mechanism’s semantic surface (slots/ops/laws/guards/audit). It does not bind project‑specific pins (P2W), and it does not emit GateDecision/GateLog; it emits Audit pins and a tri‑state guard only.

• IntensionHeader: id = UINDM, version = 1.0.0, status = stable.

• IntensionRef: UINDM.IntensionRef (canonical target for the suite member named in A.19.CHR:4.2).

• Tell. Policy‑bound indicatorization: select an indicator subset over an existing U.CharacteristicSpace under CN‑Spec.indicator_policy.

• Purpose: freeze a policy‑bound indicator subset early so downstream CHR mechanisms can assume a declared indicator profile (or explicitly degrade/abstain) rather than silently “choosing indicators” inside scoring/comparison/selection.

• Imports: A.19.CN (CN‑Spec.indicator_policy), A.6.5 (slot discipline), A.19.CHR:4.2.1 (CHR SlotKind Lexicon), and (when evidence‑gated) G.0 (CG‑Spec.MinimalEvidence).

• SubjectBlock:

  • SubjectKind: Indicatorization.
  • BaseType: U.CharacteristicSpace.
  • SliceSet: U.ContextSliceSet.
  • ExtentRule: indicatorization ranges over the host basis CNSpecSlot.cs_basis (within CNSpecSlot.chart) for the active Context slice; it never enlarges the host basis.
  • ResultKind?: U.Set.

• SlotIndex (derived projection from SlotSpecs / guard SlotSpecs; uses A.19.CHR:4.2.1 SlotKind tokens; no independent semantics):

  • CharacteristicSpaceSlot : ⟨ValueKind = U.CharacteristicSpace, refMode = CharacteristicSpaceRef⟩,
  • CNSpecSlot : ⟨ValueKind = CN‑Spec, refMode = CNSpecRef⟩,
  • IndicatorChoicePolicySlot : ⟨ValueKind = IndicatorChoicePolicy, refMode = IndicatorChoicePolicyRef⟩,
  • ContextSlot : ⟨ValueKind = U.BoundedContext, refMode = U.BoundedContextRef⟩,
  • CGSpecSlot? : ⟨ValueKind = CG‑Spec, refMode = CGSpecRef⟩ (optional; REQUIRED iff the chosen IndicatorChoicePolicy is evidence‑gated),
  • MinimalEvidenceSlot? : ⟨ValueKind = MinimalEvidence, refMode = MinimalEvidenceRef⟩ (optional override; if evidence‑gated and omitted, the effective MinimalEvidence is CGSpecSlot.MinimalEvidence),
  • IndicatorSetSlot : ⟨ValueKind = U.Set (of U.CharacteristicRef), refMode = ByValue⟩.

• OperationAlgebra (suite stage = indicatorize, per A.19.CHR:4.5; canonical stage‑op = Indicatorize):

  • Indicatorize(CharacteristicSpaceSlot, CNSpecSlot, IndicatorChoicePolicySlot, ContextSlot, CGSpecSlot?, MinimalEvidenceSlot?) → IndicatorSetSlot.

• LawSet (CHR‑lawful indicatorization):

  1. Selection‑only: Indicatorize MUST NOT alter units/scales/polarities; it only selects a subset (no implicit UNM).
  2. Host‑basis restriction: the resulting set MUST be a subset of the declared host basis (as constrained by CNSpecSlot.cs_basis / CNSpecSlot.chart).
  3. No implicit NCV⇒indicator: measurability/NCV is not sufficient; indicators exist only via IndicatorChoicePolicySlot (cites A.19.CN indicator_policy).
  4. Edition‑determinism (with slice locality): for fixed editions of all ByRef inputs (CharacteristicSpaceRef, CNSpecRef, IndicatorChoicePolicyRef, and—when evidence‑gated—CGSpecRef plus optional MinimalEvidenceRef) and a fixed active Context slice, the IndicatorSetSlot result is stable.
  5. No silent evidence coercion: if evidence is insufficient/unknown under the chosen policy, the result MUST NOT be “silently emptied” nor silently treated as “pass”; use tri‑state guards.

• AdmissibilityConditions (tri‑state guard; fail‑closed on missing legality/evidence):

  • IndicatorizeEligibility(CharacteristicSpaceSlot, CNSpecSlot, IndicatorChoicePolicySlot, ContextSlot, CGSpecSlot?, MinimalEvidenceSlot?) → GuardDecision ∈ {pass|degrade|abstain}.
  • pass requires: (i) CNSpecSlot.indicator_policy is present, (ii) IndicatorChoicePolicySlot is consistent with that policy reference (same …PolicyRef + edition pins), and (iii) CharacteristicSpaceSlot matches the host basis implied by CNSpecSlot (within the active chart and Context slice).
  • If the chosen IndicatorChoicePolicy is evidence‑gated: (i) CGSpecSlot MUST be present, (ii) define EffectiveMinimalEvidence := (MinimalEvidenceSlot if present, else CGSpecSlot.MinimalEvidence), and (iii) insufficient/unknown evidence MUST yield degrade or abstain per the effective failure‑behavior policy (never a silent pass).
  • If the chosen IndicatorChoicePolicy is not evidence‑gated, absence of MinimalEvidenceSlot MUST NOT affect eligibility; no accidental “always‑evidence‑gated” behavior is permitted.

• Applicability:

  • Intended to be used before any scoring/comparison/selection that assumes an indicator profile, while remaining a distinct step (no hidden indicatorization inside downstream mechanisms).
  • Cross‑context indicatorization is allowed only via an explicit Transport clause.
  • Pin‑binding note: choosing concrete policy editions/pins is a planned baseline concern (P2W); UINDM only consumes those refs and records the effective ones in Audit.

• Transport: declarative Bridge+CL/ReferencePlane only (refs/pins; do not restate CL ladders or Φ tables here); penalties route to R_eff only.

• Γ_timePolicy: point by default (no implicit “latest”).

• PlaneRegime: values live on the episteme ReferencePlane (the IndicatorSetSlot is a set of references into the host basis); UINDM does not introduce plane shifts. When the indicatorization outcome is used across planes, apply CL^plane by explicit policy and route penalties → R_eff only.

• Audit:

  • MUST record: CharacteristicSpaceRef.edition, CNSpecRef.edition, IndicatorChoicePolicyRef.edition.
  • When evidence‑gated, MUST record: CGSpecRef.edition and effective MinimalEvidence (MinimalEvidenceRef when provided; otherwise CGSpecSlot.MinimalEvidence).
  • SHOULD record: the realized GuardDecision (pass|degrade|abstain) and, when non‑pass, the policy‑bound failure behavior reference that justified it.
  • SHOULD record: a stable description of IndicatorSetSlot (or an id reference to a citable indicator‑set artefact), and any Bridge/CL/ReferencePlane ids when Transport was invoked.

#Interpretation notes (informative)

• IndicatorSet is a set of references, not values. IndicatorSetSlot contains U.CharacteristicRef tokens; it does not compute measurements. The move from “chosen indicators” to “measured indicator profile” is performed downstream (e.g., via scoring/comparison), not by UINDM.

• Subspace views are derived, not mandatory. If a project needs an explicit subspace view, treat it as a derived artefact CS|_S where S = IndicatorSetSlot over the host CS = CharacteristicSpaceSlot. Do not add a new mandatory output to the kernel signature; model a first‑class subspace artefact via ⊑⁺ only when it is genuinely needed.

• Justification is optional and externalized. The CHR SlotKind lexicon includes JustificationSlot, but the canonical UINDM intension does not require it. If a project needs a first‑class justification output, treat it as an extension (⊑⁺) rather than by mutating the base Indicatorize signature, and model the justification as an episteme artefact (e.g., JustificationSlot : ⟨ValueKind = U.Episteme, refMode = U.EpistemeRef⟩).

• Evidence‑gated indicatorization is explicit. Evidence gating is not default: it is activated only when the chosen IndicatorChoicePolicy is evidence‑gated, in which case CGSpecSlot and MinimalEvidenceSlot become required inputs to avoid “silent passes.”

#Archetypal Grounding (informative)

#Tell

Think of UINDM as a policy‑bound projection:

• Input: “the whole declared characteristic basis of a CN‑frame (in this context slice) + an explicit indicator choice policy”
• Output: “the subset of characteristic references that are allowed to count as indicators for downstream CHR steps”

The key didactic boundary is: UINDM chooses coordinates; it does not alter coordinates.

#Show (U.System) — cross‑unit engineering dashboard

A program manager maintains a U.CharacteristicSpace for manufacturing sites, including ~30 characteristics (quality, safety, cost, throughput, sustainability).

• The CN‑Spec’s indicator_policy for the “weekly executive dashboard” selects a subset: {DefectRate, IncidentRate, UnitCost, LeadTime, EnergyPerUnit, OnTimeDelivery}.
• UINDM runs Indicatorize(...) and outputs IndicatorSetSlot = those references.
• One site lacks reliable incident reporting for the last week. The indicator policy is evidence‑gated; IndicatorizeEligibility returns degrade (not pass), and the audit records the effective MinimalEvidence and the edition pins used.

Downstream mechanisms can now be held to the invariant: they may only score/compare/select using the declared indicator profile (or explicitly abstain/degrade). This avoids “dashboard drift” where different teams silently score on different subsets.

#Show (U.Episteme) — robust evaluation across environments

A research lead wants indicators for model robustness under distribution shift (different hospitals, sensors, geographies).

• The host characteristic basis includes many candidate metrics (accuracy slices, calibration, subgroup error, OOD detection quality).
• The indicator choice policy is “invariance‑driven”: prefer indicators whose semantics remain stable under environment changes; deprioritize proxy metrics known to be environment‑sensitive.
• UINDM returns an indicator set used by the scoring and comparison stages; uncertain indicators are handled via tri‑state guarding rather than coerced to zero or silently dropped.

#Bias-Annotation (informative)

• Gov (governance). Bias toward explicit policy surfaces (IndicatorChoicePolicyRef, edition pins, auditable outcomes) rather than tacit “expert choice.” Risk: perceived extra work. Mitigation: keep the mechanism minimal (selection‑only) and push method detail into wiring modules.

• Arch (architecture). Bias toward stable interfaces: SlotKind tokens come from the suite lexicon and evidence gates are explicit inputs. Risk: reduced “quick hacks.” Mitigation: allow ⊑⁺ extensions for richer outputs (e.g., justification) without mutating the kernel signature.

• Onto/Epist. Bias toward a strict distinction between “measurable characteristic” and “indicator under policy.” Risk: teams accustomed to “everything measurable is an indicator” may resist. Mitigation: embed this as an explicit LawSet clause (“No implicit NCV⇒indicator”).

• Prag (pragmatics). Bias toward fail‑closed guards and traceability under uncertainty. Risk: more abstain/degrade outcomes early. Mitigation: couple degrade with explicit downstream behaviors (policy‑bound) rather than silent coercions.

• Did (didactics). Bias toward “one place to learn the mechanism”: the problem/forces/solution narrative is co‑located with the canonical Mechanism.Intension.

#Conformance Checklist

A UINDM publication / usage is conformant if it satisfies:

1. Mechanism.Intension completeness. The mechanism publication includes the full intension shape (header/imports/subject/slot index/op algebra/laws/admissibility/applicability/transport/time/plane/audit), and uses the tri‑state guard form. SlotIndex is treated as a derived projection. (See CC‑UM.0/CC‑UM.1/CC‑UM.9.)

2. SlotKind discipline. SlotKind tokens match the CHR SlotKind lexicon for the roles used (CharacteristicSpaceSlot, CNSpecSlot, IndicatorChoicePolicySlot, ContextSlot, etc.). New SlotKinds, if any, are introduced by first extending the suite lexicon, not ad‑hoc in the mechanism.

3. Selection‑only behavior. Indicatorize does not alter units/scales/polarities, does not perform implicit normalization, and does not enlarge the host basis.

4. No NCV shortcut. “Measurable/NCV” is not treated as sufficient for indicatorhood; indicatorhood arises only via IndicatorChoicePolicySlot consistent with CN‑Spec.indicator_policy.

5. Evidence gating is explicit. When the chosen IndicatorChoicePolicy is evidence‑gated, CGSpecSlot is present and the effective MinimalEvidence is explicit and auditable (MinimalEvidenceSlot when provided; otherwise CGSpecSlot.MinimalEvidence); insufficient/unknown evidence must yield degrade/abstain per the effective failure‑behavior policy, never a silent pass.

6. Cross‑context indicatorization is explicit. Any cross‑context use names the relevant Bridge/CL/ReferencePlane and routes penalties to R_eff only (Bridge‑only transport + R‑only routing). (See CC‑UM.3/CC‑UM.4.)

7. Gate/guard separation + lexeme discipline. UINDM uses …Eligibility returning GuardDecision ∈ {pass|degrade|abstain} and does not embed GateDecision/GateLog in suite steps. Reserved gate‑lexemes (e.g., …Guard) are not used for mechanism‑level predicates; the mechanism stays at the guard/admissibility layer.

8. P2W seam is preserved. Planned slot fillings / edition pin‑bindings are not authored inside this mechanism intension; they are bound in WorkPlanning artefacts (P2W) and surfaced at run‑time only via Audit refs/pins.

9. Specialization discipline (if extended). Any specialization of UINDM (⊑/⊑⁺) MUST follow the multi‑level specialization discipline (A.6.1:4.2.1, CC‑UM.8): SlotKind invariance for inherited ops, no new mandatory inputs to the inherited Indicatorize op, and any extra outputs (e.g., justification/subspace artefacts) expressed only via ⊑⁺.

#Common Anti‑Patterns and How to Avoid Them

• “NCV ⇒ indicator.” Treating all measurable characteristics as indicators. Violates “No implicit NCV⇒indicator.”

• Indicatorization hidden in scoring. A scoring method silently ignores some characteristics or introduces an implicit “feature selection” without an explicit indicator set.

• Silent emptying. When evidence is insufficient, returning an empty indicator set (or treating missing evidence as “pass”) without a tri‑state guard decision.

• Cross‑context reuse without Transport. Reusing an indicator set across contexts without naming Bridge/CL/ReferencePlane, thereby hiding penalties and violating crossing visibility.

• Smuggling plan‑binding into the mechanism. Binding concrete edition pins / planned slot fillings (“launch values”) inside the UINDM description instead of using the P2W seam (WorkPlanning) and recording only effective refs/pins in Audit.

• GateDecision leakage. Emitting or implying GateDecision/GateLog as part of the indicatorize step (gate decisions are separated from suite steps; keep UINDM at guard+audit level).

#Consequences

Benefits

• Makes “which characteristics count as indicators” explicit, auditable, and policy‑bound.
• Prevents downstream semantic drift by freezing an indicator subset early in the CHR pipeline.
• Improves reproducibility via edition‑determinism (fixed editions ⇒ stable result).
• Preserves evolvability: new indicator selection method families can be added via wiring (packs/extensions) without changing the mechanism’s intension.

Costs / trade‑offs

• Adds an explicit step (and explicit policy work) before scoring/comparison.
• Strict fail‑closed behavior can increase early degrade/abstain outcomes until evidence and policies are properly specified.

#Rationale

Indicatorization is separated because it is a different kind of commitment than scoring or comparison:

• Indicatorization commits to which coordinates are allowed to matter under policy.
• Scoring/aggregation/comparison commit to how allowed coordinates are transformed, folded, or ordered under legality gates.

By making indicatorization selection‑only, UINDM avoids “semantic alchemy” (changing meanings while claiming to merely “pick indicators”) and supports the CHR suite’s broader discipline: explicit contracts, explicit crossings, and explicit handling of uncertainty via tri‑state guards.

#SoTA-Echoing

SoTA vs popular note. This section records alignment to post‑2015 evidence‑backed practice. It is not a mandate to use fashionable methods; method semantics stay in SoTA packs (G.2) and wiring modules, while this pattern fixes the stable mechanism boundary.

Pack note (Phase‑3): this pattern does not currently cite a UINDM‑specific G.2 SoTA pack/ClaimSheet. If/when such a pack is introduced, replace the bibliographic pointers below with the pack’s ClaimSheetId citations, keeping the mechanism semantics unchanged.

#SoTA alignment map (normative)

Notes per row (SoTA‑Echoing; not method mandates).

1. Invariance under shift. UINDM does not “implement IRM”; it merely makes room for invariance‑driven indicator policies to be wired while keeping the kernel selection‑only.
2. Justification discipline. UINDM keeps justification optional at the kernel level; if a justification artefact is required, add it via ⊑⁺ so the base signature stays stable.
3. Single‑owner traceability. The ISO architecture‑description discipline is used here only to motivate “one semantic owner + Tell/Cite stubs”; it does not add new Part‑A contract surfaces.

#Relations

• Builds on

  • A.19.CN (CN‑Spec, specifically indicator_policy).
  • A.6.1 / CC‑UM.* (mechanism intension shape and authoring checks).
  • A.19.CHR:4.2.1 (CHR SlotKind lexicon).

• Used by

  • A.19.CHR (suite membership and suite protocols; UINDM is the indicatorize stage).

• Coordinates with

  • G.0 (CG‑Spec / MinimalEvidence) when indicator choice is evidence‑gated.
  • E.20 (single‑owner discipline) and F.18 (alias docking) for Phase‑3 canonicalization and ID continuity. [1]: https://arxiv.org/abs/1907.02893 "Invariant Risk Minimization" [2]: https://dl.acm.org/doi/10.1145/3287560.3287596 "Model Cards for Model Reporting"

#A.19.UINDM:End