Part I - Project Focus, Environment, Consequences, and Problem/System-Family Development

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

SYSE.1:5.1 - 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.

SYSE.1:5.2 - 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.

SYSE.1:5.3 - 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

SYSE.16 - Recover the Systems and Conditions Needed for a Use Decision

SYSE.16:0 - Use This When

Use this pattern when an engineering decision concerns an actual System or intended-system designator selected as the project system-of-interest, but everything outside it has been reduced to one box called environment, stakeholders, users, the business, or the platform. The decision needs to know which larger Systems contain it, which other Systems interact with it, which transformation flows and interfaces matter, and which outside conditions can change the result.

Begin with one use situation and one receiving engineering decision. Recover only the Systems, direct relations, selected structures, conditions, evidence, and assumptions that can change that decision.

The first useful result is a bounded engineering-use account. It describes how an actual System participates, or how an intended System is expected to participate, in one named use situation. The account is an episteme used by the decision. The situation, actual Systems, containing wholes, and other obtaining relations remain its world-side subjects.

Do not use this pattern merely to draw a context diagram or inventory every nearby object. Use the governing FPF pattern directly when one already-known relation—such as parthood, interface, interaction, flow, or an architecture relation—answers the question. If the project system-of-interest designation is still unclear, use SYSE.1 first.

SYSE.16:0.1 - Terms and Distinctions

Relations commonly hidden by environment include parthood, interaction, ownership, location, authority, access, permission, service provision, use, and consequence. Name the relation that actually bears on the decision.

SYSE.16:1 - Problem Frame

Engineering choices—such as choices about System functions, architecture, interfaces, offerings, assurance, or change—depend on larger working situations. Teams nevertheless often begin with an inside representation, such as a product boundary, organization chart, component list, requirement set, or model repository. Outside Systems appear only as labels around a box.

The decision needs several selected structures: functional transformation and interaction, constructive parts and interfaces, direct relations across the selected boundary, operating conditions, and claims about what may change. One context diagram or tree cannot carry all of them.

SYSE.16:2 - Problem

A generic environment box hides incompatible claims. A customer can own a System without operating it. An operator can interact with it without containing it. A building can spatially contain a device while another System whole receives the result of its functioning. A cloud service can sit outside a product boundary while remaining part of an offering arrangement. A regulator can constrain Work without being part of the operational System.

When those relations remain implicit, a plausible concept can fail in use, an interface can be assigned to the wrong bearer, a provider can promise a result no arrangement can deliver, or later evidence can have no clear decision to reopen.

SYSE.16:3 - Forces

Recurring tensions include:

• A small use account helps early decisions; an exhaustive world model is neither possible nor useful.
• Project boundaries simplify Work, while outside Systems and conditions can still change the engineering choice.
• One System can participate in several wholes and selected structures at once.
• Functional transformation and constructive structure must correspond without being collapsed.
• Design choices concern possible futures; actual participation and observed conditions concern what obtains.
• Relevant surroundings continue to change—for example, providers, users, infrastructure, rules, competing offerings, or operating conditions.
• Existing vocabulary helps communication but can import ownership, lifecycle, or stakeholder assumptions that do not match the current relation.

SYSE.16:4 - Solution

Recover the smallest set of Systems, structures, relations, and conditions that makes one use decision well-grounded. Begin with the actual System or intended-system designator selected as the project system-of-interest and a named use situation; stop when the account exposes a material mismatch, alternative, evidence gap, or reopen condition.

SYSE.16:4.1 - Perform the Move

1. Bound the use and decision. State the actual System or intended-system designator selected as the project system-of-interest, the use situation, configuration or variant, decision, relevant place, interval or horizon, and the description sources being used. Keep the descriptions separate from the Systems and situation.
2. Find containing and receiving Systems. Identify every larger System that matters because the selected System is, or would be, its proper part, and every System that receives or would receive a result of its functioning. State each direct relation and whether it is actual or proposed; retain several wholes when the decision depends on them.
3. Recover functional organization. Identify the transformation flows, interactions, and contributions in which the System participates, including the changed or receiving Systems and conditions. Use A.6.F for function-like claims and E.18.NET when a transformation-flow network is needed.
4. Recover constructive organization. Identify the structures that matter to this use—for example, parts, bearers, modules, interfaces, or connections. Use A.22 for each selected structure and A.6.M only when module or interface claims obtain. Do not infer constructive parthood from a functional contribution.
5. Add other Systems and conditions. Include only a System or condition whose named relation can alter the use result or engineering choice. State that relation and its participants or state the relevant condition. Examples include a transfer from a named supplier System to a named receiver, access granted by a provider System, a permission or commitment between named participants, an available resource, or an operating constraint. When performed provider Work matters, identify the dated Work occurrence, performer Agent, and applied Method separately. For proposed provider Work, identify the intended Work, performer and Method, and the commitment or capability evidence actually available. Then name only the direct relations used by the decision: Agent participation in the Work, result production, supply or access from provider to receiver, receipt or use of the result, a commitment, or another governed provision relation. Distinguish obtaining relations from proposed ones; a commitment does not establish that Work or delivery occurred. Do not hide these objects or relations under environment.
6. Separate future choices from present facts. Mark descriptions as observations, predictions, design choices, commitments, or unsupported assumptions. A proposed interface or whole does not obtain merely because a model contains it.
7. Test outside change. Ask which relevant outside factors—for example, Systems, conditions, interfaces, providers, uses, or regulations—can change during the relevant horizon and which change would reopen the concept, architecture, offering, assurance, or configuration decision.
8. Return the decision-changing result. Supply the mismatch, alternative, evidence need, or qualified assumption to the receiving engineering Work. Leave unrelated surroundings out.

The numbered presentation is an A.22.CGUS learning unfolding, not a Work sequence. Work such as observation, concept development, architecture development, or trial can overlap with changes in outside Systems and recur.

SYSE.16:4.2 - Record the Result

A thin first-use account needs only one decision-changing containing or neighbouring System, one named relation or condition, its epistemic status, and one result for that decision. For an unknown that can change the result, state which decision it blocks. Use several representations when needed, keeping them distinct from the use situation and System whole they describe.

SYSE.16:4.3 - What Changes in Practice

The engineer stops asking only what lies outside a product box and asks which Systems, structures, direct relations, and conditions make this use work. Functional transformation and constructive structure stay separate, outside change becomes an engineering input, and unsupported assumptions become visible results rather than hidden context.

SYSE.16:5 - Worked Case: Upgrading an Occupied Building’s Heat-Pump Plant

An engineering team is deciding whether to add a new controller configuration to an existing heat-pump plant for the next heating season. The decision asks whether occupied rooms can remain within the selected thermal range while the plant responds to grid signals.

The decision-sized engineering-use account distinguishes these structures and relations:

• Actual System and containing whole. The heat-pump plant is an actual System and a proper part of the building heating System. The proposed controller is still an intended referent. The occupied building and its heating System are not assumed to be the same whole.
• Functional transformation and transfers. An electricity-distribution System transfers electrical energy through the feeder. A signal channel transmits demand-response information. The plant transfers thermal energy to the hydronic loop, and the loop and radiators transfer it to room air. Envelope heat transfer and occupant control actions also change room temperature.
• Constructive organization. The feeder, hydronic connections, sensors, controller interface, signal channel, and cabinet clearance are the selected bearers and interfaces for this decision. Their constructive relations do not follow from the functional-flow description.
• Maintenance supply, access, and Work. Under MaintenanceCommitment-14, maintenance company HeatCare-7 commits to supply ControllerInspectionResult-14 to building operator BuildingOperator-1 before the controller-configuration decision. The building operator grants HeatCare-7 plant-room access during stated windows. Technician T-4 is the intended Agent for ControllerInspectionWork-14; that Work has not occurred. If it occurs, the Work produces the inspection result, HeatCare-7 supplies the result to BuildingOperator-1, and the operator receives it for the controller-configuration decision. The commitment, access grant, intended assignment, capability claim, planned Work, result production, supply, and receipt remain separately supported claims.
• Systems that may bear consequences. Residents in a nearby building may experience increased low-frequency noise during night cycling. A model supports this possible consequence; no night measurement yet establishes an observed effect.
• Unsupported assumptions. Sensor latency and occupant override behaviour are unknown at the required load. A planned insulation change may alter the thermal model. Cabinet clearance is supported by a drawing but has not been checked in the plant room.

The account changes three next decisions. The Agent applying SYSE.17 uses the possible acoustic-exposure and maintenance-access consequences. The Agent applying SYSE.8 uses the maintenance commitment, provider and access relations, and the need for the inspection result. The Agent applying SYSE.2 uses the revised use claims and low-noise and cabinet-location alternatives. If the team also considers remote monitoring, that is a proposed offering: this account establishes neither its provider commitment nor its authority. The dependent remote- monitoring claim remains conditional. The team can act on the supported inputs. When the full pattern is unnecessary. If the current question is only whether one already identified sensor is a proper part of one known controller under an admitted relation, use the direct System and parthood patterns. A broader engineering-use account adds no value.

SYSE.16:6 - Bias Annotation

A source or representation—such as an official context diagram, stakeholder list, standard, or organization chart—does not by itself establish that a relation obtains or a Method is effective. Any capable and authorized Agent may develop the account; professional title, substrate, and organization label have their own evidence. Specialist Methods and evidence remain with their domains—for example, electrical, building, safety, legal, environmental, or financial practice. Agents with the relevant authority make the corresponding decisions.

SYSE.16:7 - Conformance Checklist

• The actual System or intended-system designator selected as the project system-of-interest, use situation, receiving decision, configuration, and horizon are stated.
• Actual Systems and intended referents remain distinct from accounts, models, scenarios, and diagrams.
• Suprasystem is used only with a stated actual or possible-future proper-part relation.
• Functional transformation remains separate from constructive parts, bearers, and interfaces.
• Other Systems and conditions appear only when a named relation can change the decision.
• Observations, predictions, design choices, commitments, and unsupported assumptions remain distinct.
• Outside changes and evidence that reopen the decision are stated.
• The account returns a mismatch, alternative, evidence need, or qualified assumption rather than an exhaustive inventory.

SYSE.16:8 - Common Failures and Repairs

These recurring abstractions hide a relation that changes the engineering decision:

SYSE.16:9 - Consequences

Engineering alternatives become comparable in the use that gives them meaning. Interface choices expose their bearers and receiving Systems, outside changes gain reopen conditions, and System or offering concepts no longer rely on an unexplained environment label.

The cost is maintaining several selected structures and their correspondence. That cost is smaller than preserving one stable diagram after its hidden assumptions have ceased to obtain.

SYSE.16:10 - Rationale

Systems matter through particular part, interaction, transformation, interface, transfer, and consequence relations under conditions. FPF supplies the general ontology for those claims. The engineering specialization is the repeatable move from one use decision to the smallest outside structure that can change concept, architecture, offering, assurance, configuration, or continuing development.

SYSE.16:11 - SoTA and Source Use

Functional, constructive, interface, use and continuing-development views can expose different Systems and conditions relevant to a use decision. The method relates those descriptions to the Systems and relations the decision concerns.

Reopen only a source-dependent claim that newer evidence can change. Assess enacted prevalence and effectiveness separately from the publication of a newer standard, notation, or framework.

SYSE.16:12 - Relations

• SYSE.1 supplies the System designation, decision, boundary question, alternatives, and reopen evidence needed here. Its result creates no temporal order.
• A.1.SCR distinguishes an actual acting or changed System from a designation, role word, description, process, or organization label.
• A.22 governs each selected structure. A.6.F restores function, bearer, capability, Work, and MethodDescription distinctions; A.6.M applies only to an obtaining module or interface claim.
• E.18.NET applies when the use needs a transformation-flow network. The network is a representation of selected transformations and dependencies, not the containing whole or a lifecycle.
• Agents applying SYSE.17, SYSE.8, or SYSE.2 can use the account’s consequence, provider, or concept results. Each Agent rechecks subject, configuration, horizon, evidence, and compatibility for the receiving use.
• Application profiles retain domain Methods and evidence—for example, Methods and results for operating physics, safety, legal compliance, medical use, finance, software, electrical systems, buildings, or ships.

SYSE.16:End

SYSE.17 - Find Systems That May Bear Engineering Consequences

SYSE.17:0 - Use This When

Use this pattern when a decision about a proposed System, configuration, or use change already names some participants—for example, users, owners, operators, or interacting Systems—but may still omit actual Systems whose states or decision-relevant characteristics could change through Work or events such as realization, operation, maintenance, misuse, failure, recovery, retirement, or later modification.

Begin with one proposed engineering alternative or change and the decision that can still alter it. Trace possible consequences beyond the current contractual, organizational, and technical-interface boundaries. Keep obtaining relations, modal path claims, observed changes, value judgements, and specialist decisions separate.

The first useful result is a bounded engineering consequence account. It names each actual System or intended System referent that may bear a material consequence, qualifies the consequence and its evidence, and connects it to an action or unresolved need in the receiving decision—for example, a constraint, alternative, probe, safeguard, specialist question, monitoring condition, or explicit gap. The account is an episteme; the Systems and changes it describes remain world-side. Add a value or representation claim only when the receiving decision uses it and its own grounding is available. A.1.CSD supplies the general discovery move. This pattern specializes it for engineering choices: start from a proposed System, configuration, or use change and connect qualified consequences to the named engineering decision. Use C.28 when one already identified causal claim is the whole question. Obtain a result from the applicable specialist practice whenever the decision relies on authority outside Systems Engineering.

SYSE.17:0.1 - Terms and Distinctions

Test System identity independently for every population or collection. Candidate bearers include actual Systems such as a person, organization, technical System, or ecological System. Keep a not-yet-present or unidentified bearer as an intended System referent inside the modal claim. A project assignment or decision authority requires its own grounding.

SYSE.17:1 - Problem Frame

Engineering decisions and descriptions guide realization, operation, maintenance, and modernization Work. The resulting changes can reach Systems outside the project’s influence and formal organization—for example, a downstream resident, future operator, maintenance provider, ecological System, supplier, bystander, competing resource user, or later user. Discover such a bearer from the consequence claim rather than from a stakeholder label.

The engineering problem is to discover enough consequence-bearing Systems, qualify the claims about them, and return unresolved consequences while the receiving engineering decision can still be altered.

SYSE.17:2 - Problem

Stakeholder lists are commonly built from cues such as visibility, power, contracts, interfaces, or organization charts. Those cues can miss, for example, quiet, weakly represented, future, indirect, non-human, or cross-boundary consequence bearers. The opposite error is to call every mentioned party affected without naming a change, evidence basis, or decision use.

Diagrams create another error: a plausible arrow from a proposed change to a possible bearer is reported as an actual relation or causal effect. Treat the arrow as a representation and ground its participants and predicate separately. Scale words such as person, team, organization, society, and ecosystem provide candidate scopes; recover actual Systems, whole–part relations, causal relations, and observed changes from their own evidence.

Too little discovery exports cost or harm. Unbounded discovery makes action impossible because every imaginable consequence appears equally real and authoritative.

SYSE.17:3 - Forces

Recurring tensions include:

• Consequences can cross, for example, contractual, ownership, organizational, interface, and project boundaries.
• Early choices need expert judgement; exhaustive measurement is often unavailable or uneconomic.
• A weakly supported possibility can justify a cheap probe or reversible design, but not an observed-effect claim.
• A descriptive consequence claim, a value judgement, and a deontic or governance claim use different predicates and evidence.
• Constituent, containing, neighbouring, and later reidentified Systems can change differently; aggregates can hide those distributions.
• Specialist safeguards must inform the engineering decision without Systems Engineering claiming authority it does not have.

SYSE.17:4 - Solution

Apply the general affected-System discovery move to one proposed engineering alternative or change. Retain only consequence claims that change or hold open a named engineering decision, and state what supports each claim.

SYSE.17:4.1 - Perform the Move

1. Name the focus and receiving decision. State the proposed alternative or change, the actual System or intended System referent and configuration to which it applies, the use situation, relevant scope and horizon, and the engineering decision that can use the result.
2. Generate consequence-producing situations. Consider Work and events that may expose the alternative’s consequences—for example, realization, intended use, maintenance, plausible misuse, failure, recovery, retirement, or later modification. Retain only situations whose consequences could alter the receiving decision; these examples do not impose a lifecycle.
3. Trace outward without promoting hypotheses to facts. Follow supported obtaining relation occurrences separately from modal consequence-path claims. For each modal path, name candidate participants and proposed relation kinds—for example, material transfer, energy transfer, information transfer, exposure, access, resource use, an economic relation, or an institutional relation—together with conditions, evidence, uncertainty, and the useful consequence or limit for this decision. A modal path does not itself select a probe.
4. Recognize the bearer. Identify each actual System from evidence about its identity and boundary. A role label, organization name, collection, description, or representative can help locate a candidate but does not establish that identity. Keep a possible-future bearer as an intended System referent in the claim until the System exists and can be recognized. State what remains unknown when recognition needed by the decision fails.
5. Qualify the consequence. State the characteristic or condition that may change, bearer, configuration, conditions, direction or magnitude cue when known, interval, and uncertainty. Distinguish an observed occurrence from a modal claim. State the evidence basis—for example, observation, measurement, simulation, model-based prediction, or a bounded expert estimate—and its limits. Use C.28 when reliance depends on a causal, intervention, or counterfactual claim.
6. Add value and specialist claims only when needed. Name the bearer and value frame for a value-qualified consequence—for example, a claimed benefit, harm, burden, opportunity, or accepted loss. Preserve conflicts and distributions. Select any specialist acquisition through A.15.9 and C.11.DUA before sending the question with its System, claim, evidence, and receiving decision; keep the returned authority boundary visible.
7. Change the engineering choice. Add or revise a decision contribution—for example, a constraint, alternative, probe, safeguard, monitoring condition, reversible step, refusal, or escalation. When that contribution relies on permission, authority, responsibility, or representation, establish the required relation separately.
8. Finish with the useful answer and its material uncertainty. A qualified consequence account, constraint, alternative, or explicit unknown can complete this use. Select a further discovery action through C.11.DUA only when its obtainable contribution warrants the full preparation, access, performer, interpretation, delay, displacement, and downside. Compare observations separately and together against shared resources and the decision window. Retain the residual and reopen condition that matter to the receiver; an unselected inquiry needs no proposal or omission certificate.

The numbered presentation is an A.22.CGUS learning unfolding, not a required Work sequence. Discovery, design, trial, specialist inquiry, and consequence observation can overlap and reopen one another.

SYSE.17:4.2 - Record the Result

An initial account can contain one qualified consequence and one named uncertainty—for example, an unidentified bearer, unsupported relation, or missing specialist result—when they already change the decision. A bounded expert estimate is usable when better evidence is not affordable; label it as judgement with its basis and uncertainty rather than measurement or prevalence evidence.

SYSE.17:4.3 - What Changes in Practice

Visibility, influence, contract, and project role stop being the entry criteria. Engineers trace a proposed alternative or change to actual Systems or intended System referents, distinguish obtaining relations from modal path claims, and feed uncertain but material consequences back into decisions while change remains affordable.

SYSE.17:5 - Worked Case: Quiet Consequence Bearers of a Heat-Pump Upgrade

The engineering-use account from SYSE.16 describes an existing heat-pump plant, a proposed controller, the next heating season, and the architecture decision. The team examines consequences of the proposed controller for Systems not captured by the original user-and-owner list: