A.19.CHR:4 - Solution

Select the six declarations, cite one CN-Spec and CG-Spec baseline, and state the protocol under §§4.2–4.5. Check the arguments and result of each used operation against that baseline. Record planned editions in A.15.2 when a P2W path is involved; add A.15.3 typed filling only for an independently declared position. Actual launch values and any FinalizeLaunchValues witness belong to enactment.

The suite contains membership, shared obligations, references and permitted protocols. It supplies no operation result or gate decision.

A.19.CHR:4.0 - Resolve the contract before use

A usable step names the selected member declaration, its operation and the governing argument, result, law and admission content. Use §4.2.2 to locate the declaration and the selected baseline to resolve its edition. A missing contract or unresolved edition stops that dependent step; a stage name or source list cannot fill the gap.

A.19.CHR:4.1 - Objects published by this pattern

A.19.CHR:4.1.1 - CHRMechanismSuiteDescription

A concrete MechSuiteDescription instance whose role is to:

• enumerate the canonical CHR mechanisms (as MechanismDeclarationRefs),
• declare suite‑level obligations/invariants,
• declare suite‑level spec pins (refs only),
• declare admissible suite protocols (Uses pipelines),
• require an edition/reference baseline in WorkPlanning on P2W paths; add typed planned fillings only when their independently declared positions are current.

A.6.7 supplies the general suite form. This pattern selects the six CHR roles and their shared obligations, with the P2W baseline specified below.

A.19.CHR:4.1.2 - Planned baseline and conditional typed filling

Use ordinary A.15.2 WorkPlan content for the selected suite, declaration and CN-Spec/CG-Spec editions, method and comparator references, time rule, expected guards and any required crossing references. Address that content through the exact WorkPlan and its local locator.

Use CHRMechanismSuiteSlotFillingsPlanItem under A.15.3 only when a selected operation argument or relation position already has its own meaning, designation, ValueKind, cardinality and binding predicate. Cite that governing declaration and position. A suite field or a name in the CHR lexicon does not create such a position. A missing fact may remain unknown in the plan; a missing declaration must be recovered before typed filling. Actual bindings and launch witnesses remain with actual enactment.

A.19.CHR:4.2 - Canonical mechanism membership

Tell. Select one exact A.6.1 declaration contract for each of the following six CHR roles. The resulting mechanisms set contains six distinct declaration epistemes, not implementations or unqualified operation-family names:

1. UNM — Unified Normalization Mechanism
2. UINDM — Unified Indicatorization Mechanism
3. USCM — Unified Scoring Mechanism
4. ULSAM — Unified Lawful Scale Aggregation Mechanism
5. CPM — Unified Comparison Mechanism
6. SelectorMechanism — universal set‑returning selection kernel

Show.

CHRMechanismSuiteDescription.mechanisms :=
  [ UNM.IntensionRef,
    UINDM.IntensionRef,
    USCM.IntensionRef,
    ULSAM.IntensionRef,
    CPM.IntensionRef,
    SelectorMechanism.IntensionRef ]

Membership semantics note (normative). mechanisms denotes a duplicates-free set of exact declaration epistemes; order carries no semantics. The displayed …IntensionRef labels are retained citation names for those declarations. In a concrete suite baseline, each resolves to one selected edition under A.6.7 §4.1. They are not references to a newly defined operation-family kind. Any intended ordering is expressed only in suite_protocols.

Rationale. This suite is unified by governance card, admissibility gate, and Transport discipline (CN-Spec + CG-Spec + Transport), with membership by exact operation declarations.

A.19.CHR:4.2.1 - CHR SlotKind Lexicon (suite‑wide minimum)

Tell. To prevent SlotKind drift across the CHR mechanism chain and across SoTA wiring modules, CHR mechanism declarations SHOULD use the SlotKind tokens from this lexicon whenever they refer to the corresponding semantic roles. New SlotKinds MAY be introduced, but only by first extending this lexicon (suite‑governed), then citing the new SlotKind from the affected mechanism card.

Lexicon (minimum). Tokens below are SlotKind names (not types). Concrete meanings, ValueKind / reference designation and binding rules come from the governing A.6.1 operation-local declarations; A.19 and G.0 constrain their domain use. A.6.5 relation SlotSpecs are not the source of these operation positions.

• Core suite SlotKinds

  • CharacteristicSpaceSlot
  • CNSpecSlot
  • CGSpecSlot
  • ContextSlot

• Indicatorization

  • IndicatorChoicePolicySlot
  • IndicatorSetSlot — A.19.UINDM’s selected declaration-local basis positions, retained with the exact CharacteristicSpace basis; each position keeps its Characteristic and Scale
  • JustificationSlot

• Scoring

  • InputProfileSlot
  • ScoreProfileSlot

• Aggregation

  • MeasureSetSlot
  • GammaFoldSlot
  • GammaTimeRuleSlot (optional)
  • AggregatedMeasureSlot
  • ContributorSetSlot (optional)

• Comparison

  • LeftProfileSlot
  • RightProfileSlot
  • ComparatorSpecSlot
  • ComparisonResultSlot

• Selection

  • CandidateSetSlot
  • CriteriaSlot
  • TaskSignatureSlot (optional)
  • SelectionSlot

• Evidence / admissibility (optional, policy‑bound)

  • MinimalEvidenceSlot (optional)

Note. This lexicon is intentionally small and role‑based: it constrains naming, not method semantics. Method/discipline specifics belong in SoTA packs (G.2) and wiring‑only GPatternExtension modules, not in the suite core.

A.19.CHR:4.2.2 - Canonical Intension targets (no dangling refs)

Tell. Each …IntensionRef resolves through its governing pattern below to one exact A.6.1 declaration edition. These targets locate the declaration; the selected suite/WorkPlan baseline supplies edition resolution for use. A draft stub can locate unfinished work but cannot resolve an operation contract it does not declare.

Canonical targets (normative anchors).

• UNM.IntensionRef → A.19.UNM
• UINDM.IntensionRef → A.19.UINDM
• USCM.IntensionRef → A.19.USCM
• ULSAM.IntensionRef → A.19.ULSAM
• CPM.IntensionRef → A.19.CPM
• SelectorMechanism.IntensionRef → A.19.SelectorMechanism

A.19.CHR:4.3 - Suite obligations

CHRMechanismSuiteDescription.suite_obligations MUST be written using the canonical obligation vocabulary from A.6.7:4.2 and MUST include the following clauses (duplicates-free set semantics; order carries no meaning):

{ bridge_only_crossings, two_bridge_rule_for_described_entity_change, transport_declarative_only, penalties_route_to_r_eff_only, guard_decision_tristate(pass|degrade|abstain), unknown_never_coerces_to_pass, gate_decision_separation, guard_lexeme_reservations, cg_spec_cite_required_for_numeric_ops, no_silent_scalarisation_of_partial_orders, no_silent_totalisation, no_thresholds_in_suite_core, crossing_visibility_required, planned_slot_filling_in_work_planning_only, finalize_launch_values_in_work_enactment_only, implementation_export_discipline_when_cited }.

A.19.CHR:4.3.1 - Crossings, visibility, and penalties

• bridge_only_crossings: a semantic correspondence between distinct recovered local senses requires the obtaining F.9 Bridge and the bounded-use/reliance basis consumed by this use.
• two_bridge_rule_for_described_entity_change: a C.3.3 kind correspondence retains its own endpoints, obtaining and receiving-use conditions. If an F.9 correspondence is also used, establish it independently. EntityOfConcern change alone supplies neither relation. Plane-only claims stay under their direct governor.
• transport_declarative_only: the suite does not embed CL/Φ/Ψ/Φ_plane tables and does not introduce any additional graph edge kind beyond E.18 U.Transfer; it requires only refs/pins/anchors whose realization is mediated by E.18 / gate surfaces.
• penalties_route_to_r_eff_only: CL/Φ/Ψ/Φ_plane penalties route to R/R_eff only; F/G are invariant under penalty routing.
• crossing_visibility_required: an actual E.18 crossing in an independently selected TransformationFlowStructure retains its required CrossingBundle; an A.21 work-entry gate retains its applicable gate anchors. A changed edition pin triggers the recheck required by its receiving use, but does not itself create a crossing, Bridge or gate.

A.19.CHR:4.3.2 - Guards and gate separation

• Guard decision tristate: mechanism‑level guards return GuardDecision := {pass | degrade | abstain}.
• Unknown never coerces to pass: unknown/insufficient evidence MUST map to degrade or abstain, not to pass.
• Gate decision separation: mechanisms and suite objects MUST NOT publish GateDecision nor DecisionLog. block is gate‑only (OperationalGate(profile)).
• Guard lexeme reservations: USM.CompareGuard / USM.LaunchGuard are gate‑level pins; mechanism predicates use suffixes …Admissibility / …Eligibility.

A.19.CHR:4.3.3 - Numeric admissibility and order lawfulness

• CG‑Spec citation required: any numeric scoring/aggregation/comparison MUST cite CG‑Spec (SCP + ComparatorSet + MinimalEvidence + Γ_fold + Φ/CL pins), and MUST NOT embed a “shadow CG‑Spec” inside mechanisms/suite.
• No silent scalarisation of partial orders: partial order comparisons remain set‑valued; any scalar summary is report‑only unless explicitly declared as a lawful comparator/policy.
• No silent totalisation: absence of totality MUST NOT be hidden by “tie‑breakers” or implicit weights.

A.19.CHR:4.3.4 - P2W discipline

• Edition/reference baselines use A.15.2 WorkPlan content. Typed planned filling uses A.15.3 only for independently declared positions.
• FinalizeLaunchValues in WorkEnactment only.
• Suite and plan objects MUST NOT contain launch‑value witnesses.

A.19.CHR:4.3.5 - Thresholds and defaults

• no_thresholds_in_suite_core: acceptance thresholds live in AcceptanceClauses / TaskSignature / GateProfile, not in CHR suite core.
• Default discipline (no competing defaults): the suite MUST NOT introduce competing defaults. If a default is used (e.g., PortfolioMode), it MUST be cited from its single declared source (typically a TaskSignature or an explicit policy-id), and all other mentions are citations.

A.19.CHR:4.3.6 - Implementation export discipline (when cited)

• Suite MAY cite implementations (CAL/LOG/CHR) as refs, but:

  • LOG/CHR do not export Γ,
  • CAL exports exactly one Γ,
  • imports are acyclic.

A.19.CHR:4.3.7 - Claim reference index

The existing claim identifiers resolve to the rules below. The rules are stated once at their governing locations.

A.19.CHR:4.4 - Suite spec pins

CHRMechanismSuiteDescription.suite_spec_pins MUST be refs‑only and MUST include:

1. Required spec refs: {CNSpecRef, CGSpecRef} (as required pins, not copied content).

2. Required planned baseline: cite the exact A.15.2 WorkPlan and content locator carrying the selected suite, declaration and spec editions. A typed A.15.3 item is additional only when §4.1.2 applies.

3. Required edition pins / policy pins (when applicable):

   • editions{CG‑Spec, ComparatorSet, UNM.TransportRegistryΦ, …} when the chosen protocol path is edition‑sensitive,
   • policy‑id pins for Φ/Ψ/Φ_plane when crossings are expected.

Tell (discipline). Spec pins are anchors; they do not embed tables (CL ladders, Φ registries) and do not introduce transport edges.

A.19.CHR:4.5 - Suite protocols

CHRMechanismSuiteDescription.suite_protocols follows A.6.7: each step resolves to one selected member declaration edition and one operation designator in that declaration. Its guards, laws, arguments and results come from that edition. Stage names below are readable labels, not substitute operation designators.

If suite_protocols is present, it SHALL include at least one protocol that is equivalent to the canonical suite-closed pipeline below (with fold_Γ explicitly optional).

The declaration-local bindings for the canonical stages are:

Resolve each cited edition before applying these bindings; a changed designator or contract requires a revised binding. A list of source pins alone selects no operation. If two editions remain eligible, the suite baseline must state the condition that selects one, or stop that dependent step with the unresolved choice.

Show (canonical suite-closed protocol).

normalize (UNM) →
indicatorize (UINDM) →
score (USCM) →
fold_Γ? (ULSAM) →
compare (CPM) →
select (SelectorMechanism)

Tell.

• The fold_Γ step is optional (explicitly optional, not implicit inside score/compare/select).
• suite_protocols encodes a pipeline/Uses contour between mechanisms; it does not define a specialisation relation (⊑/⊑⁺). A claimed refinement, conservative extension or equivalence uses its own A.6.1 §4.8 content-preservation test, exact predicate and endpoint facts, including the applicable A.6.RCD missing-governor/substrate branch. Project extensions retain their independently declared restrictions; a pipeline order or ⊑/⊑⁺ label establishes no such comparison.
• Any publish/telemetry step is outside suite_protocols (to preserve WF‑MS‑2 closure) and is governed by established publication patterns (G.10 and/or PTM), not as “hidden tails” inside CHR mechanisms.

A.19.CHR:4.6 - P2W hook: planned edition and reference baseline

For each P2W path that uses the suite, record the chosen suite and member declaration editions, CN-Spec and CG-Spec, method/comparator references, time selection, and applicable guard or crossing references in A.15.2 WorkPlan content. That baseline selects the contracts expected by the protocol and remains separate from actual values and gate decisions.

When a downstream claim needs a typed planned filling, apply §4.1.2 and A.15.3 to the independently declared argument or relation position. At enactment, identify the actual application and its bindings under the selected declaration. The planned baseline alone establishes neither binding nor performed Work.

A.19.CHR:4.7 - Canonical concept card fragments

A.19.CHR:4.7.1 - CHRMechanismSuiteDescription as a concrete MechSuiteDescription

Show (canonical skeleton; refs only).

CHRMechanismSuiteDescription := ⟨
  mech_suite_id        : MechSuiteId,
  mechanisms           : [UNM.IntensionRef, UINDM.IntensionRef, USCM.IntensionRef,
                          ULSAM.IntensionRef, CPM.IntensionRef, SelectorMechanism.IntensionRef],

  suite_obligations    : SuiteObligations {
                          bridge_only_crossings,
                          two_bridge_rule_for_described_entity_change,
                          transport_declarative_only,
                          penalties_route_to_r_eff_only,
                          guard_decision_tristate(pass|degrade|abstain),
                          unknown_never_coerces_to_pass,
                          gate_decision_separation,
                          guard_lexeme_reservations,
                          no_thresholds_in_suite_core,
                          cg_spec_cite_required_for_numeric_ops,
                          no_silent_scalarisation_of_partial_orders,
                          no_silent_totalisation,
                          crossing_visibility_required,
                          planned_slot_filling_in_work_planning_only,
                          finalize_launch_values_in_work_enactment_only,
                          implementation_export_discipline_when_cited
                        },

  suite_spec_pins  : SuiteSpecPins {
                          required_spec_refs := {CNSpecRef, CGSpecRef},
                          required_planned_baseline_ref := exact WorkPlan ref + local baseline locator,
                          required_edition_pins? := …,
                          required_policy_id_pins? := …
                        },

  suite_protocols?     : SuiteProtocol[*],            // includes the canonical pipeline
  suite_notes?         : …,                            // didactic boundaries + anti-patterns
  suite_audit_obligations? : …                         // UTS+Path pins, crossings visibility, guard governing-pattern assignment
⟩

A.19.CHR:4.7.2 - Baseline content and conditional CHRMechanismSuiteSlotFillingsPlanItem

The baseline names the selected declaration edition for every protocol step, the CN-Spec and CG-Spec editions, and any selected method or comparator references. Retain the described entity, bounded context, CG-frame, path slice, publication scope and explicit time selector when they qualify the planned use; a reference plane may be derivable from its cited governing context. There is no implicit latest.

Expected USM.CompareGuard or USM.LaunchGuard pins identify their gate owner where needed to aggregate later GuardFail events. An expected crossing carries only the applicable obtaining Bridge/plane relation and policy references, plus a crossing-bundle anchor when its rule requires it. The baseline copies no governing table.

For an A.15.3 typed filling, cite the exact declaration edition and its independently declared argument or relation position. target_slot_bearing_description_ref cannot point to the suite merely because the suite lists a CN-Spec field. Reuse the position’s actual meaning, designation and binding rules. In the UNM apply case, planning CN-Spec use first requires the actual selected operation’s CN-Spec argument declaration; the suite’s own citation is not that argument.

The baseline and typed plan contain planned values and references only. Actual launch values, FinalizeLaunchValues, actual bindings, GateDecision and DecisionLog retain their enactment or gate governors.

A.19.CHR:4.8 - Examples

A.19.CHR:4.8.1 - Worked case — two offers from baseline to selected set

Situation and planned baseline. The question is whether either offer can be discarded without accepting a worse price or defect-free proportion. Stipulate an A.15.2 WorkPlan OfferReviewPlan@1, local content locator characterization, selecting suite OfferCHRSuite@1. This case’s suite has the six distinct member declarations in §4.2.2, each at its §4.1 content in the same publication edition as this example. Its stable mech_suite_id is OfferCHRSuite; its obligations are exactly the §4.3 clause set. The full canonical protocol is available, with Fold_Γ optional. The selected path uses apply → Indicatorize → Score → Compare → Select, under the operations’ own eligibility evaluations.

The plan pins OfferCHR-CN@1, OfferCHR-CG@1, the methods and policies below, and the point 2030-01-01T00:00Z in UTC. The suite requires those same references and the exact OfferReviewPlan@1#characterization baseline. No typed filling is needed for this ordinary reference selection. These are planned references; no application or result is claimed by the plan.

Case specifications, outside the suite. Take the two offers, lower-price/higher-quality Pareto rule and all-nondominated selection rule defined as OfferPareto@1 and OfferSelection@1 in A.6.7 §4.6. The raw case values here are A=(1000 eurocents, 0.8), B=(1200 eurocents, 0.9), stipulated exact rather than measured in a claimed real-world episode. OfferCHRSpace@1 has basis positions cost and quality, with the price and defect-free-proportion Characteristics. Its input price chart uses eurocents; its normalized price chart uses EUR. Quality uses the same dimensionless ratio scale in both charts.

Both normalizer instances and their method descriptions are declared by the case CN-Spec, with validity window [2030-01-01T00:00Z, 2030-01-02T00:00Z). Their positive scale factors establish the stated preservation facts. The profiles retain their exact bearer, basis positions and the resulting EUR/quality chart. No quotient, class representative or additional CharacteristicSpacePredicate is used.

Applied protocol, separate from the plan. Stipulate the following actual mathematical invocation episodes, each extending from taking up its named inputs to returning its result. Its inputs bind by actual use and its results bind at that return under the selected declaration. The evaluation point qualifies the offers; it is not the calculation interval. All episodes retain the case’s scope, slice set, scheme, plane, point, basis and cited evidence. This account asserts no dated U.Work.

The suite’s audit requirement is to recover these operation refs, effective arguments, guards and returned bindings, together with the baseline citation. Shared order and uncertainty obligations are satisfied without constructing a total score. There is no semantic, kind or plane correspondence, E.18 flow crossing, A.21 gate, implementation export or publication claim in this case; their conditional anchors are therefore inactive.

Changed condition. Move the evaluation point to 2030-01-03T00:00Z while retaining the selected method validity windows. UNM_Eligibility returns abstain. The planned method refs remain readable, but there is no new admitted NCV and no basis for continuing this selected normalization-based path to a new selected set. Reusing yesterday’s values by changing their date would fail their actual binding and use conditions. A new valid method baseline and new applications are needed.

The useful result is the justified retained set under one resolved contract chain. Acceptance or authorization to buy, an independently admitted dated Work account, and publication of the result are separate claims; none follows from {A,B} or from the plan. A PlainView may say “both offers remain; neither dominates at the stated evaluation point” and cite the baseline. It may not say “purchase approved” or erase the expiry stop.

A.19.CHR:4.8.2 - Variant — archive retention with report-only illumination

For an Archive-mode use, retain the selected set under the explicitly selected selector policy. The two-offer case can retain {A,B}; archive maintenance requires its own admitted policy and declarations. Record the exact DescriptorMap and DistanceDef editions when computing illumination, together with the policy declaring that result report-only. A separate CAL policy is required before illumination influences dominance. An archive label, descriptor display or diversity summary cannot silently change the comparison or discard either offer.

A.19.CHR:4.9 - Evolution rules

• Kernel-first stability. This suite is intentionally minimal. Adding a new core CHR mechanism to this kernel suite is a suite-version change and MUST be accompanied by alias docking (F.18) so existing references remain citeable. For exploratory or domain‑specific extra stages, prefer a suite variant (e.g., A.19.CHR+ / A.19.CHR.Extended) or project‑level specializations (patterns P.*) instead of mutating the kernel.
• Mechanism specializations are not wiring. Domain/project variants are expressed via A.6.1 (⊑/⊑⁺) under their governing pattern (typically a project pattern P.*), not by editing suite membership. The suite binds to exact declaration editions through …IntensionRef; the A.15.2 planned baseline records the selected contracts and any concrete method or realizer references. A specialization that changes a used contract requires the corresponding suite member and protocol binding to change.
• Protocols evolve within the suite boundary. Adding/changing suite protocols (A.19.CHR:4.5) is allowed as long as each protocol remains suite‑closed and does not import publish/telemetry as a mandatory step. If a protocol introduces a new required stage not present in membership, treat it as a suite variant rather than a protocol edit.
• SoTA harvesting updates methods, not the kernel. Updates from SoTA harvesting/synthesis (G.2) are carried via edition‑pinned MethodDescriptionRef / ComparatorSpecRef selections and wiring modules (G.x:Ext.*), preserving the selected declaration set while its content stays unchanged. If a SoTA update requires changing a mechanism’s signature/laws, the change happens in the governing A.6.1 mechanism card and MUST emit RSCR triggers from G.Core.
• New mechanism families (outside CHR). Introduce new mechanism kinds as new family-specific patterns under the appropriate mechanism family. If they require suite-level composition and P2W binding, add a corresponding suite pattern A.6.7.<FamilyKey> with an A.15.2 edition/reference baseline and A.15.3 typed filling only when independently declared positions require it, mirroring the governing-pattern assignment routing of this pattern.

A.19.CHR:5.1 - U.System vignette (Tell–Show–Show)

Tell. A system-level decision must select a declared set of options when measurable evidence comes from multiple slices (test rigs, simulations, field trials). Measurements are multi-scale and not always comparable without explicit normalization, and some evidence is missing or stale. The team needs lawful comparison and selection without forcing a single scalar “fitness”.

Show. Use the filled reference selection in §4.8.1 as the baseline: exact contracts, scales, methods, time rule and policies yield a retained set of two offers. When the inputs instead come from tests or field trials, replace the stipulated case evidence with the evidence required by the actual CN-Spec/CG-Spec; incomplete evidence follows the declared failure rule. A claimed dated Work and any launch witness require their independent enactment basis. Any actual semantic/kind/plane relation or flow/gate crossing retains its own required anchors.

Show. If the team instead embeds normalization inside scoring (“we always normalize to [0,1]”) or collapses a partial order into a single weighted sum, the suite protocol explicitness and “no silent scalarization/totalization” obligations make the violation legible at review time, and the planned baseline cannot honestly pin the missing UNM/ULSAM steps.

A.19.CHR:5.2 - U.Episteme vignette (Tell–Show–Show)

Tell. A research episteme compares methodological claims across traditions where some evaluation scales are ordinal (rank-based) and others are interval or ratio. The group wants to select a method family for a task while keeping uncertainty explicit and avoiding illicit aggregation (e.g., averaging ranks).

Show. The episteme’s planned baseline pins CNSpecRef (comparability mode and indicator policy) and CGSpecRef (SCP, ComparatorSet, MinimalEvidence, Γ_fold). The suite runs UINDM to select indicators, USCM to compute lawful score measures under SCP, ULSAM only when Γ_fold is explicitly selected, and CPM to compare without scalarizing partial orders. The selector returns a selected set rather than forcing a single winner.

Show. If a draft evaluation writes “take the mean rank and pick the minimum”, replace that step with a scale-lawful comparator declared in CG-Spec. For report-only telemetry, retain the rank distribution or another summary justified by the declared ordinal scale, such as a median when applicable. An arithmetic mean requires a separately justified quantitative model; calling it telemetry does not make ordinal averaging lawful.