FPF Reference

    Local Closure Inside An Open World

    Preface node heading:local-closure-inside-an-open-world:932

    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

    FPF assumes an open world. New evidence can arrive. A better mathematical model may appear. A source publication, source-use record, or telemetry relation may become stale. A competitor may change the state of the art. A user need may shift. A new concern may reveal that the same system should be described differently.

    Engineering and management still need local closure. A bridge cannot wait for all possible facts. A gate decision cannot cite the entire universe. A release, experiment, procurement, safety case, or architecture review therefore defines what counts as sufficient for the next action.

    The old open-world versus closed-world distinction is a useful didactic picture. In an open world, absence of proof is not proof of absence. If a name is missing from a party guest list, the list may be incomplete. In a locally closed operational world, absence from the accepted manifest matters. If a name is missing from the aircraft manifest, the airline acts as if that passenger is not on the flight.

    FPF does not transform the open world into a closed one. It lets a project build small closed worlds for declared purposes:

    • the exact source, scope, model-use organization, working situation, comparison basis, or other subject-defined boundary states what is current for this decision;
    • an EntityOfConcern states what project entity the reasoning is about;
    • a description states what can be relied on and under what relation;
    • evidence and assurance state what claim is credible enough for the local use;
    • a gate or decision states what boundary is crossed;
    • a reopen condition states when local closure is no longer enough.

    This is why FPF patterns often look strict. The strictness is local. It lets a project act while keeping the wider world open. A local closure is not a claim that nothing else exists. It is a declared scope for responsible action.

    Local closure also does not license ceremony. Before a method, route, or review makes an action mandatory, ask whether a materially plausible result can change a named substantive decision within the nearest substantive horizon, whether the action realizes an already selected result, or whether removing it changes an assurance or recovery condition on which the use relies. Hypothetical future usefulness is not enough; use A.11.OP for the exact operational-parsimony rule and its boundary with direct duties and assurance.

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