#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 repeatable way of doing, or the entity being changed. Use it also when a project names a 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 a project-selection claim 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.

#Keywords

• project/process/case wording
• actual composite project U.Work
• reusable U.Method
• A.22-selected U.Structure
• TransformationFlowStructure
• affected case referent and change history
• actual versus intended system
• project designation and selection claim
• SystemOfInterestRole
• U.RoleAssignment
• missing constructor substrate
• result U.Episteme
• evaluation non-claim.

#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 repeatable way of doing, or the entity being changed. Use it also when a project names a 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 a project-selection claim 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 system-of-interest branch, first distinguish an actual system from a planned future one, then keep project selection, 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 patient, asset, claim, component, or other referent whose change 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 the affected referent plus its transformation history 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 the changing condition and history of the affected referent.

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, and the affected referent. The engineering problem is to recover the exact subject and relation selected by the claim 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 system of interest

Start with an ordinary sentence: this project work is intended to change, produce, restore, evaluate, or prepare the use of this system. Then separate the facts that make the sentence usable. Name the composite project U.Work, the system, the plan or decision that selected it, the concrete change or use being pursued, and the next decision that needs the selection.

When the selected system already exists, identify that same entity under its admitted U.System kind. The plan or decision may directly designate it and explain why it matters to the project, but that designation does not put the system inside a project container. The actual links still come from the relations that obtain in the case: for example, an exact work-to-referent relation, one independently identified transformation of the system, a branch-local A.15.PROD production or inception claim, an evaluation, or a later use relation. Include only the links needed for the named decision; if that decision also needs one compound project-selection claim, use the stop in section 4.1a.

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 the applicable identity rule first holds, there is no admitted future U.System, no holder for U.RoleAssignment, and no world-side selection relation to backdate. After the applicable identity facts make an actual system first satisfy that rule, a local A.15.PROD claim can state the inception boundary. Relate the new actual system to the earlier description through the applicable direct reference or identity claim, then test project selection and any role assignment at their own times.

The Plain phrase system of interest needs no technical role when it only helps a team say which system the project is about. Materialize SystemOfInterestRole only after the complete A.2 interpretation test passes: name the role value, its named role-taxonomy episteme, the effective U.ReferenceScheme, and what an admitted U.System is being in one concrete method enactment, actual transformation or functioning participation, or performed-Work participation. Being selected by the project or passively affected is not enough. Only when assignment identity or its window matters does A.2.1 add the admitted holder, one actually obtaining U.RoleAssignment, and its uninterrupted extent. The assignment says which system holds the already interpreted role during that participation; it does not say why the project selected the system.

Project selection and role assignment do not entail one another. A plan and decision can select PumpUnit-3 as the system the project will change without any SystemOfInterestRole interpretation or assignment. Conversely, a test role value interpreted through a named taxonomy episteme and effective scheme, and assigned to a pump for one qualification episode under A.2.1, does not make that pump the system selected by a modernization project. A patient record, damage claim, measurement result, or other non-system case referent cannot hold the role, even though it can be central to project work.

Stop before asserting a compound project-selection claim. The four facts below are useful for the bounded selection question, but no constructor substrate and edition has been selected to define their inputs, output claim, applicability, and truth semantics. Do not treat the conjunction probe in A.6.RCD:4.2 or the effective reference scheme as that substrate. A plan or decision may still designate the system directly, and every Work, change, production, evaluation, delivery, acceptance, and use fact remains an independent relation or claim. When the named decision needs one compound project-selection truth, return missing-substrate[project-selection-conjunction]; do not assert that compound claim until an exact constructor substrate and edition have been selected.

1. the composite Work first passes the A.15.1 admission gate and then the five project-specific qualification tests in section 4.1;
2. one identified plan or decision episteme designates the actual system and states the intended change, production, evaluation, or later use;
3. every actual work-to-referent, work-to-change, transformation, production, evaluation, delivery, acceptance, or use fact cited by the claim has its own admitted relation or claim and obtains independently; and
4. the claim names the concrete decision or action for which this system is being selected.

For PumpUnit-3, the independently admitted A.15.1 composite Work and parts, the five project-specific qualifications, the plan, upgrade decision, and independently obtaining pump-change facts together supply all four facts above. Do not assert a compound project-selection claim while the constructor substrate and edition are missing. If the upgrade decision does not designate PumpUnit-3, the selection test fails even though the Work and pump change may still exist. The satisfied facts and the failed-designation contrast create neither a predicate nor a relation occurrence. Continue independent project, process, and case recovery and admit no ProjectSelectionRelation. Reopen A.6.RCD when an exact substrate is selected for this compound claim, repeated use needs one stable predicate rule, or a named downstream decision must re-identify 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 the affected referent

When case-management work follows the changing conditions of one exact U.Entity, select that entity as the affected referent for claims actually about its condition or history. A case-description episteme takes its exact EntityOfConcern from its claim content: the affected referent for those claims, or the exact condition, transformation-history relation, Work, decision, result, or other subject actually asserted. Keep every selected subject's independently admitted kind: a patient or maintained machine may be U.System; a claim may be U.Episteme; a material batch may remain U.Entity until a direct governing pattern admits a stronger kind. Name condition and transformation-history relations separately.

Methods, Work occurrences, decisions, plans, evidence, and publications can enter as the case unfolds. They remain related objects. When the affected referent is the selected subject, it is not replaced by its work history, case file, dashboard, identifier, or management procedure.

Case remains useful Plain management wording. It does not introduce U.Case or an @Case suffix family. If a durable case record is needed, it is an episteme whose exact EntityOfConcern is the subject selected by its actual claim content, whether the affected referent or one exact relation, Work, decision, result, or condition. The corresponding SlotSpec belongs to the C.2.1 constitution-relation signature, not to the record.

#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 system of interest as a kind.
2. Ask what the next decision is about: one performed work whole, a reusable method, the organization of exact method-side objects and relations, a transformation-flow structure, or one affected referent and its history.
3. Admit or select the subject through its governing pattern: use A.15.1 for Work, A.3.1 for U.Method, A.22 for an exact method-side U.Structure, E.18 for one TransformationFlowStructure, A.3.4 for an actual transformation, or the applicable affected-referent pattern. Do not let a management label, interval, or local structure designator substitute for those admission facts.
4. If a project names a system of interest, decide whether the system already exists. Keep an intended future system inside plan or description content. For an actual system, keep the plan or decision designation and each obtaining work, change, or use fact separate. If the named decision needs one compound project-selection truth, apply section 4.1a and stop at its missing-substrate result until an exact substrate and edition are selected. Test any SystemOfInterestRole interpretation and any later assignment separately.
5. Keep the plan, 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 choose one WMR outcome: an obtaining direct relation; an exact A.6.1 application binding; a local claim under A.15.PROD or A.6.RCD; or one non-assertability result. Mark the last as factually unsupported, missing-information, or missing-governor; only missing-governor reopens ontology.
6. If a description is needed, recover its actual claim content, exact C.2.1 EntityOfConcern, and effective reference scheme after the direct subject is known; do not assign its subject from the project, process, or case label. Designate one independently selected BoundedModelUseStructure only when it changes how the next assertion is read or how the described Work will be used; otherwise omit it. Add grounding, viewpoint, scope, edition, or publication only when that assertion or Work use needs it.
7. If a local record refers to the selected subject, name the relation and use a typed reference; do not rely on a suffix.
8. Use E.18.NET only when the decision needs two or more independently identified transformation-flow structures plus at least one exact obtaining cross-boundary relation. The selected network is neither the project, the process, performed Work, nor a source of work parthood.

#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 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 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 selection 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 selection. Conversely, selection creates no assignment.

Two local cases remain separate. The pump case follows PumpUnit-3 through its vibration, bearing-condition, repair, and test history. The calibration case follows TestRig-2 through its calibration-state changes and test-use history. For the actual calibration change used by the project, CalibrationService-2 : U.System fills the acting-system position and TestRig-2 the changed-holon position. The proposed controller has no case history as an actual system before identity inception. If a controller-production change is used to support inception, ControllerAssemblyCell-2 : U.System fills the acting-system position and independently admitted ControllerSubassembly-7 the changed-holon position; a local A.15.PROD claim separately states when the resulting controller first satisfies its identity rule. Only then can a controller case or role assignment begin.

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 wall or construction state and follows its transformation history. These are three direct subject selections around related changes, 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, affected referent, result, measure, relation-bearing claim, 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 selects the exact affected referent and condition or transformation-history relations actually asserted; the 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 selection and SystemOfInterestRole are tested independently in both directions. The A.2 role test always names the role value, named role-taxonomy episteme, effective reference scheme, and the concrete method, transformation, functioning, or performed-Work participation that gives the value its enactment-facing meaning; selection or passive affected-system status alone does not pass. Only when assignment identity or its window matters does A.2.1 additionally require the admitted holder, obtaining assignment occurrence, 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. Every relied-on actual transformation names its acting system and changed holon in distinct A.12 positions; project Work, a method, or a flow structure fills neither 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 system of interest, role assignment, 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 relation, and can tell when that sentence is only a plan. Process evaluation can aggregate method-enactment observations backed by A.15.1 enactsMethod -> U.Method and operation-application observations backed by an exact A.6.1 declaration and application binding without turning the observed work into the method or structure. Case work can preserve the identity of each changing referent while methods and work change around it.

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 its claims assert, even when several methods, structures, Work occurrences, teams, results, measures, and decisions contribute to that history. Direct subject recovery therefore preserves more engineering information than a three-label hierarchy.

The 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 bounded transformations of the affected referent.
• 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 selection.
• 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 used by process-oriented work. E.18.NET governs a non-agentive network only when independently identified structures and exact obtaining cross-boundary relations are selected; neither structure is the project 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.
• E.10 governs project, process, case, and situation wording recovery when source expressions remain ambiguous.

#A.15.6:End

---

Last Updated: 2026-07-29 — this section last modified in upstream FPF commit 2ada4136 (github.com/ailev/FPF)