SYSE.2 - Develop Linked Use and System Concepts

SYSE.2:1 - Problem frame

Use this pattern when a project has selected an actual System, retained an intended System referent, or bounded another engineering subject, but the proposed concept cannot yet be defended through concrete use. The team may have, for example, an internal block diagram, requirement set, component list, product concept, or preferred technical solution while phrases such as environment, suprasystem, using system, Concept of Operations, use case, scenario, requirement, or user story stand in for several Systems, intended System referents, conditions, relations, and effects. A compatible SYSE.16 use-context account supplies decision-relevant operational structures, neighbours, conditions, and outside changes. A compatible SYSE.17 affected-system account supplies qualified consequence claims and unresolved bearers. Use only result claims compatible with the current decision.

The result is a linked use-and-system concept proposal: bounded claim content that connects a concrete use situation with a candidate System concept and states their main uncertainty. One or more descriptions may carry the claims; no document form is required.

First useful move: link one concrete use claim to one candidate system-concept claim and state their main uncertainty. This is enough to expose a grounded architecture question. Add further content—for example, another use situation, structure, participant, failure, effect, or representation—only when it can change the candidate or its boundary.

If this link is missing, internal elegance can substitute for usefulness. A pump passes a component test but worsens downstream flooding; planning software is installed but cannot support production decisions with the available data; a retrofit design works in an empty building but cannot be realized while the building is occupied.

The payoff is a revisable account that keeps outside use connected to concept content about the selected actual System, retained intended System referent, or other bounded engineering subject. Evidence about use can change that concept content, while architecture and realization findings can change the use, boundary, or affected-System claims.

Use this pattern while a concrete use claim and a candidate System concept still need to be developed together. Use C.30 and C.32 when the current question is grounded architecture and candidate synthesis, A.3.4 when the question is whether one actual bounded change occurred, and the applicable Operations Management pattern for continuing Work. Return to SYSE.1 when evidence changes which System should orient the project.

At the first consequential use of source wording, ask: does this claim connect concept content about the selected actual System, retained intended System referent, or other bounded engineering subject with a concrete use situation, participating or affected Systems, conditions, and outside effects? If yes, name those subjects and relations and use this pattern. A representation—for example, a ConOps, use case, scenario, requirement, user story, diagram, or model—presents some of these claims. Its form establishes neither their truth nor the required form for the proposal.

SYSE.2:2 - Problem

A project-system choice does not determine the useful boundary or organization of the selected actual System or intended referent. The same desired effect can be achieved through different actual or proposed changes—for example, changes to the designated System, an external System, an interface, a Work arrangement, or several sides together. A containing System may matter, but parthood must be established directly. Use, interaction, placement, ownership, authority, affectedness, and shared environment are other relation kinds and require their own grounds.

One-way handoffs make this worse. A supposedly complete use description is handed to concept development, then architecture or realization discovers that the use cannot be supported. Conversely, one attractive technical concept narrows the use description until only its successes remain visible. The recurring engineering problem is to develop the use claims and system concepts together while preserving the distinctions needed to return a failed claim.

SYSE.2:3 - Forces

SYSE.2:4 - Solution

SYSE.2:4.1 - Start with one decision-changing use situation

Take the selected actual System or intended System referent and current reason from the project-system choice account, or state the bounded engineering subject when no project-system choice is needed. If that choice is needed but no compatible SYSE.1 account is available for the same subject and decision, use a qualified direct source for the focus claim or record the missing project-focus result and stop only the linked claim it blocks. For an actual System, describe an actual or possible-future situation in which it participates. For a not-yet-present referent, keep the intended participation in modal plan, decision, or description content; do not assert an actual System or participation relation before identity inception. State:

1. the subject that relies on, uses, changes, or is affected by the proposal;
2. the direct relation by which that subject enters the use;
3. the condition or change expected;
4. the outside effect that matters to the current decision; and
5. the uncertainty that could change the concept.

Name the relying subject under its admitted kind; a person and a System are only two possible kinds. State the direct relation by which it enters the use—for example, reliance, participation, performed Work, or affectedness. Include affected Systems or intended System referents whenever their qualified consequence claims can change the decision; participation in or ownership of the designated System is not required.

SYSE.2:4.2 - Name the subjects and direct relations hidden by environment language

Start from compatible current SYSE.16 and SYSE.17 results for the same subject, configuration, use, horizon, and decision. If either result is unavailable, recover only the subjects and direct relations needed for the first linked claim. Use SYSE.16 when the decision needs several operational structures or a co-change boundary, and SYSE.17 when it needs active discovery of consequence-bearing Systems. A neighbouring System may matter, for example, through constructive parthood, placement, interface, interaction, causal participation, use, transformation, collection membership, assignment, ownership, permission, authority, or affectedness. State only relations that are current and apply the FPF pattern that defines or constrains each claim.

Use A.1.SCR when the System status of a proposed participant or containing whole is unresolved. Use A.22 when the current question selects an organization among independently identified constituents and obtaining relations for a named use. Keep several non-nested structures when one decomposition would hide a relevant claim—for example, an interaction, control relation, affected System, or source-return condition.

Authority constrains who may change a System; it does not draw the System boundary. Ownership can matter to a decision without establishing containment. A containing whole matters when its actual or proposed proper-part relations and whole-level consequences change the use or concept. Distinguish supported actual relations from proposed relations and qualified predictions; a future whole need not already exist for its proposed arrangement to affect the concept.

SYSE.2:4.3 - Develop the use claim and candidate system concept together

Write one outside-facing use claim and one inside-facing concept claim:

Linked use-and-system concept proposal:
  concrete use claim:
  candidate system-concept claim:
  main uncertainty:
  architecture question exposed:
  reopen condition:

Use any readable form for this content. The use claim names participating or affected Systems, conditions, expected transformations or behavior, and outside effects only as far as the current decision needs. The system-concept claim names what the proposed concept needs—for example, a boundary, functioning, interface, resource, constraint, or placement—while leaving full architecture selection open.

Use A.6.F when function-like wording carries a claim. Name the required functioning and its proposed bearer. Any remaining question—for example, about function, capability, Method, Work, module, interface, evidence, or architecture—stays under the pattern that defines or constrains it. Use A.6.M only when an actual module or interface claim is current. If no feasible bearer can support required functioning, revise the concept or use claim before admitting an architecture candidate.

Use A.3.4 for an actual observed transformation only after the continuing subject, boundaries, before/during/after facts, and continuity rule are available. A required, intended, or simulated transformation remains modal claim content; its description does not establish that the change occurred.

A functional or transformation-flow description of relevant environment structure can support the linked proposal by showing selected functioning or flow relations for a named use. The proposal also states which use situation matters, which Systems participate or are affected, which outside effect changes the decision, which candidate System concept is being considered, and what remains uncertain. Model only the environment structure needed by those claims.

SYSE.2:4.4 - Compare changes on either side of the boundary

Develop alternatives when changing a different subject would change the engineering answer. Compare, for example:

• an actual or proposed change to the designated System;
• a change to an external System or operating arrangement;
• a changed interface, placement, or resource relation; or
• coordinated changes on several sides.

Use a compatible SYSE.8 provider-arrangement account when its supported provider-arrangement claims or design constraints change the use, candidate System or intended referent, boundary, interfaces, realization needs, or evidence. Consume only the compatible claims named for this use. Without a compatible current SYSE.8 account, use a qualified direct source for the needed provider-arrangement claim or record the missing result and stop only the linked claim it blocks. Either account may need revision when a shared claim changes; that dependency does not prescribe the order of engineering Work. Obtain other decision-changing results from the specialist practice that owns them—for example, organization change, Operations Management, Platform Engineering, Governance, safety, security, ethics, law, or finance. Keep each result claim linked to the use or concept claim that consumes it.

For example, when source material names a product-service system, digital twin, digital thread, MBSE, PDM, PLM, eXperience platform, or Multi-D arrangement, recover the actual contribution before using the umbrella term. A concrete contribution—for example, a maintained model, configuration relation, simulation, observation return, integration capability, or change decision—can enter the linked proposal through its direct claim. The umbrella name alone does not decide whether this pattern, architecturing, realization, assurance, or a specialist practice is the next use.

SYSE.2:4.5 - Expand only when another claim can change the candidate

The cheap first result is one linked use claim, one candidate concept claim, and their main uncertainty. Expand when further content—for example, another use situation, load, failure, participant, affected System, harm, benefit, or representation—could change the candidate. Add only the relevant:

• environment structures and obtaining relations;
• transformations, interactions, conditions, and effects;
• functioning, interface, placement, resource, and constraint claims;
• correspondence between a representation and the represented claims;
• alternatives, assumptions, evidence limits, and specialist returns.

If source words such as operational system, system in operation, operations, or operational flow are current, distinguish two questions. Use this pattern for a System’s participation in use and the concept that supports it. Use Operations Management when the difficulty is managing continuing Work, queues, policies, or flows. An operational adjective does not settle that choice.

SYSE.2:4.6 - Stop at a grounded architecture question and reopen from failed support

Stop when the current use claim and candidate concept expose a grounded architecture question and their main uncertainty. The linked proposal supplies required functioning, operating conditions, outside effects, decision-relevant environment structures, assumptions, and evidence limits to C.30 and C.32.

Use C.30.ASV only when a structural description and its adequacy for a selected architecture use are current. Do not open a full view or architecture-description apparatus merely because a sketch helped the discussion.

Reopen the smallest linked claim when:

• the use claim and concept claim no longer support each other;
• a candidate architecture lacks a feasible bearer or hides a harmful effect;
• realization evidence defeats an interface, resource, placement, or capability assumption;
• operating observation changes a condition or effect; or
• a specialist result changes permission, feasibility, harm, value, or the participating Work arrangement.

Return to SYSE.1 only when the failed claim changes which System should orient the project or where the project boundary lies.

SYSE.2:5 - Archetypal Grounding

Pumping station under flood risk

In the preceding SYSE.1 use, the engineer retains the intended referent PumpingStation-P1 in decision content and records downstream exposure as unresolved. No actual PumpingStation-P1 exists yet. The first linked proposal says:

use claim: the intended referent would move water under the selected flood load without unacceptable downstream harm
system-concept claim: the description assigns pumping, positioning, power, control, and discharge functioning to the intended station referent
main uncertainty: downstream conditions may make the proposed discharge harmful
architecture question: which selected structures and possible bearers could support the claim

This is enough to use C.30 and C.32. A component pump test can contribute evidence about an actual bearer, but it establishes neither the not-yet-present station nor its outside effect. The engineer uses downstream-harm evidence to revise the use claim. The project-system choice reopens only if the station referent no longer supports the project decision.

Manufacturer’s ERP-enabled planning change

The manufacturer keeps PlanningSystem-P1 as an intended System referent in its project decision; actual System identity remains unestablished. Actual person Systems Planner-A and Planner-B perform PlanningWork-PW1. They use actual deployed software runtime ERP-Runtime-E3 and demand, capacity, material, and production-order records as resources and evidence. The records are epistemes; PlanningAPI-PA2 and the user interface are separately identified interfaces.

The linked use claim says that Planner-A and Planner-B would revise production commitments during PlanningWork-PW1 using current records and ERP-Runtime-E3. The system-concept claim describes a possible future organization in which these actual Systems, records, interfaces, and planning Methods could satisfy a separately tested A.1 System criterion. Data currentness and interface latency are the main uncertainties. The ERP vendor’s product project can instead select ERP-Runtime-E3 or its product referent for its own decision. Installation completion, an organization chart, and user acceptance establish neither the manufacturer’s production effect nor the intended composite PlanningSystem-P1.

Occupied building heat-pump control

For HeatPumpPlant-HP1, ControllerConfig-C2, the next heating season, and ArchitectureDecision-AD1, the three compatible input accounts use the same subject, configuration, use, horizon, evidence window, and receiving decision:

• the SYSE.16 use-context account states the BuildingHeatingSystem-BH1 proper-part claim, energy and information transfers, plant-room access permission, and unsupported latency, override, insulation, and clearance assumptions;
• the SYSE.17 affected-system account supplies the qualified AcousticResult-AR4, SafetyResult-SR7, ThermalResult-TR5, and their authority boundaries, including the unmeasured neighbour-noise and cabinet- clearance branches; and
• the SYSE.8 provider-arrangement account supplies only the supported provider claims and design constraints: actual provider System MaintenanceTeam-MT4, the current access permission, expected diagnostic Work, the communications bearer, and the missing commitment and authority result for remote monitoring.

The three accounts change the linked proposal as follows:

use claim: occupied rooms remain within the selected thermal range while qualified neighbour-noise and maintenance-access constraints hold
system-concept claim: ControllerConfig-C2 includes a cycle-rate limit, a low-noise branch, a measurable cabinet-location alternative, and a latency-tested override-safe branch
main uncertainty: night acoustic measurement and plant-room clearance are unavailable; remote-monitoring authority and commitment are unresolved
architecture question: which controller, sensor, cabinet, communications, and operating structures support those qualified claims
reopen condition: a specialist result, measurement, provider result, or operating observation defeats one of the linked claims

The remote-monitoring branch remains conditional because the provider-authority and commitment result is unavailable. Realization and WorkPlan descriptions may include cabinet relocation, access preparation, and test Work. Keep those realization and WorkPlan descriptions distinct from the System concept. If no feasible architecture supports the linked claims, revise this proposal. Reopen SYSE.1 only if the failure changes the project focus itself.

SYSE.2:6 - Biases to Watch

Two recurring biases matter here. Representation lock-in treats a familiar use-model form as the use itself; recover the represented Systems, relations, conditions, and effects. Concept lock-in narrows use until the preferred concept always succeeds; keep the use claim revisable and return evidence to the smallest claim it calls into question.

SYSE.2:7 - Conformance Checklist

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

SYSE.2:9 - Consequences

The project can ask architecture questions from a concrete outside-use basis without waiting for a complete requirements package. It can compare changes across the assumed boundary, preserve non-nested environment structures, and return evidence to the claim it can actually change.

The cost is ongoing concept maintenance. A use claim, System concept, and representation can diverge as new evidence arrives. Keeping their relations explicit requires more care than freezing one document, but it avoids the larger cost of treating an obsolete description as the use or architecture itself.

SYSE.2:10 - Rationale

A System concept becomes useful to an engineering decision through concrete relations with other Systems and conditions, yet no single containing whole or representation captures every consequential relation. Linking use and System concepts makes the outside reason and inside proposal inspectable while leaving architecture selection to the applicable FPF patterns.

The link is intentionally small. One use claim, one concept claim, and one uncertainty can already reveal a missing bearer, harmful effect, or misplaced boundary. Fuller descriptions are justified by decisions they can change, not by a prescribed documentation sequence.

SYSE.2:11 - SoTA-Echoing

These current lines support continuing, use-led, model-linked revision within their stated domains. This pattern connects a use situation, subjects and relations, qualified consequences and a candidate concept, using compatible SYSE.16, SYSE.17 and SYSE.8 results. Relate evidence to the claim it can change. Apply each source within its stated domain and assess cross-domain transfer against the receiving use, Systems, relations and evidence.

SYSE.2:12 - Relations

• A SYSE.1 project-system choice account supplies the selected actual System or intended System referent, current reason, boundary question, alternatives, and reopen condition used here. A changed use or boundary returns to SYSE.1 only when it changes the project focus.
• A compatible SYSE.16 result supplies selected operational structures, conditions, and unsupported assumptions; a compatible SYSE.17 result supplies qualified consequence claims and unresolved representation or protection needs; a compatible SYSE.8 account supplies only its supported provider-arrangement claims and design constraints. Use each result only for a compatible subject, configuration, use, horizon, evidence window, and decision. These relations do not prescribe an order of engineering Work.
• Use A.3.4 for the identity and boundary test of an actual bounded transformation. Intended, required, and simulated transformations remain claims or representations until that test applies.
• Use A.6.F to recover the object or claim meant by function-like wording and select the direct subject pattern. Use A.6.M only when a module or interface claim is current.
• Use A.22 for selected-structure identity in decision-relevant environment structures. Use C.30.ASV for structural-view adequacy only when a description is relied on for a selected architecture use.
• The linked use-and-system concept proposal supplies functioning, operating conditions, outside effects, selected environment structures, assumptions, and evidence limits to the architecture question. C.30 defines grounded architecture claims and relations; C.32 guides candidate synthesis over selected structures.
• Architecture, realization, operation, or assurance evidence returns to the smallest linked claim it can change. Practitioners in organization change, Operations Management, Platform Engineering, Governance, safety, security, ethics, law, finance, and other specialist practices keep their Methods and supply only the results consumed by the linked proposal.

SYSE.2:End