FPF Reference

    Local Closure Inside An Open World

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

    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 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 must decide what is enough 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:

    • a bounded context states which meanings and invariants are current;
    • an EntityOfConcern states what project thing 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.

    Last Updated: 2026-06-17 — upstream FPF commit 646b0b9b (github.com/ailev/FPF)