FPF Reference

    G.9:4.2 — Parity planning (one exact U.WorkPlan)

    Preface node heading:g-9-4-2-parity-planning-one-exact-u-workplan:105621

    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 exact BaselineSet (MethodFamilies, and optionally GeneratorFamilies) used as the comparison baseline. When SoS-log or source-maturity values change baseline eligibility or interpretation, cite SoS‑LOGBundleId? and the source-maturity ids by reference; acceptance-gate thresholds remain in G.4 Acceptance.

    2. Bind subject, scope, and evaluation window. Choose exactly one subject branch: one entityOfConcernRef, or exact targetRefs[] under their existing kinds and editions. For G.5 families, use MethodFamilyRowRef or GeneratorFamilyRowRef, not a bare lineage id. Then fix groundingHolonRef, referencePlaneRef = ReferencePlane, one exact ClaimScope, and EvaluationWindow; record them without silent widening, narrowing, collapse of an EntityOfConcern into the grounding holon, or window drift.

    3. Define baseline-set reference. Declare what counts as the baseline and how it applies to the selected subject in BaselineBindingRef (for example, through an EvidenceGraph path slice or an upstream shipped package or publication-record id). If BaselineSet also supplies the exact compared targets, say so and use the same refs by value; otherwise keep baseline and subject refs distinct.

    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.

    5. Pin governance, CSLC comparability and admissibility references, and comparator references. CNSpecRef, CGSpecRef, and ComparatorSpecRef are referenced with explicit edition pins.

    6. 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.

    7. 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.

    8. 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).

    9. Attach planned fillings when applicable. If parity depends on planned slot fillings, this WorkPlan contains the relevant A.15.3 rows in PlannedFillingRows[]; each row points to a declaration member defined by its own pattern and has no independent reference or identity. Omit the field when no such row is needed.

    10. Publish crossing pins (when invoked). When expressions have distinct recovered F.17 meanings, establish the required F.9 relation and publish its Bridge and CL pins; ReferencePlane or Kind crossings cite their own exact crossing basis and pins. Penalties affect R_eff only (invariants pinned through G.Core).

    Last Updated: 2026-09-03 — upstream FPF commit b999972c (github.com/ailev/FPF)