#Project, Process, and Case Recovery through Work, Method, and Transformation

A.15.6 · Stable · Architectural (A) · Normative unless marked informative · Part A - Kernel Architecture Cluster

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Type: Architectural (A) Status: Stable Normativity: Normative unless marked informative

Plain name. Recover what project, process, or case wording refers to.

Primary reader. This pattern is for the FPF practitioner who must identify what project-, process-, or case-management wording actually refers to before relying on the claim, then open the pattern that governs that subject.

Use this when. Use this pattern when project, process, case, program, initiative, or situation wording is about work and change, but the claim does not yet reveal whether it concerns one performed work whole, a reusable way, a selected structure, or another exact subject or claim being followed to a closure decision. Use it also when a project names a project system-of-interest without showing whether that name denotes an already admitted U.System or only an intended future system in a plan, or when project designation is being inferred from a role label. An @Project name still establishes no locality, authority, parthood, or identity without a direct relation to performed project work.

#Relations

#Content

#Problem frame

Use this when. Use this pattern when project, process, case, program, initiative, or situation wording is about work and change, but the claim does not yet reveal whether it concerns one performed work whole, a reusable way, a selected structure, or another exact subject or claim being followed to a closure decision. Use it also when a project names a project system-of-interest without showing whether that name denotes an already admitted U.System or only an intended future system in a plan, or when project designation is being inferred from a role label. An @Project name still establishes no locality, authority, parthood, or identity without a direct relation to performed project work.

First useful move. Ask what the next decision is about: the Work that happened, the reusable way of doing, the organization of particular method-side objects and relations, a transformation-flow structure, the referent being changed, or the system whose change or later use organizes the project. In the process branch, choose U.Method; an exact U.Structure selected under A.22; or TransformationFlowStructure before choosing a viewpoint, record, suffix, dashboard, or publication. In the project system-of-interest branch, first distinguish an actual system from a planned future one, then keep plan or decision designation, role interpretation, and any assignment as separate claims.

What goes wrong if missed. A plan is counted as performed work, a temporary organization is identified with its project, one work occurrence is mistaken for a repeatable process, or a case record replaces the exact subject or claim whose bounded closure is being managed. Parallel @Project, @Process, and @Case names then create apparent kinds without identity rules.

What this buys. Project work receives one accountable occurrence identity; process improvement can select one reusable U.Method, one exact A.22 U.Structure, or TransformationFlowStructure without collapsing them; case work stays oriented to the subject its claims actually concern. Plans, organizations, transformations, descriptions, publications, results, and evidence can then be related without being collapsed.

Not this pattern when. Use A.15.1 directly when the subject is already known to be performed work, A.3.1 when it is already a reusable method, A.3.4 when it is already a bounded transformation, or E.18 when it is already a selected transformation-flow structure. This pattern recovers the direct subject from management wording; it does not replace those ontics or domain management methods.

No-mint disposition. Do not publish a NameCard for ProjectWorkKind, ProjectWorkProfile, ProcessKind, or CaseKind. Recover the direct subject instead: composite U.Work for an actual project; U.Method, an exact U.Structure selected under A.22, or TransformationFlowStructure for a process concern; and one exact subject or claim plus its closure basis and named-but-excluded downstream use for a case concern. After A.22 selects a method-side structure for one named question, admissible action, and prohibited overread, call it MethodRelationStructure only for that use. The local designator is not a U-kind, relation type, method, transformation flow, work occurrence, or holon. Do not author the unsupported MethodRelationStructure@BoundedContext spelling: neither that suffix nor the label supplies locality or identity. The familiar management words remain Plain retrieval labels; they create no further kinds.

Do not mint root U.Project as a project-situation specialization. Admit actual project Work through A.15.1: name its performer systems, covering assignments, enacted method, temporal extent, containing system, exact parthood, continuity, and aggregation. State affected-referent, production, evaluation, delivery, acceptance, and other result-like facts as separate relations or claims under the patterns that govern them. A second project identity would duplicate rather than explain that Work occurrence. Do not mint ProjectSelectionRelation, ProjectResultRelation, or WorkResultRelation from familiar project wording. In section 4.1a, keep the plan or decision designation and every independently admitted fact usable; when one named decision also needs a compound project-selection claim, return the exact missing-substrate result.

Do not mint root U.Situation as a universal relation-constituted holon. Systems, work, transformations, methods, epistemes, characteristic assignments, phases, and direct relations keep their own identities; their co-occurrence or relevance to one claim does not establish constructive assembly, parthood, or a meta-holon transition into another whole.

#Problem

The same happening can be approached through three legitimate concerns. A project manager may need the identity, cost, completion, or result of one unique Work whole, but a result or measure remains its own subject when that is what the claim asserts. A process engineer may need one reusable U.Method, one exact A.22 U.Structure whose organization changes the next question or action, or a TransformationFlowStructure. A case worker may need to follow one exact subject or claim to a bounded closure while keeping the named downstream use outside that closure.

Treating these concerns as three views of one unspecified "project situation" loses the direct subjects. Treating them as three sibling kinds duplicates ontics already supplied by U.Work, U.Method, U.Transformation, selected structures, epistemes, characteristic bearers and assignments, relation occurrences, and continuing referents. The engineering problem is to recover the exact subject or claim and its direct relations while keeping familiar Plain wording available for retrieval.

#Forces

#Solution

Recover the direct subject selected by the working concern. Apply the subject's governing pattern, then relate plans, systems, transformations, results, descriptions, and publications to it through their own direct relations.

#Recover an actual project as composite U.Work

In Plain use, actual project denotes one composite U.Work occurrence: the performed work whole. A temporary organization participates in or coordinates that work; a U.WorkPlan specifies intended work; a U.Transformation identifies bounded change of an affected referent; project cards, repositories, and dashboards describe or publish claims about these objects. None supplies a second identity for the work whole.

First admit the candidate composite Work under A.15.1. Name every actual performer U.System and its covering U.RoleAssignment; state every explicit performedUnderAssignment, the exact U.Method the whole enacts, its governed temporal extent, and its executedWithin containing system. Admit each included Work occurrence independently and state the exact obtaining work-part relation that connects it to the whole. A shared project label, plan membership, continuity policy, or temporal containment establishes neither the composite Work nor its parthood.

Only then apply five project-specific qualification tests to the admitted Work:

1. The composite work has a temporary or transient boundary with a start and a completion or termination condition.
2. An accepted intention episteme whose claims state the intended objective and any intended product, service, result, or value is linked to the work through a direct plan or decision relation.
3. A work-part and continuity policy says how interrupted, resumed, split, or merged work retains or changes identity; the policy decides an actual ambiguity but does not create the Work or its parts.
4. At least one independently admitted performed Work occurrence is connected to the composite Work by an exact obtaining work-part relation.
5. For each claim used to qualify the project, name what the claim is about — the participating system, affected referent, transformation, result referent, or another subject actually asserted — and say how that subject matters to the Work. Then choose one truthful claim form: state an obtaining direct relation of the needed kind; use an exact A.6.1 binding for one reusable-operation application; state a local production, inception, or completion claim under A.15.PROD, or another relation-defined claim under A.6.RCD; or return one non-assertability result. For non-assertability, state whether the reason is factually unsupported, missing-information, or missing-governor. Only missing-governor means that no pattern currently admits the relation or claim needed for the question, so only that reason reopens ontology. Project wording and container membership supply none of these links.

No performed work means no actual project occurrence yet. A proposal, charter, authorization, schedule, budget decision, or funded intention can establish a U.WorkPlan and related commitments. It does not backdate performed work, a future system, an assignment, an actual change, or a result.

The project occurrence uses the identity, temporal extent, parts, episodes, continuity, and relation-specific aggregation defined in A.15.1. Project wording adds no second identity rule. When a reader asks for the project result, ask first: What exactly is the result, and result of or for what? Keep that referent in the kind or claim already established for it, then apply test 5. If the required relation or claim kind exists but the case facts make the assertion false, return one non-assertability result with reason factually unsupported; if that kind exists but a required fact cannot be recovered, use missing-information; only when no pattern admits the required relation or claim use missing-governor and reopen ontology. Otherwise keep an intended target in the plan.

Whole-project roll-up requires exact work-parthood plus an aggregation policy defined for the one relation and measure being aggregated. Outputs, effects, verdicts, epistemes, deliveries, and uses do not become one result merely because they share the project label.

#Connect project work to its project system-of-interest and network question

Start with an ordinary sentence: this project work is intended to change, produce, restore, evaluate, or prepare the use of this system. Then name the composite project U.Work, the system or intended-system designator, the plan or decision that selected it, the concrete change or use being pursued, and the next decision that needs the designation.

The primary expression is project system-of-interest, inherited from systems engineering without adding target, aim, or goal semantics. systemOfConcern may be used as a historical Plain synonym. Neither expression admits a system, role, relation, or project kind.

When the designated system already exists, identify that same entity under its admitted U.System kind. The plan or decision may say why it matters to the project, but that designation does not put the system inside a project container. Actual links still come from relations that obtain: an exact work-to-referent or work-to-change relation, one independently identified transformation, a branch-local A.15.PROD production or inception claim, an evaluation, a participation or use relation, or another direct owner. Include only links used by the named decision.

When the system is only intended, keep its designator and expected change or use inside the U.WorkPlan, decision, system description, or other claim episteme. Before its identity rule first holds, there is no future U.System, role-assignment holder, or transformation of that not-yet-existing system. A.15.PROD may later state the identity-inception boundary. After inception, relate the actual system to the earlier description through the applicable reference or identity claim, then test project designation, participation, and any role assignment at their own times.

Project designation and role assignment do not entail one another. Materialize SystemOfInterestRole only after A.2 names the role value, taxonomy episteme, effective scheme, and one concrete enactment-facing participation. Only when assignment identity or its window matters does A.2.1 add the admitted holder, obtaining assignment, and uninterrupted extent. Designation, passive affectedness, or a familiar label supplies none of these facts; an obtaining role assignment does not prove project designation. A patient record, damage claim, measurement result, or other non-system case subject can remain central to project Work but cannot hold that role.

When one project question spans operation or use of the project system-of-interest together with production, identity inception, later change, verification, feedback, or recursive builder questions, E.18.NET may select the relevant independently identified TFS or nested-network members. The selection must pass its four A.22 discriminators: direct members, obtaining cross-member relation occurrences, applied constraints, and one networkUseFrame; all endpoint bindings must resolve. If a member or relation is ungrounded, keep a Plain proposed network explanation and name the missing member, governor, false or unresolved predicate, occurrence, or binding. The selected network is a non-agentive U.Structure, not the project, performed Work, a case, or evidence of work parthood.

If the network-selection judgment must persist, use one ordinary C.2.1 result episteme whose exact EntityOfConcern is that selected network and whose claim says only why it answers the named project question for the stated basis and qualification window. Project Work, transformations, case closure, production, evidence, and decisions remain separate subjects and claims. A record creates none of them and creates no projectHasNetwork relation.

Stop before asserting a compound project-selection claim. A plan or decision designation and every independently obtaining Work, change, production, evaluation, delivery, acceptance, or use fact remain usable. When a named decision also needs one compound truth that this project selected this system, return missing-substrate[project-selection-conjunction] until one selected constructor substrate and edition define its inputs, output claim, applicability, and truth semantics. The A.6.RCD conjunction probe and reference scheme are not that substrate.

Keep the four inputs to that bounded question visible without turning their conjunction into a predicate: (1) the composite Work has passed A.15.1 admission and the five project-specific tests in section 4.1; (2) one identified plan or decision designates the actual system and states the intended change, production, evaluation, or later use; (3) every cited work-to-referent, work-to-change, transformation, production, evaluation, delivery, acceptance, or use fact has its own direct governor and obtains independently; and (4) the account names the concrete decision or action for which the designation matters.

For PumpUnit-3, the independently admitted composite Work and parts, five project-specific qualifications, plan, upgrade decision, and pump-change facts remain useful. The designation fails if the plan or decision does not designate PumpUnit-3, even when Work and pump change exist. The satisfied facts and this contrast create neither a predicate nor a relation occurrence. Reopen A.6.RCD only when an exact substrate is selected, repeated use needs one stable predicate rule, or a downstream decision must reidentify the same selection occurrence.

#Recover a process concern through U.Method, an exact selected U.Structure, or TransformationFlowStructure

When the question is about repeatability, ordering, throughput, variation, control, or improvement, select the exact reusable subject:

• U.Method when the concern is a way of doing with preconditions, effects, interfaces, and composition;
• an exact U.Structure under A.22 when the organization of method-side objects and relations changes the next question or admissible action;
• TransformationFlowStructure when the question is about loci, transfer relations, crossings, coupled flow valuations, split-and-join organization, or refresh slices.

Before selecting the method-side U.Structure, identify every constituent independently, state every selected obtaining relation under the pattern that admits it, and state each applied constraint. Then name the selection question, the action the selected organization permits, and the overread it forbids. Only after these four discriminators identify the structure may you call it MethodRelationStructure for that selection question. The phrase is a local designator, not a U-kind, relation type, method, flow, work occurrence, or holon; the label and an @BoundedContext suffix contribute no locality or identity. If any discriminator is absent, keep the obtaining direct relations unbundled and do not select a positive structure.

A dated U.Work occurrence may support a process claim only after you recover the exact fact it demonstrates. To show method enactment, name the obtaining A.15.1 enactsMethod -> U.Method relation from that Work to the selected U.Method. To show one operation application, use an A.6.1 binding only when the exact reusable operation declaration, the particular application, and its typed argument or result bindings are recoverable. A shared label, compatible result, trace, record, or observation establishes neither fact. Measurements, exceptions, and evaluation evidence about the Work remain separate relations and epistemes. These facts do not retype the Work as the repeatable method or selected structure. When the claim is about the execution, a deviation, or incident work, select that U.Work separately.

Process remains useful Plain management wording. It does not introduce U.Process, an @Process suffix family, or a parallel work identity.

#Recover a case concern through one exact subject or claim

A case is Plain subject- or claim-centred working language, not U.Case and not automatically a network member or slice. Start with the closure question, then return one minimal result:

1. name the exact subject or claim and its direct identity and reference owner;
2. keep only the TFS, SubflowRef, PathSliceId, exposed position, selected network, Method, Work, transformation, evidence, decision, or neighboring direct claim needed to answer the closure question;
3. state the separately governed fact, evidence, or decision on which closure depends; and
4. name one downstream receiving use or position and say explicitly that this later use is outside the closed case.

The subject is not restricted to one continuing changed entity. A maintained system, patient, material batch, or other continuing referent may be followed through conditions and independently grounded A.3.4 transformations. An episteme case instead follows exact episteme identities: changed claim content identifies another episteme and historical continuity uses EpistemeEditionRelation, not transformation of one unchanged episteme. A characteristic inquiry distinguishes the bearer, value or assignment, measurement occurrence, and result episteme; an immutable value neither changes nor acts. One exact relation occurrence, decision, result, or independently selected edition-lineage structure may be the case subject when that is what the closure claim concerns.

Methods, Work, performers, assignments, plans, transformations, production claims, evidence, decisions, and publications enter only when the closure question needs them, and each keeps its direct owner. Plain “Method for transforming the case subject” is retrieval shorthand: Work enacts a Method, while change, production, inception, readiness, result, and closure each need separate grounds. A Method or completed Work alone closes no case and proves no transformation.

If a case claim must persist, use one or more ordinary C.2.1 epistemes. A persistent case record remains an ordinary episteme and has no slots; any typed participant SlotSpec belongs to the RelationSignature of the exact governing relation, not to that record. Each episteme takes its truthful EntityOfConcern from its own claim content; split closure, relation, evidence, and network-selection claims when they concern different subjects. Usually keep the needed facts separate. Use A.22 only when one named later task must reuse their organization as one thing and all four identity discriminators pass. Otherwise keep a direct plurality or the exact E.18/E.18.NET references that answer the question. A case file, dashboard, identifier, or filled record creates none of the subject, organization, closure, or downstream relation.

You may describe this working boundary without asserting a new relation. If a later task must assert and reidentify a relation from the case to its downstream use, first open that relation's direct owner. If no current pattern supplies the predicate, return its participants and missing-governor; prose and an episteme cannot make the relation obtain.

#Do not force the three readings into one view family

Project, process, and case wording is only a cue to inspect the claim. Under C.2.1, each description is identified through its actual claim content, one exact EntityOfConcern, and the effective reference scheme; a management topic does not assign that EntityOfConcern.

One description keeps one truthful EntityOfConcern. When independent claims have different direct subjects, keep separate epistemes rather than inventing a union concern. An exact E.17.0 viewpoint episteme states the concern and conformance rules for a description; it does not turn different direct subjects into views of one entity. When accounts with different EntityOfConcern values must be related, keep each episteme and its own viewpoint-conformance judgment explicit, then state the exact correspondence relations required by the Work that uses those accounts; source-event proximity creates neither conformance nor a new multi-view family.

If the description needs empirical grounding, identify the exact admitted holon and the EpistemeEmpiricalGroundingRelation governed by C.2.1. GroundingHolonSlot belongs to that relation's RelationSignature; it is not a slot of the description episteme. Project work, U.Method, a selected method-side U.Structure, TransformationFlowStructure, transformation, and affected referent do not acquire episteme or grounding-relation slots from the account.

#State exact project-local relations

An existing @Project name is a compatibility and retrieval cue. It does not establish identity, parthood, authority, viewpoint, or locality.

When a record or relation is genuinely local to one actual project, name its exact relation to the composite U.Work and use a typed reference:

Use projectWorkOccurrenceRef only for the identified project-work occurrence. Do not use a generic project reference when the relation actually concerns a U.Method, exact selected U.Structure, TransformationFlowStructure, affected referent, description, publication, viewpoint, source use, evidence, or authority.

#Apply work continuity rather than label continuity

For interrupted, resumed, split, merged, or performer-changing project work, apply the A.15.1 work-part and continuity policy:

• performer or team replacement changes participation relations but need not change parent-work identity;
• interruption and resumption remain episodes of one parent work or become linked work occurrences according to the declared policy;
• split and merge use work-part, containing-work, predecessor, successor, or new-work identities;
• failed or terminated work remains actual project work even when its intended result is absent or adverse;
• continuous operations qualify as a project only when one finite composite Work first passes the complete A.15.1 admission basis and exact parthood, then passes the five project-specific qualifications.

The organization performing or coordinating project work is a neighboring U.System. Organization continuity does not decide project-work continuity.

#Run the direct-subject recovery sequence

1. Say the management claim in ordinary language without treating project, process, case, or project system-of-interest as a kind.
2. Ask what the next decision is about: one performed Work whole; a reusable Method; one selected method-side or transformation-flow structure; one project-level network question; or one case subject or claim and its closure.
3. Admit or select that subject through its owner: A.15.1 for Work, A.3.1 for U.Method, A.22 for a selected U.Structure, E.18 for one TFS, E.18.NET for a grounded network, A.3.4 for an actual change of one continuing referent, C.2.1 for an episteme, or the direct owner of the case subject. A label, interval, record, or local designator substitutes for none of these facts.
4. If a project names a project system-of-interest, decide whether the system already exists. Keep an intended future referent in plan or description content. For an actual system, keep recognition, plan or decision designation, each Work/change/use fact, any SystemOfInterestRole interpretation, and any assignment separate. Use section 4.1a for a project-network question or the exact compound-selection stop.
5. For a case, name the exact subject or claim, only the bounded references and direct claims needed for closure, the separately governed closure basis, and one named downstream use that remains outside the closed case. Persist only truthful C.2.1 claims; use A.22 only when one named later task must reuse the organization as one thing and all four identity discriminators pass.
6. Keep plans, performers, role assignments, transformations, results, decisions, evidence, descriptions, and publications distinct. For a result claim, ask what the result is and what it is a result of or for. Then use an obtaining direct relation, an exact A.6.1 application binding, a local A.15.PROD or A.6.RCD claim, or a non-assertability result marked factually unsupported, missing-information, or missing-governor. Only the last reopens ontology.
7. If a description is needed, recover its claim content, one truthful C.2.1 EntityOfConcern, and effective reference scheme after the direct subject is known. Select a BoundedModelUseStructure only when it changes how the next assertion is read or used; otherwise omit it.
8. If a local record refers to the selected subject, name the relation and use a typed reference. A suffix, record row, or case label adds no identity, locality, organization, or closure.
9. When these recovered results must re-enter the long dependency from outside use through architecture, Work, change, and recursive builders, continue through A.1.STM. Otherwise stop at the direct result that answers the decision.

#Archetypal Grounding

Integrated pump-modernization case: one project, several subjects. A plant approves work to modernize PumpUnit-3. Before any technician starts, PumpUpgradePlan-7 : U.WorkPlan names the already existing pump as the system whose vibration and reliability the intended work is meant to change. The plan also describes a proposed replacement controller and the expected later pumping use. At this point there is no actual project Work, no actual replacement-controller U.System, and no achieved vibration reduction. Those are intended claims, not accomplished facts.

The actual project begins only after PumpUpgradeWork-7 independently passes A.15.1. Plant-A-Maintenance-System : U.System is the containing system and executedWithin(PumpUpgradeWork-7, Plant-A-Maintenance-System) obtains. PlantMaintenanceRoles-2026 under Plant-A-Maintenance-Scheme interprets PumpUpgradePerformerRole as performing pump diagnosis, replacement, installation, and qualification through the named methods; PlantFabricationRoles-2026 under Plant-A-Fabrication-Scheme interprets ControllerUpgradeFabricatorRole as performing controller fabrication for that work. PumpUpgradeExecutionAssignment-7 assigns the interpreted PumpUpgradePerformerRole to MaintenanceTeam-4 : U.System, and ControllerUpgradeExecutionAssignment-7 assigns the interpreted ControllerUpgradeFabricatorRole to ControllerAssemblyCell-2 : U.System; both assignments obtain over and cover the full 2026-07-01T08:00:00+03:00 to 2026-07-06T10:00:00+03:00 composite extent. Both systems actually perform the composite Work, so performedUnderAssignment(PumpUpgradeWork-7, PumpUpgradeExecutionAssignment-7) and performedUnderAssignment(PumpUpgradeWork-7, ControllerUpgradeExecutionAssignment-7) obtain. enactsMethod(PumpUpgradeWork-7, PumpUpgradeMethod-7) also obtains for independently admitted PumpUpgradeMethod-7 : U.Method.

Each included Work is independently admitted; the table states its performer and covering assignment, enacted method, closed extent, and containing system. In every row, the corresponding performedUnderAssignment, enactsMethod, and executedWithin(..., Plant-A-Maintenance-System) relations obtain.

Four exact relations make these occurrences parts of the composite: OperationalPartOf_work(PumpDiagnosisWork-7, PumpUpgradeWork-7), OperationalPartOf_work(BearingReplacementWork-7, PumpUpgradeWork-7), OperationalPartOf_work(ControllerProductionAndInstallationWork-7, PumpUpgradeWork-7), and OperationalPartOf_work(PostUpgradeQualificationWork-7, PumpUpgradeWork-7). Their timestamps do not make those relations obtain. The declared continuity policy decides interruption, resumption, split, or merge only where those facts leave more than one grouping for a named use. After this admission, the plan, temporary boundary, continuity rule, exact parts, and direct claim routes pass the five project-specific tests. MaintenanceTeam-4 and ControllerAssemblyCell-2 remain neighboring systems, not the project. For the relied-on bearing-replacement and pump-installation changes, MaintenanceTeam-4 fills A.12's acting-system position while PumpUnit-3 fills the changed-holon position; the project Work and PumpUpgradeFlow-2 fill neither position. A termination after failed testing would still leave actual project Work, although the intended result was not achieved.

The plan and upgrade decision directly designate PumpUnit-3 as the project system-of-interest, and exact work-to-referent and work-to-change facts separately connect performed Work to the pump's condition. Those facts make the ordinary project sentence usable, but do not assert one compound project-selection claim while the required constructor substrate is missing. Keep project system-of-interest Plain when it only records project attention. During PostUpgradeQualificationWork-7, however, PumpUnit-3 operates as the system whose behavior is evaluated. A technical role is available only when PlantMaintenanceRoles-2026, effective Plant-A-Maintenance-Scheme, and role value SystemOfInterestRole together interpret that exact functioning and Work participation; project designation or passive affected-system status would not pass A.2. If plant practice also needs assignment identity, PumpUnit-3-QualificationSystemOfInterestAssignment-7 : U.RoleAssignment has PumpUnit-3 as holder and the already named role value, taxonomy episteme, and scheme as its other three participants; its assignment predicate obtains throughout the uninterrupted qualification interval. That A.2.1 assignment adds holder-and-window identity; it neither creates the role interpretation nor proves project designation. Conversely, designation creates no assignment.

Three local case boundaries stay separate. The pump case follows PumpUnit-3 through its vibration, bearing-condition, repair, and test facts and names the later pumping-use position without absorbing it into closure. The calibration case follows TestRig-2 through calibration-state changes and test-use history. When the project relies on the Work-realized calibration change, CalibrationService-2 : U.System is the performer in the exact actor-side participation and TestRig-2 is the changed referent; the covering assignment, Work, and work-to-change governor remain explicit. A controller-production case can close when separately grounded Work, changes of pre-existing subassemblies, identity inception, production completion or readiness, evidence, and decision establish the controller result needed here; installation and later operation in the pump are named downstream uses outside that closed case. Before inception, the proposed controller has no history as an actual system. When a controller-production change supports inception, ControllerAssemblyCell-2 : U.System performs the named Work and independently admitted ControllerSubassembly-7 is the changed referent; A.15.PROD separately states when the resulting controller first satisfies its identity rule. For any relied-on Work-realized change, name the performer, covering assignment, Work, changed referent, and direct work-to-change governor. A.3.4 may still identify an actual change whose present claim selects no Work or asymmetric actor-side account; that branch invents no actor. Only after inception can a controller case include later transformations of that continuing controller or a role assignment it actually holds.

The process question also splits. BearingDiagnosisMethod-4 : U.Method is the reusable way of diagnosing. For one method-enactment review, the independently admitted constituents are PumpDiagnosisWork-7, BearingReplacementWork-7, BearingDiagnosisMethod-4, and BearingReplacementMethod-7; the selected obtaining relations are enactsMethod(PumpDiagnosisWork-7, BearingDiagnosisMethod-4) and enactsMethod(BearingReplacementWork-7, BearingReplacementMethod-7). PumpMethodReviewWindowConstraint-7 selects only those two occurrences whose exact OperationalPartOf_work relations to the admitted composite Work obtain, while NoMethodCompositionFromWorkOrderConstraint-7 forbids inferring serial composition, fallback, quality, or causal success from their timestamps or order. PumpMethodEnactmentReviewFrame-7 asks which methods those two Works enacted; it permits listing the two exact relations for that review and prohibits treating their organization as method composition, additional project parthood, or proof of pump change. Those four A.22 discriminators identify PumpMethodEnactmentStructure-7 : U.Structure, locally designated MethodRelationStructure for this use. Without any one discriminator, the two enactsMethod relations remain unbundled. Separately, PumpUpgradeFlow-2 : TransformationFlowStructure may organize change, test, and evaluation loci.

The same reusable subject is not project-local. Suppose independently admitted DiagnosisWork-9 is connected to independent PumpUpgradeWork-9 by its own exact obtaining OperationalPartOf_work relation and concerns PumpUnit-8. If it enacts BearingDiagnosisMethod-4, name that Work's own enactsMethod relation and its separate work-to-pump fact. A second use of PumpUpgradeFlow-2 likewise needs its own selection facts. Sharing the method or flow structure creates neither work parthood between the two projects nor case identity between the two pumps.

Expected and actual results remain apart. The plan's reduced-vibration target and intended controller use are expected claims. After Work, identify an actual pump transformation only when A.3.4's occurrence basis is present and keep MaintenanceTeam-4 in the acting-system position. If the account calls that change a project result, keep the transformation and changed pump as separate subjects and say what the change is a result of or for. Then choose exactly one WMR outcome: assert an obtaining direct relation; name an exact A.6.1 application binding; state a local claim under A.15.PROD or A.6.RCD; or return one non-assertability result. In that fourth outcome, use factually unsupported when the needed relation or claim kind exists but the case facts make the assertion false, missing-information when that kind exists but a required fact cannot be recovered, and missing-governor only when no pattern admits the needed relation or claim. Any controller inception or production completion uses the selected A.15.PROD branch. Keep VibrationEvaluation-12 : U.Episteme as a separate result episteme; A.15.6 makes no evaluation claim from it until an exact evaluation governor is selected. None becomes a generic project result. A whole-project roll-up is permitted only for one declared relation and measure with the required work-part and aggregation policy.

After PumpUpgradeWork-7 completes, PumpUnit-3 performs separate PumpingRunWork-8 by enacting NormalPumpingMethod-3. During that actual operation it holds CoolingCirculatorRole through PumpUnit-3-CoolingCirculatorAssignment-8 : U.RoleAssignment. PlantOperationsRoles-2026 under effective Plant-A-Operations-Scheme interprets the role value as circulating coolant by enacting that pumping method in the run; the assignment adds the holder and uninterrupted run interval. The exact performedUnderAssignment relation connects this Work to that assignment. The assignment alone would not prove the Work. The later Work and assignment do not follow from project selection, and neither proves that selection. PumpingRunWork-8 remains outside the project unless an exact A.15.1 work-part relation says otherwise.

Finally, the controller-production flow and the pump-test flow remain two independent transformation-flow structures when they have separate members, boundaries, state, and change cadence. Select an E.18.NET network only if the engineering decision needs both and an exact obtaining cross-flow relation connects their positions. That network helps answer the declared coordination question; it is not the project, does not perform Work, and does not make Work positioned in either flow a part of PumpUpgradeWork-7.

Construction case: bricks become a wall. Vasya performs one bounded wall-building occurrence. Project management selects the unique composite U.Work: its independently admitted performer, assignment, enacted method, extent, containing system, exact work parts, intended wall description, resources, completion condition, and any actual-change, identity-inception, or completion claim the project decision needs. Process management selects the repeatable bricklaying U.Method, an exact A.22 U.Structure when all four discriminators make method-side organization change the next question or action, or TransformationFlowStructure when the question concerns transformation-flow organization; it uses Vasya's Work as a method-enactment observation only after recovering exact enactsMethod. If instead the observation concerns one declared operation application, name the exact A.6.1 declaration and binding. Case management selects the exact subject of its closure question: pre-existing bricks or other continuing materials for actual A.3.4 changes, a production or identity-inception claim for the wall as it comes to exist, or the continuing wall only after inception. It does not give a not-yet-existing wall a transformation history. These are direct subject selections around related changes and production facts, not three kinds of the same object.

Medicine case: a patient episode. A hospital improvement initiative can be the composite Work that introduces and evaluates a new care arrangement after its complete A.15.1 basis and exact work parts obtain. The clinical-pathway concern selects U.Method, an exact A.22 U.Structure only when its four discriminators make care-method organization change the next action, or TransformationFlowStructure when the question concerns care-flow organization. Evaluation across Work occurrences uses only occurrences whose exact enactsMethod relation or exact A.6.1 declaration and application binding is recovered for the observed fact. One patient's changing condition is the case concern only when that is what the claim asserts; diagnostic claims, treatment Work, evidence, and decisions remain separate subjects and relations. The improvement plan, care team, patient record, and performed clinical Work likewise retain their own identities.

Learning case: a course redesign. The finite redesign effort is composite project Work only after its complete A.15.1 basis and exact work parts obtain. The teaching U.Method, an exact A.22 U.Structure selected only when its four discriminators make teaching-method organization change the next action, and TransformationFlowStructure for learning-flow organization are distinct possible process subjects tested across cohorts. One learner's changing mastery is a case concern only for claims actually about that learner or condition. A syllabus, progress card, and course dashboard are epistemes or publications; none is the performed redesign, teaching method, structure, or learner.

Research case: an experimental materials campaign. The finite campaign that prepares alloy specimens, performs load tests, and analyzes measurements is composite project U.Work only after its actual performers, covering assignments, enacted method, extent, containing system, and exact obtaining relations to independently admitted preparation, testing, and analysis Work parts pass A.15.1. The experimental protocol is a reusable U.Method, and the selected preparation-test-analysis organization is a transformation-flow structure only when that organization changes the research decision. Each specimen remains the affected referent followed through preparation and testing. The hypothesis, preregistration, measurement-result episteme, and article are separately identified epistemes; publishing the article does not perform the experiment, and a surprising measurement does not become an actual Problem until the C.22.PFR condition and applicability relations obtain. Thus project progress, protocol improvement, specimen history, result interpretation, and publication can change independently.

Situation-wording contrast. The Plain word situation does not select one common kind. An operating pump configuration is the exact U.System, its parts, and state relations, plus Work or transformation only when the account actually asserts those facts. A proof gap is carried by the proof episteme and the exact unresolved-consequence and proof-acceptance applicability relations needed for the proof decision. A multi-party emergency comprises the participating systems, actual transformations, response work, and exact temporal or causal relations; an emergency description is a separate episteme. A future scenario is normally a U.MethodDescription when it describes a way of proceeding, or a possible-state description when it does not. Recover those direct subjects and relations; do not put all four under root U.Situation.

Incident-wording contrast. Do not mint U.IncidentSituation. Recover only what the decision or action at hand needs: the actual event or bounded change, responsive U.Work, participating systems, exact obtaining relations, and the incident-description episteme or publication. An incident record describes or publishes claims about those subjects; it is not the incident by form.

Planning-only boundary. A funded proposal with objective, schedule, assigned team, and charter can establish intended project work and a U.WorkPlan. Before a candidate composite Work has actual performer systems, covering assignments, exact enactsMethod, governed extent, executedWithin, and exact obtaining relations to independently admitted Work parts, there is no actual project-work occurrence to which cost, result, or completion claims can attach. The first performed task or its timestamp alone does not close that gate.

#Bias-Annotation

This pattern has a project-recovery bias because project wording is widespread in FPF names. The process and case branches prevent that bias from making composite work the subject of every management claim.

It has a 4D work-occurrence bias for actual projects. The guard is the two-stage recovery: first the complete A.15.1 admission basis and exact work parthood, then the five project-specific qualifications. A temporary organization, plan, transformation, product, dashboard, or time-contained occurrence remains a neighboring object unless those facts establish the composite Work and the claim is actually about it.

The examples include engineering, medicine, and learning to resist software-document bias. Working product is Plain recognition wording, not an episteme kind, result kind, or universal relation position. Recover the exact entity under the pattern that governs it, then state the production-work, entity-identity-inception, changed-referent, measurement, evaluation, delivery, acceptance, or later-use claim that the decision actually needs. Keep the Plain wording only while that exact relation or claim remains recoverable.

#Conformance Checklist

1. Before interpreting a management label, read the claim and select the independently admitted subject it actually asserts: U.Work, reusable U.Method, exact A.22 U.Structure, TransformationFlowStructure, one selected E.18.NET network, case subject or claim, result, measure, relation occurrence, or admitted collection-as-whole of occurrences.
2. An actual project first passes the complete A.15.1 admission basis as one composite U.Work: actual performer systems and covering assignments, any explicit performedUnderAssignment, exact enactsMethod, governed extent, executedWithin, and exact obtaining relations to independently admitted Work parts. Only then do the five project-specific tests qualify it as the Plain actual-project concern.
3. Planning-only material remains U.WorkPlan and related intention or decision relations until performed work occurs.
4. Project-work identity, exact parthood, and continuity use A.15.1 rather than a project label, temporal inclusion, team, charter, repository, policy, or suffix.
5. A process concern selects U.Method, an exact A.22 U.Structure, or TransformationFlowStructure. A method-side structure has independently identified constituents, exact selected obtaining relations, and applied constraints; its named frame states the selection question, the action that the organization permits, and the overread it forbids. Only then may MethodRelationStructure serve as its local designator. If any discriminator fails, keep the direct relations unbundled. Every method-enactment observation names the A.15.1 enactsMethod -> U.Method relation, and every operation-application observation names the exact A.6.1 declaration and application binding.
6. A case concern names one exact subject or claim, only the bounded references and direct claims used by the closure question, a separately governed closure basis, and one named downstream receiving use that remains outside the closed case. Episteme editions, characteristic bearers and assignments, measurements and result epistemes, relations, decisions, and continuing changed entities keep their own identity laws; a case record remains an episteme.
7. Each description's claim content, exact EntityOfConcern, and effective scheme are recovered under C.2.1; project, process, and case topics do not assign the subject, and descriptions with different EntityOfConcern values are not forced into one view family.
8. When a description needs empirical grounding, GroundingHolonSlot remains a SlotSpec of the C.2.1 empirical-grounding relation signature; it is not a slot of either the description episteme or the described work, method, structure, transformation, or referent.
9. Every retained @Project use states an exact direct relation and typed reference or remains explicitly retrieval-only.
10. Performer, result, success, acceptance, evidence, decision, description, and publication claims stay with their direct governing patterns.
11. A merely intended future system remains a plan or description designator; it becomes an admitted actual U.System only after its applicable identity rule first holds. No role assignment or actual-system history is backdated.
12. Project system-of-interest designation and SystemOfInterestRole are tested independently in both directions. The A.2 role test names the role value, taxonomy episteme, effective reference scheme, and concrete method, transformation, functioning, or performed-Work participation that gives the value its enactment-facing meaning; designation or passive affectedness alone does not pass. Only when assignment identity or its window matters does A.2.1 additionally require the admitted holder, obtaining assignment, and uninterrupted extent.
13. A project-selection account follows section 4.1a: the plan or decision designation and each direct fact remain usable, but no compound claim is asserted until one selected constructor substrate and edition gives the conjunction its semantics. Until then return missing-substrate[project-selection-conjunction]. A familiar phrase, role label, record row, common project name, reference scheme, or constructor probe creates neither a predicate, direct relation kind, nor occurrence.
14. A project-result claim names the exact referent in the kind or claim already established for it and says what it is a result of or for. It takes one of WMR's four outcomes: obtaining direct relation, exact A.6.1 binding, local claim under A.15.PROD or A.6.RCD, or one non-assertability result whose reason is factually unsupported, missing-information, or missing-governor. Only the last reason reopens ontology. Whole-project aggregation uses exact work parthood and one relation-and-measure-specific policy.
15. E.18.NET is used only for independently identified transformation-flow structures connected by exact cross-boundary relation occurrences. The network is not the project, an actor, performed Work, or evidence of work parthood.
16. For each transformation claim, A.3.4 first identifies one actual bounded change of one continuing referent. Add an actor-side participant only when its direct dynamics, interaction, participation, or causality owner grounds that position. When exact Work is claimed to cause or realize the change, separately name the performer U.System, covering assignment, Work, changed referent, and obtaining direct governor. Project Work, Method, TFS/network, record, or changed subject never fills an acting position by shorthand.
17. Reuse of one U.Method or TransformationFlowStructure in another project or for another affected referent has its own enactment or selection facts and creates neither cross-project work parthood nor cross-case identity.
18. A changed official project definition, project-theory conclusion, or direct-governor interface reopens only the smallest affected passage and nearest case named in section 11.

#Common Anti-Patterns and How to Avoid Them

#Consequences

Benefits. Costs, responsibility, and completion can attach to an actual composite Work occurrence, while the project system-of-interest, selected project-relevant network, case subjects, role assignments, changed referents, produced entities, evaluations, deliveries, acceptance decisions, and downstream uses retain their own facts. A team can say plainly which system the project is about without inventing a kind or role and can tell when that system is only intended. Process evaluation can aggregate method-enactment observations backed by an exact A.15.1 enactsMethod -> U.Method relation and operation-application observations backed by an exact A.6.1 declaration and binding without turning observed Work into Method or structure. Case work can close around a continuing entity, episteme edition, characteristic inquiry, relation, decision, or result while naming—but not absorbing—the downstream use.

Costs. Teams must state work continuity policy and distinguish intention from performed occurrence. Some legacy @Project records need exact relation fields. Description families may need to be separated when earlier publications hid different EntityOfConcern values behind one project label.

Limits. This pattern does not supply project-management, process-management, or case-management methods. It does not decide success, acceptance, evidence strength, authority, or result semantics. It only recovers the direct FPF subject and relations those methods operate on.

#Rationale

Apply A.15.1 to admit and identify actual project Work: name independently admitted performer systems and covering assignments, any explicit performedUnderAssignment, exact enactsMethod, governed extent, executedWithin, exact work parts, episodes, and continuity policy. State performer attribution, resource use, work-to-referent facts, change, production, evaluation, delivery, acceptance, and later result use as separate claims, each with its own relation and governing pattern. The project-specific tests qualify that admitted Work; they do not constitute it. Adding a project kind would duplicate the Work identity while mixing it with plans, organizations, transformations, and descriptions.

Process and case concerns reveal why one project container is insufficient. Repeatability belongs to U.Method; exact method-side relations remain direct until the structure's constituents are identified independently, its selected relations obtain, its constraints are applied, and one frame names the selection question, permitted action, and prohibited overread. Only then select one U.Structure under A.22 and, if useful for that question, call it MethodRelationStructure. Transformation-flow organization belongs to TransformationFlowStructure. None is the unique dated Work occurrence. A case remains centered on the exact subject or claim named by its closure question, even when several Methods, structures, Work occurrences, systems, results, measures, and decisions are relevant. Direct recovery therefore preserves more engineering information than a three-label hierarchy.

The project system-of-interest boundary follows the same economy. A plan or decision can directly designate why one system matters to this project, while U.RoleAssignment answers what an admitted system is being in one concrete participation. Keep the plan designation and every actual Work, change, or use fact usable on its own, but do not assert one compound selection claim until a selected substrate and edition supplies its conjunction semantics; until then return missing-substrate[project-selection-conjunction]. An intended future system remains claim content until inception. Reopen A.6.RCD only when repeated selection needs one reusable predicate, or when a named decision or action must re-identify the same selection occurrence; then state the participants, substrate, obtaining law, and occurrence-identity need.

#SoTA-Echoing

Taken together, these sources support the Solution's actions: apply A.15.1 to admit composite Work and exact parts before adding project qualifications and a continuity policy; select U.Method, an exact A.22 U.Structure, or TransformationFlowStructure for the process question; recover the case and description subjects from actual claim content; and keep temporary organization and descriptions separate.

Qualification and smallest reopen. If PMI or APM changes the temporary, unique, objective, or work-package distinctions used here, revisit only the five project-specific qualifications, planning-only boundary, and project cases that use the changed distinction. If the Winch or Sydow-Lundin-Ekstedt-Braun line is corrected on intention, temporary organization, plasticity, or continuity, revisit the matching Force, section 4.1 or 4.6 rule, and its nearest pump or failed-project case. If a direct FPF governor changes, reopen only the passage it governs: A.2 or A.2.1 for role interpretation or assignment; A.12 for acting and changed positions; A.15.1 or A.15.PROD for Work, parthood, production, or result claims; A.6.RCD or A.6.P.WMR for compound-claim or result outcomes; C.2.1 for description subjects; and A.3.1, A.22, A.6.1, or E.18 for the process branch. G.11 propagates only those affected dependencies; no calendar refresh or whole-pattern rewrite follows from an unrelated source change.

#Relations

• A.1 governs the identities of participating systems, affected holons, and description-grounding holons.
• A.3.1 governs reusable U.Method identity and composition. Apply A.22 to select an exact method-side U.Structure: identify its constituents, exact selected obtaining relations, applied constraints, selection question, permitted action, and prohibited overread. Use MethodRelationStructure only as a local designator after that selection.
• A.3.4 governs one actual bounded change of one continuing referent. A direct dynamics, interaction, participation, or causality owner separately decides any actor-side participants; Work-facing performer, assignment, Work, and work-to-change claims remain separate.
• A.15.1 governs admission and identity of performed U.Work: actual performer systems, covering assignments and any explicit performedUnderAssignment, exact enactsMethod, governed extent, executedWithin, exact work parts, episodes, continuity, and relation-specific aggregation. Project qualifications add no second Work identity or container-made parthood.
• A.15.2 governs intended work and U.WorkPlan before and during performance; a merely intended future system remains plan content rather than an actual holder.
• A.2 governs one enactment-facing role value interpreted through a named role-taxonomy episteme and effective reference scheme. A.2.1 conditionally adds its admitted holder, obtaining assignment occurrence, and uninterrupted extent; neither role interpretation nor assignment grounds project designation.
• A.15.PROD governs only the selected production-work, entity-identity-inception, or production-completion question and supplies no universal project-result relation.
• A.6.RCD governs the local-claim, reusable-predicate, and relation-kind economy. For the project-selection question in section 4.1a, keep the plan designation and independently admitted facts usable, but stop at missing-substrate[project-selection-conjunction]; neither the conjunction probe nor the reference scheme supplies constructor semantics.
• Apply A.6.P.WMR when result wording hides the relation. Choose one of four outcomes: obtaining direct relation, exact A.6.1 binding, local claim under A.15.PROD or A.6.RCD, or one non-assertability result. Its reasons are factually unsupported, missing-information, and missing-governor; only the last reopens ontology. WMR admits no ProjectResultRelation or WorkResultRelation.
• A.7 restores the EntityOfConcern, description-episteme, and publication boundary before a project card, charter, repository, dashboard, or other record is related to the composite work occurrence.
• C.2.1 governs description and record episteme identity through actual claim content, one exact EntityOfConcern, and the effective reference scheme. Management topics assign no subject; empirical grounding, viewpoint membership, scope, edition, and publication remain separately governed relations.
• E.17 and E.24.PUB govern publication of project, process, and case accounts without replacing their direct subjects.
• E.18 governs one selected transformation-flow structure. E.18.NET governs a non-agentive network only when independently identified structures and exact obtaining cross-boundary relations are selected; its use frame can answer one named project question without making the network the project, a case, an actor, performed Work, or a source of work parthood.
• A.6.REL governs explicit individuation when a work, method, transformation, result, or correspondence relation occurrence becomes a participant of another relation.
• A.1.STM receives a recovered project system-of-interest, network question, or case result only when the practitioner must restore the system-thinking long dependency; it changes none of these direct identities or relations. E.10 governs project, process, case, and situation wording recovery when source expressions remain ambiguous.

#A.15.6:End

---

Last Updated: 2026-08-04 — upstream FPF commit 8b727cba (github.com/ailev/FPF)