SYSE.1 - Choose and Reopen the Project System-of-Interest

SYSE.1:1 - Problem frame

Use this pattern when a project is already discussed through a familiar name—for example, a product, solution, tool, provider, organization, component, desired effect, or broad programme—but no defensible current decision yet identifies which System the project is intended to change or bring about. The choice matters because it changes later questions about use, boundary, architecture, realization Work, evidence, and specialist decisions.

The first result is a project-system choice account: claim-bearing project decision content that names the selected actual System or intended referent, the current reason for the choice, and what may reopen it.

First useful move: name one candidate actual System or intended referent, state the present use or change reason for choosing it, and write the main unresolved assumption. This small project-system choice account is enough to ask the next use-and-system concept question. Expand it only when disagreement, a valuable alternative, or a later answer can change the choice.

If the choice is missed, participants can work competently on different projects while using the same project name. A supplier optimizes a component, an integrator changes an operating assembly, and a client expects an outside effect, yet each assumes that the familiar noun names the same project system-of-interest.

The payoff is a shared and revisable project focus. The choice can stabilize current coordination while evidence from use, architecture, realization, or operation remains able to reopen it.

Use this pattern only when project coordination needs a System designation. If the decision already concerns another recognized subject—for example Work, a Method, a capability, a state, a material portion, a description, a collection, a structure, or a transformation—keep that subject under the pattern that defines or constrains its claim. If the issue is only whether a named entity is a System, use A.1.SCR. If the System has already been selected and the live question is how it participates in use, continue with SYSE.2.

At the first consequential use of source wording such as system of interest, target system, our system, product, or solution, ask one question: is the project choosing which actual System or intended referent it will change? If yes, state the candidate and its current use or change reason. Project system-of-interest names the designation made for this project; it is not another System kind.

SYSE.1:2 - Problem

Project names are chosen early, often before outside use, engineering boundaries, and realization constraints are understood. The first plausible referent then becomes an unstated premise in later decisions. A tool is selected as the project system-of-interest merely because it is purchased; a provider System is selected merely because its people perform the Work; or a desired state is forced into a System because the project is organized around achieving it.

The opposite error is also common: a useful tool, software product, or component is excluded by a slogan even when its own product project legitimately selects it. Compare referents for the current project and keep the choice revisable as understanding of the problem and solution changes together.

SYSE.1:3 - Forces

SYSE.1:4 - Solution

SYSE.1:4.1 - State the current project decision

Begin with the project whose coordination is current. State:

1. what change or later use this project is meant to enable;
2. which plan or decision needs a shared project-system designation now; and
3. which subject is presently proposed as the System to be changed or brought about.

Keep related projects separate. A manufacturer’s planning-improvement project, a software vendor’s product project, and an integration provider’s deployment project may use the same software and evidence without making the same project-system choice. A programme or portfolio may coordinate shared matters—for example, priority, resources, investment, risk, or evidence—without thereby becoming a composite acting System.

SYSE.1:4.2 - Recover the direct subject before forcing a System choice

Use A.15.6 when project, process, or case wording hides whether the current subject is performed Work, a reusable Method, a selected structure, a transformation-flow structure, a changed referent, or another claim. If that direct subject answers the decision, stop this pattern use and keep the subject under its own FPF pattern.

When the decision does need a System, distinguish two cases:

• For an actual System, use A.1.SCR when recognition is unresolved. Its constructive criterion supplies the tested System identity and boundary used in the comparison.
• For a System that does not yet exist, keep the intended referent in the current plan, decision, or description. Do not describe it as an already acting System.

Recognition and project designation remain different claims. Recognizing an actual System does not select it for the project; selecting an intended referent does not make it physically present.

SYSE.1:4.3 - Generate and criticize materially different referents

Generate alternatives from the working situation. After the direct-subject exit in §4.2, retain a candidate referent for the project system-of-interest only when it is one of two things:

1. an actual System, with A.1.SCR recognition when that recognition is decision-relevant; or
2. an intended referent for a System not yet present, kept as a designator in plan, decision, or description content rather than described as an already acting System.

Examples include an actual product System, tool System, engineering platform, operating System, provider System, containing System, or organization System, and the intended referent of any such possible-future System. A provider arrangement or organization qualifies only when that whole is an admitted actual System or such an intended referent. A subject changed by a tool, a collection, Work, Method, capability, state, description, or another holon remains the direct subject or a related structure unless it satisfies the same System condition. The examples are non-exhaustive. Retain only candidates that would change a later decision.

For each candidate, compare the claims that matter now:

• the outside use or change the candidate is expected to support;
• the project boundary and the relation to related projects;
• the participating and affected Systems;
• the boundary, interaction, constituent, containment, ownership, authority, or other direct relations that actually change the choice;
• the important characteristics, constraints, feasibility branches, evidence, and uncertainty; and
• the assumption or observation that would defeat the candidate.

Treat familiar project facts—payment, delivery, ownership, enterprise boundary, a diagram, the transformer that performs realization Work, or the subject visibly changed by a tool—as evidence about candidates or project boundaries. Choose the project system-of-interest through the project’s stated use and decision.

Retain several candidates when later learning can change their order or when different candidates preserve valuable options. Let the current decision, available resources, and named stop determine the candidate count and comparison effort. Stop when the current choice is good enough to ask the next consequential question and its reopening evidence is named.

SYSE.1:4.4 - Record the smallest useful choice account

The cheap first result contains only:

Project-system choice account:
  current project and decision:
  selected actual System or intended referent:
  current use or change reason:
  main unresolved assumption:
  reopen condition:

Use any readable form for this content. Add further content—for example, comparison grounds, candidate alternatives, boundary and participation claims, affected Systems, authority, realization, or evidence—only when it changes the current choice or a downstream use.

Stop when the project can ask a concrete use-and-system concept question about the named referent for the stated reason. The resulting account supplies that referent, reason, boundary question, alternatives, and reopen condition to SYSE.2.

SYSE.1:4.5 - Reopen the choice from the answer that failed

Reopen the account when one of these changes the comparison:

• observed or expected use crosses the assumed boundary;
• authority or permission makes the intended change unavailable;
• an architecture candidate moves important functioning to another System;
• no feasible realization branch supports the selected referent;
• operating or assurance evidence defeats the reason for the choice; or
• a related project is separated, combined, or reoriented in a way that changes the current project decision.

Return to the smallest failed claim. A changed use assumption may require SYSE.2 before the project focus changes. A failed bearer or architecture candidate may return through C.30 or C.32. Reopen SYSE.1 only when the evidence changes which System should orient this project or where the project boundary lies.

SYSE.1:5 - Archetypal Grounding

Pumping station under flood risk

A flood-reduction project starts with the phrase “new pump”. The engineer compares the pump unit, the pumping station, the drainage-control System, and a provider arrangement. Flood-control use crosses the pump-unit boundary: positioning, power, control, discharge conditions, and downstream exposure belong to the station’s current use question. The engineer selects the pumping station and records:

selected referent: intended pumping station
current reason: move water under the selected flood load as part of flood-control use
main unresolved assumption: downstream exposure remains acceptable
reopen: use, architecture, realization, or operating evidence changes that assumption or boundary

SYSE.2 can now link the flood-load use claim to a station concept. Later discovery that the proposed station increases downstream harm changes the linked use claim. It reopens the project-system choice only when that changed claim defeats the reason or boundary used by the choice account.

Manufacturer and ERP vendor

A manufacturer opens a “new ERP” project because production plans repeatedly fail. The manufacturer compares the software product, the planning organization, a deployed planning System containing people, software, data, and decision interfaces, and the wider production-control System. It selects the intended deployed planning System because the current project changes production-planning use and records data quality as the main assumption.

The vendor’s product project can separately select the ERP software product. “Software is always the project system-of-interest” and “software is never the project system-of-interest” both erase the project-specific decision. The two accounts preserve the shared software and the different uses.

Continuing building through several projects

For example, design, construction, operating retrofit, and heritage-restoration Work can concern one continuing building while using different plans, transformer Systems, access arrangements, and evidence. In an occupied retrofit, the engineer selects the continuing building because its occupied performance is being changed and records access during use as the main unresolved assumption.

Several descriptions of the building do not create several Systems or projects. Conversely, one programme does not become the performer of all Work. Each project account states its own reason for selecting the building and can reopen that choice without inventing a birth-to-retirement order.

SYSE.1:6 - Biases to Watch

Two recurring biases matter in this decision. System inflation forces every important project subject into U.System; use A.1.SCR and the direct-subject exit before choosing. First-candidate lock-in turns the first plausible referent into permanent project scope; retain material alternatives and state the reopen condition.

SYSE.1:7 - Conformance Checklist

SYSE.1:8 - Common Anti-Patterns and How to Avoid Them

SYSE.1:9 - Consequences

The project gains a focus that is stable enough for coordinated Work and explicit enough to challenge. Related projects can share resources and evidence without being collapsed. Architecture and realization discoveries can change the project focus without being treated as late exceptions.

The cost is visible uncertainty. Several candidate referents may remain current, and the account must be revisited when a named assumption fails. That cost replaces the larger cost of optimizing an architecture or realization network for the wrong project system-of-interest.

SYSE.1:10 - Rationale

Systems Engineering needs a project focus because architecture, realization, and assurance questions require a referent. That focus is a decision under uncertainty, not a fact supplied by the project name or by System recognition alone. Separating actual System identity, intended reference, project designation, and the account that describes the choice lets practitioners coordinate without confusing an episteme with the physical or operational System.

Ask about outside use when comparing candidates because it tests why each candidate matters. This check does not prescribe the calendar order of project Work. Problem framing, candidate development, architecture, realization, and evidence can change one another; the explicit reopen condition makes that movement normal.

SYSE.1:11 - SoTA-Echoing

These sources support comparing and revising project focus. Actual System recognition uses the FPF U.System criterion. Choosing an actual System or intended referent for the project uses the project’s decision and case facts, as in the pump, ERP, and building cases above.

SYSE.1:12 - Relations

• A.15.6 distinguishes project Work, process, case, Method, transformation, selected structure, and project system-of-interest wording before the practitioner uses this pattern to make a System choice.
• A.1.SCR supplies the constructive recognition result when the comparison depends on whether a candidate is an actual acting or changed System. It also supplies the direct-subject exit when systemhood is not load-bearing.
• SYSE.16, SYSE.17, SYSE.2, and SYSE.8 may use the project-system choice account when their question concerns the same subject, configuration, decision, and evidence window. That use identifies the engineering focus for the receiving question; it imposes no temporal order.
• An engineer uses SYSE.2 to develop linked use and concept claims whose failure may revise the choice. The resulting linked proposal helps frame the architecture question. C.30 defines that question and C.32 guides candidate synthesis; infeasibility or harm returns through the smallest linked claim and reopens this pattern only when project focus changes.
• A.1.STM provides the wider systems-mantra traversal when a practitioner must reconnect this local choice to outside use, architecture, realization Work, change, and recursive transformer Systems. It adds no project designation or fixed Work order.
• The applicable FPF decision, authority, evidence, value, harm, temporal, and direct-relation patterns define or constrain those claims when they become current; this pattern does not replace them.

SYSE.1:End