fpf.tools
Library / First Principles Framework (FPF) - Core Conceptual Specification
Jump to passage
In this reading
Source · lines 118188–118225

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 11:52:20 UTC · snapshot created 2026-10-03 11:53:41 UTC · last check 2026-10-03 12:05:13 UTC

G.9:4.3a — Worked parity slice

Ordinary case: compare two pump-triage method rows. The team from the G.5 example wants a reproducible comparison of the two exact selector-row editions, not a claim that one Method is universally better. Both rows use the same scheme, units, and ReferencePlane, so no normalization or crossing branch is needed.

ParityPlanRef = <PumpTriageParity, E1>
targetRefs = [<ThresholdTrendReview-local, R3>,
              <SpectralResidualReview-local, R2>]
entityOfConcernRef = absent
groundingHolonRef = PumpMaintenanceProgram-H1
referencePlaneRef = PumpVibrationTriage-RP1
claimScopeRef = PumpFleet-F7-VibrationTriageClaims-E1
EvaluationWindow = 2026-08-01T00:00Z .. 2026-08-07T23:59Z
BaselineSet = [<ThresholdTrendReview-local, R3>,
               <SpectralResidualReview-local, R2>]
BaselineBindingRef = PumpTriageBaselineBinding-E1
FreshnessWindows = { sensorSeries: at-most-24h-old-at-run,
                     evidencePath: at-most-72h-old-at-run }
CNSpecRef.edition = PumpCN-E2
CGSpecRef.edition = PumpCG-E4
ComparatorSpecRef.edition = PumpTriageComparator-E3
TaskSignatureRef = PumpVibrationTriage-T1
TaskMapRef = absent                         // this G.5 case uses no G.4 CAL gate
ParityPinSet = [PumpCN-E2, PumpCG-E4, PumpTriageComparator-E3, PumpVibrationMeasureSpec-E2]
EvidenceGraphId = PumpTriageEvidence-E5
PathId[] = [PumpReadings-P7, ComparatorRun-P3]
PathSliceId = PumpParitySlice-S2
expected selector result = unordered Shortlist

The plan explicitly says that BaselineSet and targetRefs[] contain the same two row refs. EvaluationWindow bounds the observations and results included in the comparison. FreshnessWindows asks a different question at run or reuse time: whether each required input and evidence path is still recent enough to rely on. A report from this run carries parityPlanRef=<PumpTriageParity, E1>, BaselineBindingRef=PumpTriageBaselineBinding-E1, the same evidence path, and the unordered Shortlist; it does not invent a scalar winner.

Conditional specialization case. Loop-engineering parity may add further pins after the ordinary comparison boundary above is complete. An evaluation program, benchmark script, or dashboard is part of the evaluation or comparison procedure; it is not the Characteristic being improved.

  • Two agentic search setups both claim bounded specialization on the same declared task family.
  • Their ParityPlan also pins the same threshold target, adaptation budget, prior-exposure declaration, and corridor-entry baseline. One setup reaches threshold sooner but shows low retention and no transfer. The other reaches threshold later, but carries reusable transfer and lower downside field.
  • Their CSLC-admissible ParityReport states what was held constant, which signals remained telemetry, and why the outcome stays a selected set or partial order rather than collapsing into a scalar winner. These specialization values extend the complete comparison boundary; they do not replace its subject, scope, windows, baseline binding, comparator editions, or evidence.