#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 defines or constrains 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 named subject or claim being followed to a closure decision.

#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 named subject or claim being followed to a closure decision.

Use it also when a team cannot keep its problem-development, solution-development, and development-platform questions connected without assuming one target noun, lifecycle, Method, or System. This branch recovers one revisable project account before the reader opens the patterns that define its selected subjects and relations.

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 system-role label.

An @Project name alone establishes no locality, authority, parthood, or identity. A claim of locality to one actual project requires a direct relation to its performed project Work, as section 4.5 states.

First useful move. If the project focus itself is unresolved, state the sought outside difference, relying use, conflicting interests, comparison-and-acceptance conditions, receiving decision, evidence horizon, and main uncertainty. Compare candidate project subjects and materially different solution forms before designating a project system-of-interest or Method-of-interest.

Otherwise 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 TransformationFlowStructure, the referent being changed, or the System whose change or later use organizes the project.

In the process branch, choose U.Method, a 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, local system-role-kind classification, and any system-role assignment as separate claims.

Three short recognition cases. Use these before the full pump example.

• Project: a plan designates PumpUnit-3 for an upgrade. While work is only intended, use A.15.2 for the U.WorkPlan and stop there. After performance, use A.15.1 to identify the composite project U.Work; add a work-to-pump or work-to-change relation only under its own predicate. Stop when the current plan or Work question is answered—the plan, Work, and pump are not one project object.
• Process: several inspections use BearingInspectionMethod-4. Use A.3.1 for that reusable U.Method and stop when the way-of-doing question is answered. Open A.22 only when the organization of identified method-side objects and obtaining relations changes the next action, and E.18 only when transformation flow is the question. One inspection Work merely enacts the Method.
• Case: a failed pressure test opens a closure question about PumpUnit-3 or about one readiness or acceptance claim. Use the pattern for that subject—A.15.5 when readiness is current, otherwise the pattern that defines or tests the acceptance or the named subject—and stop when the closure answer and its basis are known. Name later release or pumping use, when relevant, as outside the case closure rather than absorbing it into a case object.

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 named 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 occurrence identity under A.15.1. Process improvement can select one reusable U.Method, one A.22 U.Structure, or one 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. Any responsibility assertion must name its own direct relation and participants; if no pattern defines that relation, return missing-governor and name the participants.

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 new management kinds. Project, process, case, program, initiative, and situation are useful Plain cues, not automatic FPF kinds. Start with the positive recovery in section 4: an actual project may be composite U.Work; a process concern may select U.Method, an A.22-selected U.Structure, or TransformationFlowStructure; a case concern follows the named subject or claim to its closure. Plans, organizations, changes, descriptions, results, and evidence keep their own identities and relations.

A method-side structure may be called MethodRelationStructure locally only after A.22 selects it for one question and use; the label or an @BoundedContext suffix adds no identity. Likewise, familiar management wording does not create a project, case, situation, selection, or result relation. If the required relation or claim has no current defining pattern, return the named participants and missing-governor; do not repair the gap by minting a management kind.

#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 A.22-selected U.Structure whose organization changes the next question or action, or a TransformationFlowStructure. A case worker may need to follow one named 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 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. Use the pattern whose Solution answers that subject question, then relate plans, Systems, Transformations, results, descriptions, and publications through their own obtaining relations.

#Recover the subject before adding management detail

1. Read the working question, not the management label. Ask whether it is about one performed Work whole, a reusable way, an organization of already identified things and relations, a transformation flow, or a named subject or claim being followed to closure.
2. Name that subject in ordinary language. Use A.15.1 for Work, A.3.1 for a Method, A.22 for a selected U.Structure, E.18 for a transformation-flow structure, or the pattern that defines the other subject or claim.
3. Add only the plan, system, assignment, change, result, description, evidence, or publication relations needed by the current question. A common label or record makes none of those relations obtain.
4. Stop when the direct subject and the claim needed now are clear. Continue to section 4.1 for actual-project qualification, 4.2 for a process concern, or 4.3 for case closure only when that further question remains current. If a needed relation has no defining pattern, return its participants and missing-governor rather than inventing one.

#Select or reopen one bounded project focus

Use this branch only while the next decision still depends on selecting or reopening the problem, direct project subject, solution form, Method relation, or development-platform contribution. If one already identified Work, Method, System, transformation, structure, episteme, capability, population, relation, or other subject answers the current question, use its direct pattern and stop rather than completing a project template.

Project-focus decision is Plain wording for one conforming C.11 ChoiceResult over an already-current OptionSet. It introduces no project-focus kind, project record, project-partition object, relation kind, or actual project occurrence. If options are still being invented, expanded, or reframed, complete that work under the Method that governs the project question. If the rows are only labels or fragments and the question is several complete ways to obtain the same result, stop here and apply C.38. If the hard work is open-ended invention, expansion, or reframing, apply C.18. Return only after a current OptionSet exists; do not manufacture a winner to enter this branch.

When the result must persist, identify one ordinary C.2.1 episteme through all three identity discriminators:

This aboutness choice lets one chooser revise the selected problem without inventing a project-focus object. Authority, commitment, budget ownership, Agent status, and performed Work remain neighboring claims under their own governors; none changes the EntityOfConcern merely by appearing in the decision record.

The minimally useful result carries the full C.11 choice discipline through five connected content groups:

1. the observed situation, sought outside difference, and already-available bounded problem options in the current OptionSet;
2. affected entities and interests, materially relevant alternatives, and one explicit comparison basis: a PreferenceOrder or EvaluativeMeasure, plus the current BeliefState and OutcomeModel and any decision-relevant dependence layer;
3. the selected option's direct-subject disposition: one exact System, Method, capability, Work, episteme, population, relation, arrangement, or other admitted subject when that choice changes the decision, or an explicit unresolved-subject disposition;
4. the identified DecisionSubject and DecisionSubjectGranularity, one explicit ChoiceRule, and, when an inquiry alternative is live under C.11, its probe-worthiness account using ProbeActionSet, ProbeBudget, CostToProbe, and the applicable ValueOfInformation or ValueOfComputation; and
5. one explicit ChoiceResult—choose now, reject current set, probe again, or reroute—with the receiving decision or use, evidence horizon, principal uncertainty, next question, and observation that reopens the choice.

Keep any inquiry limitation or reason needed by the decision or its recipient in the same result; inactive inquiry adds no placeholder or omission account.

An unresolved direct subject does not force a false selection. A choose now result may select a bounded problem whose option explicitly leaves that disposition unresolved and names the next question; otherwise return probe again with the exact next probe or reroute to the pattern that now owns the question. If the current set itself still needs reframing, return to the option-formation step at the start of this branch.

Stop when the lawful ChoiceResult and the reason it is lawful are recoverable. Changing the selected problem, OptionSet, comparison or acceptance basis, direct-subject disposition, ChoiceRule, ChoiceResult, or receiving decision changes the identity-bearing U.ClaimGraph and therefore identifies another episteme even when the chooser remains the same. Another supporting item, evaluation, or publication does not reidentify the focus episteme unless claim content, EntityOfConcern, or effective scheme also changes.

Call a later focus episteme another edition only when an exact C.2.1 EpistemeEditionRelation obtains under the named project-focus continuation rule: the later episteme actually uses the earlier one as its revision source; preserves the exact DecisionSubject as EntityOfConcern, the receiving-use lineage, and the scheme features that keep the decision interpretable; explicitly records every deliberately changed focus-defining claim or permitted scheme feature; and is not a fork, translation, retargeting, or independent reconstruction. Shared chooser, performers, organization, budget source, label, or calendar alone establishes neither episteme identity nor edition continuity. Focus succession decides no performed-Work identity question.

Proceed by logical dependency, not by a compulsory Work sequence:

1. problematize the situation and comparison basis;
2. compare candidate direct subjects, designating a project system-of-interest only when one System boundary and systemhood change the decision;
3. describe the use or operation in which the subject is expected to matter, keeping functioning, behaviour, interaction, causal participation, intended Work, actual Work, and Method enactment under their own governors;
4. compare materially different solution forms, which may be Systems, Methods, epistemes, arrangements, or combinations;
5. designate a project Method-of-interest only when that Method's identity, architecture, comparison, enactment, development, or maintenance is the current question; and
6. recover the Methods and arrangements used to develop it and the other Methods whose change affects the selected problem or solution.

Inspect the account through the lightest optional view that changes the decision:

The development lemniscate is a didactic view of recurrent dependency and feedback among these questions. It is not a universal Method, lifecycle, calendar sequence, Work occurrence, level stack, or organization. For a mantra or diagram, state whether the order shown is teaching order, logical dependency, Method unfolding, planned Work order, observed Work order, or feedback; one order establishes none of the others.

Return ordinary prose and add a small map only when it changes the decision. The account may be distributed across existing artifacts and may remain partly unresolved. A missing chooser, granularity, current option set, comparison basis, lawful choice result, direct-subject disposition, or receiving decision is a named stop or reroute—not an invitation to fill a project template. A missing performer basis or authority claim leaves only a selected claim that depends on it unresolved. An actual project occurrence still enters section 4.1 and receives its identity only as admitted composite U.Work.

#Recover an actual project as composite U.Work

In Plain use, actual project denotes one composite U.Work occurrence: the performed work whole. A project-focus decision, temporary organization, U.WorkPlan, authorization, schedule, budget, dashboard, or repository is a neighboring object or claim; none supplies another identity for the performed whole.

First recover every actual performer System's A.13 core: the exact admitted System, local agential system-role kind and classification, obtaining assignment for the scope, working situation, and window, evidence adequate for the local criterion and classification, and any characteristic profile conditionally consumed by a Grade, autonomy, criterion-dependent, or assurance claim. Recover the exact composite performance history, Method actually followed, temporal extent, containing-System relation, and independently admitted Work parts. Use those facts to admit the candidate composite W : U.Work under A.15.1 and state the Work-part relations; do not use an F.6 conclusion as an admission premise. Only afterward, when precise assignment-bound attribution is current, use F.6 to relate that already admitted Work to each performer's same obtaining A.13 assignment, preserving direct case support, holder equality, species, participants, and coverage. A short attribution account may omit an unused identifier only when every required link remains recoverable. Admit each included Work occurrence independently. A shared project label, plan membership, focus decision, 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 states the intended objective and any intended product, service, result, or value. For this qualification, either an existing direct predicate connects its intended-performance designation to the admitted Work and obtains, or one local claim under A.15.2 or A.6.RCD names the plan or decision, designation, Work, applicable policy, and independently obtaining Work facts. If no predicate or claim constructor governs the needed connection, return missing-governor and name the unsupported relation; use test 5's factually unsupported or missing-information result when a governor exists but the case does not support the positive claim. Do not imply a generic 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 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 a typed 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 governor exists, the available case basis is sufficient to apply its positive test, and that test fails, return one non-assertability result with reason factually unsupported; if a fact needed to decide the test cannot be recovered, use missing-information; only when no predicate, applicability condition, or other rule defines the required relation or claim use missing-governor and reopen ontology. A negative additionally needs an applicable non-obtaining criterion or complete closure basis and satisfying facts. Otherwise keep an intended target in the plan.

Whole-project roll-up requires obtaining 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, system-role kind, assignment, 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: a 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 separately defined direct relation. 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, 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, local system-role classification, and any assignment at their own times.

Project designation, local system-role classification, and system-role assignment do not entail one another. Classify an actual System under SystemOfInterestSystemRole only after A.2 identifies that local kind and its feature criterion and the System satisfies it. When assignment identity or its window matters, A.2.1 names an occurrence with the System as holder and its declared U.SystemRoleAssignment species. That species declares SystemOfInterestSystemRoleKindDomain for the assigned-kind position; the occurrence supplies SystemOfInterestSystemRole as a value from that domain. Designation, passive affectedness, or a familiar label establishes neither classification nor assignment; an 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 be classified under that system-role kind or hold such an assignment.

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 EntityOfConcern is the 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.

Use the lightest claim that answers the project-selection question. A plan or decision designation and every independently obtaining Work, change, production, evaluation, delivery, acceptance, or use fact remain usable. Often the ordinary sentence “this plan designates PumpUnit-3 as the system this upgrade is about” is already the whole needed claim; do not construct a conjunction around it.

For one bounded decision that genuinely needs the combined truth, a C.2.1 local compound claim may cite the named plan or decision, composite Work, actual System, direct facts, applicability, and case facts. Its constructor semantics must be recoverable, but A.6.RCD does not require a separately materialized substrate document for a simple one-case claim. Name and pin the substrate when the derivation is nontrivial, intended for interoperability, used as proof, or reused. Repeated parameterized use may justify a reusable predicate-definition episteme. Admit a relation kind only when a named receiver also needs distinguishable project-selection occurrences with their own identity.

Return missing-substrate[project-selection-conjunction] only when the stronger compound claim is needed and no current substrate supplies the proposed operator semantics. The blocker stops that compound claim; it does not invalidate the plan designation or any direct fact.

For PumpUnit-3, the plan and upgrade decision directly designate the pump, while the admitted composite Work, Work parts, and pump-change facts remain supported independently by their defining patterns and facts. That is enough for ordinary project attention. Open a compound local claim only for a decision that consumes the conjunction, and materialize or pin its substrate only under the conditions above.

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

When the question is about repeatability, ordering, throughput, variation, control, or improvement, select the subject that the claim actually concerns:

• U.Method for the reusable way of doing;
• a U.Structure selected under A.22 when the organization of already identified method-side objects and relations changes the next question or admissible action;
• TransformationFlowStructure when the question concerns the organization of transformation flows.

Keep a measure, evaluation result, relation occurrence, event collection, or dated Work as its own subject when that is what the claim asserts.

For a method-side U.Structure, identify the constituents, the selected obtaining relations, the applied constraints, and the frame that states the selection question, permitted action, and prohibited overread. Only then may MethodRelationStructure serve as a local designator. If any discriminator is absent, keep the direct relations unbundled.

A dated U.Work occurrence supports only the fact recovered from it. To show Method enactment, use A.15.1 to state which Method that Work enacts. To show one operation application, name the reusable A.6.1 declaration, the particular application, and its typed argument or result bindings. A shared label, compatible result, trace, record, order, or timestamp establishes neither fact and does not retype Work as a Method or structure.

Do not force multi-object event data into one preselected case key or one flattened sequence. Preserve the relevant object and event relations, then select a process execution, grouping, query, or constraint only when the current use needs it. The selection is a modeling decision. A selection-result episteme concerns the observed material and serves as evidence only through an independently obtaining evidence-use relation; neither the selection nor that evidence use establishes Method identity. Stop when the reusable way, selected organization, or transformation-flow question has been answered.

#Recover a case concern through one named subject or claim

A case label is a cue to read the closure question. Recover:

1. the named subject or claim and the pattern that identifies it;
2. only the Work, changes, conditions, measurements, evidence, decisions, and references used by this closure question;
3. the pattern and facts that define the closure basis;
4. the later receiving use, named plainly but kept outside the closed case.

The subject need not be one continuing changed entity. It may be any independently identified thing or claim needed by the closure question—for example, a maintained System, patient, material batch, episteme edition thread, characteristic bearer or assignment, measurement or result episteme, relation occurrence, decision, Work occurrence, or selected edition-lineage structure. Each keeps its own identity rule. Changed claim content identifies another episteme; a value neither changes nor acts merely because it is measured.

Do not infer the case subject from a log's case key or from one record format. Object-centric evidence may connect several objects and several possible groupings. Select the grouping the closure question needs and state the information lost by any flattening. CMMN, DCR, Declare, and similar notations can help represent flexible case work, but their usefulness or ease of use is a separate use question; notation does not choose the subject, close the case, or prove that Work occurred.

If a case claim must persist, use one or more ordinary C.2.1 epistemes. A case record remains an episteme and has no participant slots; any SlotSpec belongs to the signature of the relation it declares. Split closure, relation, evidence, and network-selection claims when they concern different subjects. Use A.22 only when one named later use must reuse their organization as one selected structure and all four identity discriminators pass.

You may state the working boundary without asserting a new relation. If a later use requires a relation from the closed case to that use, apply the pattern that defines or tests that relation. If none does, return its participants and missing-governor; prose or a record cannot make it obtain.

A reusable Method or completed Work alone closes no case and proves no Transformation. State the separate closure or change claim and apply the pattern that defines it.

#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, the EntityOfConcern recoverable from that content, 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 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 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 admitted grounding holon and the EpistemeEmpiricalGroundingRelation defined 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.

For process and case descriptions, readability, simulation support, and ease of use are properties of the representation in a stated use. They can change which representation a team chooses, but they do not identify the described subject, establish claim truth, close a case, or prove that Work occurred.

#State 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 the obtaining 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, selected U.Structure, TransformationFlowStructure, affected referent, description, publication, viewpoint, source use, evidence, or authority.

#Apply work continuity rather than label or focus continuity

Project-focus succession and actual-project Work continuity are different questions. A changed focus-defining claim, EntityOfConcern, or effective scheme identifies another C.2.1 episteme. It becomes another focus edition only through an obtaining EpistemeEditionRelation under the project-focus continuation rule in 4.0a; a same chooser or label is insufficient. Neither another focus episteme nor an edition relation continues or reidentifies performed Work. Conversely, one composite Work may continue under its declared A.15.1 policy while its focus episteme changes. 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 and A.13/F.6 bases 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; and
• continuous operations qualify as a project only when one finite composite Work first passes independent A.15.1 admission and obtaining work-parthood, then passes the five project-specific qualifications; any precise assignment-bound performer attribution is a separate later F.6 result.

The organization performing or coordinating project Work is a neighboring U.System. Organization, project-focus, DecisionSubject, or label continuity does not decide project-Work continuity.

#Use the recovered subject and stop

Section 4.0 is the first pass. Sections 4.1–4.6 add only the branch detail needed by the current question. The worked cases below point back to those tests instead of restating them as new admission rules.

Stop when the direct subject, the required relation or claim, and its basis are clear. Continue to A.15.7 only when ongoing Work now needs a next-action choice; continue to A.3.1.MR only when several Work occurrences or sources still support competing candidate Methods. A later decision, publication, evidence, or assurance question opens its own pattern rather than extending this recovery indefinitely.

#Archetypal Grounding

Integrated pump-modernization case: one project, several subjects. Before performance, PumpUpgradePlan-7 : U.WorkPlan describes intended upgrade Work, the existing PumpUnit-3, a proposed replacement controller, and expected later pumping use. At this point there is no actual project Work, no replacement-controller System, and no achieved vibration reduction.

Apply section 4.1 when the Work occurs. PumpUpgradeWork-7 is admitted after its actual performer Systems have A.13 bases and its performance history, enacted Methods, extent, local containing-system relation, and four obtaining Work-part relations independently pass A.15.1. F.6 then separately checks each claimed assignment-bound attribution through the same A.13 assignment. The included diagnosis, bearing-replacement, controller-production-and-installation, and qualification Work occurrences are each admitted independently. Their timestamps and common project label do not establish parthood.

The five project qualifications add only what this use needs. A local C.2.1 claim may record that the admitted composite Work fulfilled the intended-performance designation under the stated policy; it creates no universal plan-to-Work relation. MaintenanceTeam-4 and ControllerAssemblyCell-2 remain neighboring performer Systems, not the project. A failed pump-qualification test may still leave actual project Work while the intended result remains unachieved.

Apply section 4.1a to the project system-of-interest. The plan and upgrade decision designate the already existing PumpUnit-3; direct Work-to-pump and Work-to-change facts separately say how the pump matters. Classification under a local SystemOfInterestSystemRole and any assignment occurrence require their own tests. A proposed controller remains plan content until its identity rule first holds; production completion, later operation, classification, and assignment are separate claims.

Apply section 4.3 separately to the pump, calibration, and controller-production cases. The pump case follows pump condition through repair and test while later pumping use stays outside closure. The calibration case follows TestRig-2 and the calibration facts used by qualification. The controller-production case closes only when the applicable Work, change, inception, completion or readiness, evidence, and decision facts support that result. Any Work-realized change separately names the performer System with its A.13 basis, Work, changed referent, and the relation connecting Work to change, plus F.6 attribution only when the receiving question explicitly asks under which assignment the Work was performed.

Apply section 4.2 to the process question. BearingDiagnosisMethod-4 is the reusable way. An A.22-selected enactment-review structure may organize independently admitted Work and the obtaining relations that state which Method each occurrence enacts, but it neither composes the Methods nor proves pump change. If event data links the work order, pump, controller, test rig, measurements, and several Work occurrences, keep those object relations visible; select a grouping or query only for the question being answered.

Expected and actual results remain apart. A vibration target in the plan is intended. A pump Transformation, production result, evaluation episteme, delivery, acceptance, and later use each need their own pattern and facts. If result wording hides the relation, apply A.6.P.WMR and return its one applicable outcome. Whole-project roll-up requires an obtaining Work-part basis and one policy for the stated relation and measure.

After the project completes, PumpingRunWork-8 is separate Work unless an obtaining Work-part relation says otherwise. Likewise, controller-production and pump-test transformation-flow structures remain independent. Select an E.18.NET network only when the engineering question needs both and the required cross-boundary relation occurrences obtain; the network is not the project and performs no Work.

Construction case: bricks become a wall. Vasya performs one bounded wall-building occurrence. For the project question, first admit the composite U.Work from Vasya's A.13 basis, grounded action history, enacted Method, extent, containing-System relation, and Work-part relations. Then add F.6 only if the claim needs the exact assignment under which Vasya performed it. Keep the intended wall description, resources, completion condition, and any actual-change, identity-inception, or completion claim separate.

For the process question, select the repeatable bricklaying U.Method; use an A.22-selected U.Structure only when its four discriminators make method-side organization matter, or TransformationFlowStructure when transformation-flow organization matters. Vasya's Work supports an enactment observation only when A.15.1 states that it enacts the Method. A declared operation application instead needs its A.6.1 declaration and typed binding.

For the case question, follow the subject named by closure: pre-existing bricks or other continuing materials for actual A.3.4 changes, a production or identity-inception claim while the wall comes to exist, or the continuing wall only after inception. Do not give a not-yet-existing wall a transformation history. These are related project, process, and case subjects, not three kinds of one object.

Medicine case: a patient episode. A hospital improvement initiative can be admitted as the composite Work that introduces and evaluates a new care arrangement after its A.13-qualified actual performers, performance history, enacted Method, extent, containment, and obtaining Work-part relations pass A.15.1. Any precise assignment-bound attribution follows separately through F.6. The clinical-pathway concern selects U.Method, an A.22-selected 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 for which A.15.1 states the enacted Method, or for which a declared A.6.1 operation and typed application binding support 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 A.13-qualified actual performers, performance history, enacted Method, extent, containment, and obtaining Work-part relations pass A.15.1; any precise assignment-bound attribution follows separately through F.6. The teaching U.Method, an A.22-selected U.Structure used 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. Use C.2.1 and E.24.PUB to distinguish the epistemes and publications encountered through a syllabus, progress card, and course dashboard; 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 admitted as composite project U.Work only after its actual performers have A.13 bases and its performance history, enacted Method, extent, containing System, and obtaining relations to independently admitted preparation, testing, and analysis Work parts pass A.15.1. Any precise assignment-bound attribution is checked afterward through F.6. 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 comprises the admitted 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 named 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 relevant temporal or causal relations; an emergency description is a separate episteme. A future scenario is a U.MethodDescription only when the same episteme meets A.3.2's criterion for describing one independently admitted Method. A possible-state description keeps its own claim content; describing a future state alone does not admit a MethodDescription. 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, 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 A.13-qualified actual performers and independently passes A.15.1 for its performance history, enacted Methods, extent, at least one obtaining local containing-system relation, and obtaining Work-part relations, there is no actual project Work to which cost, result, or completion claims can attach. F.6 may add precise assignment-bound attribution only after that admission. The first performed task or its timestamp alone does not close the admission 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 has an explicit order: first A.13-qualified performer facts and A.15.1 Work admission with obtaining work-parthood; separately, F.6 attribution when a precise assignment-bound claim is current; then the five project-specific qualifications. A temporary organization, plan, Transformation, product, dashboard, or time-contained occurrence remains a neighboring object unless the admission and qualification 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 entity under the pattern that defines or constrains 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 the needed relation or claim remains recoverable.

#Conformance Checklist

1. Start with section 4.0: read the claim and name the subject it actually concerns rather than interpreting the management label as a kind.
2. For an actual project, apply A.15.1 to the composite U.Work, then the five project qualifications in section 4.1. Planning material remains content of its U.WorkPlan until Work occurs.
3. Use obtaining Work-part relations and A.15.1 continuity rules; a time interval, team, charter, repository, policy, or label establishes neither parthood nor continuity.
4. For a process concern, choose among U.Method, an A.22-selected U.Structure, and TransformationFlowStructure as section 4.2 states. Before using Work as evidence, use A.15.1 to state which Method the Work enacts, or identify the A.6.1 application and bindings that support the claim.
5. Preserve multi-object evidence until the current use selects a grouping, query, or constraint. Record what a flattening omits; do not identify its result with a Method, Work occurrence, or case subject.
6. For a case concern, name the subject or claim, the references used by closure, the closure basis, and the downstream use that remains outside. Keep the case record as a separate episteme.
7. Recover each description's claim content, EntityOfConcern, and effective scheme under C.2.1. Treat notation readability or simulation support as a representation-use question, not as subject identity, claim truth, case closure, or performed Work.
8. Keep project system-of-interest designation, System identity, local system-role classification, and any assignment occurrence separate in every direction. Do not backdate a future System.
9. Use section 4.1a for a project-selection account. A direct designation may answer the ordinary case; a stronger compound claim needs recoverable constructor semantics, and missing-substrate blocks only that stronger claim.
10. Keep performer, Work, change, result, success, acceptance, evidence, decision, description, publication, and later use as separate claims. Apply the pattern that defines or tests the current relation.
11. For result wording, name the referent and say what it is a result of or for; then use the applicable A.6.P.WMR outcome. Whole-project aggregation also needs its Work-part basis and relation-and-measure policy.
12. Use E.18.NET only for independently identified transformation-flow structures connected by obtaining cross-boundary relation occurrences. The network is not the project, an actor, performed Work, or evidence of Work parthood.
13. For a Transformation, first identify the actual bounded change and continuing referent. Add an actor-side or Work-realization claim only when its own predicate and facts establish it.
14. Reuse of one Method or transformation-flow structure elsewhere has its own enactment or selection facts and creates neither cross-project Work parthood nor cross-case identity.
15. A changed source or direct FPF dependency reopens only the affected rule and nearest case named in section 11.

#Common Anti-Patterns and How to Avoid Them

#Consequences

Benefits. Cost and completion claims can refer to one actual composite Work occurrence through their direct predicates. Any responsibility assertion separately names its relation and participants or returns missing-governor with the unsupported relation. The project system-of-interest, selected project-relevant network, case subjects, system-role classifications and 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 assignment and can tell when that System is only intended. Process evaluation can use Work observations whose A.15.1 relation states which Method was enacted, or operation-application observations supported by a declared A.6.1 operation and typed binding, without turning observed Work into a 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 explicit typed 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.13 and A.15.1 first to admit and identify actual project Work: recover every actual performer System's local agential kind and criterion, classification, obtaining assignment, scope, working situation, and window, with evidence adequate for those core claims and a characteristic profile only when conditionally consumed; name the exact performance history, at least one Method the Work enacts through an obtaining relation, the Work extent, at least one obtaining locally declared containing-System relation, and the Work-part relations that constitute the composite. Only after admission, use F.6 for each precise assignment-bound attribution. Add an episode, continuity, or aggregation claim only when the project use needs it. A short project account may omit assignment identifiers or further valid boundaries its receiving claim does not use. State resource use, Work-to-referent facts, change, production, evaluation, delivery, acceptance, and later result use as separate claims, each under its direct relation predicate and case basis. 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; direct method-side relations remain unbundled 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 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 distinction follows the same economy. A plan or decision can directly designate why one System matters to this project, while A.2 separately answers whether the System is classified under a defined local system-role kind and U.SystemRoleAssignment answers which assignment occurrence obtains. Use that designation directly when it answers the question. For a one-case compound claim, recover the constructor semantics and direct facts; materialize or pin a substrate only for nontrivial derivation, interoperability, proof, or reuse. Return missing-substrate only for a needed stronger claim whose operator semantics are unavailable. An intended future System remains claim content until inception. Reopen A.6.RCD for a reusable predicate or relation kind only when a named receiver needs that stronger result.

#SoTA-Echoing

Taken together, these sources support the Solution's actions: admit composite project Work before qualifying it; select the Method, structure, or transformation-flow subject for a process question; recover a case from the closure claim rather than a record key; and keep organizations, descriptions, results, and later uses separate.

Qualification and smallest reopen. If project-practice or project-theory sources change the temporary, unique, intention, organization, or continuity distinction used here, revisit the matching section 4.1 or 4.6 rule and nearest case. If object-centric process or case-language work changes the loss from grouping, the available query or constraint result, or practitioner-use consequence, revisit only sections 4.2–4.4, their checklist item, and the case that uses it. If a direct FPF dependency changes, reopen only the passage it defines or constrains. G.11 propagates those affected dependencies; an unrelated source update triggers no whole-pattern rewrite.

#Relations

• A.1 defines the identities of participating Systems, affected holons, and description-grounding holons.
• A.3.1 defines reusable U.Method identity and composition. Apply A.22 to select a method-side U.Structure: identify its constituents, selected obtaining relations, applied constraints, selection question, permitted action, and prohibited overread. Use MethodRelationStructure only as a local designator after that selection.
• Use A.3.4 for one actual bounded change of one continuing referent. State actor-side participants only when the applicable dynamics, interaction, participation, or causal-use predicate obtains; Work-facing performer, assignment, Work, and work-to-change claims remain separate.
• Apply A.13 first to recover each actual performer's local agential kind and criterion, classification, obtaining assignment, scope, working situation, and window, with evidence adequate for those core claims; add a characteristic profile only when a Grade, autonomy or profile result, criterion-dependent characteristic, or assurance use consumes it. A.15.1 then independently supplies the admission and identity test for performed U.Work: performance history, actual performers, at least one enacted Method, extent, at least one obtaining locally declared containing-System relation, and the Work-part relations that constitute a composite. Only after admission does F.6 add any precise assignment-bound attribution through the same assignment. Name another enacted Method, episode, continuity claim, or relation-specific aggregation only when the receiving use needs it. A short account may omit unused assignment identifiers or further valid boundaries. Project qualifications add no second Work identity or container-made parthood.
• Use A.15.2 for intended work and U.WorkPlan before and during performance; a merely intended future System remains plan content rather than an actual holder.
• Use A.2 to identify and classify local system-role kinds from their feature criteria. When assignment identity matters, A.2.1 adds an assignment occurrence and its declared U.SystemRoleAssignment species. The species defines participant meanings and the predicate; the occurrence supplies the participants and extent for the case. Neither classification nor assignment grounds project designation.
• Use A.15.PROD only for the selected production-work, entity-identity-inception, or production-completion question; it supplies no universal project-result relation.
• A.6.RCD defines the economy among one-case claims, reusable predicates, and relation kinds. For project selection, use the direct plan or decision designation when sufficient. A one-case compound claim needs recoverable constructor semantics but no separately materialized substrate document unless nontrivial derivation, interoperability, proof, or reuse requires one; missing-substrate blocks only a stronger claim whose operator semantics are unavailable.
• Apply A.6.P.WMR when result wording hides the relation. Choose one of four outcomes: obtaining direct relation, typed 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 defines description and record episteme identity through actual claim content, one EntityOfConcern recoverable from that content, and the effective reference scheme. Management topics assign no subject; empirical grounding, viewpoint membership, scope, edition, and publication remain separate relations.
• Use E.17 and E.24.PUB to publish project, process, and case accounts without replacing their direct subjects.
• E.18 defines one selected transformation-flow structure. E.18.NET defines a non-agentive network only when independently identified structures and 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.
• Use A.6.REL when a Work, Method, Transformation, result, or correspondence relation occurrence must be identified because it participates in 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. Use E.10 to recover project, process, case, and situation wording when source expressions remain ambiguous.

#A.15.6:End

---

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