FPF Reference

    G.9:4.2 — Parity planning (design‑time / WorkPlanning)

    Preface node heading:g-9-4-2-parity-planning-design-time-workplanning:83073

    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

    Planning is the act of making the parity run reproducible by construction:

    1. Fix the baseline set. Choose the BaselineSet (MethodFamilies, and optionally GeneratorFamilies) to compare; where parity context matters, cite SoS‑LOGBundleId? and source-maturity ids by reference (acceptance-gate thresholds remain in G.4 Acceptance).
    2. Bind scope. Fix entityOfConcernRef, groundingHolonRef, and referencePlaneRef = ReferencePlane and record all three in the plan (no silent widening/narrowing or EoC/grounding-holon collapse).
    3. Define baseline-set reference. Declare what counts as “baseline set” and how it is cited (e.g., BaselineBindingRef, the evidence-backed baseline-set reference, pointing to an EvidenceGraph path slice or an upstream shipped package or publication-record id).
    4. Equalise window (and budget, if pinned). Declare a single FreshnessWindows and apply it across all baselines; if Budgeting is used/pinned, it MUST be shared/pinned across baselines as well.

    When specialization is part of the parity claim, the same plan should also hold constant the declared task family or target scope cut, the work-measure threshold target, adaptation budget, prior exposure declaration, and freshness window; if transfer, retention, downstream exploitation efficiency, downside field, or corridor entry are part of the claim, those pins should be explicit as well, including the baseline relative to which corridor entry is being claimed.

    1. Pin governance, CSLC comparability and admissibility references, and comparator references. CNSpecRef, CGSpecRef, and ComparatorSpecRef are referenced with explicit edition pins.
    2. Pin measurement/comparator definitions (conditional). Where parity depends on mode‑specific definition records (e.g., DHC/QD/OEE), pin the relevant definition ids/editions/policies. The minimum required pins are declared by the applicable Extensions blocks (e.g., G.9:Ext.DHCParityPins, G.9:Ext.QDArchiveParity, G.9:Ext.OEEParity) and the referenced records they cite.
    3. Bind comparator choice to CG-Spec (CSLC comparability and admissibility). Any numeric comparison or aggregation MUST be CSLC‑admissible and cite the corresponding CG‑Spec entry (via ComparatorSpecRef). If Characteristics differ by unit, scale, or space, the plan MUST declare the ids used for “normalize, then compare” (UNM_id?, NormalizationMethodId[]?, NormalizationMethodInstanceId[]?) — ids only; semantics are defined elsewhere.
    4. Declare order & PortfolioMode semantics. Parity MUST preserve set‑return semantics; PortfolioMode and DominanceRegime are either explicitly pinned or cited through G.Core.DefaultGoverningDefinitionIndex. IlluminationSummary/coverage/regret remain telemetry unless a CAL policy explicitly promotes them (policy‑id pinned & recorded).
    5. Attach planned baselines (when applicable). If parity depends on planned slot fillings, the plan cites the relevant SlotFillingsPlanItem refs (A.15.3) via PlanItemRefs[] rather than embedding a competing baseline object (nil‑elision when unused).
    6. Publish crossing pins (when invoked). Cross-Context or cross-plane/Kind reuse requires explicit Bridge/CL/Φ pins; penalties affect R_eff only (invariants pinned through G.Core).

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