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.