FPF Reference

    Practical-Use Cards

    Preface node heading:practical-use-cards:526

    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

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

    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 honest 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 — Develop a practice without collapsing its structures

    • Situation: Methods, Work, capabilities, providers, descriptions, tools, and cultural change do not align one-for-one in a practice.
    • Question: Which relations must be reconciled for the practice to become usable or improve in representative Work?
    • First useful result or honest 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. Keep Methods, Work, capabilities, providers, descriptions, tools, and cultural processes distinct; compare the structures that conflict; develop the limiting capability; test transfer in real Work; return when practice, 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 practice description is not the practice or 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 honest 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.

    COMMUNICATION-FOR-USE — Make communication useful, then learn from what happens

    • Situation: A report, model, message, or answer seems clear, but its intended use and evidence are unclear, including whether its producer can use it later.
    • Question: Who should understand or do what with it, what evidence is enough, and what should change if that use is not achieved?
    • First useful result or honest blocker: A supported decision to keep or repair it, change prerequisites or a future use, or stop, with evidence, causation, and permission limits.
    • Mantra: Name who should understand or do what. Judge the act of communicating against that use. Keep the act distinct from its wording and medium; separate interpretation, response, later action, world change, and causal contribution. Repair wording, representation, prerequisites, medium, interaction, or a future use—or stop. Check authority, consent, and admissibility separately. Do not rewrite the earlier use after seeing the response.
    • Start with: A.2.9 for communicative Work; A.6.3.CR for wording; A.6.3.RT for representation; A.6.3.NAR, E.17.EFP, or E.24.PUB for narrative, explanation, or publication. A.10 for evidence, C.28 for causation, and C.11 only to compare repair options.
    • Stop or return: Stop when the named use has enough support or a blocker is explicit. Response or silence alone proves neither meaning, success, causation, authority, consent, nor permission.

    OPTION-COMPARISON — Keep unlike option results distinct

    • Situation: A candidate list mixes labels such as build, buy, reuse, provider, internal, outsource, or AI; or one unresolved question makes a costly commitment unsafe.
    • Question: Must you form complete ways to obtain one result, compare or retain them, govern a pool, prepare a set for another chooser, choose now, or resolve the uncertainty blocking commitment?
    • First useful result or honest blocker: A complete-enough same-result way set, comparison or retained set, pool rule, prepared OptionSet, ChoiceResult, 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.38 when labels or fragments need complete ways; otherwise open only the current branch in A.19.ECS, C.18, C.19, G.5, or C.11. For costly action, use only 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 result for the present question. An option description does not choose or establish capability, authority, Work, provision, delivery, acceptance, or use.

    RESULT-TO-NEXT-MOVE — Route an obtained result to the next probe or option

    • Situation: A DPF or project calls something information gain, learning progress, novelty, or a former cue and wants it to change the next probe or option.
    • Question: What result actually exists, and which downstream question, if any, is current?
    • First useful result or honest blocker: The direct result plus the first needed reliance disposition, characterization, possibility-space claim, configuration-relative comparison, ChoiceResult, or missing basis.
    • Mantra: Name the result; split ambiguous learning claims; keep each with its direct pattern. Move only to the current question: relied-on evidence, characterization or possibility space, realizable configuration comparison, or live choice. Stop when the present question is answered.
    • Start with: Use E.10.LRN only to recover a result hidden by learning; otherwise its direct pattern. Then use A.10 only for actual reliance, C.17/C.18 only for characterization/space change, C.11.CRC only for a missing finite configuration comparison, and C.11 only for a live choice.
    • Stop or return: Stop before every non-current question. Observation, objective, former cue, and characterization retain their identities; this card creates no generic signal, cue, qualification, or choice.

    ACTUAL-TEMPORAL-STRUCTURE — Recover what actually obtains before testing coordination

    • Situation: A cycle, onset list, trace, notation, or geometry is called rhythm, but may be a prescription, representation, Method unfolding, or account rather than what obtains.
    • Question: Which subjects and relations support one actual selected structure, what grounds it, and what coordination change should be tested?
    • First useful result or honest blocker: One A.22-selected structure and grounded C.2.1 account—or the missing bearer, relation, observation, or grounding. Keep future specifications and representations separate. For coordination, add direct relations, trial conditions, observations, and next decision or stop.
    • Mantra: Start with actual changing subjects and use. Recover changes, Work parts or continuous carrier, plus exact obtaining relations. Select one structure; ground only supported account. Keep structure, account, future specification, representation, Method unfolding and Work distinct. For coordination, name bearers and direct relations; compare interventions, try one in bounds, observe, then decide or stop. Never infer structure from periodicity, onsets, notation or geometry.
    • Start with: A.3.4/A.15.1 for change/Work, C.27.TA/A.22 for claim/structure, C.2.1 for account; add specification, representation, decision, causal, trial, or domain patterns only when current.
    • Stop or return: Stop when use is answered. Return when bearer, relation, constraint, grounding, intervention, or use changes; domain Methods stay in DPF.

    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 honest 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 honest 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 honest 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 the result with a cold reader; 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 honest 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 and source-use limits; 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. 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 honest 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.

    CONSEQUENCE-BEARERS — Find omitted Systems before closing a decision

    • Situation: A change has one plausible receiver, but the list may omit other physical or operational wholes that can change.
    • Question: Which other Systems may undergo a relevant change, through what supported relation or still-modal path, and what should the receiver do next?
    • First useful result or honest blocker: An affected-System consequence account naming the focus; one or more bearers or intended referents; obtaining or modal path; possible changed characteristic; support, uncertainty, receiver connection, and residual; plus the next probe or stop—or the missing System-recognition or relation fact.
    • Mantra: Name the focus and receiver; generate concrete possibilities; trace obtaining relations and modal paths separately; challenge the boundary; recover real holons instead of a level ladder; qualify each changed characteristic; keep the sides distinct; return the cheapest probe, constraint, alternative, monitoring condition, or honest stop.
    • Start with: A.1.CSD; use A.1.SCR only when a candidate's systemhood is load-bearing, and leave through the direct evidence, causality, comparison, domain, or value pattern only when that stronger question is current.
    • Stop or return: Stop at the smallest account that changes or holds open the named decision or investigation. Return when the focus, configuration, horizon, whole, relation support, bearer, observation, or receiving use changes.

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