FPF Reference

    SYSTEM-RECOGNITION - Decide whether the exact entity in the claim is a system

    Preface node heading:system-recognition-decide-whether-the-exact-entity-in-the-claim-is-a-system:652

    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

    • Situation and question. A decision will change depending on whether one exact entity is a system, but the same noun may instead denote Work, a Method, a capability, an episteme, a structure, or another directly governed subject. Ask which exact entity is being proposed as the system and what the named decision may do differently if the A.1 criterion passes, fails, or cannot yet be evaluated.
    • First route. Open A.1.SCR. Start with the proposed system reading of the phrase before referent recovery. Once the referent is exact, use the exact U.Entity being evaluated under the already admitted U.System kind. Use “an alternative being considered for designation as the project system-of-interest” only inside one named project plan or decision, and keep designation separate from system recognition.
    • Template A — direct-owner exit. If system recognition cannot change the decision, return the exact Work, Method, capability, episteme, structure, relation, or other subject to its direct pattern. Ordinary examples include a role assignment, functioning relation, method enactment, Work participation, selected structure, evidence-use relation, or assurance claim; each keeps its own direct owner, participants, and result, and the examples form no common relation family or omnibus result. The first result is that owner's exact potential-result kind or its exact missing-governor or missing-information blocker.
    • Template B — system recognition. If systemhood remains load-bearing, apply the complete A.1 criterion to the exact entity: recover its six world-side constructive components and acting-eligibility condition. Return the same entity recognized under U.System, reject the proposed system reading when a required condition fails, or return unknown with the exact unavailable evidence or dependency. A durable classification episteme is optional and exists only when a named later use must inspect or cite the judgment.
    • Boundaries. Stop at the direct-owner exit, recognized exact system, rejected proposed reading, or exact missing-information blocker needed by the named decision. Return when the referent, system-dependent decision, six construction facts, acting-eligibility basis, evidence availability, or project designation changes. A familiar noun, role assignment, capability claim, interaction, plan, or project designation does not establish system identity.
    • Result test. Name the exact entity, the decision that depends on system recognition, and either the direct-owner result or the complete A.1 basis and disposition. State the concrete action now allowed: use the direct owner, rely on the entity as a system for this decision, reject that reading, or obtain the named missing information. Do not create a recognition-result kind, system-candidate status, or generic context record.
    • Public coarsening. “System recognition” restores to one exact entity and its A.1 direct-owner, recognized, rejected, or missing-information disposition for one named decision.

    Last Updated: 2026-07-30 — upstream FPF commit 308edacf (github.com/ailev/FPF)