Library / First Principles Framework (FPF) - Core Conceptual Specification
Jump to passage
In this reading

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 05:29:54 UTC · snapshot created 2026-10-03 05:30:57 UTC · last check 2026-10-03 05:55:15 UTC

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 declarations.
  3. Suite obligations: shared invariants that every member (and any permitted composition of members) must respect.
  4. Suite spec pins: required citations/pins to governing spec refs 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 := declared suite-level obligation
// Canonical reusable names (not exhaustive):
//   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: MechanismDeclarationRef[+] ,     // references to exact member declarations
  suite_obligations: SuiteObligations ,
  suite_spec_pins: SuiteSpecPins ,
  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 resolves to pairwise distinct A.6.1 declaration epistemes under C.2.1 identity; field order carries no semantics. Two citations of the same declaration are one member.

  • WF‑MS‑2 (Protocol closure and resolution). Every ProtocolStep.mechanism resolves to one member declaration at its selected edition, and step.operation resolves to one operation designator in that declaration. The selected operation supplies its arguments, results, laws and admission conditions. A stage label or unqualified family name is insufficient.

  • WF‑MS‑3 (Suite ≠ Pack). MechSuiteDescription does not carry shipping/publication payloads; use the applicable shipping or publication pattern for those results.

  • 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 exact declaration (order-free). mechanisms MUST denote a duplicates-free set of distinct U.Mechanism members. Membership order has no semantics; any intended ordering is expressed only in suite_protocols. A suite is defined by selected operation declarations and suite protocols.

Declaration reference and edition selection. MechanismDeclarationRef is a reference to an independently identified A.6.1 U.Mechanism episteme, not a new kind. Resolve it under the effective reference scheme to its content and EntityOfConcern. The published edition used for that resolution must be explicit or uniquely determined by the cited suite baseline. When several editions qualify, state a selection condition that yields one before using a protocol step; otherwise return the unresolved alternatives. There is no implicit latest.

Changing declaration content, EntityOfConcern or effective reference scheme follows A.6.1/C.2.1 identity. Changing a carrier, layout or citation alone can leave the member unchanged. A changed guard or argument selects a different declaration contract and requires the affected protocol bindings to be checked again. A claim that two declarations concern the same operation family needs that subject’s own identity rule; suite membership does not establish it. Distinct declaration contracts can be selected without inventing a universal operation-family kind.

  • 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 and does not absorb gate logic.