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

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 11:55:15 UTC

Practical-Use Cards

These cards offer a non-exhaustive set of optional routes for extended work with a pattern language, each selectable by its situation and intended result and composable only from contributions current in the actual case.

The keys only help navigation. Compare cards by the situation and intended result, then open the direct patterns needed in the actual case. Skip a contribution whose question is not current, and stop at the first useful result or blocker.

UNFAMILIAR-THEORY - Make an unfamiliar theory usable

  • Situation: A theory offers a useful construction or result, but you cannot yet assemble and interpret its application to your question.
  • Question: How can you obtain the needed consequence and use it?
  • First useful result or blocker: A worked application with an interpreted answer, or the missing operation, premise or correspondence that directs the next contribution.
  • Mantra: Recover the question the theory helps answer. Connect its objects and rules to one case. Obtain the construction and reconstruct the decisive argument. Compare the corresponding operations when using another representation. Apply the consequence; use what suffices or identify the remaining question.
  • Start with: B.5.TU for application construction. B.5.RC and B.5.RA supply construction and argument recovery, A.6.3.RT an operative expression, and C.29.1 result transfer. Use C.39 for a missing way.
  • Stop or return: An adequate supplied result can enter where needed. Stop when its interpreted consequence answers the question. If a premise changes, follow its effect instead of repeating unaffected work.

PHYSICAL-RESULT - Connect physics, mathematics and computation

  • Situation: A team has physical, mathematical and programming knowledge, but cannot connect the contributions needed to produce a physical result.
  • Question: Which missing contribution prevents the next engineering move?
  • First useful result or blocker: An interpreted calculation, proposed realization or located failure in the physical account, computation or execution.
  • Mantra: State the physical change sought. Construct the state and continuation needed to reason about it. Formulate the mathematical question and interpret its variables and operations. Obtain a result or computational procedure. Connect input preparation, system actions and output reading. Return to the physical question and repair the failed contribution.
  • Start with: B.5.MPC to connect available contributions and select the missing one. C.29 constructs mathematical correspondence; C.29.1 tests result transfer; C.29.2 constructs computation; C.29.3 connects it to an executing system. Subject engineering supplies physical laws and mechanisms.
  • Stop or return: Reuse ready contributions. Stop when the result suffices for the present decision. Reopen the contribution whose changed condition invalidates its use.
Expansion for PHYSICAL-RESULT

Divide the work. Give the next participant the result, what it denotes and the assumptions needed to use it. For the robot in B.5.MPC:5.1, the physical contribution supplies the motion model; the mathematical contribution relates distance to motor increments; the computational contribution produces an integer command and its rounding bound; the realization contribution checks what that command makes the controller do. People and AI agents can take these contributions according to their capabilities.

Use A.3.3 to construct a missing state account and C.16 for a needed measurement relation. These are dependencies between results. A ready model or computation can be reused at its point of need. Slip can reopen the motion model, overflow the command representation, and changed timing the execution arrangement. A calculated displacement remains conditional on the model until actual motion is established.

ARCHITECTURE — Carry an outside need through structure and feedback

  • Situation: A system or another architecture subject must produce an outside result, but its pressure, options, decision, or realized feedback is unclear.
  • Question: What missing architecture result prevents the next useful decision or action?
  • First useful result or blocker: One clear architecture question, candidate comparison, decision, or exact missing fact or constraint.
  • Mantra: Start with the outside change and who relies on it. Name the subject and pressure; separate facts from intended constraints; compare plausible structures; choose what the current decision needs; check what the realized structure produces; reopen when use, evidence, or structure changes.
  • Start with: C.32.P2S, then the pattern for the current question in C.30, C.32, C.32.PAD, or C.30.AD.
  • Stop or return: Stop when the first result makes the architecture work reviewable. The card is not a compulsory lifecycle.

PRACTICE-ARCHITECTURE — Connect methods with their use, support and development

  • Situation: A decision about methods depends on performed or planned Work, capabilities, providers, descriptions, tools or cultural change whose structures do not align one-for-one.
  • Question: Which relations change how the methods can be used or improved?
  • First useful result or blocker: One readable synthesis, one bounded development action, or the exact missing Work case, relation, or transfer evidence.
  • Mantra: Start from representative Work and its needed result, or a proposed use with a later-test condition. Keep Methods, Work, capabilities, providers, descriptions, tools and cultural processes distinct; compare the structures that conflict; develop a limiting capability when needed; test transfer in real Work; return when the method, provider, evidence or style changes.
  • Start with: C.32.MWA; use E.23.CDI, E.23, or C.36 only for the question actually opened.
  • Stop or return: Stop when the synthesis or transfer result answers the decision. A method description is distinct from the method and from performed Work.

WORKING-DOCUMENTS — Make a document answer one use

  • Situation: A document is requested, but its label does not reveal the use it must support.
  • Question: Do you need to check one view, reuse related views, show the same subject differently, see enough structure, compare named sources, or use an architecture description in a decision?
  • First useful result or blocker: A checked view, a reusable viewing approach, another presentation of the subject, an account of sufficient or missing structure, a source comparison, the architecture-description result needed now, or the exact blocker.
  • Mantra: Name who will use the document and what it must support. Check one view; prepare recurring views; show the subject another way; expose enough structure; compare sources; or use a description in architecture work. Keep document, subject, decision, and performed Work distinct. Stop when the needed result exists; return when its use or content changes.
  • Start with: E.17.0 for one viewpoint; E.17.1/E.17.2 for recurring use; A.6.3.RT for representation change; C.33 for structural information; E.17.ID.CR for source comparison; C.30.AD for architecture-description use; otherwise use the direct pattern for the document result.
  • Stop or return: Stop when that result answers the use. One file may carry several results without merging them.

OPTION-COMPARISON — Keep unlike option results distinct

  • Situation: Labels such as build, buy, reuse, provider, internal, outsource or AI need comparison; uncertainty blocks costly commitment; or advice demands costly or infeasible work.
  • Question: Form complete ways, compare or retain candidates, govern a pool, prepare options for another chooser, choose now, or repair an evidence demand?
  • First useful result or blocker: A complete-enough same-result way set, comparison or retained set, pool rule, prepared OptionSet, ChoiceResult, usable advice, answer to the blocking question or exact gap.
  • Mantra: Name one result, use, situation, horizon, and acceptance basis. Turn labels into complete ways on one parity basis, keeping supported, proposed, and unknown premises visible. Compare or choose only when current; preserve worthwhile variants and gaps. For costly action, resolve only the uncertainty blocking commitment. Return when the result, basis, evidence, or use changes.
  • Start with: C.11.DUA for a demand’s contribution or feasibility; C.38 for incomplete ways; otherwise A.19.ECS, C.18, C.19, G.5 or C.11 for the current question. For costly commitment, select the current check in A.10, B.3, A.20, A.21, C.28, C.11 or A.15.5.
  • Stop or return: Stop at the present question’s result. Option descriptions establish neither choice nor capability, authority, Work, provision, delivery, acceptance or use.

PROBLEM-SHAPING — Stop at the earliest honest problem-side result

  • Situation: Something matters, but the team may have only signals worth preserving, a direction for inquiry, a question about competing explanations, or enough clarity to accept a problem statement.
  • Question: What can you honestly produce now: preserved signals, a routed direction for inquiry, an explicit question that contrasts possible explanations, or a problem statement ready for acceptance?
  • First useful result or blocker: A preserved set of signals, a clear inquiry route, a question about plausible explanations, an accepted problem statement, or the exact missing anchor, route, subject, constraint, or acceptance basis.
  • Mantra: Keep what was noticed before declaring a problem. Route the inquiry only when the signal has a stable anchor. Ask about explanations only when the open question and contrast are clear. Accept a problem statement only when the subject, constraints, unresolved relations, important distinctions, and basis can be stated. Stop at the earliest useful truth; return when its basis changes.
  • Start with: A.16.1 for a cue pack, B.4.1 for routed cues, B.5.2.0 for an abductive prompt, and C.22.2 for an accepted ProblemCard.
  • Stop or return: Do not force a cue into a problem. Open C.22.PFR only when whether the adverse relation obtains changes the next use.

IMPROVEMENT — Define better before repeating change

  • Situation: A team wants to improve something but has not agreed what better means or how the changed version will be checked.
  • Question: Which evaluation question, characteristics, scales, changes, and comparison make improvement reviewable?
  • First useful result or blocker: One evaluation question, current assessment, bounded change, before-after comparison, or exact missing use, evidence, scale, or trade-off.
  • Mantra: Name the entity, current state, and use that better must serve. Frame the question before choosing metrics; select characteristics, scales, and protected trade-offs; assess the current state; compare candidate changes; make only the supported change; evaluate it on the same basis; continue, stop, or change direction from that result.
  • Start with: E.22, A.19.ECS, C.16, and E.23 as their questions become current.
  • Stop or return: Stop at the first missing prerequisite or useful comparison. Reopen when the entity, use, evidence, or scale changes.

WORDING — Repair language without replacing the project question

  • Situation: A load-bearing sentence hides the subject, relation, kind, use, or nearby false inference.
  • Question: What should the reader understand and do, and which distinctions matter for that use?
  • First useful result or blocker: One plain repaired sentence, direct clarification, local naming result, or exact missing subject, sense, test, or reader use.
  • Mantra: Recover the ordinary project sentence first. Name what it is about, what it claims, and who must use it; add ontological distinctions only where they change truth, understanding, or action; choose a durable name only when later use needs one; rewrite in plain technical language; check that a reader without private context can recover the intended claim and action; retain a guard only under F.19’s full grounded-contribution test; return to the domain task.
  • Start with: F.19; use E.10 for unresolved FPF wording, and F.18, F.0.1, F.9, or the subject’s direct pattern only when needed.
  • Stop or return: Stop when the reader can understand the claim and carry out its intended use. Do not continue ontology work after the language problem is solved.

SOTA-PORTFOLIO — Move from a plural field to the cheapest useful result

  • Situation: A project needs the modern field of approaches rather than one popular answer and may later need maintained domain guidance.
  • Question: What plural view is adequate now, and does the remaining problem call for reuse, a contribution, another product, a DPF or LPF, or no maintained result?
  • First useful result or blocker: One source-linked SoTA view, live option set, reuse route, framework decision, or exact missing scope or maintenance basis.
  • Mantra: Name the practical question, scope, freshness need, and rival traditions. Build a source-linked plural view; preserve disagreement, source-use limits and constructions; compare useful approaches; try cheaper reuse or contribution first; open a framework decision only for a recurring unmet problem; author and test the needed patterns; refresh when the field or use changes.
  • Start with: G.2; add C.18, C.19, or G.5 for the set and the E.4/E.9 authoring route only if a framework is selected.
  • Stop or return: Stop at the first adequate maintained or one-off result. If allocation to familiar patterns loses a source’s construction, use FPF.Preface:16.5 to identify the missing result, obtain it through the appropriate subject method and return to the original use. A source pack or proposal is not a framework by appearance.

SYSTEM-DELIMITATION — Separate parts, selected boundary, and crossings

  • Situation: One System is recognized, but a decision mixes its parts and assembly with a chosen boundary, external participants, and relations that cross it.
  • Question: Which facts, use-relative choice, crossings, and selected structure answer the decision?
  • First useful result or blocker: One exact part or assembly fact, boundary choice, crossing relation, selected structure, or missing participant, predicate, constraint, or use.
  • Mantra: Start with the recognized System and decision. Recover parts and assembly as facts; keep external participants outside the part list; choose a boundary only when alternatives matter; name every crossing by its own relation; select a joint structure only when organization changes the decision; reopen when identity, facts, use, crossings, or constraints change.
  • Start with: B.1.2, A.14, and C.13; use C.11, C.32.PAD, the direct relation pattern, or A.22 only when needed.
  • Stop or return: Stop at the smallest result answering the decision. If system recognition is unresolved, return to A.1.SCR.