FPF Reference

    A.6.7:4.3 SuiteSpecPins

    Preface node heading:a-6-7-4-3-suitespecpins:16587

    What this page is

    This is generated FPF reference text from the specification preface or supporting sections. It helps interpret FPF; it is not FPF Reference product documentation.

    Methodology

    Use it to understand how the specification wants to be read, then return to a route, pattern, or work packet for active work. Cite generated IDs only when the wording changes the task decision.

    Content

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

    SuiteSpecPins := ⟨
  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).
    • Spec pins are citations and anchors. They do not replace the underlying …Spec objects.
    • A suite MAY require the presence of a planned-baseline WorkPlanning plan item 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 WorkPlanning plan item is authored in WorkPlanning and is citeable by downstream U.Work.Audit; any FinalizeLaunchValues witness remains U.WorkEnactment-only.
    • A suite MAY be referenced by TargetSlotOwnerRef for a planned-baseline plan item: the Description-level ref names the description whose SlotKind set is being filled. This does not make the suite a mechanism and does not create run-time slot instances.

    Last Updated: 2026-06-17 — upstream FPF commit 646b0b9b (github.com/ailev/FPF)