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

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 16:02:47 UTC · snapshot created 2026-10-03 16:03:51 UTC · last check 2026-10-03 17:15:04 UTC

E.18.1:1 - Problem frame

Use this pattern when an accepted ProblemCard@Context is ready enough to guide work, but the next FPF use is unsettled. Ask which accepted distinction should shape the next question, which relation and participants that question asserts, and what result or stop is needed before the next action.

The accepted ProblemCard@Context is the primary EntityOfConcern of any materialized P2W note. Start from one accepted claim and one decision or use that needs it. Then state the relation being asserted, name its participants, and apply the pattern whose Solution answers that relation-specific question. A separately identified U.Viewpoint episteme or BoundedModelUseStructure participates only when the claim designates that object and its organization changes how the receiving claim is interpreted; neither becomes an identity field of the ProblemCard or note. Method selection, planning, dated work, actual change, result interpretation, and return remain separate continuations. For each, state the exact current question and apply the pattern whose Solution answers it; carry only the returned result or honest stop. P2W introduces no relation kind or occurrence and is neither dated work nor a U.Transformation. Citing a PatternID, selecting a continuation, recommending an action, writing an imperative, or stating an intended realization does not admit any episteme as U.MethodDescription; A.3.2 requires one already identified C.2.1 episteme, one independently admitted U.Method as its exact EntityOfConcern, and at least one substantive way-of-doing claim.

Keep three objects separate. The accepted ProblemCard is the EntityOfConcern of a materialized P2W note. The note is identified under C.2.1 by its ClaimGraph, the accepted card, and its effective U.ReferenceScheme; its ClaimGraph names the receiving use and designates a separately identified viewpoint or model-use structure only when the claim uses that object and its organization changes how the receiving claim is interpreted. Each cited PatternID locates the Solution passage needed for the question about its subject EntityOfConcern. A practitioner or another capable system applies that guidance to the project entity or relation—for example, a System, episteme, Method, Work occurrence, or direct relation. When source wording says role, apply E.10.ROLE before treating it as a local system-role kind, separate System-classification judgment, assignment occurrence, participation or functioning relation, ordinary non-use, or missing-governor case. The compact note, diagram, plan, trace, and publication are epistemes or publication-side values that describe, constrain, or make those claims inspectable. Later method enactment or dated work can change or preserve a subject EntityOfConcern; improving a P2W note or completing its fields does not establish that subject change, work occurrence, evidence, acceptance, or result.

Primary reader and question. The reader already has an accepted ProblemCard@Context and must decide one next claim. Ask in ordinary words: what relation am I asserting, between which participants, and what result would change the next action? Then apply the pattern whose Solution answers that question. Source wording or a supporting episteme may help formulate the question but does not supply the downstream result.

So-what adoption test. Use P2W only when keeping the accepted distinction changes which relation you assert, what result you write, or whether you continue, split, stop, or return. If the relation and result are already settled and P2W would add only another note, skip P2W and apply the pattern whose Solution answers the current question.

E.11.PUA covers a smaller use and may begin without ProblemCard@Context: use one selected pattern for one current practical question and reach the smallest useful result that truthfully answers it, or an honest stop. That ordinary use may stop there; name a receiving use only when the enclosing P2W continuation or another actual later use is current. E.18.1 begins only when the wider work-facing continuation depends on preserving accepted problem-side material. PUA may support one pattern inspection inside a P2W flow, but it does not replace the accepted-problem carry-through.

E.18.1:1.1 - Use this when

  • an accepted ProblemCard@Context names a working problem and the team needs a disciplined next FPF use toward method, planning, performed work, or result interpretation;
  • an invariant, U.Signature(profile=FormalSubstrate), PrincipleFrame, mechanism-position, method-position, A.15.2 U.WorkPlan or plan-item wording cue, performed-work, result-record, or source-currentness cue is present, but the FPF kind or relation to use next is still unsettled;
  • a transformation-flow structure, mathematical path relation in a graph-shaped description, flow diagram, principle scheme, scenario, functional description, or source publication helps the team think, while the next FPF use still lacks an FPF kind or relation named by value;
  • a result artifact, telemetry line, acceptance record, quality-evaluation record, done-state update, feedback pin, or integration claim needs to be unpacked before it can guide the next FPF use.

E.18.1:1.2 - What goes wrong if missed

The team jumps from a convincing problem-side formulation into downstream language without naming the FPF relation being used. The work then looks responsive to the accepted problem, but the next record is unclear, the result phrase becomes too broad, and measurement or source-currentness changes have no honest return relation.

E.18.1:1.3 - What this buys

The practitioner gets one concrete next move: keep the accepted claim in view, state the question and participants, apply the pattern that answers it, and use the result it returns. Split several relation claims before applying their patterns. If the relation or needed facts are missing, keep the cue and stop. If a relied-on result changes, reopen only the continuation that used it. Add the compact note only when another person or later action must replay that path. The accepted problem-side distinction remains useful without becoming hidden permission to start work.

E.18.1:1.4 - Not this pattern when

  • there is no accepted problem-side record; use C.22.2 or the problem-side pattern named by value first;
  • the FPF kind under repair, relation, and record to write are already settled; use that pattern directly and do not add a P2W layer;
  • the requested output is a local project procedure, schedule, or work-management method; use the relevant work, planning, method, gate, or operational-management pattern;
  • the requested record or claim is an evidence case, assurance case, gate record, decision record, architecture description, publication-use claim, or wording-use repair; recover the relation and apply the pattern whose Solution answers that exact evidence, assurance, gate, decision, description, publication-use, or wording question.