#MechSuiteDescription — Description of a set of distinct mechanisms

Pattern A.6.7 · Stable · Architectural pattern. · Normative [A] (Core). Part A - Kernel Architecture Cluster

Type: Architectural pattern. Status: Stable. Normativity: Normative [A] (Core).

One-line summary. A MechSuiteDescription is a Kernel Description token that names a set of distinct U.Mechanism.Intension (different mechanisms, not realizations of one mechanism) and declares suite-level obligations, required contract pins, and allowed usage protocols, without conflating this with MechFamilyDescription or with publication Packs.

Plain-name. mechanism suite description; mechanism suite passport. Placement. Part A → cluster A.IV (A.6), immediately after A.6.5.

Builds on. E.8 (pattern template discipline), A.6.1 (U.Mechanism.Intension canonical form), A.6.5 (slot/ref discipline), E.10 (lexical + ontological rules; strict distinction; minimal specificity; kind suffixes), E.19 (conformance checks), E.18 (TGA / P2W graph discipline; crossing visibility), A.21 (OperationalGate(profile) and gate-level decisions).

Used by. Any framework area that needs a stable “universal kernel” shared across multiple mechanisms (notably the universalization of Part G patterns, including but not limited to G.5), and any “mechanism stack” whose correctness is defined by shared legality + transport + audit obligations rather than by a single shared BaseType.

Mint vs reuse.

• Mints: MechSuiteDescription (KernelToken, Description) and the record names used by its canonical form: MechSuiteId, SuiteObligation, SuiteObligations, SuiteContractPins, SuiteProtocol, ProtocolStep, SuiteAuditObligations.
• Reuses (by reference): U.Mechanism.Intension (members), MechFamilyDescription / MechInstanceDescription (optional citations), existing pinned references such as CN‑Spec / CG‑Spec (as pins), and E.TGA/P2W notions (as obligations/pins), without introducing new U.* kernel types.

LEX.TokenClass.

• LEX.TokenClass(MechSuiteDescription) = KernelToken.
• LEX.TokenClass(MechSuiteId) = KernelToken.
• LEX.TokenClass(SuiteObligations) = KernelToken.
• LEX.TokenClass(SuiteContractPins) = KernelToken.
• LEX.TokenClass(SuiteProtocol) = KernelToken.
• LEX.TokenClass(SuiteAuditObligations) = KernelToken.

I/D/S. Description (D); Tech name ends with …Description. Lexical note: do not prefix this token with U. — U.* is reserved for Kernel types, while MechSuiteDescription is a Kernel descriptor (Description token).

In FPF, a mechanism is a node-level intensional object (U.Mechanism.Intension) with explicit SlotSpecs inside operator signatures, and a declared LawSet/guards/transport/audit (A.6.1, A.6.5). Many architectures, however, require a stable bundle of multiple different mechanisms that are intended to be used together under shared legality and crossing discipline (e.g., a characterization chain, a legality-gated selection pipeline, or a universal Part‑G kernel that multiple G.* patterns must reuse).

#Keywords

• mechanism suite
• distinct mechanisms
• suite obligations
• contract pins
• CN-Spec
• CG-Spec
• P2W
• planned baseline
• crossing visibility.

#Relations

#Content

#Problem frame

In FPF, a mechanism is a node-level intensional object (U.Mechanism.Intension) with explicit SlotSpecs inside operator signatures, and a declared LawSet/guards/transport/audit (A.6.1, A.6.5). Many architectures, however, require a stable bundle of multiple different mechanisms that are intended to be used together under shared legality and crossing discipline (e.g., a characterization chain, a legality-gated selection pipeline, or a universal Part‑G kernel that multiple G.* patterns must reuse).

FPF already has MechFamilyDescription, but its meaning is: many realizations of one and the same U.Mechanism.Intension. That construct cannot correctly represent a bundle of different mechanisms (different intensions), and trying to overload it creates a level error.

Additionally, FPF reserves “Pack” for publication/shipping bundling (e.g., G.10); using “Pack” to mean “container of mechanisms” creates ontological collisions and downstream confusion.

#Problem

We need a Kernel-level descriptor that can:

1. represent a set of distinct mechanisms (distinct U.Mechanism.Intension),

2. declare shared obligations that must hold across the set (e.g., crossing visibility, legality citation discipline, guard decision format, penalty routing),

3. provide shared contract pins (e.g., “this suite is contract-bound by CN‑Spec + CG‑Spec”), without duplicating those contract contents,

4. constrain allowed protocols of use (allowed pipelines / permitted ordering), without turning the suite into a mechanism, and

5. preserve strict distinction among:

   • a suite of mechanisms (MechSuiteDescription),
   • a family of realizations of one mechanism (MechFamilyDescription),
   • a publication bundle (Pack, e.g., G.10).

#Forces

1. Strict distinction (level hygiene). “many mechanisms” must not be encoded as “many realizations of one mechanism”. Violating this blurs specialization laws, SlotKind invariance expectations, and audit/crossing responsibilities.

2. Minimal specificity + kind suffix discipline (E.10). The token name should encode only what is essential: it is a description, it is about mechanisms, it is a suite. It must not capture a particular domain (e.g., CHR) in the Kernel name.

3. Contract-surface centrality (CN‑Spec / CG‑Spec). Suites must cite contract surfaces as pins, not duplicate their internals, otherwise multiple competing “centers of legality” arise.

4. Transport and crossing visibility discipline. Cross-context and cross-plane steps must be visible and bridge-only; penalties must route to R/R_eff only; suites must not embed CL/Φ/Ψ/Φ_plane tables. Visibility is mediated via E.TGA / P2W (crossing bundles + UTS/Path pins), not by “implicit semantics”.

5. Guard vs gate separation. Mechanisms can output tri-state guard outcomes and explanations; gate decisions (including block) and DecisionLog remain gate-level (OperationalGate(profile)). A suite must not collapse these layers.

6. FPF is conceptual. The suite is a conceptual descriptor: no implementation fields, no “lint rules”, no machine governance. The suite expresses obligations as conceptual constraints and required pins/anchors.

#Solution

Introduce a new Kernel description token:

#A.6.7:4.1 MechSuiteDescription (data model)

MechSuiteDescription declares:

1. Suite identifier: a stable identifier for downstream citation.
2. Membership: a finite set of distinct mechanism intensions.
3. Suite obligations: shared invariants that every member (and any permitted composition of members) must respect.
4. Suite contract pins: required citations/pins to contract surfaces and other “anchor” references.
5. Suite protocols: allowed pipelines of use (permitted ordering and optional steps), expressed at the descriptive level.
6. Suite audit obligations: required audit/pin visibility for downstream uses (UTS/Path pins, crossing pins, guard pins), expressed as required anchors (not run-time values).
7. Notes: didactic boundaries and anti-pattern warnings.

A minimal canonical form:

MechSuiteId := Identifier  // PascalCase; stable citation handle. Versioning MAY be carried externally.

SuiteObligation := one of {
   * 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
  +}

SuiteObligations := { SuiteObligation[*] } // clause set; duplicates-free.

MechSuiteDescription := ⟨
  mech_suite_id: MechSuiteId ,
  mechanisms: U.Mechanism.IntensionRef[+] ,     // distinct members; references preferred
  suite_obligations: SuiteObligations ,
  suite_contract_pins: SuiteContractPins ,
  suite_protocols?: SuiteProtocol[*] ,
  suite_audit_obligations?: SuiteAuditObligations ,
  suite_notes?: DidacticNotes
⟩

Norms.

• Suite identifier. mech_suite_id MUST be present and stable: it is the citation handle for downstream planning and U.Work.Audit.

Well-formedness constraints (admissibility; non-deontic).

• WF‑MS‑1 (Membership set semantics). mechanisms denotes a duplicates‑free set; order carries no semantics.

• WF‑MS‑2 (Protocol closure). If suite_protocols is present, then for every ProtocolStep in every SuiteProtocol, step.mechanism ∈ mechanisms.

• WF‑MS‑3 (Suite ≠ Pack). MechSuiteDescription does not carry shipping/publication payloads; publication remains the role of Pack patterns.

• WF‑MS‑4 (Suite ≠ Mechanism). MechSuiteDescription contains no OperationAlgebra/LawSet/execution semantics and is not admissible where a U.Mechanism.* node is required.

• Membership is by mechanism intension (order-free). mechanisms MUST denote a duplicates-free set of distinct U.Mechanism.Intension members. Membership order has no semantics; any intended ordering is expressed only in suite_protocols. A suite is not defined by a shared BaseType.

• No substitution by MechFamilyDescription. A suite MUST NOT be encoded as a MechFamilyDescription. If desired, a suite MAY additionally cite MechFamilyDescription / MechInstanceDescription for particular members (e.g., “preferred realization for this context”), but such citations do not redefine membership.

• No “Pack” meaning. A suite MUST NOT be named or treated as a publication pack. Pack remains reserved for publication/shipping bundling (e.g., G.10).

• No mechanism semantics in the suite. A suite is a Description, not a mechanism: it does not define OperationAlgebra, it does not execute, and it does not absorb gate logic.

#A.6.7:4.2 SuiteObligations (canonical obligation vocabulary)

MechSuiteDescription MAY declare any obligations, but the following obligation vocabulary is canonical and is intended to be reused across the universalization of Part G and legality-gated characterization stacks.

SuiteObligations SHOULD be written as an explicit clause set, e.g.:

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,
  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
}

Obligation meanings (normative).

1. bridge_only_crossings. Well-formedness constraint: cross-context / cross-plane reuse performed by any member mechanism is represented via that member’s published Transport as Bridge-only (no implicit crossings). A suite does not create transport exceptions.

1.1. two_bridge_rule_for_described_entity_change.

• If a suite member’s lawful use requires changing the described entity (kind/identity change, CL^k), the crossing MUST be explicit and MUST satisfy the two-bridge rule: plane/context transfer and kind transfer are distinct, both are Bridge-mediated, and both remain penalty-routed to R/R_eff only.

1.2. transport_declarative_only.

• Well-formedness constraint: suite obligations do not add transfer edges or embed CL/Φ/Ψ/Φ_plane tables. Any transport-related obligation is expressed only as referenced pins/anchors whose realization is mediated by E.TGA / gate surfaces.

2. penalties_route_to_r_eff_only. Well-formedness constraint: CL/Φ/Ψ/Φ_plane penalties associated with crossing discipline route to R/R_eff only; suites do not define transport penalties that alter F/G.

3. guard_decision_tristate(pass|degrade|abstain) and unknown_never_coerces_to_pass. Well-formedness constraint: admissibility/eligibility outcomes use a tri-state guard result GuardDecision := {pass|degrade|abstain}. Unknown/insufficient evidence is not coerced to pass; it resolves to {degrade|abstain} under declared failure behavior (e.g., probe-only as a SoS‑LOG branch id, not as a new decision value).

4. gate_decision_separation. Well-formedness constraint: suites do not define or use GateDecision values (including block) as part of mechanism/suite semantics. Gate-level outcomes and DecisionLog remain on OperationalGate(profile).

5. guard_lexeme_reservations. Well-formedness constraint: USM.CompareGuard and USM.LaunchGuard denote gate-owned guard events/pins; member mechanisms and suite protocols use …Admissibility / …Eligibility for guard predicates, not the reserved gate lexemes.

6. cg_spec_cite_required_for_numeric_ops. Well-formedness constraint: any member operation that performs numeric comparison/aggregation/legality-sensitive scoring cites the applicable CG‑Spec (and relevant subrefs) as contract pins, rather than embedding equivalent “local legality” content.

7. no_silent_scalarisation_of_partial_orders and no_silent_totalisation. Well-formedness constraint: if a member mechanism induces a partial order, it preserves set-/relation-valued semantics; it does not silently reduce to a scalar/total order. Any totalization is explicit and policy-bound.

8. no_thresholds_in_suite_core. Well-formedness constraint: suite core does not publish acceptance thresholds (“passing scores” / hidden cutoffs). Thresholds belong to acceptance clauses / task signatures / gate profiles.

9. crossing_visibility_required. Well-formedness constraint: any GateCrossing relevant to suite use publishes a CrossingBundle (E.18) and can be cited as an audit anchor. GateCrossing includes (at minimum) cross-context, cross-plane, and cross-kind/described-entity changes, entry into U.WorkEnactment (LaunchGate), and any edition_key change of pinned editions{…} vectors. Suites may require CrossingBundleRef / UTS / Path pins and policy-id pins as anchors, and MUST NOT embed CL/Φ/Ψ/Φ_plane tables.

10. planned_slot_filling_in_work_planning_only. Well-formedness constraint: any planned slot filling used as a baseline for suite use is authored in WorkPlanning as a planned baseline (no run-time slot instances; no launch values).

11. finalize_launch_values_in_work_enactment_only. Well-formedness constraint: FinalizeLaunchValues (and any witness of actual launch values) occurs only in U.WorkEnactment; neither the suite nor any planned-baseline artifact is a place for launch values.

#A.6.7:4.3 SuiteContractPins

A MechSuiteDescription MUST be able to declare required contract pins as references, not as duplicated content. Canonically:

SuiteContractPins := ⟨
  required_spec_refs?: {CNSpecRef?, CGSpecRef?, ...},
  required_edition_pins?: EditionPin[*],
  required_policy_id_pins?: PolicyIdPin[*],
  required_planned_baseline_ref?: PlannedBaselineRef?
⟩

Norms.

• If the suite is legality-gated for characterization, CNSpecRef and CGSpecRef MUST be required (as references/pins).
• Contract pins are citations and anchors. They do not replace the underlying …Spec objects.
• A suite MAY require the presence of a planned-baseline artifact in P2W (e.g., a WorkPlanning plan item such as …SlotFillingsPlanItem that pins chosen refs/editions), but MUST treat it as a reference/pin requirement, not as a place to store launch values or gate decisions. When required, the planned-baseline artifact is authored in WorkPlanning and is citeable by downstream U.Work.Audit; any FinalizeLaunchValues witness remains U.WorkEnactment-only.
• A suite MAY serve as TargetSlotOwnerRef for a planned-baseline plan item (planned slot filling owner role), but this does not make the suite a mechanism and does not create run-time slot instances.

#A.6.7:4.4 SuiteProtocols

A suite MAY describe allowed protocols (pipelines) as descriptive constraints on how suite members are intended to be composed. A protocol description:

• MUST name the member mechanisms it uses (explicitly; no “implicit use”),
• MAY mark steps as optional,
• MUST NOT introduce hidden crossings or hidden legality steps,
• MUST treat “publish/telemetry” as an external protocol step that is realized through existing publication surfaces (e.g., Part G shipping), rather than as a hidden tail inside a mechanism.

A canonical shape for protocols:

SuiteProtocol := ⟨
  steps: [ ProtocolStep₁, …, ProtocolStepₙ ],
  invariants?: ProtocolInvariant[*],
  notes?: DidacticNotes
⟩

ProtocolStep := ⟨
  mechanism: U.Mechanism.IntensionRef,
  operation: OperationName,
  optionality: {required|optional},
  requires_pins?: PinRef[*]
⟩

#A.6.7:4.5 SuiteAuditObligations

A suite MAY require that downstream use provide certain audit anchors. These are requirements, not run-time values. A suite audit obligation MAY include:

• required UTS + Path pins,
• required crossing-surface visibility pins for any crossing relevant to suite use,
• required presence of USM.CompareGuard and/or USM.LaunchGuard pins (not gate checks),
• required declaration of guard ownership (e.g., a GuardOwnerGateSlot anchor),
• required expression of guard violations as GuardFail events aggregated by the guard-owning gate (per GuardOwnerGateSlot), not as extra mechanism/suite states,
• required policy-id pins for any degrade/sandbox/probe-only branches (SoS‑LOG branch id anchors).
• required parity/selection-grade pins when applicable (e.g., when suite use claims parity-grade comparison/selection surfaces downstream).

Norm. A suite must never publish a DecisionLog or GateDecision. If the suite requires guard pins, it requires their presence as anchors so that the gate-level owner can aggregate GuardFails and decide degrade|block per gate profile.

#A.6.7:4.6 Examples (tell–show–show discipline)

Example 1 (conformant). A characterization legality suite:

CHRMechanismSuiteDescription : MechSuiteDescription :=
  mech_suite_id = CHRMechanismSuiteId
  mechanisms = { UNM, UINDM, USCM, ULSAM, CPM, SelectorMechanism }
  suite_obligations includes:
    bridge_only_crossings,
    penalties_route_to_r_eff_only,
    guard_decision_tristate(pass|degrade|abstain),
    gate_decision_separation,
    cg_spec_cite_required_for_numeric_ops,
    no_silent_scalarisation_of_partial_orders,
    crossing_visibility_required,
    planned_slot_filling_in_work_planning_only,
    finalize_launch_values_in_work_enactment_only
  suite_contract_pins requires: {CNSpecRef, CGSpecRef}
  suite_protocols includes:
    normalize → indicatorize → score → (fold_Γ?) → compare → select → publish/telemetry

This description is not a MechFamilyDescription (because it contains multiple distinct mechanisms), and it is not a Pack (because it does not ship artifacts; it only declares membership and shared obligations/pins/protocols).

Example 2 (non-conformant). Misusing a family as a suite:

CHRMechanismFamily : MechFamilyDescription := { UNM, UINDM, USCM, ... }

This is a level error: MechFamilyDescription is reserved for realizations of a single mechanism intension.

Example 3 (non-conformant). Turning a suite into a hidden gate:

• The suite declares GateDecision values or embeds a DecisionLog.
• The suite defines acceptance thresholds (“pass score ≥ 0.7”) as part of suite obligations.
• The suite embeds Φ/CL tables or invents ad-hoc “transfer edges”.

All violate the separation between mechanism/suite descriptions and gate-level operational control.

#Archetypal Grounding

A suite is an archetypal “passport” or “capability bundle descriptor”:

• It answers what mechanisms exist in the bundle and what shared invariants make their composition lawful.
• It provides shared contract anchors (pins) that downstream planning and work must cite.
• It remains descriptive: it does not execute, it does not contain run-time outputs, and it does not replace the E.TGA subgraph that actually connects nodes by Uses and manages crossings.

#Bias-Annotation

Common biases this pattern guards against:

• Overloading “family”. Treating “many different mechanisms” as “many realizations of one mechanism” destroys level hygiene and encourages semantic drift across members.
• Publication conflation. Using “pack” semantics to smuggle publication/shipping obligations into the meaning of a mechanism bundle.
• Gate conflation. Treating suite-level obligations as gate decisions (“block”) instead of keeping block at the gate layer.
• Convenience totalization. Collapsing partial orders into scalars “for ease of selection”, which undermines set-return semantics and legality gating.

#Conformance Checklist

A MechSuiteDescription is conformant iff all applicable items hold:

CC‑A.6.7‑1 (Correct level). The suite’s mechanisms enumerate distinct U.Mechanism.Intension members. The suite is not encoded as MechFamilyDescription.

CC‑A.6.7‑2 (Description token, not U.*). The suite token is a Description token and MUST NOT be introduced under U.*. Its name ends with …Description.

CC‑A.6.7‑3 (No execution semantics). The suite MUST NOT define mechanism blocks (OperationAlgebra, LawSet, etc.) and MUST NOT be used as a mechanism node.

CC‑A.6.7‑4 (No gate decisions). The suite MUST NOT define GateDecision, MUST NOT publish DecisionLog, and MUST preserve gate/mechanism separation.

CC‑A.6.7‑5 (Contract pins, not duplication). If the suite is legality-gated for numeric comparison/aggregation/scoring, it MUST require CG‑Spec citation pins (and SHOULD require CN‑Spec pins where applicable). It MUST NOT duplicate contract content as “local CG‑Spec”.

CC‑A.6.7‑5a (CN+CG pins for legality-gated characterization). If the suite is legality-gated for characterization, it MUST require both CNSpecRef and CGSpecRef as pins (references), consistent with A.6.7:4.3.

CC‑A.6.7‑6 (Transport discipline preserved). The suite MUST NOT introduce transport exceptions. Any crossing obligations must remain Bridge-only and must route penalties to R/R_eff only.

CC‑A.6.7‑7 (Tri-state guard discipline when used). If the suite declares admissibility/eligibility semantics, it MUST use GuardDecision := {pass|degrade|abstain} and MUST NOT coerce unknown to pass.

CC‑A.6.7‑8 (No thresholds in core). The suite MUST NOT publish acceptance thresholds or “passing scores”. Thresholds must remain in acceptance clauses / task signatures / gate profiles.

CC‑A.6.7‑9 (Crossing visibility anchors). If suite use depends on crossings (context/plane/kind, entry into U.WorkEnactment (LaunchGate), or edition-key changes), the suite MUST require crossing visibility anchors (BridgeId/channel, ReferencePlane, CL mode, policy-id pins, UTS/Path pins) as audit obligations, without embedding the tables.

CC‑A.6.7‑10 (Suite id present). The suite MUST declare mech_suite_id: MechSuiteId so that downstream planning/audit can cite it stably.

CC‑A.6.7‑11 (Two-bridge discipline preserved). If suite obligations claim cross-kind/described-entity validity, they MUST require explicit CL^k handling (two-bridge rule) and MUST NOT allow implicit described-entity changes.

CC‑A.6.7‑12 (Implementation export hygiene when cited). If the suite cites realizations/implementations, the citations MUST preserve export/import discipline (LOG/CHR: no Γ export; CAL: exactly one Γ; imports acyclic).

CC‑A.6.7‑13 (No Pack conflation). The suite MUST NOT be introduced, named, or used as a publication/shipping Pack.

CC‑A.6.7‑14 (Protocol closure & explicitness). If suite_protocols is present, every ProtocolStep.mechanism MUST be a member of mechanisms (WF‑MS‑2) and the protocol MUST NOT rely on implicit mechanism steps or implicit crossings.

CC‑A.6.7‑15 (P2W split preserved when applicable). If the suite requires a planned-baseline pin (e.g., a planned slot-fillings artifact), that baseline MUST be a WorkPlanning artifact and MUST NOT contain launch values or FinalizeLaunchValues witnesses; such witnesses remain U.WorkEnactment-only.

#Common Anti-Patterns and How to Avoid Them

1. Anti-pattern: “Family-as-suite”. Using MechFamilyDescription to list multiple distinct mechanisms. Fix: use MechSuiteDescription for “many mechanisms”, and keep MechFamilyDescription for “many realizations of one mechanism”.

2. Anti-pattern: “Pack-as-suite”. Naming/using the suite as a Pack. Fix: reserve Pack for publication/shipping bundling; use Suite for mechanism bundles.

3. Anti-pattern: “Suite contains legality tables”. Duplicating CG‑Spec or embedding CL/Φ/Ψ tables in suite obligations. Fix: publish pins and references only; keep legality content in …Spec and policy registries; keep crossing realization in E.TGA/gate surfaces.

4. Anti-pattern: “Suite is a hidden gate”. Introducing thresholds, block, or DecisionLog in the suite. Fix: suite declares guard formats and required pins; the gate owns decisions.

5. Anti-pattern: “Implicit calls”. A protocol implies “normalize happens somewhere” without explicit member and pin visibility. Fix: protocols enumerate steps and required pins; E.TGA Uses edges remain explicit.

#Consequences

Benefits.

• Eliminates level confusion between “family of realizations” vs “bundle of mechanisms”.
• Provides a Kernel home for universal obligations reused across multiple patterns (notably Part G universalization).
• Makes legality/transport/audit obligations shared and explicit, reducing semantic drift across member mechanisms.

Costs.

• Introduces an additional descriptive artifact that must be maintained as suites evolve.
• Requires discipline: suites must remain descriptive and must not become “meta-mechanisms” or “hidden gates”.

#Rationale

Characterization and legality-gated selection pipelines are not unified by a single shared BaseType; they are unified by:

• shared contract surfaces (e.g., CN‑Spec / CG‑Spec),
• shared transport and crossing discipline (Bridge-only; penalties to R_eff),
• shared guard semantics (tri-state, no coercion),
• and explicit protocol constraints (allowed pipelines).

Encoding this unity as “one mechanism” or “one family” forces false commonality and invites hidden semantics. A dedicated suite descriptor preserves modularity and keeps the level separation clean.

#SoTA-Echoing

This pattern echoes post‑2015 best practice in modular reasoning systems: separation of contract surfaces from operators, explicit composition protocols, and strong boundaries between decision procedures and gating/acceptance control.

In modern multi-step evaluation pipelines (e.g., calibrated scoring, uncertainty-aware comparison, portfolio/pareto selection, and quality-diversity archives), correctness typically relies more on explicit contracts and lawful composition than on a single monolithic “universal metric”. MechSuiteDescription provides the Kernel representation that allows such pipelines to be described with stable obligations while keeping domain methods and FPF patterns generators outside the universal core.

#Relations

• Relates to A.6.1: suite members are U.Mechanism.Intension; the suite does not replace the mechanism definition.
• Relates to A.6.5: suites must not weaken slot/ref discipline; any suite protocol assumes member mechanisms follow A.6.5 invariants (SlotKind stability, correct refMode, no semantic meaning in SlotIndex).
• Relates to E.18 / P2W: suite protocols describe intended composition; actual composition and crossings are expressed in E.TGA subgraphs and P2W flow.
• Relates to E.19: suite-level conformance is a conceptual review checklist; suites require pins/anchors rather than procedural validation.
• Relates to G.10: suites are not packs; publication/shipping is handled via G.10 and MVPK faces.

#A.6.7:End