FPF Reference

    Decide Whether FPF Fits

    Preface node heading:decide-whether-fpf-fits:399

    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

    Use FPF when ordinary discussion is no longer enough to keep work coherent. Typical signs:

    • several teams, experts, tools, or AI agents share reasoning about the same work;
    • the real-world test is slow, expensive, noisy, risky, or politically hard to repeat;
    • different readers need different reports, dashboards, explanations, or decisions about the same underlying work;
    • names, roles, responsibilities, options, evidence, or quality criteria are starting to blur;
    • the team needs a current view of possible approaches, not just one recommendation;
    • a decision is small enough to make now but important enough to leave a durable reason.

    FPF is probably too heavy when the task is small, feedback is fast and cheap, the vocabulary is already stable, the decision will not be reused or audited, and a quick answer is enough.

    FPF is mainly useful for people who have to keep difficult work understandable across boundaries:

    • engineers and systems engineers working with complex products or operations;
    • researchers building claims for inspection or reuse by others;
    • platform and AI teams coordinating humans, models, tools, and approvals;
    • safety, assurance, compliance, and regulatory leads who need visible evidence and responsibility boundaries;
    • managers and product leaders comparing options, budgets, risks, and delivery promises without hiding trade-offs.

    There are three common ways to use FPF:

    1. Human-only: use it as a writing and review discipline for meetings, notes, decisions, and technical documents.
    2. Mixed team: use it to keep specialists, managers, safety leads, and AI assistants aligned around the same work.
    3. AI-assisted: attach or index the specification, ask for plain-language project help first, and use pattern names only when they make the answer easier to check.

    Stronger AI does not remove the need for FPF. AI can generate fluent options quickly, but projects still need to decide what counts as evidence, which option is being compared, who may rely on an answer, when a claim is stale, what remains only a guess, and what work is actually authorized. FPF helps make those boundaries explicit before a confident answer becomes an expensive mistake.

    Core ideas in plain language:

    • first name the project object under concern; when it is treated as a whole with parts, FPF calls it a holon;
    • local teams may use local meanings; boundary-crossing work makes the translation relation explicit;
    • the project object itself, its description, a dashboard about it, a decision about it, and the work done to change it are not the same;
    • architecture is structure of that holon or project object in a context, not the diagram, document, approval, or plan about it;
    • serious architecture work can move from problem pressure to candidate structures, selected structures, decisions, method and work, actual structures, and feedback;
    • when the current question is which reusable way of doing changes, produces, derives, selects, controls, or preserves the project object under stated conditions, inspect A.3.1 U.Method; a strategy name, procedure text, program, plan, dated run, mechanism, or evidence record does not answer that method question by its label or form;
    • when an accepted ProblemCard@Context claim must remain usable while the project selects a method, prepares or performs work, interprets a result, branches, stops, or returns after a changed assumption, inspect E.18.1 P2W Problem-to-Work Carry-Through; it carries that claim into one next value or relation governed by its direct pattern rather than prescribing one universal workflow;
    • when a route-like explanation has several candidate positions and proposed relations or constraints that may change which continuations remain admissible, use it as a ProvisionalUnfoldingDemonstrationDescription@Context while any A.22.CGUS admission coordinate remains unresolved; after the wider CGUS is admitted, a separate DemonstrativeUnfoldingSlice@Context may present one traversal, and when admitted positions organize bounded transformations inspect the E.18.3 specialization;
    • keep several options alive until the comparison is clear enough to choose;
    • say what "better" means before optimizing or scoring;
    • make trust depend on evidence, freshness, scope, and intended use;
    • publish different views for different readers without changing the underlying claim;
    • when explanation, reader-facing ordering, or narrative rendering of selected source structure is current, state what structure is preserved, deliberately coarsened, abstracted, omitted, or lost, and which named source basis or governing pattern receives the return when loss matters;
    • use mathematics or formal models when they clarify what structure is preserved, what is lost, and what can be checked;
    • build domain or local FPF-grounded frameworks as dependents of FPF Core, not as silent rewrites of the Core.

    Last Updated: 2026-07-12 — upstream FPF commit 44dd8818 (github.com/ailev/FPF)