A.15.6:1 - 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.