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

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 17:24:51 UTC · snapshot created 2026-10-03 17:30:20 UTC · last check 2026-10-03 18:05:19 UTC

E.18.1:5.0 - Seal-failure carry-through

A maintenance team has an accepted ProblemCard@Context for recurrent seal failure. It records the operating conditions, the distinction between thermal deformation and material degradation, and the observations that would challenge that distinction. The team uses E.18.1 because diagnostic-method selection, repair planning, dated repair work, interpretation of the post-repair measurements, and return after a changed diagnosis all depend on preserving these accepted problem-side distinctions.

E.11.PUA may help the team inspect and apply one diagnostic-pattern candidate inside this flow. Its result might be one fit finding or one diagnostic method-selection input. That smaller result does not replace the accepted problem material, the repair plan, the repair work, or the later interpretation and return relations.

E.18.1 is grounded in a simple System and Episteme contrast. In System-facing work, an accepted problem-side record may lead toward method choice, planning, performed work, result records, and result measurement. In Episteme-facing work, the same record may lead toward a U.Signature(profile=FormalSubstrate) declaration, mathematical-lens use, description, publication, evidence, or gate-related claims. The P2W application asks one question in both cases: which FPF kind or relation can carry the next claim being made?

ArchetypeSystem-side groundingEpisteme-side grounding
TellA manufacturing team accepts a problem card showing that a fabrication issue is caused by a missing functional constraint.A research team accepts a problem card showing that two descriptions may be almost the same only under a declared U.Signature(profile=FormalSubstrate).
Show without P2WThe team treats the principle scheme as method selection, work plan, performed work, and acceptance evidence at once.The team treats mathematical equivalence as real-world identity, measurement validation, evidence, and decision claim.
Show with P2WThe team carries one accepted claim and separates method comparison from one exact A.15.2 U.WorkPlan. That WorkPlan’s declaration-local planned-filling content may carry the Method, window, intended performer and kind conditions, evidence-reference pins, freshness requests, and planned constraints; a needed row is cited only through the exact WorkPlan edition and its local-content locator. The team separately records references to dated U.Work occurrences while keeping those records as separate epistemes, and unpacks result relations; it writes a compact note only when replay matters.The team separates mathematical-lens use, U.Signature(profile=FormalSubstrate), bridge, measurement, evidence, and provenance relations, and keeps equivalence bounded by the declared formal relation.