Systems Engineering Principles Framework

DocID: SYSE within FPF Library.

A domain pattern language for bringing about and changing engineered Systems, from their intended use and architecture to realization, assurance, and continuing development.

• Author: Anatoly Levenchuk, with AI-assisted development and review
• Version: 12 October 2026
• Status: Eternal alpha: a published working framework, already used in analyses and worked applications, while continuing to evolve.
• License: CC BY 4.0 for original framework content; third-party material retains its own terms.
• Publication: FPF repository

Begin with the engineering question that blocks your project: the project System and its use, an architecture choice, a realization branch, an integration result, or the evidence needed for a decision.

Use the Table of Contents below to search by a familiar term or working question and find the relevant PatternID. Open the pattern and apply its Problem frame, Solution, worked cases, and checklist to the actual System, configuration, or engineering decision. Follow dependencies when a needed result is missing; engineering Work may otherwise overlap or begin from an already available result.

The Readme follows worked connections between patterns for larger engineering questions. The Architectural Reference explains the recurring distinctions. The full Table of Contents also serves questions outside the examples, and the pattern bodies supply the working moves, conditions, and stops across kinds of engineered System.

Table of Contents

Search the Keywords & Search Queries column for the engineering difficulty, subject, or result you recognize. Each row explains the pattern’s contribution and links to its full body. The Readme offers selected starting examples; use the complete index for other working questions. Dependencies name result relations, not a mandatory entry order.

Public units

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

Part II - Architecture, Descriptions, Offerings, and Professional Contributions

Part III - Obtaining Engineering Results, Recursive Realization, Platforms, Independent Constituents, and Evolvability

Part IV - Configuration, Continuing Change, and Source Continuity

Part V - Assurance, Method and Work Architecture, Repertoire, and Cultural Continuation

Part VI - Platform Engineering: Supported Use and Continuing Change

Part VII - Software Platform Engineering

Part VIII - Engineering Agent Work and Support

Systems Engineering Principles Framework Readme

This framework helps engineers and managers bring about or change engineered Systems. Use its patterns to connect intended use and problem formulations with System-family options, architecture, realization, configuration, and evidence. The patterns also connect these decisions to the engineering platform, evolvability, and continuing Method development. The framework applies across kinds of engineered System. The framework also supplies a common Platform Engineering language and a selected Software Platform Engineering repertoire for service software. It also supplies Methods for engineering agent work and support, with human and technical realizations and a bounded LLM-learning branch. The selected repertoire is not complete software engineering. Software, electrical, ship, building, medical-device, cyber-physical, and other application profiles retain the specialist Methods and sources that differ because their engineered Systems differ.

Start from a working difficulty. Engineering Work can overlap: a team can refine use, architecture, realization, configuration, assurance, and its engineering Method during the same bounded project interval. A logical dependency still matters when one result cannot be used before another exists. Use the patterns to recover the actual result dependency; do not turn the order of this file into a prescribed project sequence.

The Architectural Reference explains how the common engineering Methods, Platform Engineering and the selected software profile fit together. Use Architectural Rationale when choosing or adapting that combination, and Check the combined engineering answer when several contributions must support one decision. These explanations reuse the full patterns and the existing applications; the Table of Contents remains the direct route to any individual Method.

You can ask an assisting agent to explain or apply these methods in the language of your work, without FPF jargon, while preserving the distinctions needed for the question.

When independently released components have to work together, begin with SYSE.53. It derives the requirements and sharing scopes that support one usable composition, or returns the conflict or missing premise. Its software and corpus cases distinguish selection from construction and provision.

Practical entries

The following selected examples show how an engineering answer depends on results from several methods. Enter with what the project already knows; obtain the missing contribution and return it to the decision that needs it. A changed use, configuration or observation can reopen an earlier choice. These examples are not a complete catalogue or a boundary of the framework’s coverage, and they do not prescribe a project lifecycle. For questions outside these examples, use the Table of Contents and the PatternID and title for direct help with one method.

SYSE-CARD-01 — Release a mixed physical-and-software change without losing service, configuration, or evidence

• Situation: A pump-station change combines equipment, control software and operating limits while the district-heating service must continue.
• Question: What connects local design and test results to a defensible decision about using the changed station?
• First useful result or blocker: A recommendation for a named configuration and operating use, carrying what the available results support and what still prevents release.
• Start with: SYSE.1 for the project system and SYSE.2 for its intended use, or the first missing result if these are already understood.
• Stop or return: Return the recommendation to the release authority when it can decide. Reopen only the conclusions affected by a changed configuration, use, source or observation.

In APP-SYSE-01, the station’s configuration PS17-C42 combines a pump-train modification and software changes. SYSE.16 identifies the surrounding heating arrangement; SYSE.17 finds the systems that may bear consequences, including connected users and maintainers. Their results let SYSE.2 describe the proposed operating use and the station arrangement that could support it.

SYSE.5 uses that account to develop different functional allocations and physical or software bearers. SYSE.6 compares these alternatives and selects the structures on which realization will depend. If no complete way of obtaining an included result is available, SYSE.24 compares arrangements such as adapting existing equipment or obtaining a supplied contribution, including integration and continued support. SYSE.3 then develops the required realization work and its means. An unsupported branch can return the project to the architecture choice.

SYSE.11 integrates the realized contributions and observes the increment in its named use. SYSE.13 identifies the resulting configuration and where it applies. These results give SYSE.4 a subject for interpreting the component, station and downstream observations. Component evidence supports only the claim and conditions for which it was qualified; it does not settle the station-use question. SYSE.14 consumes the configuration and qualified evidence to prepare the release decision, retaining the deciding authority and any separate permission.

The example’s recommendation remains conditional on a restored-function check and unresolved safety permission. A new component version reopens the claims affected by that version; it need not invalidate unrelated evidence. If the trial also used a new AI-assisted analysis method, SYSE.15 addresses its further use for the supported claim classes. SYSE.21 becomes relevant only when the question concerns transmission and retention across practitioners. A local trial and a claim about later cultural continuation need different results.

The same connections apply to other engineered systems. APP-SYSE-03 gives a software-only case with displayed alternatives and four limits: its one surviving architecture supports a specified canary, not unrestricted release. The specialist security result remains a premise supplied by that practice.

SYSE-CARD-02 — Develop a problem portfolio and System family without freezing either

• Situation: A prototype or operating observation changes which problem is worth solving, while an attractive system option may be difficult to realize with the available means.
• Question: Should the next change concern the problem, the system option, its builder arrangement, or a combination?
• First useful result or blocker: Comparable options and a choice, a worthwhile probe, rejection of the set, or the missing question or authority.
• Start with: SYSE.22 when project focus and use are understood. Resolve an ambiguous system through SYSE.1 and incomparable configurations through SYSE.13.
• Stop or return: Stop at a useful option decision if realization does not change it. Use SYSE.23 when the relation between the option and its builder changes the next investment or reconfiguration choice.

APP-SYSE-02 considers inspection systems whose relevant problems include early damage, false alarms, inaccessible locations and interruption of operation. SYSE.22 keeps the problem formulations connected to, but distinct from, the system-family options. SYSE.2 supplies their intended uses; SYSE.5 and SYSE.6 supply materially different arrangements; SYSE.7 and SYSE.13 keep descriptions and configurations comparable. SYSE.10 interprets what a prototype or trial actually supports.

These contributions allow SYSE.22 to choose among surviving options, reject them, or select a feasible probe whose result could change the choice enough to justify its cost. For example, a trial revealing inaccessible locations can change the use question and the relevant sensing options. Repeating the old ranking with unchanged acceptance conditions would miss that change. The new question returns to the linked use and system concepts before their architectures are compared again.

A surviving option can instead be blocked by the arrangement that builds or supports it. SYSE.3 makes that dependency explicit; SYSE.12 identifies the platform contribution. SYSE.23 then compares changing the option, changing the builder arrangement, changing both, and retaining the present arrangement. The next result is an investment or reconfiguration choice. SYSE.20 distinguishes work that can overlap from contributions that must be available first. Developing a problem, a system and its builder therefore need not become three consecutive project stages.

A source change returns through SYSE.19 to the decisions that relied on it.

SYSE-PLATFORM-PATH — Make an engineering task easier without losing its usable result

• Situation: Practitioners repeatedly reconstruct inputs, reconcile results or wait for help even though individual tools and providers work.
• Question: Which supported way of working would remove that burden while preserving the result its user needs?
• First useful result or blocker: A supported interaction for a named task, including its failure return and the professional results still needed to compare or qualify the production arrangements.
• Start with: SYSE.25 for the practitioner’s difficulty; SYSE.24 when the whole obtaining arrangement is undecided.
• Stop or return: Use the improvement when its receiving task is supported. Pass the observed failure, uncertainty or missing professional result to the practitioner who can address it. Continue independently supported interface or planning work.

In APP-SYSE-06, planners cannot reliably connect returned coated parts with their drawing, lot, fixture and program. SYSE.25 selects the practitioner improvement; SYSE.24 compares internal production, external finished-part supply and a mixed arrangement. The comparison includes waiting, transport, rejected lots, support and exit as well as price.

The example explores the mixed arrangement; choosing it for production still requires the missing professional results and comparison with the other arrangements. SYSE.26 constructs a request, clarified input, authorized operation and returned result that the practitioner can follow. SYSE.13 carries the configuration relations through it. The example request names fixture B but supplies a program qualified only for A: the receiving interaction exposes that mismatch before machining. Correcting the association permits interface qualification to continue; qualification of the B program’s machining behavior remains a professional contribution. SYSE.18 handles the independently controlled coating provider, and SYSE.9 connects the dimensional and process results to the receiving engineering decision.

APP-SYSE-05 works an analogous connection for software. Its constructed candidate B retains the unresolved comparison with candidate A. SYSE.31 constructs trustworthy shared-mainline feedback, SYSE.30 addresses build inputs when they prevent it, and the runtime, data and recovery methods supply their own contributions. Data change, alerting and failed-task diagnosis can also start directly at SYSE.34, SYSE.37 and SYSE.38. The manufacturing case does not acquire these software prerequisites; both cases use the common methods to connect a practitioner’s task to supported results.

SYSE-LLM-PATH — Choose and use a way to complete the task

• Situation: A person or technical agent has several ways to obtain a required result, or repeatedly wastes effort, misses needed support or fails to use its return.
• Question: Which complete available way should be used now, and what should change when the difficulty recurs?
• First useful result or blocker: A supported choice followed by the performed operation and used result, or a worthwhile probe or exact missing condition that prevents choice or completion.
• Start with: The receiving result and its conditions. Use C.38/C.11 for an unsettled choice; obtain discriminating evidence through SYSE.46 when it is missing for a recurring difficulty.
• Stop or return: Stop at the used result when the current way suffices. For recurring failure, compare complete repairs and enter only the needed construction. Return missing domain meaning, access or authority to its supplier.

Start with the result someone needs and the complete available ways to obtain it. Compare only what can change the choice: supported performance, available means, setup, checking, receiving use and total burden. C.38 supplies the comparable ways; C.11 applies the evidence and preference, or selects a worthwhile probe.

For six lots of 347 items, suppose comparable evidence supports mental decomposition, no intermediate record is required, and paper or calculator would need setup. Under the preference for the least added burden among adequate ways, choose 350 × 6 − 3 × 6. Calculate 2100 − 18, check that the subtraction removes the extra three items per lot, and report 2082. If intermediate digit operations must be retained, a ready column layout can become the least burdensome adequate way. If a calculator is already open and frees working attention needed elsewhere, it can be worthwhile despite retained mental ability: enter and check 347 × 6, obtain 2082 and use it. These are constructed conditions, not measured performance comparisons. The Reference (Engineering.Reference:19.3) works the changed conditions and worthwhile-probe return.

That current task can end with its used result. Repeated wrong choices open a different question. For example, an agent repeatedly retrieves a maintenance procedure. If it sees the applicable premise yet asks again without a need, SYSE.50 constructs the assistance rule. If the next input lost a needed observation or unresolved effect, SYSE.52 restores the working material. If the input and return are usable but the controller routes back to retrieval, SYSE.47 repairs that transition. SYSE.42 still binds the call, reconciles an uncertain effect and uses the actual state; a generated prediction supplies no observation.

SYSE.46 obtains the discriminating evidence and tests the changed arrangement. Compare matched work without optional documentation, with the source operation supplied, and with the agent choosing whether to obtain it. Keep required execution and checks common. The trace distinguishes an omitted necessary call from a malformed call, lost input or ignored return. Fewer calls is useful only with correct result use, necessary access and appropriate stopping. SYSE.49 constructs missing informative experience. These tests can qualify a fixed-model repair; training and division of work remain separately selected alternatives.

Choose the body that supplies the missing operation:

Use an adequate current way and its result. Enter only the construction the task needs; these results are not compulsory stages. Return unknown domain meaning or missing authority to its supplier. The connected Reference answer (Engineering.Reference:19) works the current choice and then the development comparison, retaining the actual predictive, reusable-calculation and human-learning contributions.

Citation

If you use this framework, cite it as below and add the version date shown above:

Levenchuk, Anatoly. Systems Engineering Principles Framework.
GitHub repository: https://github.com/ailev/FPF

For a particular pattern, add its PatternID and title, for example: Systems Engineering Principles Framework, SYSE.6 - Decide and Reopen the Engineering Architecture. Retain the release date, and include a permanent link or stored copy when the exact wording matters.

Systems Engineering Principles Framework Architectural Reference

Systems Engineering changes or brings about engineered Systems through explicit reasoning about use, problem formulations, System families, architecture, realization, configuration, evidence, evolvability, and the engineering arrangement itself. The phrase is not a synonym for engineering of systems. Software engineering, electrical engineering, ship engineering, building engineering, medical-device engineering, and other profiles concern different kinds of engineered System and retain specialist Methods, evidence, laws, tools, and sources. This framework provides the common Systems Engineering layer that materially changes their Work, together with selected service-software platform Methods and engineering of agent work and support. That selection does not replace the remaining professional Methods or make one application profile universal.

FPF supplies the transdisciplinary distinctions used here: holons and Systems, parts and relations, Methods and MethodDescriptions, Work and results, architecture as selected structures, evidence and assurance, decisions and authority, cultural evolution, and precise plain language. This DPF applies them in engineering-specific moves: choosing a project system-of-interest, relating use and System concepts, developing a problem portfolio and System-family options together, developing functional and bearer alternatives, deciding engineering architecture, coordinating specialist returns, realizing recursively through builder Systems, developing the platform used by practitioners, maintaining configuration and release evidence, choosing changes to the project system-of-interest, its System-family option, the builder arrangement, or both for evolvability, and continuing engineering Methods.

SYSE.Reference:1 - Choose a useful result and combine its needed contributions

Use SYSE when local engineering answers leave an important connection unresolved: a component works but the intended use is unsupported, an architecture is attractive but its realization is missing, or a test result does not identify the configuration and decision it can support. Seek the result that changes the next engineering move. Depending on the question, obtain a selected alternative, a bounded usable increment, a justified reliance decision, a discriminating trial, or an exact missing contribution.

The patterns describe a repertoire of Methods. A project can use one Method directly or combine several. Start with the System, receiving use and decision that matter now. Reuse adequate concepts, configurations, specialist conclusions and evidence. Follow a further pattern when its result is needed, and return the result to the engineering decision that consumes it. For example, an obtaining comparison in SYSE.24 can expose a missing provider commitment for SYSE.18; an actual integration result from SYSE.11 can support, but does not make, the release decision in SYSE.14. The following sections explain these connections.

A provisional project focus can support individual concept work. Before joint work relies on a common focus, SYSE.1 makes participants’ referents, interests and contribution connections visible through a concrete use. The result may be sufficient common understanding for the current decision, an unresolved coordination condition, or distinct projects with a defined receiving contribution. A shared project name or written account cannot supply that result by itself.

The choice of Methods must accommodate useful effects, cost and time, available evidence, and consequences for other Systems. Preserving an option can be worth more than completing a design early; a faster local operation can transfer delay or risk to integration, maintenance or a user. Compare the complete arrangements that would produce the required result, including the work and support each retains. Use SYSE.20 when shared resources, conflicting conditions or actual dependencies determine what work can overlap.

If a current specialist Method or available result already answers the whole question, use it directly. Common Systems Engineering becomes useful when the question crosses those local answers or changes their receiving use. Stop when the bounded answer is sufficient; a missing premise holds only the conclusion or action that depends on it.

SYSE.Reference:2 - One System can appear in several engineering structures

An engineered System can be the project focus, a part of a using or containing System, the bearer of functions, the result of realization Work, one configuration in a product family, a participant in operation, and the subject of evidence. Each position expresses a different relation. Each pattern states that relation and the decision for which it matters. Ownership does not prove parthood; interaction does not prove membership; a description is not the described System; a release record is not the released configuration; and a passed component test does not establish an outside benefit.

Describe the operational environment through the containing, using, neighbouring, and interacting Systems and the conditions that matter to the current use. Call a System a suprasystem only when the engineered System under discussion is its proper part. SYSE.16 restores those relations; SYSE.17 follows the planned use, realization, operation, maintenance, misuse, and change to Systems that can bear benefit, harm, or another engineering consequence.

SYSE.Reference:3 - Use and System concepts stay linked

A concept of use says how actual or intended Systems participate in an operating situation and what effects are expected. A System concept says what engineered System arrangement could participate that way. Either can expose a defect in the other. SYSE.2 therefore guides an Agent in developing linked use-concept and System-concept candidate families rather than letting one preferred technical solution determine the use story after the fact. An available construction can also start the inquiry: develop a plausible use, follow its consequential behaviour, and let the failed assumption change the required functioning or proposed bearer. The next result can be a grounded architecture question while the proposed use remains conditional.

Functional organization and constructive organization answer different questions. A function claim concerns a contribution under conditions. A bearer claim concerns an actual System or intended System referent that could make that contribution. SYSE.5 guides the Agent in developing alternatives for both and making allocation and interface choices explicit. Then use SYSE.6 to compare the candidates for the current engineering use, record the selected result, and state the evidence and conditions that would reopen the choice.

SYSE.Reference:4 - Realization is recursive and continuous

Concept and architecture Work can continue during realization. Agents change engineered Systems by performing Work with Methods. Those Agents rely on builder and enabling Systems that may themselves require platforms, capabilities, resources, suppliers, facilities, models, software, data, and further engineering. SYSE.3 makes this recursive realization arrangement visible. Use SYSE.11 to obtain and modernize bounded usable increments.

The engineering platform is also an engineered System when it is deliberately developed to enable named practitioner Work. SYSE.12 starts from that Work—modeling, computation, build, integration, test, release, observation, or another engineering activity—and asks which actual capability, service condition, access, data, tool, automation, facility, or provider contribution is needed. Buying a tool or naming a platform does not establish that engineers can perform the Work.

Independently governed constituent Systems require another distinction. Their authority, operation, configuration, or evolution can remain partly independent even when a higher-level use depends on them. Use SYSE.18 to coordinate commitments, interfaces, configurations, decisions, and evidence while respecting those limits on the integrating project’s control.

SYSE.Reference:5 - Common platform work and software-specific Methods

Platform Engineering concerns an enabling arrangement for named practitioner work. Its common language asks what task should improve, how a supported interaction works, how interfaces and contributions change, where already justified controls apply, and how users and obligations move when an old path is retired. SYSE.25–SYSE.29 supply those Methods. The platform’s user can be a software developer, a production planner, a laboratory practitioner or another engineer; the required professional means are not interchangeable.

SYSE.53 addresses independently released digital components before their selected composition is realized. Actual shared meaning or interface use determines which requirements must hold together and where qualified isolation is possible. Its result supplies the selected inputs and bindings to configuration, construction and environment provision.

A supported path includes usable inputs, results, failure returns and actual support. State which path is described, what is currently provided, and what observations establish about the practitioner’s task. Use SYSE.12 to assess the enabling arrangement, distinguishing evidence available before reliance from observations of later use. SYSE.8 develops a providing-System concept when missing; SYSE.18 handles independent provider decisions; SYSE.24 compares whole obtaining arrangements. Sharing, self-service and a portal remain alternatives to test, not default winners.

At this common Platform scope, standardizing an interaction competes with legitimate user variation; improving one user’s task can increase provider or maintainer work. A control can reduce one risk while delaying feedback or blocking an authorized exception. Compare those effects for the actual user population and undertaking. A one-off tool use whose result and support are already adequate need not become a shared platform path.

The Software Platform Engineering branch supplies selected professional Methods in SYSE.30–SYSE.41. They construct repeatable builds and trustworthy feedback; preserve verified artifacts; reconstruct environments; manage compatible data change; produce and test actual runtime configurations; and govern bounded exposure, task-relevant reliability, alerts, diagnosis, repetitive burden and resource pressure. A platform service and the application it delivers have different users and success meanings. The same measurement Method can be used for each when its conditions fit, without combining their evidence or error budgets.

Faster feedback must preserve meaningful tests, appropriate environment isolation, identified build inputs and compatible retained state within available execution capacity. The software profile supplies the technical moves needed to investigate those trade-offs: for example, SYSE.30 identifies and controls build inputs, while SYSE.34 qualifies which application and data states can coexist or be recovered. A general request for trustworthy evidence would leave those different working moves unresolved.

Enter the Method for the missing result and retain compatible existing results. Runtime deployment needs its own observations and deployment test after artifact verification. Application behavior and permission for wider exposure need the application’s acceptance criteria and the release holder’s decision. Recovery with an old executable requires data compatible with its contract. These dependencies determine which results are needed for the current engineering move.

The software profile is a selection for particular uses, or a bounded-use projection of the SYSE repertoire. It reuses the common configuration, evidence, obtaining and provider Methods and adds the software Methods whose inputs, operations or stops differ. Common Platform Engineering applies beyond software; it is not obtained by renaming software objects. The eight Parts group the publication. A Method’s participation in a profile does not by itself make it a part of another Method.

Profiles can overlap. A laboratory with a software-supported instrument may need both the software build Methods and separate instrument, sample and measurement Methods. A further profile is useful when it changes what a practitioner can do, obtain or qualify in the same situation, or saves necessary source reconstruction. State that difference and reuse the sufficient common answer. If a narrower label changes nothing in use, the existing Method remains enough. This publication supplies the declared service-software and agent-engineering repertoires; the professional filling for further profiles remains with its domain sources.

The professional boundary remains concrete. A machining path can use the common interaction and provider Methods, but it still needs qualified tooling, changeover, metrology, capability and nonconforming-material Methods. A software path still needs application behavior, security and other specialist results not supplied by this selection. Obtain missing professional results from the relevant practitioners and merge, release, production-acceptance or organization-change decisions from their authorized holders.

SYSE.Reference:5.1 - Improve an agent’s choice and use of support

Part VIII supplies engineering Methods for a person or technical agent whose work can use tools, records, other contributors and procedures. The common question is which complete way to use now and what to change when decisions repeatedly waste effort, miss needed support or fail to use its return. The first use reaches the chosen and used answer 2082. Existing C.38/C.11 retain comparison and choice. Ten Methods have common operations with unlike human and technical realizations; SYSE.45 supplies the particular construction of learned LLM parameters or adapters. Human capability development uses E.23.CDI and HCD, including the bodily Methods when needed.

When the comparison basis is missing, SYSE.46 obtains qualified performance and support contrasts; SYSE.50 constructs a bounded assistance rule from signals available before the decision; SYSE.51 constructs effort and stopping rules with sufficient completion means. A confident answer alone supplies neither need nor expected benefit. SYSE.42, .52 and .47 make the chosen contribution effective by binding the operation, preparing its next input and consuming its actual return.

Keep the changed subject precise. SYSE.43 retains and reorganizes external records; SYSE.44 constructs a division and recombination of contributions; SYSE.48 constructs a reusable operation; SYSE.49 constructs informative tasks and feedback for development. Changing the next input, a durable record, a procedure or model parameters produces different results. A team or device can supply a contribution without becoming part of the same System merely because the workflow uses it.

The development explanation (Engineering.Reference:19.7) compares complete manual, explicit-rule and learning arrangements by stability, recurrence, preparation, qualification failure, runtime support and maintenance. It selects a rule trial under constructed conditions, while a shorter horizon selects manual work. Needed current facts, execution, verification and control remain available at runtime. The prediction, reusable-calculation and bodily cases retain their actual suppliers and mechanisms.

Recognition and construction precede assurance. SYSE.46 compares matched support regimes, result, selection, invocation, use, restraint and total burden. A claim about persistence also needs the relevant delayed and shifted tests with configuration and support identity. A current success establishes none of those wider claims by itself. Enter only a needed construction, stop at an adequate used result, and reopen the affected contribution when its source or conditions change.

SYSE.Reference:5.2 - Construct and change a software delivery and recovery path

Use this connected application when a software change must become a usable service and the existing build, test, environment, deployment and operating arrangements do not yet work together. It governs the means of constructing, changing and recovering that service. These independently usable Methods connect through their results and shared conditions; enter at the missing contribution and retain qualified existing parts. Application acceptance meaning, information meaning, security decisions and release authority still come from their responsible practices. A working path whose relevant conditions are already established can be reused; a small change does not require rebuilding the whole arrangement.

Start at the receiving result and work backward to the first contribution that is missing. A developer may need an identified candidate runtime for a test; an application user needs a correct and timely task result; an operator may need a recoverable deployment after interruption. Those are different results even when one platform helps supply all of them. SYSE.13 identifies the configuration and evidence needed for the decision. SYSE.25–SYSE.29 establish the task to improve, supported interaction, interface obligations, qualified controls and the transition from an older path. They need not prescribe a particular CI product or hosting architecture.

Construct a first complete path around a small useful change. Work backward from the user task to its actual runtime, required information and dependencies, then to the artifact, feedback and build inputs that can produce it. Work forward through the same joins to establish that each result is usable by its consumer. A test result for one package cannot qualify a rebuilt package merely because their source label matches. An environment description cannot supply absent data or expired access. A working installation cannot supply unobserved application behavior. This backward construction and forward exercise finds missing contributions that a list of individually green tools can hide.

On the construction side, use SYSE.30 to recover the build dependency graph and control the inputs needed for the chosen reconstruction claim. Use SYSE.31 to integrate small compatible changes against the current mainline and obtain actionable feedback on the resulting combination. Retain the resulting artifact and connect its own observations to its actual identity through SYSE.32. Choose a faster check or reuse valid evidence when it answers the next question; keep an unresolved slower question visible rather than rebuilding or retesting everything by habit.

Prepare the conditions in which that artifact will be used. SYSE.33 derives environment fidelity from the task and establishes actual resources, information and access. Those contributions must be available together for long enough to complete the task: a short-lived environment that expires while data or permission is still being prepared is not a usable supported path. SYSE.34 constructs the application/data transition by comparing old and new readers, writers, retained state and in-flight work. Choose a compatible expansion, adapter, qualified synchronization or planned interruption from the actual need; establish the return or forward-repair boundary before depending on it.

SYSE.41 makes the artifact/configuration combination real on named targets and tests its bounded use. Its result is an observed runtime, including partial or unknown targets where those remain. The deployment arrangement can separate candidate construction from ordinary exposure when the architecture supports that separation. If starting a worker already consumes live work, construct the exposure protection and obtain its authority before startup. SYSE.35 then supplies a comparison and stopping action for the permitted exposure unit. Wider rollout consumes the evidence and authority for that wider use; it is not a side effect of a green deployment job.

Construct observation and recovery while designing that path, not after all delivery steps are complete. SYSE.36 defines the relevant task outcome, observation and agreed reliability use. SYSE.37 derives actionable alerts from consequential loss and the time available to respond. SYSE.38 follows a failed task through its actual effects, mitigates within a known boundary and distinguishes plausible causes. SYSE.40 keeps admission, waiting, dependency pressure and recovery within a qualified resource envelope. These Methods can change earlier design choices: a candidate that cannot be stopped, an unobservable write or a recovery path starved by test jobs may require a different deployment or interface arrangement.

For a constructed example, ParcelWorks changes a one-field address editor to a first-line/tail form. First make the old and new use compatible through one authoritative stored value and the lossless correspondence in SYSE.34; preserve absence versus an empty tail. Integrate that preparatory change and the form in usable increments. Obtain a retained artifact from the combined mainline and run the relevant transformation, database and browser feedback. Reconstruct a candidate environment with the qualified data and access, then observe the actual artifact and effective configuration under SYSE.41. This establishes a bounded runtime result while the old serving pool remains usable.

Next exercise complete edit attempts in a permitted cohort. General page visits do not qualify the changed form; a successful platform deployment does not qualify the application’s edit result. If the new form hides a non-empty tail, stop the relevant exposure and verify the qualified old path against current data. If the deployment request instead timed out after h2 started with c1, recover that partial target and correct or return it under the known compatibility conditions. Do not create a new operation solely because its predecessor’s response was lost. If build workers were unavailable throughout, the deployed old application can remain reliable while the developer-facing path fails. Each observation reaches its own task, objective and responsible decision.

Adapt the whole by following the changed condition. A scheduled importer needs whole-job exposure and completion observations rather than short request windows. A stateful migration can retain a forward-repair path after exact return becomes impossible. A rare critical task may need a direct failure response rather than a high-volume burn rule. A new expensive test class may require different admission and dependency limits. Reuse build and promotion results whose subjects and conditions survive; repair the specific affected join and exercise the resulting path.

Finally examine the work that the path repeatedly creates. SYSE.39 compares cause removal, simplification, automation and retaining the current method across user effort, provider support, exceptions and maintenance. Faster individual stages or fewer tickets can leave the whole task slower or more expensive. Use observed total burden and user results to choose the next improvement through SYSE.25. This closes a learning loop without turning every delivery attempt into another platform redesign.

The strong professional comparison is the Continuous Delivery deployment pipeline together with the SRE Workbook. These already connect delivery, operational reliability and learning. This application makes their selected technical contributions usable with SYSE’s configuration, obtaining, provider and supported-path Methods. Use those sources for their detailed professional treatments and obtain the implementation practice for the selected technology. The useful result here is a path whose joins, alternatives and change conditions the engineer can construct and explain.

SYSE.Reference:6 - Configuration and evidence travel with continuing change

Engineering identity is decision-relative but not arbitrary. A product-family item, actual unit, installed configuration, software realization, description edition, baseline, variant, state, and effectivity range can differ. SYSE.13 supplies the configuration basis needed by a named decision. SYSE.14 connects a proposed or performed world-side change to that basis, its deciding System, permission, implementation, release, cited evidence, and unresolved conditions.

Evidence supports a stated claim only for the receiving decision and conditions to which that evidence applies. A model, experiment, trial, test, certificate, review, or observation supports only the claims for which it is applicable. SYSE.10 connects research and trial results to engineering claim assessments. Use SYSE.4 to reuse compatible current results, qualify evidence use and revise reliance. Select further challenge Work when its attainable contribution justifies the burden or the selected use requires it. A narrower supported answer or a justified stop may already settle the question. Return the result to the Agent responsible for the earliest answer it could change. Safety, security, legal, ethical, financial, certification, acceptance, permission, and release decisions keep their specialist criteria and authority.

A source change is not automatically a world-side System change. A changed model, standard, requirement, MethodDescription, architecture description, or supplier claim first changes an episteme. SYSE.19 traces the claims and engineering decisions that relied on it and revalidates only the affected uses.

SYSE.Reference:7 - A Method has several structures; Work can be simultaneous

An engineering Method can be described through several non-isomorphic structures. Its constructive composition asks which Methods or method parts make up a larger Method. Its unfolding asks which results and dependencies permit a next move. A Work account asks which Work occurrences overlap, participate in a larger Work whole, or must occur in a real order. A provider or build-the-builder account asks which enabling Systems and capabilities must exist. A cultural account asks how Method variants are generated, transmitted, enacted, recognized, selected, retained, changed, and lost across a practitioner population.

Do not call every vertical list a level stack. A first–then relation normally describes an unfolding or Work order. Simultaneous participation at different holonic or scale positions is different: physical computation, model use, architecture judgement, configuration coordination, and assurance can all contribute during the same bounded engineering Work while remaining different Methods or Work wholes. Use SYSE.20 to recover those overlaps, conflicts, dependencies, and required orders.

SYSE.15 guides development of a decision-usable engineering Method repertoire. A standard, branded framework, model-based recipe, toolchain, or AI workflow is a candidate contribution, not the Method by title. The repertoire records fit, evidence, exclusions, branches, and reopen conditions. SYSE.21 guides a different decision: how an authorized Agent deliberately continues or changes the Systems Engineering culture of a named practitioner population. One team choice or one successful project does not prove transmission, retention, or cultural change. Claims of later enactment and engineering consequences need their appropriate observations. A qualified current account or supported continuation may instead finish on existing evidence; a new study is selected only when its attainable contribution warrants its whole burden. Keep the deciding and affected Systems explicit.

Constituent actions in ongoing work. For example, while a technician acquires a measurement, an engineer may be conducting a requirement-verification trial through that measurement, within an ongoing system-acceptance exercise. Recover the constitutive connection rather than infer it from matching timestamps. If the requirement concerns a short transient, a setting adequate for a steady reading may no longer support verification. Instrument-operation skill and knowledge of the requirement can both be present while the intermediate skill of choosing a suitable acquisition arrangement is missing. Supply that capability or qualified assistance before relying on the trial. The obtained reading is still only a constituent result; it does not by itself authorize acceptance. FPF B.1.5.EW helps recover this vertical; SYSE.20 addresses a consequential conflict in its arrangement.

For a connected application, Connect contributions, concerns and consequences across a whole project (Engineering.Reference:6) follows two module teams, independent acceptance and a shared laboratory into a project that changes the supplying organization. It shows which general engineering questions transfer, which specialist results are needed, and how lost provision, authority or capability changes the next work.

SYSE.Reference:8 - How project Work contributes to engineering culture

A gadget release, a subsystem architecture decision, a platform improvement, or an assurance account is a bounded project result. The Systems Engineering Discipline is a continuing cultural phenomenon: Method variants, terms, examples, tools, criteria, institutions, and practitioner habits are reproduced and changed across many Work occurrences. A project can generate a candidate variant, enact it, produce consequences, and influence selection. Cultural retention requires evidence across that practitioner population.

Most users should stop with the project pattern that resolves their current difficulty. Open SYSE.21 only when the receiving question is deliberately to continue or change a Systems Engineering Method variant across a named practitioner population. Open the FPF cultural-evolution patterns when the claim is transdisciplinary rather than Systems-Engineering-specific.

SYSE.Reference:9 - Architectural Rationale

The common language connects use, architecture, realization and evidence at the engineering decisions that need them together. A proposed System can have an attractive functional organization yet lack a viable builder arrangement; a realized configuration can pass its tests yet fail the receiving use. The repertoire therefore separates independently useful results and states how one result constrains or enables another. Observations from realization or use can reopen an earlier assumption. A project phase plan remains usable when it preserves those returns and the orders required by actual dependencies, physical operations and governing decisions.

FPF distinctions and a curated standards or handbook route are a useful smaller answer when they already supply the needed engineering move. SYSE adds the domain work of constructing linked use and System concepts, complete obtaining arrangements, recursive realization and configuration-bound engineering judgements. Its common layer does not replace the specialist procedure that determines a material, software or regulated result. The shared source account explains the different roles of process scope, engineering practice and professional procedures.

SYSE.21–24 address different questions in continuing engineering. SYSE.21 connects a proposed practice change to the configured results, assurance, support and receiving enactment that it must preserve. When changed use or a new means makes the old problem–solution pair doubtful, SYSE.22 develops the problem and feasible System-family options together. It returns supported correspondences, unresolved conditions and a bounded choice. When the difficulty concerns which target or builder change is worth making for later changes, SYSE.23 compares interventions across that arrangement, including transition, evidence and continuing burden. Its investment choice is a proposal with expected consequences; obtaining the means and observing later Work support different, stronger claims. SYSE.24 constructs ways of obtaining the needed result by changing what is supplied and completing the remaining receiving Work. An unsupported provider condition can return the choice to that construction without invalidating an unaffected technical Method. These Methods can be entered independently. Connecting their results requires compatible configurations, use conditions, horizons, authority and shared resources. SYSE.2 supplies a missing linked use–concept construction, SYSE.3 the realization branch, and SYSE.6 a needed architecture decision. Their numbers do not prescribe the order of Work.

Platform Engineering retains SYSE.12 for the enabling-System question and reuses SYSE.24 for obtaining alternatives and SYSE.18 for independent provider decisions. The supported-interaction, interface-change, control-placement and migration Methods have different first results; putting them all into one large platform Method would make a narrow question harder to answer. The same reason supports direct software bodies for a build, data change, alert or restoration question. Their detail is useful because it changes the operation or evidence, not because each topic needs another title.

Use a developed professional account directly when it already supplies the required technical operation or complete arrangement under the receiving conditions. Continuous Delivery and SRE already explain connected delivery and reliability Methods; SLSA supplies artifact verification. The software profile retains that professional basis. Where a receiving connection remains unresolved, §5.2 develops the whole path through artifact identity, environments, data, provider limits, task observations and release authority, with contributions from SYSE.30–41. When only one result is missing, its direct source or pattern can suffice; performing the complete path would add no necessary result.

Choosing a platform’s architecture requires comparing the available arrangements. Retaining repaired local provision, sharing a bounded contribution, obtaining external provision and adding an interface can each be appropriate. APP-SYSE-05 keeps the repaired local and thin shared arrangements tied after their matched initial trial; developing the shared candidate further does not select it. This preserves a serious alternative to treating shared provision or a portal as the inevitable outcome of Platform Engineering.

The common and software Methods are available together so that a reader can follow these real result dependencies without duplicating the common Methods in every profile. A focused profile can reuse that content while explaining its own changed conditions. Further physical and software profiles need their professional filling: recoverable software state, irreversible material processing and an instrument’s measurement validity require different procedures. A new source or an unlike use that defeats a purportedly common move should change that move’s scope or the affected profile, while the other usable contributions remain available.

SYSE.Reference:10 - Check the combined engineering answer

Recognizing a situation, finding a Method and constructing a candidate answer do not establish that the System is usable or that a change is authorized. The worked applications show how to obtain and limit an answer; their stipulated observations are not evidence about the reader’s own project. Before relying on a combination, ask the following questions about the intended decision.

• Do the contributions concern compatible subjects and uses? Recover the project System and the relevant configuration, variant, interval and operating conditions through the existing answers for SYSE.1, SYSE.13 and the patterns being used. Resolve any interpretation difference that changes whether the results can be used together.
• Is each needed result available at the strength the decision requires? A usable MethodDescription tells the practitioner how to obtain a result. A supplied observation, model conclusion or permission must have its own applicable basis. Use SYSE.9 for a missing professional contribution; keep independent work moving.
• Can the required contributions hold together for this undertaking? Reconcile interfaces, shared resources, permissions, retained state and the receiving deadline. Over the same receiving horizon, count all work using the same constrained capacity, including support, rework and changeover; distinguish independent resources. Compatible pairs do not by themselves establish that the complete arrangement can produce the required result.
• Whose result improves, and who bears the remaining burden or consequence? At whole-SYSE scope, use SYSE.16 and SYSE.17 for the relevant surrounding and affected Systems. At Platform scope, include failed, abandoned and unsupported practitioner attempts in SYSE.25’s task evidence. In the software profile, SYSE.36 keeps platform and application users, task success and missing observations separate.
• What action does the evidence and authority permit now? Reuse the applicable SYSE.4 and SYSE.10 evidence judgements and retain SYSE.14’s release boundary. Software artifact verification, actual runtime deployment, compatible data recovery and wider exposure need the distinct results in SYSE.32, SYSE.41, SYSE.34 and SYSE.35 when that action depends on them. A physical path instead needs its actual process, measurement, material disposition and production-acceptance results.

The whole-arrangement condition is visible in APP-SYSE-06. Its nominal 143 machining cycles do not establish delivery of 120 acceptable brackets: measurement, yield, rework, coating and transport still determine the end-to-end result. The supported interface can nevertheless be improved while the production claim remains open. The software application likewise distinguishes a constructed supported path from its unresolved obtaining choice and application-exposure result. Each application returns the particular missing contribution rather than discarding every useful part.

The examples foreground deliberate engineering projects with identifiable decisions and access to relevant observations. A sponsor’s or provider’s account may omit a future operator, an infrequent user or a System bearing harm. Missing access limits the conclusion; it does not make the omitted consequence harmless. Software-practice sources also give stronger detail for software work than for physical production. Retain that difference when using a common Platform Method in another domain.

These questions are inherited by the common Platform language and the software profile. Reuse a sufficient answer when its subject, conditions and receiving use still match; examine the profile-specific difference when they do not. Use the affected pattern’s reopen condition when a project condition changes. When a relied-on source changes, use SYSE.19 to find the dependent conclusions. The practical gain is a usable engineering answer with a bounded next move. The cost is the work of reconciling contributions and obtaining the missing evidence; an isolated direct result should not acquire that cost unless its receiving use needs the combination.

SYSE.Reference:11 - Scope and specialist boundaries

The framework groups its common-engineering patterns in five connected problem families (Parts I–V): project focus, use, and joint problem/System-family development; architecture and professional contributions; obtaining engineering results, recursive realization, engineering platforms, independent constituents, and evolvability across the project system-of-interest and builder arrangement; configuration and continuing change; and assurance, Method-and-Work architecture, repertoire, and cultural continuation. Part VI adds the common supported-use and continuing-change Platform Engineering Methods. Part VII adds the selected Software Platform Engineering Methods. Part VIII supplies eleven Methods for engineering agent work and support: ten common operations with human and technical realizations, and the bounded LLM-learning construction in SYSE.45. The Readme starts with current choice and use; Architectural Reference §5.1 connects that use to diagnosis and development when needed.

The 53 pattern bodies provide the authoritative descriptions of engineering Methods, cases, checks, source uses, and relations. The Readme provides selected entries. This Architectural Reference explains the distinctions that make the entries cohere. Two navigation walkthroughs show result dependencies. Four worked applications demonstrate joint use in software, cyber-physical equipment and manufacturing, including filled values, reopen conditions, inconclusive results and missing professional Methods, without defining a lifecycle. The framework leaves the remaining specialist application-profile Methods, a full history of Systems Engineering, curricula for developing human capability, organization design, general operations management, corporate governance, finance, law, safety, security, ethics, and detailed domain standards to their own patterns, DPFs, or sources. Return there when those results change the engineering decision. The boundary prevents common language and a bounded software repertoire from replacing a specialist answer with a vague analogy.

SYSE.Reference:12 - Intended use and non-use boundary

Use this framework for recurring common Systems Engineering difficulties that materially change decisions about an engineered System, its use and operational environment, problem formulations and System-family options, architecture, realization, enabling platform, configuration, evidence, evolvability, continuing change, or engineering Method. It also supplies the common Platform Engineering Methods in Part VI and the selected service-software platform Methods in Part VII and agent work and support Methods in Part VIII. It is intended for engineers, engineering managers, architects, technical leads, specialist contributors, and assisting agents able to use the required FPF distinctions and domain evidence.

Do not use this framework as a complete application profile or a substitute for specialist decisions. The software selection covers the build-and-delivery and reliability questions named in its pattern bodies, not all application algorithms, software architecture, compiler construction, distributed-data mechanisms or software engineering. It does not supply cryptographic design, security threat models, privacy decisions or security-incident authority merely by providing artifact, deployment or technical-recovery Methods.

Manufacturing still needs operative process/tooling and changeover design, measurement-system qualification and uncertainty, sustained capability, acceptable-part delivery capacity and nonconforming-material recovery. Other physical and regulated profiles likewise retain their professional Methods. Electrical design rules, naval architecture, structural calculations, medical regulation, safety cases, legal or financial decisions, certification and organization change remain outside this selection.

Further profiles can retain the common use, configuration, provider and evidence answers while requiring different professional results. Robotics needs the relevant simulation-to-real, calibration, operating-envelope, physical recovery and fleet-maintenance Methods. Laboratories need instrument and Method qualification, sample identity and handling, uncertainty, contamination control and scientific-validity judgements. Administrative enabling paths need the actual finance, personnel or procurement procedures, access and authority conditions. These are remaining professional obligations, not additional Methods supplied by a common platform description.

The selected software repertoire also leaves deeper mobile and embedded toolchains, foundation-model pretraining, distributed storage, identity and secret infrastructure, comprehensive security design and further service classes to their own Methods. Part VIII supplies tool use, external memory, work division, qualified experience, procedure and operator construction, assistance decisions, adaptive effort and working-material preparation. Its human and technical realizations keep their own mechanisms; SYSE.45 supplies bounded LLM policy learning. It does not supply every human-acquisition, ML-evaluation, robotics-control or task-domain Method. A narrower profile may reuse appropriate existing bodies and add a warranted difference; this framework sets no fixed final depth for such useful specialization. For each missing result, recover the relevant practitioner, qualified Method and deciding authority. An omission blocks only the dependent claim or action, not every independent engineering move.

SYSE.Reference:13 - PatternID discipline

SYSE.* provides addresses for the authoritative pattern bodies in this Systems Engineering Principles Framework. The eight Parts and four ordinary worked connections group patterns for reading. These groups do not establish semantic parentage, Method composition, or project order.

SYSE.Reference:14 - Source use and epistemic status

Each pattern carries its own source-use decisions, adopted payload, rejected shortcuts, evidence limits, and reopen conditions. Standards, textbooks, academic attention, vendor claims, institutional promotion, and press coverage can identify candidate Methods or terminology. They do not by themselves show actual project use, causal effectiveness, widespread retention, or state of the art. When direct prevalence evidence is unavailable, label the value as an expert estimate and state its uncertainty.

SYSE.Reference:15 - Shared engineering sources and architectural choices

The working synthesis combines common engineering reasoning with procedures that produce a particular professional result. These sources shape several patterns together, while their evidence limits determine what can be inherited by a profile.

ISO/IEC/IEEE 15288:2023 supplies process scope that includes acquisition and supply within or outside an organization. The historical NASA Systems Engineering Handbook, Rev 2 (2016) distinguishes realization through purchase, making, coding and reuse, together with enabling products, integration and verification. The synthesis retains those connected questions but makes the needed result, rather than a process-list position, select the next Method. SYSE.24’s source comparison explains why the complete obtaining arrangement is compared, including internal work, provider contributions and continuing burden. Neither a standard’s process scope nor NASA’s programme setting settles a local supplier, contract or release decision.

SYSE.12’s source comparison relates task-oriented software-platform practice and qualified software-work evidence to manufacturing arrangements with different participants, physical means and information-use conditions. It qualifies their contribution to the named practitioner Work; professional operations and their qualification remain profile-specific.

DORA and CNCF’s platform lines, detailed below, provide a direct task-and-product treatment of internal software provision, including composition over existing capability providers. SYSE.12 adopts that answer where it fits and compares it with retaining competent local provision. For mixed physical and software Work, its authored synthesis adds the capability, provider and evidence qualifications needed by the relying decision, accepting their maintenance cost. The pump case compares that cost with repeated manual reconciliation; its observed user saving leaves total burden open. The software profile then combines locally described build, environment, data, deployment and observation Methods with exact source procedures where appropriate. SLSA’s procedure addresses consumer verification under a configured trust basis; artifact verification does not establish application correctness. Runtime deployment must be performed and observed, and release needs its authorized decision. The source table keeps these contributions and limits visible; one branded practice or toolchain does not supply the whole supported use.

The historical SRE lines remain useful for the particular operating distinctions and conditions retained here. Implementation documentation can expose a missing outcome, such as an inconclusive exposure result, or constrain an alert’s lookback; its recency does not validate every historical recommendation. Use each source at the scope stated below and in the receiving body. Reopen a shared choice when a better-supported alternative changes the working move, or when an unlike application defeats the assumption being carried across profiles.

SYSE.Reference:16 - Dependence on FPF and neighbouring products

FPF remains the source for transdisciplinary ontology, holons and Systems, Method and Work distinctions, architecture, evidence, assurance, decisions, cultural evolution, precision restoration, pattern form, and DPF publication form. This framework specializes those moves for common Systems Engineering and its selected service-software platform and agent work and support branches. A relied-on FPF result remains external to this DPF.

External application-profile frameworks and direct specialist sources keep their own product boundaries; the selected Methods in Parts VII–VIII do not import their entire repertoires. Another DPF may use a named Systems Engineering result only when the subject, conditions, edition or current state, receiving use, and availability fit. Co-listing in a collection or Guide does not establish dependency, compatibility, currentness, or authority.

For the organizational gap in SYSE.27, open the Organization Change Engineering Principles Framework (OCE): OCE.4 - Design an Organization’s Contribution Architecture for a contribution-architecture decision, or OCE.6 - Establish Holder Assignments and Enabling Relations for Organization Change for obtaining actual holder assignments and separately effective enabling relations. OCE.4 needs a compatible focus, current account and organization-concept comparison or equivalent content. OCE.6 needs the actual authority and applicable relation predicates; naming an owner does not supply them.

For the shared operating account needed by SYSE.38, open the Operations Management Principles Framework (OPS): OPS.3 - Distinguish Operating Subjects, Cases, Queues, Resources, and Records to obtain the bounded subject/account distinctions, and OPS.4 - Keep Current Operating State Recoverable Across Participants for a participant-usable current account with evidence, uncertainty, permissions and next decisions. A record or shared display does not establish the underlying subject or the truth of its visible state.

For the resource comparison in SYSE.15, use OPS.11.1 to construct the relevant operating account, reconcile shared resources and existing assignments, and compare allocation alternatives. This can change the use of bench time without redesigning who may request, promise or accept the work.

Use equivalent current local content when it already suffices; no repeated application of a neighbouring pattern is then required. Before relying on either return, check the supplying source’s availability and current governing claim, the receiving subject and conditions, and the actual assignment/authority or state evidence needed now. Reopen only the affected return when these change; a missing result stops its dependent use. These source texts and the organizational or operating results remain external to SYSE: availability of a pattern is neither an obtained local assignment nor an established current operating account.

For Part VIII, MMP.8.SD supplies an action-conditioned decision model, MMP.17 a qualified approximation when needed, and CMP.7 learner construction. The engineer recovers candidate reusable operations; F.0.2.MA reconciles or allocates already recovered contributions, while A.3.1.MV and A.15.8.MS retain semantic repertoire and usable discovery. HCD, SOM and RHY retain human practice, learning, observation and timed bodily coordination; an LLM-generated account supplies no bodily response. C.38/C.11 retain complete-way comparison and choice. The Reference (Engineering.Reference:19) gives direct access and worked returns for these separate contributions.

SYSE.Reference:17 - Edition scope and refresh

This publication contains the 53 SYSE.* pattern bodies indexed across eight reading Parts, the Readme, this Architectural Reference, two navigation walkthroughs, four worked cross-pattern applications, and the Sources and Edition Notes with their professional source coverage. Boundary and refresh explanations belong to this Architectural Reference. The bodies remain the authority for working moves; the Readme, Architectural Reference, ToC, and applications help readers find and combine them. For an engineer using this language, a changed premise can affect reliance in several ways:

• An FPF dependency that changes a kind, relation, evidence, architecture, Method, Work, culture, or publication rule used by a pattern puts in question the pattern’s use of that distinction or rule.
• A direct source that changes a load-bearing engineering claim or exposes a better current Method puts in question the affected claim or the reason for using the current Method.
• A project case that shows a pattern’s first result, stop, authority boundary, or specialist return is wrong puts that particular guidance in question.
• Repeated use showing that two patterns duplicate the same move or that one recurring Systems Engineering problem family remains uncovered puts the repertoire’s useful division or coverage in question.
• An application profile showing a common specialization that changes the cross-profile working move puts the shared move and its applicability in question.
• A publication that no longer preserves the pattern bodies, first entries, cross-pattern use, source return, or framework boundary for its intended readers no longer supplies those affected instructions or limits adequately.

For a current engineering use, reconsider the smallest affected claim, move, result, or receiving relation. Contributions whose conditions still hold remain usable.

When the required work is revision of the SYSE framework, its author uses FPF E.4.DPF for framework construction and publication, and FPF E.19 for the affected review and refresh. The author first refreshes the smallest affected unit. The framework architecture is reopened only when evidence changes the promised field, selected problem families, pattern split, material result relations, publication form, or maintenance boundary.

For source qualifications, citation and edition information, see the Sources and Edition Notes.

SYSE.Reference:End

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

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

Status: Stable

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. An individual can use this provisional choice to ask the next use-and-system concept question. Before coordinated Work relies on a common focus, compare the participants’ intended referents and how their contributions connect, as in §4.4.1. Expand the account only when disagreement, a valuable alternative, or a later answer can change its use.

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 defensible provisional choice and, when participants have established the needed common understanding, a shared focus for the current coordination. Evidence from use, architecture, realization, operation, or a participant’s different understanding can reopen the claim on which that coordination relies.

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 under the actual-System and intended-referent conditions in §4.2. Use its direct-subject exit when a System designation is unnecessary.

Examples include a product or tool System, an engineering platform, an operating or provider System, a containing or organization System, and intended counterparts. 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.4.1 - Establish enough common focus for the current coordination

When the next decision relies on several contributors working on the same project System, compare their understanding through one concrete use or change. Include the people whose contributions, receiving use, or limits can change that decision. Existing compatible exchanges may already supply the answer.

Ask each contributor to point to the actual System or intended referent they mean, explain what matters to them in the project, and trace how their contribution would help change or use that referent. Follow a contribution across its next dependency: have the person relying on it explain what they expect to receive and how it supports the proposed use. A short conversation, annotated example, or asynchronous exchange can expose the connection; no particular meeting or form is required.

For example, “install the planning software” and “produce a feasible production plan” may initially share a project name. Following one changed order reveals whether installation, current stock information, capacity decisions, and the planner’s use actually connect. Compare the decision-changing differences under §4.3. Distinguish different accounts of one proposed project from legitimate separate projects that must exchange contributions.

Resolve a material mismatch through the project’s actual decision authority and the contributions available. Explain the selected referent and the reason for selecting it; then ask the affected contributors to apply that choice to the same example. The current coordination has enough common focus when those relying on it can identify the selected referent, connect the contributions on which their next action depends, and state the unresolved condition that limits that action. They may retain different interests and preferred alternatives. Common understanding supplies neither permission to act nor a commitment to perform Work; obtain those when the next action requires them.

If the participants still mean different referents or cannot connect a needed contribution, preserve the individual choice as provisional and hold the joint claim that depends on the unresolved connection. Name the difference and the answer needed to resolve it. Independently supported work can continue. If the apparent disagreement instead comes from separate projects, keep their designations and coordinate the receiving result between them; use SYSE.8 for a provider-use arrangement or SYSE.9 for a specialist contribution when that question is current.

Keep the choice account aligned with this result: provisional individual choice, sufficient common focus for a named decision, unresolved mismatch, or coordination between distinct projects. The account makes the result recoverable; writing it does not produce agreement or establish that an intended System already exists.

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.

An observed mismatch between contributors reopens the common-focus claim in §4.4.1 even when the individual choice remains defensible. Repeat only the exchange affected by that mismatch; reconsider the designation if its reason or boundary has changed.

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 the project-system designation 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. Its engineering lead compares the software product, the planning organization, an intended deployed planning System, and the wider production-control System. She provisionally selects the deployed planning System because the project is meant to improve production-planning use, with data quality as the main assumption. That choice is enough for her first concept question.

Before assigning joint work, she asks the contributors to follow one order moved to an earlier date. The IT lead means the installed ERP runtime by “our system”; his contribution is software installation and data interfaces. The production planner means an arrangement that produces feasible commitments; she needs current stock and capacity information and a way to resolve conflicts. The stock controller expects the existing overnight update to remain sufficient. The vendor means its software product and wants to preserve a supportable standard configuration.

Tracing the intended contributions exposes a mismatch. IT can deliver the interface and the vendor can supply rescheduling, but the planner would receive a new schedule based on stock information that predates the moved order. No contribution yet supplies the missing current information. Recording the lead’s choice again would leave the same joint plan unsupported.

In this worked case, the manufacturer’s authorized project owner retains the intended deployed planning System as the focus. The stock controller and planner agree to investigate current-information and confirmation arrangements; IT identifies what each would require from the software interface. Each explains how that contribution would support the moved-order decision, and the planner identifies what she would still need before treating a proposed schedule as a production commitment. The common next decision is now to compare those arrangements in SYSE.2. Software installation alone is no longer their completion claim. This establishes enough common focus for that investigation, while feasibility, implementation permission and the eventual production benefit remain to be established.

If the stock-information contribution cannot be obtained or participants still disagree about the proposed referent, the shared planning-change claim remains open. The lead’s provisional designation and independently supported interface investigation can remain useful; the missing contribution prevents reliance on the joint change. If the manufacturer authorizes only a software deployment project, that is a different bounded designation whose completion cannot establish the planning benefit.

The vendor’s product project continues to select the ERP software product. The parties coordinate its contribution to the manufacturer’s use without merging their projects or requiring identical interests. “Software is always the project system-of-interest” and “software is never the project system-of-interest” would both erase this distinction. Their respective choice accounts retain the shared software, different referents and receiving use.

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 defensible provisional focus and a way to establish how far contributors can rely on it together. An unresolved mismatch becomes a bounded coordination question. Related projects can share resources and evidence while retaining their own designations. Architecture and realization discoveries can change the project focus without being treated as late exceptions.

The cost is visible uncertainty and, for a shared claim, the work of comparing participants’ understanding. Several candidates may remain open, and changed assumptions require a return. Spend that effort where an unresolved difference could redirect architecture or realization; a compatible existing result needs no repeated elicitation.

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

The practice question is how to establish a defensible, shared and revisable project focus for the next engineering decision. The selected answer combines explicit framing and valuable alternatives with the contribution comparison in §4.4.1. The following research lines support parts of that synthesis; they do not establish its comparative effectiveness as a whole. Exact work titles, primary identifiers and evidence limits are in the public project-focus research sources.

The serious practice alternative is the NASA handbook’s Stakeholder Expectations Definition. Its iterative treatment uses operating scenarios to refine expectations, develop mutual understanding and obtain commitments. Those operations are useful here; its broader programme baseline is not required for every provisional choice.

Compare both ways on the ERP case at the same effort: the same contributors examine one moved order and its receiving use. A bounded expectations-and-scenario discussion can expose the stale-information gap. The §4.4.1 contribution comparison can expose it too. SYSE makes the designation question explicit alongside that discovery: does the decision need a System designation, which actual System or intended referent is selected, and which contributions belong to separate projects? Its direct-subject exit remains available in §4.2.

For this next concept decision, the selected result is a revisable focus and the unresolved connection. It deliberately leaves a complete expectations set and broader commitments unprovided. When the receiving decision needs those results, obtain them through the expectations treatment. When an existing scenario exchange already establishes the needed focus and connections, reuse it. The small account saves no participant work that is actually necessary, and the comparison establishes no general time or outcome advantage.

Reopen this methodological choice when contributors can repeat the designation but apply incompatible contribution paths, or when a bounded scenario or facilitated framing treatment resolves the same mismatch with less reconstruction. Repair the failed connection or use the better-suited treatment. Reconsider the retained research contribution when its evidence or transfer conditions no longer support the receiving use; keep the affected project’s assumptions and return in view.

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

Status: Stable

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

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.

Reuse an adequate existing account or direct relation result for the same decision and conditions. Use the bounded recovery below when a missing connection prevents that answer. If the operating situations themselves need development or agreement, use a suitable scenario or concept-of-operations Method; obtain any missing specialist result from its domain before relying on it.

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 steps explain the Method. Determine Work order from the actual dependencies. Observation, concept development, architecture development and trials can overlap and recur while outside Systems change.

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, sensors and controller cabinet are physical bearers. The account also identifies the hydronic connections, proposed controller interface and signal channel. Required clearance around the cabinet is a spatial condition on its location and maintenance access. Establish the part and connection relations independently of 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.
• 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.

For the cabinet-location choice, the next result is confirmation of the required and available clearance under the installation and access conditions. If those conditions already determine the required clearance, the team can answer that spatial question directly. If occupant and grid-control behaviour leave the operating situation unsettled, develop the relevant scenarios before relying on that use.

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 the selected structures, conditions and their correspondence. A bounded account accepts incomplete coverage of other uses; broaden the work when an omitted situation can change the decision.

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

Working question: Which Method should an engineer use when different relations hidden inside an “environment” label prevent one use decision?

The selected answer depends on what is missing. Use an adequate existing account or the direct relation Method when it settles the question. Use this bounded recovery when the needed result depends on connecting several Systems, relations and conditions. A developed concept-of-operations (ConOps) Method is an alternative when operational situations or agreement about intended use still need to be constructed. It develops and challenges scenarios; identifying a few relations cannot supply that broader result.

The bounded connection accepts limited coverage in exchange for concentrating the account on one decision. It still needs the applicable evidence and specialist contributions. Section :4 makes this choice at entry; steps 1–6 recover the missing connections, and steps 7–8 return changed conditions to the affected decision. The thin :4.2 result is sufficient only within that use. In :5, cabinet location returns a spatial-evidence question, whereas unsettled occupant/grid behaviour returns scenario development. An adequate earlier answer can be reused in either branch.

Reopen the Method choice when a sufficient account becomes available, an omitted condition defeats the receiving use, the question expands to other scenarios, or a supported alternative offers a preferable combination of coverage and effort. Retain qualified evidence for unaffected claims while revising the dependent conclusions.

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

Status: Stable

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 bearers of consequences. Their states or decision-relevant characteristics could change through Work or events such as realization, operation, maintenance, misuse, failure, recovery, retirement, or later modification. Retain existing bearers even when their identities are only partly known. Qualify not-yet-present bearers as intended System referents in modal claims.

Begin with one proposed engineering alternative or change and the decision that can still alter it. If an existing account already covers the material consequences at the needed scope and evidence strength, use that answer. Otherwise 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. When the missing result is a person’s preference, an agreement, or an account of how a proposed operation would work, use a corresponding elicitation or scenario result, or return that missing input to the decision. Tracing consequences alone cannot supply it.

The first useful result is a bounded engineering consequence account. It identifies material consequence bearers as far as the evidence permits, preserves unresolved identity or existence questions, qualifies each consequence, 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 when the claim relies on treating a bearer as one System—for example, when attributing a consequence to a population as a whole. Candidate bearers include people, organizations, technical Systems, and ecological Systems. Preserve evidence of an actual bearer even when its name or full boundary is unknown. Use an intended System referent for a not-yet-present bearer, and state uncertainty explicitly when existence itself is unestablished. 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. First compare the available account with the receiving decision: does it cover the material bearers, consequences, conditions, and evidence needed now? Reuse a sufficient answer. If a missing consequence or bearer could change the choice, perform the bounded discovery below. If the choice instead needs preferences, agreement, or developed operating situations, use an available elicitation or scenario result, or assess its acquisition under step 8. Return a needed but unavailable result as an explicit gap.

Retain consequence claims that change or hold open the named engineering decision, and state what supports each. This bounded account can support a choice with explicit uncertainty; it does not promise complete preferences, representation, or operational scenarios.

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. Identify the bearer to the extent needed by the claim. Keep an observed participant actual even if its name or full identity is unknown; refer to the observation, place, and time that support the claim. Keep a not-yet-present bearer as an intended System referent in a modal claim. If existence itself is uncertain, retain that uncertainty. Test System identity and boundary when the consequence claim depends on that classification, especially for a collection treated as one whole. A role label or representative cannot supply that evidence. Return any unresolved recognition question that matters to the decision.
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. Reopen the account when a new bearer, changed configuration or use, conflicting value claim, failed premise, or required missing authority could change the decision. If discovery reveals that the operating situation or affected people’s requirements are insufficiently understood, reconsider broader elicitation or scenario work against that missing result and its attainable contribution.

Discovery, design, trial, specialist inquiry, and consequence observation can overlap and reopen one another. A receiving decision still needs the claims and evidence on which it relies. An observed encounter can support an account before personal identities are known; a claimed future consequence remains conditional on its path and conditions. Select any further inquiry separately from identifying that possible consequence.

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 consequence bearers, retaining supported occurrences even when identities remain partly unknown. They distinguish obtaining relations from modal path claims and feed uncertain but material consequences back into decisions while change remains affordable.

SYSE.17:5 - Worked Cases

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

Each row links a possible or observed change to a named System and supports only the stated consequence and decision contribution. Ground any authority or representation used later with separate evidence. The team can make a bounded architecture choice using these qualified contributions while keeping measurement gaps explicit. For example, suppose a plant-room measurement and competent safety interpretation are available before layout freeze; their combined result could rule out an unsafe irreversible placement at a burden justified by that gain. Select that acquisition. An unavailable seasonal noise study is a different proposal: retain the low-noise alternative and the conditional noise claim without making the study a condition of this narrower return. The resulting account grants neither release permission nor evidence of an observed improvement.

SYSE.17:5.2 - Observed Pedestrians and a Not-Yet-Installed Locker

A team must decide tomorrow whether to fix the geometry of an east-side delivery-cart route across an existing public footpath. Its participant list names the operator, supplier, and customer. Video shows people crossing between 07:30 and 08:00, but their names are unknown. A maintenance log records a van using the loading bay at 07:45. The proposed locker has not been built or installed, and the carts have not operated there. A simulation predicts short cart queues near the proposed locker; a west-side route is only a sketch.

The people and van were actual participants in the recorded events. Their presence identifies a footpath and access use that the engineering decision must retain, without requiring personal names. Possible obstruction or delay from future carts remains a modal consequence. For the not-yet-built locker, retain an intended System referent: a claim that queues could impede its replenishment depends on its eventual position and operation. Neither the observations nor the simulation establish that future interaction as an obtaining relation. No claim here depends on recognizing the pedestrians as one collective System.

The account now connects two missing consequences to the layout decision: preserve pedestrian and maintenance access, and examine the proposed replenishment access. It returns the observations, the conditional queue claim, and the unresolved geometry. These inputs do not yet rank the east and west alternatives or establish physical clearance. The team can compare a layout that preserves room for later access correction, if feasible, with deferring the irreversible geometry choice; operating approval remains a separate decision.

Suppose the only qualified engineer has 45 minutes before the decision. A proposed 30-minute geometry walkthrough is attainable only if access, preparation, and interpretation also fit that window. If entry requires a 70-minute induction, withdraw that proposal and return the qualified account already available. A larger inquiry is warranted only for a result the receiving decision needs: for example, elicitation if footpath-priority requirements remain unsettled, or scenario development if replenishment and crossing arrangements are not yet defined. Those results may expose further bearers and revise the layout alternatives; they do not replace the missing physical-clearance evidence. If an existing qualified geometry and access account already settles the narrow choice, use it directly.

When the full pattern is unnecessary. If the available account already answers the decision at its required scope and strength, return that answer. If one identified causal claim about one already identified System is the whole question, use C.28 and the direct subject pattern.

SYSE.17:6 - Bias Annotation

Trace consequences from proposed engineering alternatives and changes rather than institutional visibility. Quiet or unidentified people can bear consequences. Preserve their supported involvement without inventing preferences, representatives, or agreement.

Use affordable evidence. A bounded expert estimate, simulation, or modal path claim can justify a reversible probe; an observed-effect claim needs observation. Include any actual System or intended System referent whose qualified consequence can change the decision; specialist authority remains with the applicable practice.

SYSE.17:7 - Conformance Checklist

• One proposed alternative or change, its actual System or intended System referent, configuration, use, horizon, and receiving decision are stated.
• Bearers are found by tracing the proposed alternative or change. Observed participants remain actual when personal identity is unknown; not-yet-present bearers remain intended referents in modal claims.
• Unknown identity, boundary, or existence is explicit where it matters. System recognition is performed when the consequence claim relies on that classification.
• Supported obtaining relation occurrences remain distinct from modal consequence-path claims and missing-relation blockers.
• Every affected-System claim states the qualified consequence and bearer; every further relation used by the decision is grounded separately.
• Every material claim states bearer, changed characteristic or condition, configuration, time, evidence, uncertainty, and causal status.
• Every value-qualified consequence names its bearer and value frame, and any conflict remains explicit.
• Each retained consequence changes or holds open an engineering choice through a named decision contribution.
• The account retains the residual uncertainty and reopen condition needed by its recipient. Further inquiry is selected for attainable value against its whole burden, including the combined programme; no action or omission record is required merely because a gap remains.

SYSE.17:8 - Common Failures and Repairs

These recurring failures hide a bearer, relation, claim status, or decision contribution:

SYSE.17:9 - Consequences

Engineering decisions become harder to optimize for visible participants while exporting consequences elsewhere. Quiet and future bearers enter through qualified consequence claims. Those claims can change the decision through, for example, a probe, safeguard, specialist result, monitoring condition, or unresolved decision need.

The cost is additional inquiry and maintenance of uncertain claims. Every retained bearer or modal path claim must change a decision, evidence need, probe, or reopen condition so the account does not grow without bound.

SYSE.17:10 - Rationale

A.1.CSD supplies the transdisciplinary discovery action. Systems Engineering adds a recurring subject-specific move: start from a proposed System, configuration, or use change, examine physical and operational consequences, and connect qualified claims to the engineering decision that can still change the choice.

Questions that need specialist authority remain with the applicable practice.

SYSE.17:11 - SoTA and Source Use

The practice question is how much consequence discovery an engineering choice needs when the visible participant list may omit those who bear its effects. Three approaches answer different missing questions:

NASA’s Stakeholder Expectations Definition, especially §§4.1.1.2.1–4.1.1.2.4, connects stakeholder identification and elicitation with expectations, agreement, and nominal and off-nominal operational scenarios. Adopt its attention to affected participants and operating situations. Adapt that broader practice to the present question: stop with a sufficient bounded answer when it settles the engineering use, and request elicitation or scenario development when that is the missing result. Consequence tracing cannot establish someone’s preference or agreement.

A.1.CSD supplies the discovery and claim distinctions: actual occurrences, intended future referents, and unresolved recognition questions remain separate from modal consequences. This pattern adapts that move to configuration choices and physical and operational situations. A.15.9 and C.11.DUA govern acquiring further results: compare attainable decision contributions with the complete burden, including competing use of the same people and decision window.

The research contributions qualify how the account is used. Volden and Welde distinguish delivery performance from outcomes and wider effects, with context-dependent indicators and valuations. Carry relevant valuation differences into step 6 before any aggregation selected for the decision. Williams et al. examine changing interpretations and continuing benefits in three public projects; use that contribution to reconsider beneficiaries and consequences when use changes, without assuming the same evolution in every project. Thabit, Sancino, and Mora synthesize public-administration work on representation and benefit distribution. Preserve those as distinct questions in step 6 and in any later authority claim; that review does not supply a complete engineering-harm discovery method.

Apply the comparison at entry and when deciding whether to continue discovery: a sufficient direct account can finish the use, a material bearer gap opens bounded discovery, and an unsettled operating situation can require broader work. In the cart case, the observations already restore omitted access uses; the unavailable walkthrough supplies no further result. Reopen only the affected claims when a new bearer, changed use, conflicting concern, required authority, or failed premise changes what the decision needs.

SYSE.17:12 - Relations

• A.1.CSD supplies the general discovery move and bounded consequence account. This pattern adds engineering alternatives, configuration, physical and operational situations, decision contributions, and specialist interfaces.
• SYSE.1 supplies the System and candidate boundary; SYSE.16 supplies use structures, other Systems, conditions, and unsupported assumptions. Equivalent qualified direct sources can be used without implying a temporal order.
• A.1, A.14, B.1, B.1.2, and C.13 govern Systems, wholes, collections, delimitation, crossings, and constructive facts. Treat a scale word only as a cue until those objects and relations are grounded.
• C.28 qualifies a causal-use claim. The Agent performing consequence-discovery Work applies this pattern to identify the Systems that may bear consequences and supplies the resulting account to the receiving engineering decision.
• D.1–D.5 govern value frames, actual conflicts, mediation, and audits when those questions arise. An affected-System claim states the qualified consequence and bearer.
• A compatible consequence account can inform SYSE.2, SYSE.8, SYSE.4, SYSE.6, SYSE.10, SYSE.14, and specialist practices. Each receiver rechecks focus, configuration, use, horizon, evidence, and authority.
• Application profiles retain their own consequence-discovery Methods—for example, safety, security, medical, ecological, legal, economic, software, electrical, building, or transport specializations.

SYSE.17:End

SYSE.2 - Develop Linked Use and System Concepts

Status: Stable

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 the concept for the selected subject. Evidence about use can change that concept, 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 the concept for the selected 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. An individual can explore a linked proposal from a provisional focus. When its use depends on joint action, use SYSE.1:4.4.1 to establish the common referent and contribution connections for that action, or retain the unresolved coordination condition. 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.

When an available construction starts the inquiry, ask who could use it, in what situation, and for what outside effect. Follow one consequential behaviour path from the triggering change through the participating Systems to that effect. Try the condition most likely to defeat the proposal. Use the resulting success or failure to revise the functioning, bearer, interface or use claim that made the difference. Expand the path only when another condition could change the concept; no complete scenario set is needed for the first link.

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. Reuse an adequate scenario or use-case slice as the proposal: retain its compatible use and concept claims and add only the missing relation, consequence or uncertainty needed for this decision. The progressive-slice comparison in §11 helps choose when to continue toward implemented, tested behaviour.

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

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

SYSE.2:5.2 - Manufacturer’s ERP-enabled planning change

An available construction starts this concept question: deployed ERP-Runtime-E3 offers automatic rescheduling when an order date changes. The manufacturer considers using that facility to revise production commitments. Its usefulness depends on what the planners would receive and could act on.

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 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 common-focus exchange in SYSE.1:5.2 has made the missing stock-information contribution visible.

The first linked proposal lets the software reschedule a moved order and release the revised production commitment. Its use claim is that the planners could promise the earlier date from the resulting plan; its main assumption is that the runtime’s material and capacity information supports that commitment.

Follow the proposed behaviour. When an order needs six units, ten are recorded and actually available, and the needed capacity is available, the proposed schedule has support for those constraints. Now try a failure path: the imported record still shows ten unreserved units, but eight have since been allocated elsewhere. The moved order needs six, while only two remain unreserved. A successful date recalculation leaves the proposed commitment unsupported. It has exposed a stale-input failure, without establishing that rescheduling itself is useless.

Revise the linked concept. Required functioning becomes proposing a schedule, obtaining current material and capacity confirmation and any needed reservation, and holding commitment when that support is missing. One proposed allocation gives ERP-Runtime-E3 schedule proposal and an explicit unconfirmed state; Planner-A obtains the needed confirmation and reservations, and Planner-B makes the commitment decision under the applicable authority. This changes the bearer proposal from software alone to a coordinated use of the runtime and people. Their proposed organization still has to satisfy the System criterion for PlanningSystem-P1; a list of participants and records does not establish that composite.

The resulting C.32 question is which arrangement can support that functioning before the required commitment time. Use SYSE.5 to develop and compare event-fed information with reservation interfaces against provisional software plans with human confirmation and a hold on unsupported commitments. Compare latency, available contributions and the burden of exceptions as well as normal use. The concept now gives that comparison a specific function, possible bearers, failure path and uncertainty; it does not select a finished architecture.

If confirmation cannot arrive in time, return to the timing claim or proposed allocation. If the required stock-control contribution or authority cannot be obtained, hold the commitment relying on it and use the smallest affected concept or focus return. Reopen SYSE.1’s designation only when the failure changes the project’s selected referent or boundary.

The vendor’s product project can still 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.

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

The practice question is how much use description is needed to change the concept or expose the next architecture question. The selected approach develops a small linked proposal with progressive behavioural detail. Existing scenarios and slices can supply that content directly.

A serious alternative is a progressive use-case slice following the Use-Case 3.0 guide. It starts with a user goal and can grow from a sketch through selected normal and failure paths toward a testable increment. It need not enumerate all scenarios before useful work starts.

Compare the two on the same moved-order facts in §5.2, including the stale stock record. A small slice for rescheduling an order can already reveal the unsupported commitment and supply a failure path that holds it. The linked proposal should reveal the same failure. Its selected next result is the architecture question: which functioning, people, runtime and interfaces could support a commitment under the stated conditions? An adequate slice can already supply those claims; use them without a second description.

The trade-off depends on the next result. This linked proposal leaves implementation and path-specific acceptance tests unprovided while the bearer and interface choices remain open. Progressive slice practice supplies the route toward implemented, tested behaviour when that is needed. Neither representation earns a general effort advantage from being called small. In the ERP case, the proposed confirmation and reservation arrangements still need comparison, so §§4.3–4.6 return the functional and bearer question to C.32 and SYSE.5; a later testable slice can use that result.

Reopen the choice of a thin linked proposal when it appears coherent but a consequential path changes the functioning or bearer—for example, when another order consumes the promised stock between proposal and commitment. Add the missing path or use the progressive slice directly. Prefer an available scenario treatment when it supplies the required architecture claims with less reconstruction or maintenance. These are selection conditions, not evidence that one description form has superior project outcomes.

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. SYSE.5 develops the engineering functional and bearer alternatives, their allocations, interfaces and feasibility limits from those compatible claims.
• 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

SYSE.22 - Coevolve Engineering Problems and System-Family Options

Status: Stable

SYSE.22:0 - Use This When

Use this pattern when an engineering project keeps improving one problem statement and one proposed System while the situation around both has changed. For example, a new operating condition, affected-System consequence, supplier limit, technology, or evidence result can make the old problem–solution pair obsolete even while its backlog closes.

Begin with one observation or claim that can change the current engineering decision. Put the selected problem record beside the System option it currently constrains. State the receiving decision and the claim within it that would change—for example, an admission rule, comparison coordinate, affected-System consequence, evidence need, or choice. If none changes, keep the observation without reopening this decision.

The first useful result contains these four parts:

1. the problem records selected for current attention and a separately retained problem archive;
2. actual Systems in current configurations and possible-future System-family specifications with their architecture, membership, and effectivity bases;
3. supported problem–option correspondences and unresolved mismatches; and
4. one replayable ChoiceResult: choose an option or tie-set, reject the current set, request one worthwhile probe, or refer the question to the decision and authority that can answer it.

An Agent makes the bounded choice under authority. Other Agents later perform any authorized experiment or implementation Work. A DecisionSubject states whose choice is represented; this is separate from the Agents who later perform Work.

Use SYSE.1, SYSE.16, and SYSE.17 first when project focus, operating environment, or affected Systems are unclear. Use SYSE.2 when one linked use-and-System concept is the immediate result, and SYSE.6 when the problem and option set are stable and only an architecture choice remains. Use C.18 when the question concerns only an archive or Front. A contested problem formulation may require a Decision Design Method; a changed Method may require Method Engineering.

SYSE.22:0.1 - Terms and Distinctions

SYSE.22:1 - Problem Frame

Engineering problems and System concepts develop together. For example, an architecture can expose a manufacturing constraint; a prototype can change what users consider possible; an operating failure can reveal an affected System absent from the original scope; a new component can make a previously unaffordable option feasible.

Five recurring confusions make that mutual development hard to manage:

1. a problem situation is confused with its ProblemCard;
2. a problem archive is confused with the finite portfolio receiving attention now;
3. an actual System is confused with a possible-future specification;
4. an exploration archive or Front is confused with the current decision’s OptionSet; and
5. an experiment proposal is confused with authorized and performed experiment Work.

Keeping these distinctions lets the project preserve lineage while changing only the claims affected by a new observation.

SYSE.22:2 - Problem

The usual failure is a frozen pair: one backlog becomes the problem and one baseline becomes the solution. Local optimization continues after a relevant condition changes—for example, intended use, environment, a protected characteristic, a supplier condition, or the reachable System family.

Another failure retains many alternatives without their identities and rules. A single portfolio mixes records of unlike kinds—for example, signals, problem formulations, architectures, configurations, experiment proposals, and decisions. A moving Pareto Front then hides changes in its candidate set or comparator and appears to demonstrate improvement across incomparable questions.

Reopening everything after every signal is equally costly. The project needs dependencies and currentness conditions for individual claims so it can revise a problem without restarting unrelated Work.

SYSE.22:3 - Forces

• Stable identities preserve evidence and decisions, while stale problem or family boundaries make that continuity misleading.
• Retained variants preserve stepping stones, while a project still needs finite current commitments.
• Shared family architectures reduce repeated Work, while one environment or affected System can require a distinct branch.
• Several options can remain non-dominated, while the next project move still needs a choice or probe.
• Novelty can open a useful region, while admission, safety, evidence, integration, and service constraints remain.
• Dependencies support selective reopening, while records that change no decision add maintenance cost.
• A local gain can move cost, risk, Work, or failure exposure to another affected System.

SYSE.22:4 - Solution

Maintain a finite selected problem portfolio and a separately identified set of System-family options. Connect them through decision-bearing correspondence claims, compare them under the current use and evidence, and end the pass with one replayable choice or probe result. Observations from either side can then reopen the other without discarding archives and lineage. A supported current comparison can remain usable while its carrier ages; neither retention nor an unchanged receiving use requires a fresh trial.

SYSE.22:4.1 - Pattern-Use Unfolding

The Method uses eight recurring moves. They organize production of the account; problem-development, System-development, research, realization, integration, operation, and decision Work can overlap.

1. Decision boundary. The Agent identifies the actual System or intended-system designator selected as the project system-of-interest, or the System family and its membership and effectivity rules; current use, environment, affected Systems, configuration, horizon, resources, DecisionSubject, and authority complete the boundary.
2. Situation and problem records. The Agent separates the world-side occurrence or condition from assertions, observations, and evidence about it. Each selected ProblemCard states detection, problematic relation or unresolved claim, improvement check, constraints, affected Systems, evidence, receiving use, and the premises that make that evidence applicable. Include an expiry only where an actual qualification, right, resource or promised-use window ends; a review date alone does not invalidate the claim.
3. Archive and portfolio. Alternative formulations and weak signals remain in the archive under retention rules. The selected portfolio is finite and states why each record receives current attention or resources and what removes or reopens it.
4. System-family options. Actual Systems and configurations, candidate architectures, family membership and effectivity rules, and possible-future specifications are identified separately. Each option states what is realizable now and which builder or platform change it needs.
5. Problem–option correspondences. Every relied-on pair states the changed admission, comparison coordinate, protected characteristic, affected-System consequence, evidence need, or next action. A pair with no supported decision-bearing difference remains an unresolved mismatch.
6. Plural comparison. Archives, Fronts, and the decision OptionSet retain their own membership rules. The Agent compares several result and resource coordinates while retaining protected losses, uncertainty, and non-dominated alternatives. Do not force those coordinates into one scalar objective.
7. Choice or probe. The current OptionSet is fixed. The deciding Agent performs comparison-and-choice Work, applies C.11.CRC when a finite configuration-relative contribution comparison is needed, and applies C.11 to produce a decision result: a choice, tie-set, rejection, named probe, or reroute. The Agent selects a probe only when its expected contribution warrants its full burden: participant and engineering effort, delay, foregone alternatives and displaced protective Work as well as direct expenditure. The performer, resources, access, authority and useful observation window must be available. An affordable discriminator is not by itself a worthwhile probe; a useful qualified result may stand without new observations.
8. Later Work and selective reopening. Assigned Agents plan, authorize, perform, and interpret later Work through the applicable relations. New observations reopen only the problem records, correspondences, options, Fronts, configurations, or decisions that relied on the changed claim.

SYSE.22:4.1.1 - Recover the changed engineering question

Use the eight moves above as a short reminder. The following explanation supplies their construction when the problem and alternatives are not already available. The intended practitioner can interpret the project’s operating and configuration records and obtain the needed domain, production, service, and assurance judgements. This pattern does not supply a missing compressor model, safety limit, or manufacturing process.

Start at the observation that made the old pair doubtful. Recover the earlier use claim and the System concept that was supposed to support it. For one consequential operating situation, follow what happens from the triggering event through the proposed behaviour to the effect on the user or another affected System. Use SYSE.2:4.3–4.6 for that linked construction; use an adequate existing result directly. The return needed here is a use–concept pair with its conditions, main uncertainty and failed or supported connection, not a complete new concept study.

Identify what the observation changes. It may contradict the predicted effect, expose an omitted condition, change the value of the effect, or make a new means available. These lead to different engineering questions. For example, repeated network outages can change “minimize purchased peak power using cloud forecasts” into “maintain occupied-building comfort during a demand reduction, including loss of network service.” The new formulation retains the useful outside result and adds a condition that the old means did not meet. It does not make reduced comfort acceptable simply because the incumbent cannot deliver it.

A new means can instead initiate the inquiry: a local controller may make coordinated short demand reductions possible where only fixed schedules were previously affordable. Ask which use would benefit, what change in behaviour could supply that benefit, and which operating condition could defeat it. Keep a technically interesting challenge in the archive until there is a reason to spend current project resources on it. C.40.CD:4.1–4.5 supplies this general reciprocal development of a problem and a way; here the returned question must bind an engineering use, family configurations and realization conditions.

Preserve the obligation or interest behind the earlier formulation. Distinguish correcting a mistaken description, negotiating a different wanted result, and exploring a deliberately relaxed condition. A solution to the relaxed question answers the original only if its result can be returned under the original condition. When interests or authority remain contested, return that specific formulation question to the competent decision participants. Do not hide it as a low score for a design variant.

The result of this inquiry is a revised problem record and a reasoned relation to its predecessor: retained need with corrected conditions, a distinct new need, a superseded premise, or an unresolved disagreement. That relation tells later engineers which earlier evidence still applies.

SYSE.22:4.1.2 - Construct family alternatives with a feasible common basis

Develop alternatives around the disputed connection. Change the allocation of behaviour, the physical or computational means, the interface, or the operating arrangement when that could answer the revised question. An alternative can retain the incumbent, vary a current member, add a family branch, change the shared architecture, replace a previously assumed means, or stop pursuing this use. Creativity need not come from one assigned role: production, service and domain practitioners can expose a better candidate through their own constraints and available means.

For each promising alternative, recover what remains common and what must vary. State the retained architectural commitments, permitted differences and dependencies between differences. Use SYSE.13:4.1 for variant, unit, configuration and effectivity identity. It supplies the distinctions and supported mappings; the engineering work here determines which proposed combinations can meet this problem.

For example, local fallback, a different compressor, a larger processor and a network gateway are four design choices, not four independent switches. The new compressor may require a different output board; the fallback algorithm may fit only the larger processor; that board may lack an applicable test result. Build a candidate by carrying these dependencies together. Reject an incompatible combination, retain a visibly conditional combination for inquiry, or propose the missing interface or realization change. Do not count the Cartesian product of independently feasible features as reachable family variants.

Retain more than one alternative when they answer materially different conditions or preserve a useful future choice. Ask which differences change admission, value, burden or later reuse; do not expand every possible parameter. A family boundary is itself revisable. If an option requires different functioning, support and evidence assumptions from the shared architecture, compare a separate branch or family with extending the common basis. Forced commonality can move repeated adaptation and service burden into every member.

This produces candidate specifications with explicit variation and compatibility rules. It does not produce new actual Systems or establish that current installed units realize the specifications.

SYSE.22:4.1.3 - Test the join between use, variant and means of realization

A correspondence becomes useful when an engineer can follow why the variant could answer the problem. For each relied-on pair, connect the outside result to the proposed behaviour, the required configuration, the means of obtaining it, and the evidence the receiving decision needs. Use the supported realization branch from SYSE.3:4.2–4.4, a platform result from SYSE.12:4.1, and the applicable SYSE.10 evidence assessment where these already answer the question. Open only the first unsupported result that can change the decision.

The conditions must hold together. A candidate that fits one board, a test that covers another firmware realization, and a service procedure for a third installation do not combine into one supported family option. Likewise, separate statements that two trials can each use the only rig this week do not make their simultaneous commitment feasible. Compare compatible configurations, conditions and receiving decisions, and check shared capacity where the portfolio relies on simultaneous Work. Use SYSE.20 when overlap or acceptance of a partial result is the engineering question.

Keep two different conclusions visible. An option can deserve development attention while its operational admission remains unresolved. A bounded experiment can be feasible even when its subject variant is not yet admissible for ordinary use. State the scope of admission at the receiving decision; evidence sufficient to select a probe does not become evidence that permits deployment.

Use a failed join constructively. If a variant cannot be tested within the existing arrangement, the result may be a precise builder investment question for SYSE.23. If the proposed behaviour cannot supply the required outside effect, return to the use–concept pair. If every candidate fails a protected condition, reject the set or seek an authorized reformulation; ranking failed options cannot supply a successful one.

SYSE.22:4.1.4 - Let one side revise the other without losing the original need

Run the candidate forward far enough to reveal the consequential mismatch. A model, an existing comparable case, a supplier answer or a performed trial can supply that result at its own evidential strength. Relate it back to the problem before generating another variant.

A better means may change which problem is worth current attention. Conversely, a revised problem may change which retained design is useful. Preserve the decision-bearing reason for that movement. This is how an old stepping stone can become useful again without treating its earlier rejection as an error or its archive membership as current endorsement.

SYSE.22:4.1.5 - Compare complete alternatives and stop at a useful decision

Use one comparison situation per consequential operating profile, including the failure condition that reopened the question. Compare complete candidates under the same profile and assumptions. Keep admission constraints separate from preferences among survivors. If an option obtains its benefit only with an unprovided builder change, include that change and burden in the comparison or keep the benefit conditional.

When profiles favor different members, the useful result can be a family rule assigning different variants to different conditions, rather than one universal winner. Examine the shared consequence: supporting two members may require extra configuration, spare parts, qualification or service Work. The cost of the portfolio is not necessarily the sum of isolated variant estimates; common tools can save work while common scarce resources can create conflicts. Do not claim family superiority from two separate local wins.

A revealing probe is worth selecting only if an obtainable outcome could change this comparison enough to justify its full burden. The current result can also be enough to choose, retain a tie, reject, narrow or stop. Use the existing decision account in C.11.

SYSE.22:4.1.6 - Pass the unresolved engineering question at its actual scope

The receiving work determines the next use of the joint account. A compatible use–concept pair can go directly to architecture Work through SYSE.6; a supported member can proceed through its existing realization arrangement. Use SYSE.23 when the unresolved question is which change in the target or its builders is worth making to enable later changes. Send the expected change family, blocked correspondence, current configuration and realization basis, protected conditions, horizon and relevant uncertainty. The receiver constructs its investment alternatives; the SYSE.22 choice does not select an investment for it.

Use SYSE.24 when the needed contribution is already clear and the remaining comparison is how to obtain it. If the question instead concerns wider agreement about the problem, return that exact question to the relevant problem-structuring or strategy practice. These are conditional result uses, not stages through which every project must pass.

A builder improvement from SYSE.23 returns as a changed feasibility premise only for the family options it actually affects. An investment decision alone supplies an expected premise; a supported capability or realization result supplies a stronger one. Reopen the corresponding comparison at that strength. This keeps problem and means developing together without borrowing benefits from unfinished Work.

SYSE.22:4.2 - Record the Result

The joint problem–System-family account records these eight items:

SYSE.22:4.3 - What Changes in Practice

The project stops treating backlog items and design variants as two fixed columns. It can say which world-side change reopened which problem–option pair, why a candidate remains in an archive but not the current decision, and why the choice rule permits a choice, rejection, probe, or reroute as the next result.

SYSE.22:5 - Worked Case: Heat-Pump Controller Family

In this constructed case, a manufacturer maintains heat-pump controllers for occupied apartment buildings. The current decision concerns the controller family and a reversible building pilot. Installed controllers and a laboratory unit are actual Systems; the options below are possible-future specifications under the family’s architecture and effectivity rules.

The earlier selected problem was peak electrical demand during cold mornings. The preferred specification used a schedule optimizer and cloud forecast service. These three field observations now reopen the comparison:

1. several buildings lose network service during the coldest periods;
2. compressor cycling increases service calls in one installed configuration; and
3. a new tariff rewards short demand reductions but penalizes slow recovery that leaves occupants cold.

The current problem portfolio and System-family options produce four correspondence rows:

The final row explains archive retention and current non-selection; it supplies no OptionSet member. The first three rows are the complete correspondence set used by the current decision.

The earlier Front compared energy use and peak demand. The current comparison uses a new candidate set and the following complete coordinate set: continuity, recovery time, occupied-zone temperature, peak power, compressor cycling, processor load, calibration effort, and service burden. It is therefore a new Front with its own basis.

The fixed current OptionSet has three members:

1. continue developing the cloud-schedule specification;
2. develop the local-fallback specification; or
3. develop the variable-speed-control specification.

Safety and occupied-zone comfort are hard guards. The remaining coordinates form a partial order. The cloud- schedule specification without a qualified local fallback fails the network-loss guard. The variable-speed option retains the incumbent local control during network loss and remains admitted, but evidence about processor load and cold recovery is missing for the local-fallback option. That option cannot yet be admitted or rejected.

The controller-family council is the deciding Agent. Its current assignment authorizes it to choose the next engineering probe, or decline new probing on the present basis, and allocate no more than 160 engineering hours. A building operations manager separately authorizes any occupied-building trial; the product-family owner separately authorizes later adoption. The probe choice grants neither authority.

The council uses one shared comparison basis:

• The fixed OptionSet remains cloud schedule, local fallback, and variable-speed control.
• The current BeliefState contains the three field observations, the hard safety and comfort guards, the cloud option’s network-loss failure, the variable-speed option’s admitted local control, and the missing local-fallback processor-load and recovery evidence.
• The OutcomeModel states how each possible probe observation changes admission and the survivor relation. A local-fallback pass admits that option and leaves it non-dominated with variable-speed control; a guard failure or processor overload rejects it. The current calibration uncertainty changes burden estimates for variable- speed control but does not change its admission or resolve the local-fallback question.

The ChoiceRule compares obtainable probes with retaining the qualified current result. Changing admission or the survivor relation is a possible contribution, not an obligation to buy it. In the first resource situation of this case, the council’s qualified judgement is that resolving the local-fallback option before the next family investment is worth the 96 hours, scarce pilot allocation and one-week delay. Assume that capable performers and the windows can be obtained, and that this allocation does not displace more valuable protective or development Work. This value-and-feasibility premise, not the 160-hour ceiling, supports the choice. The calibration trial cannot resolve that question. The deciding Agent applies C.11 and records ChoiceResult-HPF-1 = probe_again for the network-loss and cold-recovery trial.

In the paired resource situation, the same discriminator would consume the only pilot window needed for already supported protective maintenance, or no competent performer can use it before the investment decision. The council can decline that probe and retain the qualified comparison above. Local fallback stays unresolved; no observation or safety assurance is invented. A later owner can make a supported bounded development choice among admitted options.

In the selected-probe situation, after that ChoiceResult, a planning Agent must still prepare the trial plan, the building operations manager must authorize the occupied-building trial, and assigned Agents must perform and interpret the Work. Family adoption remains a separate decision by the product-family owner. If pilot authority is withdrawn before the trial Work, a new decision pass records reroute and the missing authority without rewriting ChoiceResult-HPF-1. Later observations reopen only the three current problem–option correspondences and dependent family results; the voice-control archive entry remains unchanged.

For currentness, first keep the same configurations, relied-on observations, calibration, rights and supported use while only the source export date changes: the comparison remains usable. Now change a controller configuration so that the relied-on processor-load evidence no longer covers it, or let a real calibration or pilot permission window end: reopen or suspend the affected use, not every claim in the source. Keep the needed qualification with the comparison for later receivers; do not turn the first case into renewal Work. The case’s 20-minute and 70% limits are receiving acceptance conditions, not universal thresholds supplied by this pattern. Their protective basis and any proposed amendment require the relevant engineering judgement and authority; merely choosing or declining a probe changes neither.

SYSE.22:5.1 - Construct the family account behind the probe and use its return

The heat-pump case starts with observations, not three fully formed alternatives. To obtain the specifications above, the engineers first retain the outside need for acceptable heating and change the problem from peak reduction alone to peak reduction with continuity and timely recovery. Following SYSE.2:4.3, they trace the cloud command through the connection, local controller and compressor to the occupied-zone effect. The trace exposes the missing behaviour during disconnection. Continuing with only a lower peak-power target would leave that failure intact.

They then vary the means at the failed connection. One proposal adds an independently functioning local mode; another changes compressor control while retaining the existing local protection. The cloud-only proposal is kept in the comparison long enough to show why it fails the revised condition. Voice control does not repair that connection and stays outside the selected portfolio.

For this constructed account, assume the larger processor is available only in two controller configurations, and that the variable-speed compressor needs its matching output board. The option descriptions therefore name those combinations and the effectivity proposal; they do not offer every feature on every installed unit. The local-fallback option’s conditional status is precise: a plausible configuration exists, but the current decision lacks the load and recovery evidence that would permit its admission. The rig and occupied-building window in §5 explain how that uncertainty could be resolved.

Now take the selected-probe branch and stipulate that the authorized trial is subsequently performed and passes its stated limits in both configurations. The interpretation admits local fallback on that bounded basis and preserves variable-speed control as a non-dominated alternative. It does not choose a release or extend the observation to other boards. The family owner can now compare different members for their applicable buildings rather than insisting on one universal controller. The problem portfolio remains the three selected problems; the voice-control request is unchanged.

The next supplier-change inquiry reveals that producing and assuring more combinations with rig R4 requires repeated interface work. The returned SYSE.23 question is specific: for the named controller family and next supplier replacement, which target, rig and evidence changes would reduce that repeated work while preserving the existing comfort and configuration limits? Local-fallback evidence supplies one applicable input; it does not settle the supplier interface or evidence-reuse questions in SYSE.23:5.

Changed condition. Suppose a later building requires the smaller processor, on which the fallback algorithm would exceed the same load limit. The passed trial remains valid for its two configurations. The revised family account keeps the supported larger-processor member where applicable. The same fallback specification fails the smaller-processor condition and is excluded for that use; it is not merely awaiting more evidence. Incumbent local control can retain its previously supported use while a different algorithm or board is considered for the unmet demand. The owner compares a separate branch’s supply, configuration and service burden with replacing the small board. Reclassifying the small-board building as “not a customer” would change the problem scope and require its own grounds and authority; it would not demonstrate that the fallback solves the original use.

This continuation explains the joint result of the Methods. SYSE.22 changes which problem–variant pairs are worth pursuing; SYSE.23 can change the means and burden of reaching them. Either result can stand for its own decision while the other remains unresolved.

SYSE.22:6 - Bias Annotation

Watch for these six recurring biases:

SYSE.22:7 - Conformance Checklist

• The decision boundary identifies the actual System or intended-system designator selected as the project system-of-interest, or the System family; current use, environment, affected Systems, configuration, horizon, chooser, and authority.
• World-side problem situations and ProblemCard epistemes remain separate.
• The problem archive and finite selected problem portfolio have separate membership rules.
• Actual Systems and configurations remain separate from possible-future specifications.
• Every option identifies its family architecture, membership or variant rule, and effectivity basis.
• Exploration archive, Fronts, and current OptionSet retain their own candidate and admission rules.
• Every relied-on correspondence changes a decision-bearing claim or remains visibly unresolved.
• The comparison preserves relevant result and resource coordinates, protected losses, affected-System consequences, uncertainty, and non-dominated alternatives.
• The choice or probe result states its basis, rule, full burden and value when relevant, actual obtaining conditions, authority, and reopen condition. Retaining a supported result is not conditional on a new probe.
• Proposal, planning, authorization, performed Work, observation, and later adoption retain separate results.

SYSE.22:8 - Common Failures and Repairs

SYSE.22:9 - Consequences

The project can change both what it is solving and what Systems it considers without discarding lineage. Useful stepping stones remain recoverable, stale comparisons become visible, and one bounded probe can be chosen while the problem and System family remain revisable.

The cost is maintenance of identities and decision-bearing correspondences. Some cells remain unresolved, and the best current result may be a probe, rejection, or reroute rather than a selected System variant.

SYSE.22:10 - Rationale

FPF already supplies problem records, plural search, archives, Fronts, currentness, comparison, and choice. Systems Engineering adds the action-changing specialization: selected problem formulations must be compared with architecture- and configuration-identified System-family options under project use, operational environment, affected-System consequences, realization limits, and engineering evidence.

The terms problem factory and solution factory describe different but corresponding Work and Method structures. The described Work can take place concurrently. Identify the Systems involved separately; use SYSE.20 when overlap or required order becomes the engineering problem.

SYSE.22:11 - SoTA and Source Use

Engineering can revise problem formulations and System-family options together, including the Work and Methods used to develop them. Problem archives and portfolios retain material for later choices; comparison and acceptance use their stated bases. When the way of developing a System becomes the obstacle, the same inquiry can extend to its builders.

The source comparison matters to the choice of Method. NASA’s currently provided Design Solution Definition guidance, §4.4.1.2 already connects iterative concept development, operating concepts, stakeholder expectations, technology maturity and enabling products. Use a sufficient result from that practice directly. This pattern’s additional work is the engineering connection between a changing problem portfolio and configuration-qualified family alternatives: explaining which combination is reachable, which use it can answer, and which changed premise reopens the comparison.

A competent product-line practice can already provide a variability model and a way of producing its members. For example, the SEI production-plan guidance describes how core assets are used to build a particular product. Retain that supported basis rather than rebuilding it here. The remaining question in this pattern is whether changed use and realization conditions require a different family option, problem formulation or current commitment.

The table names the sources used here and the contribution and limits of each.

Reopen one source-use row when changed evidence alters its practical contribution or boundary.

SYSE.22:12 - Relations

• SYSE.1, SYSE.16, and SYSE.17 supply project focus, operational environment, and affected-System consequences for compatible uses.
• SYSE.2, SYSE.6, SYSE.7, SYSE.10, and SYSE.13 supply linked concepts, architecture decisions, descriptions, evidence, and family/configuration/effectivity identity.
• SYSE.15 can supply a compatible engineering-Method repertoire. SYSE.21 can supply bounded observations of an enacted variant and its population; each claim keeps its own evidence and transfer boundary.
• C.40.CD:4.1–4.6 supplies the general reciprocal development of a question and a way; SYSE.22:4.1.1–4.1.6 binds its use here to family compatibility, realization and receiving decisions. SYSE.2:4.3–4.6 supplies the linked use–concept construction, and SYSE.3:4.2–4.4 the realization branch.
• C.22.2 governs ProblemCard epistemes and C.22.PFR any world-side ProblematicForRelation. C.17, C.18, C.19, G.5, and G.11 govern characterization, archives and Fronts, live pools, selected sets, and use-qualified currentness. SYSE.19 and SYSE.23 retain changed-premise and claim-specific receiving rules.
• C.11.CRC governs finite configuration-relative contribution comparisons and C.11 the bounded choice.
• Supply the project focus, selected problem portfolio, System-family option set, correspondences, unresolved mismatches, and current ChoiceResult from SYSE.22 to the Agent using SYSE.23 for an investment or reconfiguration decision.
• Feedback reopens SYSE.2, SYSE.6, or SYSE.13 only when the changed result crosses their stated reopen condition.
• Decision Design, Strategy, Method Engineering, and Operations Management retain their domain Methods even when their Work uses the same archives or decisions.

SYSE.22:End

Part II - Architecture, Descriptions, Offerings, and Professional Contributions

SYSE.5 - Develop an Engineered System’s Functional Organization and Bearer Alternatives

Status: Stable

SYSE.5:0 - Use This When

Use this pattern when engineers can name a desired outside effect, use situation, or observed functioning failure, but have already treated one familiar bearer cue—for example, a component, product, service, software partition, or supplier offering—as the only candidate. Use it also when a functional diagram exists but no one can show which actual Systems or intended System referents could bear the contributions named by its claims under decision-relevant conditions—for example, operating, interface, placement, integration, or assurance conditions.

The first result is an account that compares several functional organizations with the Systems and interfaces that could realize them. It records proposed many-to-many allocations, the conditions under which each proposal could work, conflicts among proposals, evidence limits, and the first unsupported dependency. It is a proposal for later architecture selection. Realization, integration, and observed performance require their own work and evidence.

First move. In one sentence, name the required outside effect, the current decision question, and the first familiar bearer assumption. Add one materially different way in which the contribution might instead be borne. If no bearer or allocation choice is current, stop and use A.6.F for the function-like claim.

Use this pattern while an allocation choice can change an engineering decision. For one function-like claim, use A.6.F; for one module or interface claim, use A.6.M; for transdisciplinary candidate synthesis across several structures, use C.32; and for choosing an architecture from developed alternatives, use SYSE.6. When a subject-specific Method—for example, one for physics, software semantics, clinical action, electrical protection, or structural integrity—determines the answer, use the relevant application DPF with this allocation account.

SYSE.5:0.1 - Terms and Distinctions

Words such as functional block, module, service, component, agent, sensor, platform, and open interface do not establish a common kind. Restore their subjects and relations before using them in an allocation proposal.

SYSE.5:1 - Problem Frame

An engineered System participates in a use situation through interactions under stated conditions. A desired outside effect can often be produced by several functional organizations, and one functional contribution can often be borne by several Systems together. Conversely, one System can bear several contributions in one configuration and different contributions in another. Distribution can change, for example, across operating modes, failure states, product variants, sites, and time.

The engineer therefore needs more than functional decomposition and more than a component search. The working result links functional and constructive candidates to their outside use, proposed allocations, interface realizations, placement, integration dependencies, and evidence. The result table below states its required content. These selected structures answer different questions and need explicit correspondence where the decision depends on them.

SYSE.5:2 - Problem

Starting from the incumbent construction makes familiar parts look necessary. Starting from a functional graph alone makes abstract elements look like purchasable or assignable things. A supplier search can then be mistaken for proof that the proposed functioning is feasible, while an unsuccessful search can be mistaken for proof that no bearer is possible.

The result is an allocation that survives on paper but fails in use. For example, a bearer may lack power, capacity, placement, access, timing, environmental tolerance, or realization support. Two nominally conforming interfaces may fail to interoperate. Several Systems must cooperate but their joint contribution and failure handling are absent. A standard connector admits a damaging wrong connection. A general-purpose supporting System can reduce one development burden while increasing, for example, latency, energy use, certification Work, or continuing-change burden. Procurement and Work are then organized around functional labels before actual supply items, assembly relations, and evidence needs are known.

The opposite failure is endless decomposition and candidate generation. The engineering account is useful only when it exposes alternatives and conflicts for a named decision question and stops at the first unsupported feasibility dependency.

SYSE.5:3 - Forces

The move must manage these recurring tensions:

• Reusing an incumbent construction saves effort, while it can hide a better physical principle or distribution.
• Functional abstraction protects solution freedom, while abstract labels can conceal, for example, physics, operating conditions, or joint bearer requirements.
• A general-purpose bearer can absorb several contributions, while specialization can improve, for example, performance, safety, energy use, evidence production, or fault containment.
• Standard interfaces can reduce coordination cost, while compatibility, integration, substitutability, and correct-use claims still need their own grounds.
• More alternatives preserve option value, while every alternative adds Work—for example, modeling, specialist analysis, comparison, or evidence production.
• Early quantitative estimates help eliminate infeasible candidates, while premature precision can hide unknown models, wrong subjects, or unsupported measurements.
• AI-assisted generation can widen a functional candidate set quickly, while bearer-feasibility and project-correctness claims still need project evidence.
• Engineering Work must proceed under incomplete knowledge, while later commitments—for example, purchase, realization, integration, or release commitments—need progressively stronger grounds.
• Selected structures—for example, functional, constructive, placement, control, information, configuration, and evidence structures—constrain one another while each answers its own engineering question.

SYSE.5:4 - Solution

Develop several functional organizations and materially different bearer-and-interface proposals together. Enter at the claim that blocks the current decision, keep the outside effect and use visible, and iterate between functional and constructive accounts. Make every allocation, interface condition, conflict, evidence limit, and decision-relevant consequence explicit. Use C.32 for the general multi-structure candidate palette; apply the Systems Engineering content below to make that palette usable for realization, integration, procurement, assurance, and continuing change.

SYSE.5:4.1 - Perform the Move

1. Bind the engineering decision. Name the actual System or intended-system designator selected as the project system-of-interest, decision question, use situation, required outside effect or observed failure, configuration or variant, operating envelope, horizon, and protected characteristics. Use SYSE.2 candidates and unresolved use–System mismatches when they are current and compatible; otherwise use a qualified direct source or record the missing result.
2. Restore the blocking function-like claims. For each material contribution, use A.6.F to state the predicate, possible bearer, receiving whole or effect, conditions, and claim status. Begin from outside use, an observed internal failure, a candidate construction, or a feasibility result as the current question requires.
3. Develop several functional organizations. Construct how contributions cooperate to produce the required outside effect, using §4.1.1 when that connection is not already clear. Vary that organization together with its possible bearers. Include decision-relevant situations—for example, operating, degraded, maintenance, recovery, or consequential foreseeable use. A tree is optional; use the representation that reveals the material transformations, exchanges, states, feedback, or mode-dependent relations.
4. Generate materially different bearer arrangements. Start with actual or intended Systems that might carry the contributions. For each arrangement, state how each candidate System would be obtained and operated— for example, by using an available System, procuring or realizing one, relying on provider Work, or combining software and physical Systems. Record shared resources and changes to supporting Systems as dependencies unless they themselves carry a contribution. Vary decision-relevant structures—for example, physical principle, distribution, placement, redundancy, containment, control boundary, or interface grammar. State separately whether an actual System exists, whether it is procurable, what realization or provider Work is needed, and which candidate claim still lacks support.
5. Write many-to-many proposed allocations. Associate functional contribution claims and candidate bearers explicitly. Permit several bearers for one contribution, several contributions for one bearer, and different allocations by mode, use, configuration, place, or effectivity. Treat weak cues—for example, co-location, matching names, diagram overlap, product kind, ownership, or system-role assignment—only as possible evidence for a separately stated claim.
6. Develop interface and placement conditions. For every material interaction, state the boundary and participants. Add the conditions that matter to the decision—for example, exchanged quantity or signal, units, geometry, protocol states, timing, capacity, environment, error handling, configuration, and effectivity. Identify the physical realization or missing realization separately from the interface specification. Add decision-relevant constraints—for example, placement, access, assembly, maintenance, supply, or resource constraints—when they change feasibility.
7. Challenge intended and unintended interaction. Test the proposed arrangement against relevant cases—for example, loads, failures, swaps, reversals, stale configuration, unavailable resources, human or machine misuse, and external change. For consequential wrong use, compare candidate changes—for example, to geometry, keying, protocol, control, detection, containment, or operation. Test evidence supports a mitigation claim only for the tested interaction and conditions.
8. Check realization and integration dependencies. Identify each dependency needed to make and join the bearers—for example, a System, Method, capability, resource, service, assembly Work, configuration episteme, or specialist result. Record each dependency with its own kind and relation to the proposal. Distinguish a missing catalogue item from a missing physical principle and from a missing project capability. When a recursive realization dependency is current, use SYSE.3 to develop it; do not hide it in a module name.
9. Compare engineering consequences. For each proposal, state predicted gains, losses, and unknowns for the current decision. Compare proposals for the engineering concerns that matter, such as performance, energy, safety, security, fault containment, latency, placement, service access, manufacture, assembly, integration, supply, cost, configuration, changeability, evidence burden, and affected-System consequences. Express each comparison through a characteristic with an explicit subject, conditions, Scale, and comparison frame. Bring in specialist Methods for the actual physics and risks.
10. Examine a representative slice. Use available evidence that supports the present claim under the needed representative conditions. When further challenge Work could change the decision, use C.11.DUA and the applicable C.11 or specialist experimental-design Method to decide whether to obtain it, comparing its attainable contribution with the whole burden. For selected Work, choose the Method suited to the claim—for example, computation or simulation, prototype-building and testing, or a physical trial. For an analysis or trial whose result is relied on, identify the performed work, its performer and Method, configuration and conditions, observations, and claim limits. A model, simulation result, or trial observation remains an input to later claim assessment; its form alone does not establish feasibility of the whole proposal.
11. State the decision use and local stop. Record which alternatives remain usable, were revised, combined, or rejected; record the reasons, protected losses, and smallest unresolved dependency. When an architecture decision is current, use this account as an input to the Work governed by SYSE.6. When no admitted bearer can satisfy a sound contribution, choose explicitly among another bearer, a changed functional organization, new realization or supporting-System capability, bounded exploratory Work, or stopping the current proposal. Pause only the commitment whose basis is missing.

Revisit these questions in the order that helps answer the current decision. Functional reasoning, construction search, realization, integration, and testing can overlap and recur. A claim’s reliance on another result does not require all work producing that result to finish before work on the dependent question starts.

SYSE.5:4.1.1 - Construct the Joint Functioning

For a decision-relevant use, build one connected explanation of how the proposed interactions produce the outside effect. Begin with an existing arrangement when it supplies a useful starting point; its parts are candidates, not limits on what can be constructed. The following questions connect functional reasoning with bearer choices.

Work back from the effect to what must happen. Identify the receiving System, the condition to change or preserve, and what must reach or act on it. Recover the relevant inputs and initial states: for example, available energy, material, information, permissions, or a prior operating state. Ask what transformation, transfer, decision, or maintained interaction could connect them to the effect. Follow each needed intermediate result back to a possible producer or available source. This exposes cooperating contributions; it does not require decomposing every function to a uniform depth.

Make the cooperation possible. Connect what one contribution produces to what another needs, retaining the identity and relevant properties of what passes between them. Distinguish an exchange from a condition for starting, continuing, or stopping an operation. State where contributions must coexist, synchronize, wait, or feed back, and what changes with the operating mode. If two inputs must meet, explain the operation that combines them and how candidate bearers could perform it. A junction on a drawing supplies neither that operation nor its means. If production and use occur at different times, identify what preserves the needed material, energy, information, or state between them.

Reason forward through one complete use. Starting from the available inputs and states, explain what each cooperating contribution changes, what becomes available next, and why the receiving System would obtain the required effect. Use relevant domain relations: energy and material balances, a valid data transformation, or an operating rule, for example. Include simultaneous contributions where the effect depends on them. Check that the account has no required input without a source, unavailable initial state, incompatible handover, or unexplained jump from individual contributions to the whole effect. State assumptions that still need support. A coherent conditional explanation is a candidate for investigation, not observed functioning.

If automated numerical planning can help, supply compatible initial states, goal conditions, and permitted quantitative transformations with their units and constraints. Use the generated arrangement only within that model’s scope. A failed or timed-out search leaves the modeled search question unresolved unless its result establishes more; it does not show that no physical arrangement is possible. §11 compares this branch with construction that begins from less complete information.

Change a relation together with its possible realization. Try a different physical principle, move a transformation, retain a resource for later use, distribute a decision, or change which interactions continue during failure. Follow the changed relation forward to the outside effect and back to its required inputs. Revise the affected bearer and interface proposals, state what still works unchanged, and expose new dependencies. If no credible means of producing a required intermediate result is known, keep that exact gap open and use specialist development or the local return in step 11. Renaming a box does not fill it.

Choose a representation that exposes the difficult relation:

These are choices for the current question, not four required diagrams. A short explanation can suffice; combine representations only when one hides a consequential relation. A control-layer split is also not a physical containment hierarchy. When reliance depends on stability, response bounds, capacity, or another specialist property, obtain the relevant domain construction and evidence; use C.30.LCA for the conditions of a relied-on layered-control view. This pattern does not derive a controller or establish physical adequacy from the organization alone.

SYSE.5:4.2 - Record the Result

The account can use several linked representations. Each representation names the functional organization, constructive organization, or engineered System it describes, and the account states the correspondence among those subjects.

SYSE.5:4.3 - What Changes in Practice

Engineers stop asking which named component implements each box and start asking which materially different arrangements can produce the required outside effect under the actual use conditions. They no longer treat functional names as purchase items or procurement specifications. Interface standards become inspectable specifications and evidence questions. Failed feasibility changes the smallest affected functional or bearer claim instead of silently collapsing the candidate set or restarting the whole project.

SYSE.5:5 - Worked Case: Heat-Pump Plant Control and Protection

An occupied building has a heat-pump plant whose controller must respond to electricity-price and grid-flexibility signals while maintaining room comfort and protecting compressors. The engineering team must choose a control architecture for plant configuration HP-2 that remains useful for the next three heating seasons. Earlier concept-development Work produced two viable use/System concepts and one unresolved mismatch: centralized optimization improves plant coordination, but communication loss must not remove local protection.

During allocation Work, the engineers restore four contribution families as claims whose bearer arrangements remain to be chosen:

• modulate heat production against building demand under temperature, occupancy, tariff, and plant conditions;
• keep compressor pressure, temperature, cycling, and flow within protected limits;
• accept, validate, and act on external price or flexibility signals within declared timing and authority;
• retain local safe operation and recover state after communication, sensor, or controller failure.

They develop three materially different proposals:

1. A central building controller carries demand estimation, optimization, dispatch, and most protection logic; unit controllers provide actuation and a small emergency stop.
2. Local unit controllers carry protection and normal regulation; a supervisor sends bounded set-points and coordinates units, while loss of the supervisor leaves a declared local operating envelope.
3. Thermal storage and a tariff scheduler carry most time-shifting; local controllers retain protection and regulation, so grid response is split across storage, scheduler, drives, sensors, and plant state estimation.

To construct proposal 2, the team works back from room comfort. In this case the rooms receive heat through water-fed emitters. Maintaining the selected room condition therefore requires heat delivery that can meet the building’s changing loss, a circulating water path, and suitable water conditions at the emitters. The heat pump must transfer energy from its source, with electrical input, to that water circuit. This identifies a cooperating thermal path before deciding which controller should carry each decision.

The team then connects regulation to that path. Room and water observations support an estimate of demand; unit-state observations delimit the operating capability. A valid price or flexibility request can change the supervisor’s requested operating point within those limits. The local controller accepts a compatible request and regulates the unit using local observations. Local protection can restrict or stop actuation when a protected condition would be violated. Heat delivery requires the thermal source, electrical supply, circulation, emitters, and admissible actuation to work together; issuing a set-point alone cannot produce the outside effect.

In normal operation, a change in room demand can alter the requested and locally accepted operating point, which changes heat transfer and subsequent room observations. Price information influences that choice but does not replace the heat demand or the protection condition. During communication loss, the proposed local mode continues regulation only from information and authority available locally; an unavailable remote request cannot remain a required input. If local conditions permit protection but insufficient heat delivery, the result is protected operation with reduced comfort, not satisfaction of the whole original requirement. The team must expose that loss to the architecture decision.

Now change the relation between heat production and room delivery. Proposal 3 inserts thermal storage: the plant can charge it when permitted, while the distribution circuit can draw stored energy later. The scheduler consequently needs an estimate of usable stored energy and the permitted charge and discharge conditions, as well as demand and external signals. Local protection and the heat-delivery path remain necessary. What changes is the timing dependency: current delivery can depend on an earlier charge rather than simultaneous compressor operation. Storage, sensors, valves, and circulation must realize that changed relation; adding a box named buffer is insufficient.

For this candidate the team assumes a storage capacity and discharge rate adequate for a stated flexibility interval. It still needs a thermal/hydraulic account that covers losses, usable temperature range and room demand, together with storage-cycling evidence. If those conditions fail, the intended time-shift is unsupported: shorten the interval, change the storage or operating proposal, or retain proposal 2. The functional requirement and the local-protection contribution survive that return. Control behavior and physical margins require their specialist analyses and trials before reliance. This is a worked candidate construction, not a qualified plant design.

The functional contribution claims and candidate bearers are not one-to-one. Protection is distributed across software, local electronics, sensors, drive limits, valves, and physical pressure relief. Grid response depends on the supervisor or scheduler, communication bearer, storage state, unit capability, and operating permission. Every bearer entry identifies an actual System or intended referent and its proposed allocation. A model-box label such as protection or optimization is only a cue for recovering those claims.

The interface account separates signal semantics, units, timestamps, command validity, latency, state quality, fallback behavior, configuration identity, and physical connections. The team separately tests rejection of stale commands, agreement of sensor units, local fallback behavior, and the integrated plant contribution. Simulation Work challenges thermal and tariff behavior; Hardware-in-the-Loop Work challenges timing and fallback; a bounded plant trial challenges actual integration. Each produces observations with different claim limits.

An AI coding Agent proposes a fourth function graph and controller split. That Agent and the engineers perform candidate-generation and criticism Work; the generated graph is a description candidate. It enters the account only after its functional claims, candidate bearers, interface assumptions, and unsupported physical dependencies are recovered.

The account retains proposals 2 and 3 and rejects proposal 1 because its local protection split cannot satisfy the declared communication-loss condition. It also records one unresolved storage-cycling evidence need. The two alternatives, allocation conflicts, predicted losses, and conditions for revisiting the decision become inputs to architecture-decision Work governed by SYSE.6.

SYSE.5:5.1 - Small Wrong-Use Check

A service machine uses one lubricant cartridge and one cleaning-solvent cartridge. Cross-connection damages seals. The engineer states the two fluid-delivery contributions and service conditions, then compares candidate cartridges, ports, seals, and connection arrangements. The retained proposal uses mechanically distinct keyed couplings whose materials and geometry fit the relevant fluids, pressure, assembly, and service conditions.

The check attempts every intended connection and the consequential swapped connections under the declared conditions. A colour label is a cue, not evidence that cross-connection is impossible. If an intended connection fails or a damaging swap remains possible, the allocation and interface proposal reopens. The resulting observations can support claims only about the tested configurations and wrong-use cases.

SYSE.5:6 - Biases to Watch

Three recurring biases matter here. Incumbent-form bias lets a function tree, current parts, or a supplier catalogue determine the candidate architecture; start from the required effect and compare materially different arrangements. Conformance-label bias lets an interface name, standard, or certificate replace project evidence; state the interface claim and test it under the relevant conditions. Fluent-generator bias lets a plausible human- or AI-generated graph outrun bearer physics; recover the claims, Systems, and unsupported dependencies.

SYSE.5:7 - Conformance Checklist

SYSE.5:8 - Common Failures and Repairs

SYSE.5:9 - Consequences

Engineers gain alternatives that can survive contact with physical realization, integration, procurement, and operation. Functional freedom remains tied to stated bearer claims and use conditions. Supplier claims and AI-generated candidates become inspectable inputs. Wrong-use cases, interface gaps, unallocated contributions, and unsupported realization dependencies appear early enough to change the architecture choice.

The cost is maintaining correspondence among several selected structures and qualifying claims by use, configuration, and evidence. Candidate diversity also costs modeling and specialist Work. Those costs are bounded by the decision question and stop rule: stop with decision-sufficient alternatives and the first unsupported feasibility dependency.

SYSE.5:10 - Rationale

FPF already explains functions, structures, modules, interfaces, candidate synthesis, and architecture choices. Apply these to engineering by keeping the required outside effect and use visible while engineers iteratively develop functional organizations, actual or intended bearer arrangements, many-to-many allocations, physically meaningful interfaces, realization dependencies, wrong-use challenges, and bounded evidence use for one engineered-System decision. Procurement, realization, assurance, and continuing engineering Work need those constructive and integration details.

SYSE.5:11 - SoTA and Source Use

Working question. How can an engineer construct and vary the joint functioning that could produce a required outside effect, while keeping bearer, interface, and realization choices usable for the next architecture decision?

The selected answer is the synthesis in §4.1: construct a cooperating arrangement from relevant inputs and states, reason through its effect, and vary its relations together with possible bearers. Preserve unknowns where the decision can proceed conditionally; return a missing physical or operational contribution to its actual producer. §4.1.1 supplies that connection and §5 works it through a changed timing dependency.

A serious alternative is the enhanced sequence diagram of Yildirim and Campean (2020), §§3–4.3. It already connects functional flows with possible design elements and supports changes to an existing arrangement. Adapt its treatment of transformation, transmission, and joining conditions in §4.1.1; use the fuller ESD when a systematic flow representation is needed. SYSE.5 makes representation conditional and carries the construction into alternative allocations, obtaining arrangements, evidence limits, and local return. Compared with developing one ESD arrangement, that adds comparison and realization work. The accepted gain is that the next decision can distinguish different ways of obtaining the effect and the unsupported dependency of each. The heat-pump case supports this conditional reasoning; it establishes neither measured effort savings nor general superiority.

For a compatible quantified problem, Rosenthal, Heesch, and Niggemann (2026), §§3–5 offers a serious numerical-planning alternative. The cited formulation is linear; inherently nonlinear couplings such as pump or fan flow losses fall outside it. Before choosing the method, check that the relations needed for the decision fit this boundary. For an unsupported relation, justify a linear approximation for a stated operating range and error tolerance, with evidence adequate for the intended decision, or use another Method with its own applicability and evidence limits. Otherwise leave the affected quantitative conclusion unsupported. Adapt the cited method’s explicit states, goal conditions, and admissible quantitative transformations for the optional automated branch in §4.1.1. Its two cases demonstrate model-level consistency, with results dependent on the specified problem and search; they do not qualify this plant or every realization. Preparing that model costs work. Prefer the branch when its consistency checks or search can change the decision and the requisite model can be supplied. Reject making that formalization a prerequisite for every early alternative: unresolved operating concepts may first need the joint reasoning and specialist inquiry described here. This choice accepts less automatic assurance in exchange for useful conditional development with incomplete inputs.

The constructive connection and its realization/decision use are this pattern’s authored synthesis. The sources below support particular premises and limits, with their dispositions stated at that scope.

For the AI-generation branch, adapt generated graphs as proposals to examine; reject using graph connectivity or a study score as bearer-feasibility evidence. This is the boundary applied to the fourth proposal in §5.

Reopen the selected construction when a credible rival produces equally usable alternatives and local returns at lower total effort, when an actual use exposes a missing cooperation relation, or when a changed problem makes the quantitative branch newly useful or inadmissible. Reopen only the dependent allocation, interface test, AI-use boundary, or assembly/economic claim when its source or use conditions change.

SYSE.5:12 - Relations

• When compatible, practitioners can use linked use/System candidates and unresolved mismatches from a SYSE.2 result as inputs. They must still check the subject, configuration, horizon, evidence, and compatibility before developing the alternatives in this account.
• Use A.6.F to restore each function-like claim and possible bearer. A.6.M governs module and interface claims; A.22 and C.30 govern selected structures and architecture relations. Applying those patterns alone does not produce the Systems Engineering allocation account defined here.
• Use C.32 for general multi-structure architecture-candidate synthesis: vary selected structures and retain their gains, losses, and next use. SYSE.5:4.1.1 develops the engineering connection from required effect to cooperating contributions and possible bearers; the remaining move supplies physical interfaces, realization, integration, wrong-use challenge, and decision use. Reuse a C.32 palette when its subject and content fit this question. For a relied-on layered-control view, C.30.LCA supplies its interlayer conditions; it does not prescribe a universal number of layers or replace specialist controller design.
• The allocation-alternative account is an input to architecture-decision Work governed by SYSE.6. That Work may produce a chosen architecture and conditions for revisiting it. Candidate generation in SYSE.5 does not select the architecture.
• When an unsupported realization or build-the-builder dependency, evidence claim, description-correspondence problem, or assurance question is current, apply SYSE.3, SYSE.10, SYSE.7, or SYSE.4 respectively to its own subjects and sources. The realization dependency, evidence claim, description-correspondence problem, and assurance question concern different engineering subjects and require different Work results; Work performed for one does not supply the missing results for the others. A description ensemble remains distinct from candidate Systems, allocations, interfaces, and the selected architecture.
• Practitioners can reuse a compatible SYSE.5 result in MDPE.3 when an engineered instrument, robot, hybrid body, venue, or software System is itself an architecture subject in the performing whole. Recheck the reused result against the MDPE subjects, authority, conditions, evidence, and current music-and-dance sources.
• Agents performing downstream application Work—for example procurement, manufacturing, configuration, maintenance, operations, software, electrical, mechanical, safety, or human-factors Work—use the result through their own Methods, authority, conditions, and evidence.

SYSE.5:End

SYSE.6 - Decide and Reopen the Engineering Architecture

Status: Stable

SYSE.6:0 - Use This When

Use this pattern when an engineering project has several architecture candidates, yet local design choices are accumulating without one recoverable decision about the project-shaping structures of the engineered System. Use it also when an earlier architecture decision still appears in a record, but changed conditions—for example, use, integration, configuration, evidence, or operation—may have made its accepted losses and open refinements stale.

The intended result is an engineering architecture decision that selects one option, fixes the project-shaping constraints, and states when to reconsider it. In FPF this is an ArchitectureDecisionRelation@Project supplied by C.32.PAD, not a second decision kind. In this Systems Engineering specialization, the decision uses the required engineering content recorded below: each candidate’s use, functional organization, bearers, interfaces, realization, integration, affected-System consequences, and evidence. The decision names the selected option, explicit constraints, and results needed by later engineering Work.

First move. Name the architecture question, the decision subject, and the smallest project-shaping structure choice that two current candidates answer differently. When the choice requires authority, cite the separate authority relation; an assignment or architecture record does not supply it.

This pattern begins after candidate development and ends with a decision plus conditions for reconsideration. Use C.32 and SYSE.5 to develop the candidates, SYSE.7 to maintain architecture descriptions, C.32.PAD directly when no Systems Engineering specialization changes the choice, and SYSE.4 to qualify the decision or identify the basis it still lacks. Release approval and evidence that the intended architecture now obtains remain separate decisions and claims.

SYSE.6:0.1 - Terms and Distinctions

Words such as architecture, style, pattern, platform, modular, open, integrated, distributed, AI-native, and evolutionary are recognition cues until the current claim identifies the selected structures, criteria, Method, decision relation, or observed change meant.

SYSE.6:1 - Problem Frame

Engineering architecture decisions coordinate many later choices without deciding every detail. They can fix a functional allocation, module boundary, interface grammar, placement, control boundary, redundancy principle, product-family variation policy, evidence boundary, or other selected structure that several realization and specialist decisions must respect.

The decision sits between possible futures and physical realization. Its grounds may include, for example, current descriptions, comparisons, estimates, experiments, or specialist returns. Later Work may produce a different actual structure or expose consequences that were not visible. The architecture decision must close enough choice for current engineering Work while preserving alternatives and explicit conditions for revision.

SYSE.6:2 - Problem

Without a bounded architecture decision, local choices become a de facto architecture. Contributors—for example, component suppliers, software teams, construction specialists, operators, safety specialists, or providers of supporting Systems—each optimize their own structure. Their decisions can be individually reasonable and jointly incompatible. Burdens such as interface, placement, configuration, assurance, or affected-System consequences appear only during integration or operation.

An oversized architecture decision causes the opposite failure. It fixes low-level details without the local knowledge needed to choose them, substitutes centralized approval for specialist contribution, and makes every revision look like a whole-project exception. A broad quality catalogue or one score does not solve the problem: characteristics have different bearers, Scales, conditions, evidence, and protected losses.

A decision record can hide both failures. A file can be complete while the candidate basis is narrow, accepted losses are absent, the selected structure is unclear, or no observation can reopen the decision. Engineers then preserve documentation instead of maintaining a current engineering choice.

SYSE.6:3 - Forces

The decision must manage these recurring tensions:

• Current engineering contributors need stable constraints, while architecture knowledge and operating conditions continue to change.
• Whole-System coherence requires cross-boundary constraints, while detailed choices need local specialist knowledge and room to vary.
• A small characteristic set makes trade-offs visible, while omitted affected Systems or scales can move the burden outside the chosen boundary.
• Early estimates are cheaper than realization, while integration and operating evidence are often more decision-relevant.
• Architecture moves such as modularity, reuse, distribution, or standardization can reduce one burden while increasing others—for example, coordination, evidence, latency, supply, cost, or failure-coupling burdens.
• Current contributors need one selected option as a common decision basis, while rejected or deferred alternatives can remain valuable when the environment, technology, or evidence changes.
• AI-assisted synthesis and analysis can widen and criticize alternatives, while authority, accepted loss, and the engineering decision still require an identified decision subject and adequate grounds.
• A decision that is easy to supersede supports continuing change, while a decision with no stable identity or effectivity cannot coordinate implementation and configuration.

SYSE.6:4 - Solution

Apply C.32.PAD to the Systems Engineering decision. Compare candidates only when their engineering consequences are visible enough for the current commitment. Select the smallest set of project-shaping structures needed to coordinate later Work. State accepted losses and open refinements, then state which later results—for example, from realization, integration, configuration, specialist, assurance, or operating Work—can confirm or reopen the choice.

SYSE.6:4.1 - Perform the Move

1. Bind the architecture question. Name the actual engineered System or intended referent, composite project Work, decision subject, deciding Agent, use, configuration or variant, operating envelope, horizon, and the later decisions this architecture choice must coordinate. If the intended System does not yet exist, keep its referent in claim content as required by C.32.PAD. When the decision requires authority, cite the independently obtaining direct authority relation with its bearer, scope, basis, applicability, and interval. If that relation lacks a governing rule or does not obtain, candidate analysis may continue. Report the missing rule or authority relation; do not treat an assignment or record’s presence as authorization.
2. Select the project-shaping structures. Identify the selected structures whose alternatives can change several downstream choices or a protected characteristic. Examples include functional, constructive, placement, control, transformation-flow, information, evidence, Method, Work, and organization structures. Name each structure and the relation under discussion; important, cross-cutting, and hard to change are prompts, not membership tests.
3. Prepare candidates for the decision. Start with a compatible SYSE.5 account or a qualified direct source for functional organizations, candidate bearers, allocations, interfaces, and conflicts. Add provider-arrangement constraints from SYSE.8, description evidence from SYSE.7, specialist results from SYSE.9, and engineering claim assessments from SYSE.10 only when they fit the same subject, configuration, use, horizon, decision, and evidence window. For each input, state what it describes and which claim it can support. Evidence informs the decision but neither authorizes nor entails it; a specialist result answers only its receiving question under its stated conditions. If an input is unavailable or incompatible, use a qualified direct source or record the missing result. Keep a candidate only when its unsupported dependencies—for example, bearer, interface, realization, integration, configuration, or evidence dependencies—are visible as bounded residuals that the decision subject can knowingly accept.
4. Define the criteria before evaluating. Select a small set of C.32.ACS rows tied to this use and decision. For every characteristic, name the bearer, scale or qualitative frame, operating conditions, protected loss, comparison use, and guardrail or reopen reading when one is justified. Keep non-equivalent characteristics— for example, safety, performance, cost, resilience, changeability, or evidence burden—in separate rows unless the decision supplies and justifies an aggregation Method that preserves the distinctions it uses.
5. Compare coherent candidates. Compare whole proposals rather than isolated module choices. Include decision-relevant consequences—for example, expected functioning, physical principle, interfaces, placement, failure containment, realization and integration dependencies, supply and provider conditions, configuration continuity, operating and maintenance effects, affected Systems, evidence burden, or change consequences. Use A.19.CPM, C.11, or another direct comparison or choice pattern for the claim actually being made.
6. Challenge the preferred option. Ask which omitted structure or affected System could reverse the preference. Examine the relevant existing analyses and observations under their configuration, conditions, and claim limits. Before commissioning further Work, use C.11.DUA to compare it with proceeding on the present basis, narrowing the commitment, or stopping. Include what the inquiry could change, its cost and delay. Applicable evidence requirements govern that choice. The challenge may use specialist criticism, computation, simulation, prototype or bench tests, integration trials, or operating observation. For challenge Work whose result the decision uses, keep its performer, Method, configuration, conditions, and claim limits recoverable from that result; reuse the existing account where it is sufficient. Use an AI-produced ranking or architecture description as one input. The identified deciding Agent remains responsible for the choice. A claim of physical adequacy needs evidence about the physical System; selecting an option with stated residual uncertainty does not assert that stronger claim.
7. Make the decision relation explicit. Fill the current ArchitectureDecisionRelation@Project with the candidate basis, selected option, affected structures, criteria and trade-offs, accepted losses, rationale, consequences, effectivity and currentness claims, horizon, and rejected or retained alternatives. A bounded exception is a decision only when its scope, cost, protected loss, and reopen condition are explicit.
8. Fix constraints and preserve refinement freedom. State the decision-relevant constraints—for example, structure relations, interfaces, allocations, variation policies, or characteristic guardrails—that later Work must preserve. Separately state which implementation details and lower-scope structures remain open. Establish Work assignments, authority, commitments, and permissions through their own relations rather than through the architecture decision.
9. Name the engineering uses. Identify the receiving Work and the constraint or question it needs. Where later Work can change the grounds for this choice, connect its relevant result or return condition to the affected architecture question and decision subject. Use an existing compatible decision or configuration account for these connections when it already supplies them. Supply compatible selected-structure constraints and reconsideration conditions to SYSE.3, SYSE.13, and SYSE.18 only where they change the receiving design choice. During decision Work, use SYSE.9 to request a specialist contribution when one is needed. Use SYSE.7, SYSE.10, or SYSE.4 for a current description gap, evidence question, or assurance question. Each receiver rechecks subject, configuration, horizon, authority, and compatibility.
10. Design the continuation. For each material assumption or accepted loss, name the event or observation that calls for reconsideration—for example, a source change, actual-structure comparison, characteristic reading, failed interface, changed use, or affected-System consequence. Name the decision subject and the question to reconsider. A threshold crossing supplies an observation, not an automatic replacement decision.
11. Check what actually obtains. After realization or integration Work, compare the observed configuration and selected structures with the decision content. Record divergence and evidence separately from the decision and its description. Supersede the decision when the smallest material changed claim alters the selected option, accepted loss, fixed/open boundary, or receiving Work.
12. Stop at coordination sufficiency. Return when affected practitioners can tell what current structures and constraints guide their Work, what remains open, which losses are accepted, which result they must return, and what can reopen the choice. Do not wait for complete detailed design.

This list is a learning and reasoning aid, not a lifecycle or temporal order. Work such as candidate development, specialist analysis, realization preparation, evaluation, configuration, or architecture revision can overlap. A result dependency states which earlier result the receiving decision Work needs; it does not prescribe when each producing Work occurrence must finish.

SYSE.6:4.2 - Record the Result

Record the decision with C.32.PAD. For Systems Engineering use, include the following content in the decision relation and its cited subjects:

An ADR-like file or architecture description can publish parts of this result through C.32.ADR and C.30.AD. Identify its correspondence to the decision relation. Ground the actual architecture and later Work’s use of the decision independently.

SYSE.6:4.3 - What Changes in Practice

The engineering project stops collecting local choices and starts making a bounded, inspectable commitment across the structures that constrain several contributors. Downstream teams receive constraints and questions their Work must answer. Detailed design remains free where the decision leaves it open, and later integration or operating evidence can supersede the smallest affected decision rather than forcing either silent drift or a whole-project restart.

SYSE.6:5 - Worked Case: Architecture Decision for the Heat-Pump Plant Controller

Engineers using SYSE.5 have developed two alternatives for the same occupied-building heat-pump plant. In A, local unit controllers carry protection and normal regulation while a supervisor sends bounded set-points. B adds thermal storage and tariff scheduling; its local controllers retain protection and regulation.

The decision is which architecture should guide engineering of configuration HP-2 for the next three heating seasons. The architecture board is the decision subject; a separate project relation gives it authority for that choice. The assignment and decision record do not create that authority.

Continue the SYSE.5 proposals with additional stipulated design inputs: a thermal/hydraulic account and a compatible sensing and control arrangement. These are premises of this worked case, not reported plant results. If the sensor-variant conflict in SYSE.7 remains open, follow that return before relying on the storage comparison below.

Both proposals use the same building heat-demand and weather envelope, comfort requirement, communication-loss condition, installation window and budget. Compatible unit results and design analyses support both at the scope of the architecture commitment; whole-plant qualification is still required before operation. Seasonal energy and storage-cycling claims remain unresolved as shown below. Layout and supply estimates leave both options within the window and budget, with the required maintenance access.

After protection and comfort, the building owner gives priority to less installation disturbance and a smaller added maintenance burden. Peak-period flexibility is desirable but is not a current requirement. The board compares the complete arrangements under those conditions:

Present choice. The board selects A. Both proposals meet the conditions needed for this bounded commitment, and A is better on the owner’s stated priority. B’s supported peak-shifting possibility does not override that priority while flexibility remains optional and its seasonal economic advantage is unknown. No aggregate score is needed. The board accepts A’s lack of the modeled two-hour shift, continued exposure to peak-period purchases, and the possibility of a later retrofit. It does not claim that A has the lowest lifetime cost.

The resulting ArchitectureDecisionRelation@Project fixes these structures:

• local protection remains within each unit boundary and does not depend on supervisor or utility communication;
• supervisory set-points stay inside declared unit operating envelopes;
• plant-state and command interfaces carry units, timestamps, quality, validity, fallback, configuration and effectivity conditions;
• a later storage branch enters through the declared thermal, control, configuration and assurance interfaces.

Algorithm choice, hardware supplier, detailed state estimator and user-interface design remain open provided they preserve those constraints. The controller and integration teams use the constraints while shaping controller, bench, installation and integration Work with SYSE.3. Configuration and interface-version Work uses SYSE.13; utility-signal authority and service conditions use SYSE.18. Model and trial results are assessed through SYSE.10, and assurance through SYSE.4. Each receiving practitioner applies the relevant Method to produce the needed result; the architecture decision supplies constraints and questions.

Changed premise. Suppose the utility contract now requires that same two-hour compressor stop while the building’s comfort requirement remains. The accepted flexibility loss is no longer admissible. Reopen the A/B choice: with the other stated premises still current, B’s heat balance supports selecting it for further engineering, while A’s does not support the new requirement. The board can make a new decision for the remaining horizon; this does not qualify B for operation. Preserve the local protection constraint and still-applicable unit results, and return the storage, charging-control and integration questions to their receiving work. If the relied-on storage calculation or installation premise fails, reopen that unsupported branch instead of treating the new contract as proof that B works.

A lower tank price alone would not automatically overturn A: the board would examine whether it changes the burden comparison or the owner’s priority. Unknown seasonal savings remain unknown. Communication-loss failures, comfort or cycling guardrail crossings, changed utility-signal semantics and material installed divergence also retain their named return to the affected architecture question.

After integration, compare the actual installed Systems and relations with the decision content. Different wiring, fallback or control allocation is an implementation divergence even if the architecture record was left unchanged. The decision, its later supersession and evidence of the obtaining plant configuration remain separate.

SYSE.6:6 - Biases to Watch

Three recurring biases matter here. Record-presence bias treats a complete diagram or file as a current decision; recover the selected option, constraints, accepted losses, effectivity, and reopen conditions. Single-score bias lets a modularity measure, connection count, maturity level, or aggregate score hide different bearers and losses; compare decision-specific criteria. Software-transfer bias imports a software architecture example as a general engineering rule; recheck the physical realization, operating conditions, and evidence of the engineered System.

Agents may contribute when their capability and assignment fit the needed work. The deciding Agent remains responsible for the choice under the applicable authority and evidence conditions. Application DPFs supply the subject-specific Methods and safeguards needed for the engineering question.

SYSE.6:7 - Conformance Checklist

SYSE.6:8 - Common Failures and Repairs

SYSE.6:9 - Consequences

Engineering contributors gain a current structural commitment that is strong enough to coordinate their Work and narrow enough to preserve local design knowledge. Accepted losses and unresolved residuals become visible. Realization, configuration, assurance, operation, and maintenance receive explicit questions and return conditions. The architecture can evolve through superseded decisions rather than through undocumented drift.

The cost is deliberate comparison and continuing maintenance of decision identity, descriptions, evidence, and effectivity. Some candidates remain open longer, and a preferred local solution can be rejected because it moves an unacceptable burden elsewhere. That cost is bounded by selecting only the project-shaping structures and the smallest evidence capable of changing the decision.

SYSE.6:10 - Rationale

C.32.PAD already supplies the transdisciplinary architecture decision relation. This specialization changes the Systems Engineering move: candidates must expose use, functional organization, actual or intended bearers, physical and informational interfaces, realization and integration feasibility, affected Systems, and specialist evidence. The decision turns the selected option into constraints and result conditions for realization, configuration, integration, assurance, operation, maintenance, and later checks of the actual structure.

SYSE.6:11 - SoTA and Source Use

Practice question. In a project using FPF, how should engineers choose among developed architecture options and keep that choice useful when realization, integration or operation changes its grounds?

Selected answer. Combine proportionate decision analysis with an explicit fixed/open boundary and connections from the decision to receiving engineering work and back. Use the direct comparison and choice Methods for selection; use C.32.PAD for the commitment, accepted losses, refinement freedom and reconsideration. The Systems Engineering contribution is to fill those connections with the actual realization, interface, configuration and evidence dependencies that could change this choice.

A serious alternative is NASA’s Systems Engineering Handbook, §6.8, especially §§6.8.1–6.8.1.2.5. It distinguishes mandatory and enhancing criteria, scales the analysis to the decision, examines whether reducing uncertainty is worth its cost and delay, allows closely ranked alternatives to reach the decision maker, and separates a recommendation from the authorized choice. Adopt these disciplines in §4.1 steps 4–7. They support the qualitative A/B choice in §5; neither a compulsory aggregate score nor exhaustive inquiry is needed.

NASA §6.5, especially §§6.5.1.2.2–6.5.1.2.3 and the configuration-verification activity connects approved baselines, change authority, impact evaluation and verification of implementation. A project applying these together can maintain an architecture decision through change. Its actual arrangement may already supply the connections used here.

The remaining practical question is what this choice constrains and what a later result can overturn. For HP-2, the ordinary supplier choice remains open while local protection and command limits remain fixed. The new two-hour curtailment requirement changes the acceptability of the flexibility loss and reopens the A/B decision. It preserves the still-valid local-protection basis. That is the connection made explicit in §4.1 steps 8–11 and the engineering-return position in §4.2: the receiving work, its relevant result or changed condition, and the affected architecture question stay joined.

Adapt decision-analysis and configuration information to these bounded engineering uses. The C.32.PAD fixed/open and source-return distinction supplies the general move; the HP-2 filling is authored here. Compared with a choice report and product baseline that leave those connections for each receiver to reconstruct, this account gives the installer, controller developer and architecture board a shared answer about which change needs which decision. If the existing report and configuration arrangement already give that answer, cite and use them. This pattern calls for no duplicate account or replacement of their change authority.

The deliberate cost is identifying and maintaining the few receiving questions and return conditions that matter. Accept that effort when an engineering result can invalidate a material decision premise or expose a conflict between fixed constraints and open refinement. For a self-contained choice whose consequences need no such coordination, use the direct decision Method. The comparison supports this bounded connection and its worked changed-condition return; it supplies no measured reduction in engineering time or failure rate and no general ranking above NASA’s wider process.

Ford, Richards, Sadalage and Dehghani, Software Architecture: The Hard Parts, chapter 7, “Finding the Right Balance” and “Ticket Assignment Granularity,” pp. 24–28 provides a developed comparison of opposed consequences. Adopt its explanatory move: connect the choice to the actual interactions and priorities, and retain a disadvantage of the selected option. The heat-pump case applies that move to installation burden and peak flexibility. Reject transferring a particular software granularity choice into a universal engineering rule; the physical dependencies and qualifications in §§4–5 govern this use.

Reopen this selection if the connections fail to identify the affected decision, their maintenance costs more than the receiving use warrants, or another applicable method supplies the same decision and return with less effort and no lost constraint. Changed source or engineering conditions reopen the affected comparison. Recheck an affected AI allocation or evidence claim when the tool generation, task distribution, engineering profile or quality outcome changes.

SYSE.6:12 - Relations

• SYSE.5 describes how to produce explicit allocation choices and conflicts. Practitioners using SYSE.6 recheck a compatible result’s subject, configuration, horizon, evidence, and conditions before using it as a candidate-set input; generation does not select.
• A compatible SYSE.8 account can supply provider-arrangement constraints that change this architecture decision. Recheck its subject, configuration, use, horizon, evidence window, and availability. If it does not fit, use a qualified direct source or record the missing result. Keep the described offering or arrangement, provider Systems, performed Work, consequences, responsibility, and authority as distinct objects.
• A compatible SYSE.7 account or SYSE.10 assessment supplies evidence only when it can change this decision at the same configuration and horizon. A compatible SYSE.9 account supplies a specialist result for its receiving question and conditions. During decision Work, a conditional SYSE.9 request names the question, subject, conditions, authority, and desired result. Evidence and specialist results inform the choice; the decision subject retains the authority to make it. If an input does not fit, use a qualified direct source or record the missing result.
• C.32.PAD supplies the decision relation and the distinction among selected option, affected structures, Method and Work consequences, publication projection, and reopen conditions. C.32.ACS defines criteria rows; C.32.ACE defines eval programs and results; direct comparison and choice patterns govern their own claims.
• SYSE.6 can supply selected-structure constraints and reconsideration conditions to SYSE.3, SYSE.13, and SYSE.18 when they constrain the receiving design choice. The Agent performing each receiving Work applies its Method to generate and compare that Work’s own alternatives and checks subject, configuration, horizon, and compatibility. If the decision result does not fit, use a qualified direct source or record the missing result.
• Practitioners use SYSE.4 in assurance Work to qualify the engineering decision or identify the basis it still lacks. That assurance result is separate from architecture selection and from later acceptance, permission, release, and observed use success.
• C.32.ADR, C.30.AD, E.17, and E.24.PUB govern decision projection, architecture description, source-backed publication, and audience availability. A current decision can exist without one particular file, and a file can persist after the decision is superseded.
• Application DPFs retain the subject-specific architecture Methods and safeguards needed for the engineered System’s profile.

SYSE.6:End

SYSE.7 - Keep Engineering Descriptions Usable Together for Decisions

Status: Stable

SYSE.7:0 - Use This When

Use this pattern when an engineering decision depends on several description epistemes, but the project cannot yet tell whether they concern the same subject, compatible configurations and intervals, mutually interpretable claims, or the evidence needed by that decision.

The first useful move is to name one receiving decision and the smallest set of claims that could change it. For every description used by those claims, identify its subject, edition, reference scheme, intended use, currentness, and the Work that relies on it. State a cross-description relation only when its participants and meaning are recoverable.

The result is a decision-bounded account of usable descriptions and their relations: it names usable claims, contradictions, unsupported correspondences, omitted claims, and refresh conditions. Its technical label is EngineeringDescriptionEnsembleAccount@Project, a project-local U.Episteme. The account remains distinct from the described engineered System, the descriptions it selects, their publication carriers, configuration baselines, and evidence that their claims obtain.

Use a simpler description directly when one episteme already supports the decision and no material cross-description claim is being made. Use SYSE.10 when the problem is the credibility of an evidence source—for example, a model, experiment, or trial—for a named engineering claim; use SYSE.13, SYSE.14, or SYSE.19 when configuration identity, change, release, or a changed source edition is the governing problem.

SYSE.7:0.1 - Terms and Distinctions

Words such as model, view, specification, requirement, data, digital thread, digital twin, traceability, and single source of truth are recognition cues. Before relying on them, restore the objects and relations that matter to the decision.

Restore only the distinctions that can change the receiving decision.

SYSE.7:1 - Problem Frame

Engineering decisions rarely depend on one self-sufficient description. A controller-architecture decision can depend on a plant model and a sensor’s component specification. These epistemes may concern different subjects, scales, configurations, and intervals. They may use different reference schemes and intentionally omit different characteristics.

The difficulty is not solved by putting every expression into one repository or by declaring one model authoritative. Engineers need to know which claims support which decision, what each claim concerns, how a cross-description comparison is warranted, and what world-side or evidence result would expose a mistake. Otherwise a shared part number or generated link can be silently treated as identity and agreement.

Two symmetric failures recur.

1. One-model overreach. One favored description is expected to contain every useful engineering distinction. Its local ontology and omissions then become hidden project law.
2. Unrelated-description accumulation. Specialists maintain useful local epistemes but no one states their shared subjects, configuration applicability, interpretation, evidence, contradictions, or receiving decisions. The project has many artifacts and little joint decision support.

The general FPF distinctions support the applied engineering move between these failures: make descriptions jointly usable for decisions about an engineered System and its affected Systems.

SYSE.7:2 - Problem

A hidden gap in the description set can invalidate an engineering decision. Check whether the descriptions make the following clear:

• the receiving decision and the claim that a description is expected to change;
• each claim’s subject or intended referent, with its own identity and independently established kind;
• whether two descriptions concern the same individual, the same kind, related parts, successive configurations, or merely similarly named subjects;
• the reference scheme, scale, coordinate frame, units, tolerance, assumptions, omissions, and modeled interval;
• whether an alleged cross-description link is a representation correspondence, source dependency, configuration relation, transformation relation, evidence relation, or only a navigation aid;
• the edition and currentness of each source episteme and the Work that still relies on it;
• whether a diagram or simulation output describes a candidate, an intended configuration, an actual configuration, an observed occurrence, or a possible-future structure;
• which Agents produced, checked, changed, published, or use each result, through which Work and with what capability and authority;
• which contradiction, unsupported relation, or omitted characteristic blocks the next decision;
• what observation, configuration change, source change, or decision change requires refresh.

The result is often a false impression of precision. Every artifact may have an identifier and version while the central engineering claim remains ambiguous. Automated trace generation can multiply this impression: thousands of links exist, yet the project cannot say which direct relation each link records or which decision would change if the linked claim failed.

SYSE.7:3 - Forces

SYSE.7:4 - Solution

Maintain the smallest current set of engineering description epistemes that can change the receiving decisions, and make every material cross-description use explicit. Select descriptions from decisions and Work. Existing document inventories, notations, process presentations, and tool repositories are candidate sources rather than the selection rule.

Start with the project’s existing descriptions and review results. Reuse results that still apply to the receiving decision and whose subjects, editions and interpretations remain recoverable. When a material claim lacks that basis, recover or establish the missing comparison through :4.1 and keep the usable results for unaffected claims. This work can remain within the existing data-management arrangement.

SYSE.7:4.1 - Perform the Move

1. Name the receiving decision and its decision-changing claims. State the decision, decision subject, intended use, project focus, current option set, and the claims for which a changed value, contradiction, or evidence result could change the choice.
2. Recover each described subject. For every needed claim, identify its subject or intended referent and retain its independently established kind. A description of an engineered System concerns that System; a description of a selected organization of relations concerns a U.Structure. Distinguish an individual from its kind, one selected structure from another, and an actual configuration from a possible-future candidate.
3. Select the description uses. Choose the smallest set of description epistemes needed for those claims, and state each description’s use.
4. Identify each episteme and expression. Record claim content, EntityOfConcern, effective reference scheme, edition, source, provenance, modeled interval or effectivity, assumptions, omissions, and relying Work. Separately identify any material expression or publication object when its identity changes use.
5. State interpretation and model-use conditions. As needed by the decision, name conditions such as units, coordinate frames, scales, tolerances, abstractions, parameter sources, boundary conditions, solvers or inference procedures, and validation limits. State the project’s interpretation separately from language rules and tool capabilities.
6. Recover cross-description relations. For every material link, state its participants and relation: same subject under different schemes; part or interface correspondence; claim dependency; source derivation; configuration applicability; transformation from one expression to another; test-to-claim assessment; or another direct relation. If the project lacks a governed relation kind or evidence for that claim, record an unsupported correspondence rather than inventing a generic trace edge.
7. Check collisions at the claim level. Compare claims only after subject, configuration, interval, scheme, scale, and tolerance are aligned or their differences are explicit. Classify the result as agreement for the bounded use, an explainable difference, an unresolved contradiction, a missing interpretation, or a missing world-side check.
8. Check correspondence to realization and observation. Identify which claims describe candidates or intentions and which concern actual configurations or occurrences. Connect design claims to relevant observations—for example, from realization, integration, trials, commissioning, operation, or affected Systems—through their evidence and configuration relations. Do not let description-to-description consistency substitute for physical adequacy.
9. Choose publication forms for actual users. Publish only the forms needed by the receiving Work and its users. Reuse or author a viewpoint only when U.View membership and conformance matter. Keep the source episteme, view, publication occurrence, form, carrier, and audience use separate.
10. Assign maintenance Work. For each material entry, identify the Agent assigned to change its description, decide a contested interpretation, accept a cross-description relation, or stop reliance, together with the needed capability and authority. Specify the observations that call for refresh and the Work that will update the affected account.
11. Return the bounded result. Make the usable claims, contradictions, unsupported correspondences, gaps, reliance limits, and refresh conditions available to the named engineering decisions and dependent Work.

Description production, realization, checking, operation, and decision Work can overlap. Comparing claims still requires recoverable claim content and subjects.

SYSE.7:4.2 - Record the Result

Keep a compact EngineeringDescriptionEnsembleAccount@Project for the receiving decision. Reuse applicable existing results that supply the content below; add only what is missing or must change. It is a project-local episteme; the FPF kinds of its participants remain unchanged.

The account can use existing publication forms. Its identity and sufficiency do not depend on one storage technology.

SYSE.7:4.3 - What Changes in Practice

Engineers stop asking whether documentation or “the model” is complete. They ask whether the current description ensemble can support a named decision without hiding a subject mismatch, configuration mismatch, interpretation gap, contradiction, or unsupported world-side claim.

The Agent performing modeling Work enacts the Method; modeling tools are resources. Ground decision authority and warranted reliance on modeling results through their own relations. Traceability becomes a collection of testable relations rather than a link count. A digital thread is a maintained arrangement for named engineering uses. Use the local label digital twin only when its selected subject, descriptions, automation, observations, and use are stated.

The account includes conditions for reconsideration. A change to, for example, a configuration, source edition, environment, model assumption, trial result, or receiving decision can call for refresh. The assigned Agent then refreshes the affected claims and relations. Unaffected descriptions remain usable under their stated conditions.

SYSE.7:5 - Worked Case: Controller Architecture Description Ensemble

The project is preparing evidence for a controller-architecture decision: whether plant configuration HP-2 should use direct compressor modulation alone or modulation coordinated with thermal storage over the next three heating seasons. The plant, use, configuration, and decision focus are the same across the selected inputs. Outside-use, functional, and bearer descriptions already exist, but the decision-changing claims remain distributed across several descriptions. The engineering team constructs this bounded account:

A collision check finds that the plant simulation and controller description assume a two-hertz supply-water temperature update with an error bound of plus or minus 0.1 kelvin. The currently selected procurement variant is specified only for a half-hertz update and plus or minus 0.3 kelvin under the installed cable length and filtering arrangement. Matching the token SupplyTemperatureSensor across three tools had hidden the difference.

The engineers recover the sensor variant and interface configuration instead of merely synchronizing names. They update the model-use assumptions, evaluate another component and estimator option, and perform a controller-in-the-loop trial. The resulting evidence revises the architecture comparison: direct modulation remains acceptable for one building profile, while the storage branch remains unselected until it has either the faster sensing configuration or a different estimator and the corresponding assurance result. This evidence informs the current decision; it does not approve a later storage increment.

The account records the usable description editions, the unresolved estimator claim, the tested configuration, and a reconsideration condition tied to component substitution or a changed grid-response requirement. Controller, procurement, integration, configuration, and assurance Work use different publication forms over recoverable source epistemes while the decision-changing relations remain explicit. The result stays bounded to this decision.

If the data-management review already distinguishes the sensor variants and relates the model assumptions to the selected variant, the engineers reuse that result. When procurement later substitutes a variant, they reconsider the affected timing and error claims and the dependent architecture branch. Unchanged descriptions and qualified earlier results keep their stated applicability.

An AI System also produces a proposed cross-description summary and candidate correspondence list. Those outputs are new epistemes produced by performed Work. They are checked against source editions and accepted only where the relation and participants are recoverable. The generated confidence score supplies neither an evidence relation nor authority to alter the architecture decision.

SYSE.7:6 - Bias Annotation

This pattern resists four recurrent source and practice biases.

• Artifact bias. Sources such as standards, university curricula, tool vendors, and process descriptions often organize engineering around named documents or model kinds. The pattern preserves useful distinctions but begins from current decisions and Work.
• Official-model bias. A heavily published source—for example, a normative language, standard, ontology, or repository—may have limited or ceremonial use in projects. Official publication establishes scope and declared capability; assess practical adoption, beneficial use, shared interpretation, and current SoTA separately.
• Software-transfer bias. Software practices such as executable models, generated links, continuous integration, and automated checks can be valuable. Physical concerns—for example, realization, supply, installation, calibration, environmental exposure, or operating evidence—remain distinct and may require slower or destructive checks.
• Academic-evidence bias. A bounded study—for example, a prototype consistency checker, digital-twin mapping study, or one case—can sharpen a Method without establishing broad industrial effectiveness. Use the best available expert judgment with a stated epistemic status when comparative field evidence is unavailable; do not demand an unaffordable prevalence study or upgrade publicity to use evidence.

SYSE.7:7 - Conformance Checklist

• One receiving engineering decision, its decision subject, and the decision Work are named.

• Applicable existing results are reused with recoverable interpretations and returns to the decision; added content answers a material gap.

• Every selected description has a source episteme and edition, claim content, EntityOfConcern, effective reference scheme, configuration or effectivity where material, modeled interval, and use.

• Each claim’s subject or intended referent is identified without merging distinct subjects or kinds by name.

• Model purpose, assumptions, omissions, scale, units, tolerances, and interpretation are sufficient for the receiving decision.

• A U.View claim cites a viewpoint episteme and obtaining E.17.0 conformance; otherwise view stays ordinary source wording.

• Publication occurrence, form, carrier, rendering, and source episteme remain separate where their identities change reliance.

• Every material “trace” is resolved to a relation or marked as an unsupported correspondence.

• Cross-description comparison aligns or explicitly distinguishes subject, configuration, interval, reference scheme, scale, and tolerance.

• Claims about physical realization, benefit, safety, compliance, and acceptance use their own evidence; description consistency supplies only its stated comparison result.

• AI-generated, transformed, or summarized descriptions retain source provenance, subjects, check results, and reliance limits.

• The maintenance Agent, assignment, capability, authority, triggering observations, and refresh Work are stated for material entries.

• The returned account names contradictions, gaps, unsupported relations, accepted reliance limits, and the smallest decision or account to reopen.

SYSE.7:8 - Common Failures and Repairs

SYSE.7:9 - Consequences

Benefits. Decisions can use several specialist descriptions with their different boundaries intact. Contradictions become claim-sized and actionable. Model, configuration, and evidence changes reopen bounded uses rather than the whole project. Publication can be tailored to actual readers without changing source claims. Automation can check more relations because the relation kinds and subjects are explicit.

Costs. Engineers must maintain subject identity, editions, interpretation, configuration applicability, and selected correspondences. Some attractive links will remain unsupported. Specialists must expose enough of their assumptions for the receiving decision, and the integration team must understand where formal checks stop.

Risks. The account can itself grow into a master-model bureaucracy. Prevent this by requiring a receiving decision for every maintained entry and by retiring a relation when no current Work relies on it. Conversely, aggressive minimization can omit a slow feedback channel; the result check therefore asks what decision would become unsound if the omitted claim failed.

SYSE.7:10 - Rationale

An engineering decision can need claims from descriptions with different purposes and omissions. Preserving their subjects and configuration applicability keeps the comparison about the intended case. Exposing conflicts and connecting candidate and intended descriptions to evidence from actual realization and operation turns gaps into questions for the engineering Work that can change the System or revise the decision.

The ensemble is decision-bounded because no description is complete for every use. The same plant can require different selected structures and representations for control design and maintenance. Choose and relate descriptions by the claims that must be jointly usable now.

SYSE.7:11 - SoTA and Source Use

Working question. Once engineering descriptions are available and controlled, what further work makes their claims usable together for one decision? The selected answer is an authored combination: retain adequate data-management arrangements, then establish only the missing claim-level interpretation and applicability. Keep that result available to the decision and to the changes that can defeat it.

NASA’s Technical Data Management treatment, §§6.6.1.2–6.6.1.3 is a serious alternative. It selects needed data, addresses adequacy and consistent use, defines exchange conventions and responsibilities, and weighs acquisition burden. It also permits existing contractor arrangements when they meet project requirements. Adopt that selection and reuse principle. A tailored implementation may already provide all the content review this decision needs. Retain an applicable result whose claim interpretation, configuration basis and receiving use remain recoverable.

For a concrete comparison, give both approaches the HP-2 inputs in :5 and engineers able to interpret the sensor specifications and control-model assumptions. Either can discover the conflict between the assumed two-hertz, 0.1-kelvin bound and the selected variant’s half-hertz, 0.3-kelvin bound. Controlled exchange alone leaves that conflict unresolved. Where the existing review already connects those claims to the selected variant and the architecture choice, :4 and :4.2 reuse it. Where that connection is missing, :4.1 moves 4–8 recover the interpretation, test the correspondence and return the unsupported architecture claim. The additional useful result is a recoverable reason for limiting the storage branch and reconsidering it after sensor substitution, as :5 demonstrates. This is a conditional benefit of the added comparison, not a claim that NASA’s process precludes such a check.

Both arrangements need the specialist interpretation. This pattern additionally asks that the material correspondence, applicability and return remain recoverable. Accept the work of recording and maintaining them when dependent decisions or changes would otherwise require reconstruction or risk reusing the wrong result. For a one-off decision, a short explanation in its existing record may suffice. A maintained shared account earns its cost through actual relying Work; retire unused relations under :9. Total effort depends on how often the result is reused and how often its basis changes.

A shared semantic model is another serious alternative when recurring exchanges justify the conversion and maintenance. The landing-gear case in Wu et al. (2025) combines shared model semantics, conflict handling, traceability and versioning. Adapt that joint treatment in :4.1 moves 4, 6 and 10. Use an existing common model when it retains the distinctions needed by the decision; use explicit correspondences between specialist descriptions when conversion would lose a needed distinction or cost more than maintaining those correspondences. For HP-2, either arrangement must preserve the sensor variant and its timing and error bounds. Reject shared names or storage co-location as substitutes for that relation. The case supplies a feasible arrangement, not evidence that one architecture wins across domains.

Bound the reliance on each comparison. Riedmaier et al. (2021), §§2.5 and 7 distinguish validated conditions from the intended model application and examine uncertainty: adopt that distinction in :4.1 moves 5 and 8. Schwarzburg, Trauer and Rebentisch (2024), §§5.2–5.3 examine model history, competence, access and decision risk: adapt these as questions for a consequential unresolved reliance under SYSE.10, without importing an exploratory confidence score as an acceptance threshold. The study’s small non-probability sample cannot establish comparative industrial effectiveness. These sources limit what either data arrangement can warrant: internally consistent claims still need a qualified basis for the physical use.

For optional AI assistance, adapt the task-specific allocation proposed by Pradas Gomez et al. (2025), §§4–5. In :5, the AI System proposes correspondences; the assigned engineers check their sources and implications before accepting reliance. Tools remain resources under :4.3. The source offers a conceptual model for choosing contributions; its survey and literature review do not demonstrate this HP-2 arrangement’s effectiveness or confer decision authority.

Reconsider the choice when a material relation cannot be recovered before use, a changed configuration or source defeats its applicability, or a different arrangement supplies the same needed distinctions with less total work. Reopen the affected claims and return them under :4.1 move 11 and :4.3. A credibility gap goes to SYSE.10; a configuration-identity gap goes to SYSE.13; a changed description used by Work returns through SYSE.19. Preserve the usable remainder. This is also the limit on :12’s return to SYSE.6: only an account applicable to the same architecture decision, configuration and horizon can inform it.

SYSE.7:12 - Relations

• C.2.1 supplies episteme identity, EntityOfConcern, effective reference scheme, and edition discipline.
• C.2.P.DR repairs declarative-representation overread; C.29 applies only when a mathematical-lens use and its explicit correspondence, preserved structure, loss, and stop condition are current.
• E.17.0 supplies the dependent U.View membership and viewpoint-conformance relation; E.17 and E.24.PUB keep selected episteme, publication occurrence, form, carrier, reader, and use distinct.
• A.6.3.RT governs a representation-scheme transition when the same EntityOfConcern is deliberately redescribed; it does not establish world-side identity or the correctness of the receiving claims.
• A.10, B.3, and G.11 govern evidence reliance, assurance, and source-edition currentness. SYSE.10 specializes the return from research, models, and trials to engineering decisions.
• E.15, C.27, SYSE.13, SYSE.14, and SYSE.19 govern configuration continuity, temporal claims, change, release, and revalidation when those are the current problems.
• A compatible SYSE.1 result can supply the scope and intended-result frame for the same subject and decision. It does not prescribe Work order. If it does not fit, use a qualified direct source or record the missing result. Descriptions remain governed by their own subject patterns.
• SYSE.7 supplies evidence to SYSE.6 only when the account can change the same architecture decision at the same configuration and horizon. The account neither authorizes nor entails that decision. If the account cannot serve the use—for example, because it is unavailable, stale, outside scope, or incompatible—SYSE.6 uses a qualified direct source or records that missing result.
• SYSE.7 supplies a MethodDescription or representation input to SYSE.19 only for the named receiving use. Description order or conformance does not establish Method order or effectiveness. If the account cannot serve the use—for example, because it is unavailable, stale, outside scope, or incompatible—SYSE.19 uses a qualified direct source or records that missing result.
• When the current problem is requesting and accepting a professional contribution, apply SYSE.9 to that result and receiving decision. When neighboring Work needs a description, its governing pattern uses the source episteme through its own subject, configuration, evidence, and use relations. The Agent performing that Work applies its governing Method, and the Work produces its own result for the named receiving use.
• Engineering profiles may specialize description Methods where their subjects, formalisms, evidence, and realization relations change the working move. A profile name alone adds no pattern.

SYSE.7:End

SYSE.8 - Develop an Integrated Offering and Provider Concept for Using an Engineered Result

Status: Stable

SYSE.8:0 - Use This When

Use this pattern when a project is defining what a provider will make available and under what promise. The proposal may, for example, transfer a product, grant access to a shared enabling System, maintain an agreed condition, or accept responsibility for an agreed result, but the project has not yet connected that promise to the provider arrangement needed for the receiving use.

The result is an account that connects a bounded offering to the provider arrangement, responsibility claims, and evidence needed for it. It becomes an input to engineering and neighboring decisions. The account describes an engineering proposal; commercial viability, actual provider Systems, performed Work, duties, and authority claims require their own support.

Apply the pattern when a choice among forms of provision—for example, transfer, access, continuing provision, or responsibility for a result—changes the engineered System, interfaces, provider Systems, capabilities, risks, or realization network. A mere change from product to service wording is outside its boundary. Use A.2.3 for promise content alone; use SYSE.1, SYSE.16, and SYSE.2 when the project system-of-interest or use is unclear. Neighboring specialist practices retain their own Methods, results, and authority—for example, practices governing demand, positioning, price, finance, legal duty, organization change, continuing operations, or shared enabling Systems.

SYSE.8:0.1 - Terms and Distinctions

The everyday words in this field are overloaded. Recover the object or relation before relying on them:

Bare service is a recognition cue. At a consequential use, apply the FPF service-word recovery in A.6.P:4.11a and name the recovered referent or relation. A local ProviderSystemRole kind, an assignment occurrence, an actual provider System, its capability, its Method, and its dated Work remain different objects.

SYSE.8:1 - Problem Frame

Many engineered results are usable only through an arrangement that continues beyond transfer of a product. For example, software needs operating infrastructure and change capability; a machine may need consumables, calibration, maintenance, logistics, data, trained operators, or financing; and a promised condition such as temperature, availability, or stock level needs Systems that can observe and restore it. Changing the commercial or access relation can also change the technical architecture and the allocation of risks—for example, variability, failure, asset, or update risk.

Product-only engineering leaves those changes to later improvisation. Service-first rhetoric creates the opposite failure: every object and Work occurrence is bundled under one broad word, and the project assumes that renaming the offer creates a desired effect—for example, demand, recurring revenue, sustainability, or provider capability.

SYSE.8:2 - Problem

A plausible technical product concept can coexist with an impossible provider concept. Recurring mismatches include promising availability without observing the relevant state, retaining ownership without financing or maintenance capability, automating access while transferring exception Work to users, and depending on partner Systems whose responsibilities and interfaces are not engineered.

Four failures recur in engineering descriptions: a business model omits bearer and interface constraints; a technical architecture description omits obligations and continuing Work; an SLA omits the actual provider arrangement; and a service blueprint is treated as evidence that provision will work. Use the descriptions needed for the bounded decision, with their claims and omissions explicit.

SYSE.8:3 - Forces

The engineering decision must manage these recurring tensions:

• A useful first concept must be cheap, while the provider arrangement crosses several kinds of boundary—for example, technical, operational, organizational, financial, legal, or commercial.
• Arrangements such as product transfer, access provision, continuing activity, availability responsibility, or result responsibility allocate assets, variability, evidence, and risk differently.
• Provider Agents need freedom to choose Methods, yet promise content and acceptance claims must be explicit.
• A technically feasible arrangement can be commercially unattractive; a commercially attractive promise can be physically unrealizable.
• Partner Systems and internal shared enabling Systems can supply capability through relations that make them neither parts of the provider System nor subjects of the same project.
• Continuing change makes a frozen launch configuration inadequate; evidence must reopen both offer and provider choices.
• Current PSS and servitization literature supplies many representations and Methods. Selecting one for the current use and claiming a performance gain still require project evidence.

SYSE.8:4 - Solution

Develop client-use and provider-arrangement candidates together. Name the engineering decision that consumes each choice and obtain needed specialist results from the responsible practice.

First inspect available accounts of this use. Reuse one that already connects plausible alternatives, the provider’s and client’s decision-relevant Work, and applicable grounds to the receiving decision. If a missing connection can change the choice, develop that connection through :4.1 and preserve unaffected grounds. When the receiving use or the range of possible arrangements is itself unsettled, use the relevant PSS design work in :11 to generate candidates before qualifying them for the engineering decision.

SYSE.8:4.1 - Perform the Move

1. Bound the use and decision. Name the client-side use, intended change, receiving Systems, project system-of-interest or intended System referent, configuration, horizon, and decision. Use SYSE.1, SYSE.16, or SYSE.17 results only when they fit that subject, configuration, use, horizon, decision, and evidence window. Otherwise use a qualified direct source or record the missing result, then pause only the decision that needs it. These result dependencies do not prescribe the order of Work.
2. Recover the promise. State the consumer-facing promise content and its edition, eligibility or applicability, access terms when access is promised, acceptance conditions, and the evaluation Method and evidence needed to evaluate fulfilment. Keep each actual commitment, permission, delivery relation, acceptance relation, payment, and Work occurrence separate.
3. Name the subject. Identify what is transferred, accessed, changed, used, restored, or kept within a stated range or condition: for example, a machine, material lot, software edition, data, access point, temperature range, stock state, or performed Work. Keep non-System subjects in their recovered kinds.
4. Compare materially different candidates. Reuse applicable alternatives and generate further ones when an unresolved decision needs them. Plausible arrangements include product transfer with support, access or use provision, continuing availability responsibility, result-oriented provision, and mixed forms. Retain variety when evidence can still change the choice.
5. Develop the provider structure. For each candidate, identify the actual provider and partner Systems. Represent a provider that does not yet exist only as an intended referent in a possible-future claim. Record the relations and assignments that obtain. Then name the capabilities, Methods, recurring and exceptional Work, interfaces, resources, data, tools, shared enabling Systems, supply relations, and recovery arrangements that can change the decision. State the kind of each relation—for example, parthood, interaction, transfer, access, obligation, or contribution—and ground it independently of any intended referent.
6. Separate expected Work from responsibility and authority. For planned Work, name the intended performer Agent or the conditions for selecting one, together with the sought result. For Work that has occurred, identify the actual performer Agent and the Work independently; add assignment-bound attribution only when the receiving use needs it. Separately identify the System that holds or owns each asset; the Agent expected to bear or manage variability and failure exposure, observe or restore a condition, and receive each decision or evidence result; and any current responsibility, commitment, permission, legal duty, or authority relation.
7. Connect realization and continuing change. Identify the realization and change Work, its intended or actual performer Agents as applicable, and the Systems it uses or changes. Name the subjects changed—for example, the product, provider capability, interfaces, data, operating arrangement, or shared enabling Systems. State what later evidence or change will reopen the concept—for example, evidence from a new configuration, update, migration, maintenance event, partner change, or recovery attempt.
8. Obtain specialist results. Request a specialist result only when it can change the candidate—for example, a result from strategy, marketing, commercial analysis, finance, law, organization change, operations, supporting-System engineering, safety, security, or environmental engineering. Preserve its source and authority boundary.
9. Compare the candidates. Compare decision-relevant consequences—for example, client-side use, technical feasibility, architecture, capability, value, cost, financing, risk allocation, operational burden, changeability, evidence, or affected-System consequences. Keep non-equivalent measures separate unless an explicit aggregation Method preserves the distinctions used by the decision.
10. Record the bounded concept. Give each candidate one current disposition: select it, retain it for later comparison, branch it by a stated condition, or reject it. Record unsupported claims, needed specialist and realization results, responsibilities, evidence needs, and conditions for reconsideration. A conditional candidate is useful when it makes the next decision visible.

Use analysis, concept development, architecture, organization change, operations, commercial analysis, trials, and realization Work can overlap and reopen earlier decisions. Each receiving decision needs the particular inputs on which it relies; the numbered explanation does not determine when every activity must occur.

SYSE.8:4.2 - Record the Result

For a new account, begin with the client-side use and decision, one promise claim, the supplied or accessed subject, one actual provider System or named possible-future provider referent, one critical Work or direct relation, and one evidence gap or receiving decision. An adequate existing result can be referenced and used directly; adopting this Method does not require recopying it.

Expand this account through the moves in :4.1 only where another fact can change the current candidate. Details that cannot yet change it may remain not yet needed. Mark a needed but unavailable answer as unknown and name the claim or decision it blocks. The account can use several representations; use those descriptions as sources and ground the provider arrangement in its actual Systems and relations.

SYSE.8:4.3 - What Changes in Practice

The practitioner follows the receiving use beyond product transfer, exposes the provider’s continuing Work and the burden passed to the client, and returns their consequences to the engineering decision.

SYSE.8:5 - Worked Case: Cast-Iron Transfer, Delivery, or Replenishment

A foundry organization and a machining company must decide how an accepted grey-cast-iron lot will reach the machining plant. The lot is a material portion, not a System. They compare three arrangements for the same machining use, material specification, unloading point, and planning horizon.

A commercial lead may decide price and credit and select an arrangement only after an operations coordinator accepts its schedule. Each person has a current assignment and a separate authority relation. The assignments identify their project participation; they do not create authority.

SYSE.8:5.1 - The Three Alternatives

Current lot and gate records support gate availability, and the operations coordinator accepts the handover window. Gate transfer places little provider burden on the foundry while passing transport coordination to the machining company.

For replenishment, sensor history does not yet establish observation reliability; no finance result supports retained inventory, and no authorized commitment supplies restoration responsibility. Observation Work, replenishment Work, access permission, custody, ownership, and restoration commitment remain separate claims. The candidate remains open for a named observation test and finance decision.

SYSE.8:5.2 - Scheduled Delivery and Its Grounds

Truck-12 is the intended transport bearer. A driver selected under the qualified-driver condition is the intended Agent for the planned transport Work. The proposed PlantHandover-and-Acceptance-Lot-27 relation keeps custody with the foundry until handover at the unloading point. It lets the machining receiver accept only the identified lot, seal, mass, and visible condition against LotAcceptanceRule-7. Under proposed DeliveryExceptionRecovery-Lot-27, the provider dispatcher must arrange a replacement truck within four hours after a truck failure before handover.

Operations coordinator OC-4 has performed delivery-assessment Work using the plant’s delivery-planning Method. The resulting DeliveryScheduleAssessment-Lot-27 uses the current carrier roster, unloading calendar, and ten recent runs on the same route: nine arrived inside a four-hour window; one truck failure was recovered with a replacement in three hours. This supports planning for the 08:00–12:00 window and four-hour recovery only for this route, lot class, season, and current provider roster. It establishes neither future performance nor legal responsibility. The authorized operations coordinator accepts that schedule.

SYSE.8:5.3 - Commercial Comparison and Engineering Return

For schedule-accepted candidates, CommercialComparisonRule-2 compares quoted buyer payments plus receiving transport-coordination Work valued at EUR 50 per staff-hour. It selects a candidate only when its advantage exceeds EUR 100 and records any earlier payment obligation.

The EUR 150 advantage exceeds the EUR 100 threshold. Using the schedule assessment, the operations coordinator’s acceptance and the comparison rule, the authorized commercial lead selects scheduled delivery for this lot and retains gate transfer as fallback. The earlier haulage payment remains visible rather than being silently treated as equivalent credit. Replenishment remains a possible-future candidate pending its named observation test and finance decision.

The selection does not assert that transport, handover, acceptance, or recovery Work has occurred. The intended driver becomes an actual performer only through separately identified Work. Engineers carry the resulting product, interface, custody, Work, provider, evidence and recovery constraints into use, architecture and realization decisions. Commercial and operations decisions retain their own authority and evidence. Replacing these relations with cast iron as a service would lose the decision.

For this lot, the alternatives and receiving use are already known. Comparing lot quotations alone would prefer gate transfer; joining the receiving Work and accepted schedule grounds changes that choice. An existing procurement and operations account containing these connections would already suffice. A PSS comparison with the same connections and supplied facts reaches the same result; building another case repository or business model would need a further decision to justify it.

If the question changes to keeping stock available throughout a season, explore the plant’s consumption and replenishment activities, possible provider partners and the inventory business arrangement. That broader design work can generate alternatives to the present replenishment proposal. It still leaves the named observation test, financing and restoration commitment to their responsible practices; a promising blueprint does not supply those results.

SYSE.8:6 - Bias Annotation

Select candidate distinctions and Methods for the named engineering decision rather than importing a branded framework as a whole. Sources such as PSS, servitization, service design, SaaS, outcome contracting, or engineering of shared enabling Systems can contribute bounded alternatives. Reported economic and environmental gains are configuration-dependent. Academic popularity or official adoption is evidence of visibility or declared use, not of enacted prevalence or success.

Identify each provider or receiving System from its own basis and name the actual Agent performing each Work occurrence. Keep neighboring claims separate—for example, claims about ownership, legal duty, capability, authority, assignment, or a later provider-development decision—even when one System participates in several of them.

SYSE.8:7 - Conformance Checklist

SYSE.8:8 - Common Failures and Repairs

SYSE.8:9 - Consequences

The project can compare arrangements that change the engineered System and provider capability. Promises are matched to feasible provider arrangements and evidence plans. Technical architecture exposes operational and organizational dependencies, and specialist results reach the decisions that need them.

The cost is coordination across several practices and maintenance of corresponding descriptions. Viability and success retain their own evidence and decisions. Record unsupported promise, capability, responsibility, and evidence claims in the offering-and-provider account so that concept comparison and realization decisions can branch or stop the candidate before commitment.

SYSE.8:10 - Rationale

A choice among transfer, access, continuing provision, or responsibility for a result can change both the engineered subject and the provider arrangement that sustains its use. This pattern connects those design decisions, using the FPF distinctions at their points of application.

SYSE.8:11 - SoTA-Echoing

How much offering and provider design is needed before choosing an arrangement for a bounded use? The selected answer is to reuse a sufficient account, repair a consequential missing connection, or expand the design inquiry when the use or candidate range is unsettled. The :4 entry rule, :4.1 move 4 and :4.2 make that choice part of the Method.

A serious alternative is richer PSS comparison and design. Adopt Kim (2020), §§2.5.2 and 6.1–6.3’s connection between customer activities, actors, value, business models and detailed provision activities. Adapt its selective, iterative use of representation spaces and case analogies: use the parts that can expose an overlooked arrangement or develop an unfamiliar one. Its comparison of cases helps generate design choices but does not qualify this project’s provider capability or future performance.

Adopt Brambila-Macias, Sakao and Kowalkowski (2018), §4.3’s attention to customer networks, hidden coordination costs and organizational flexibility. Moves 5, 6 and 9 apply that contribution by recovering the work and constraints behind a price or promise. Reject quote-only selection when those consequences can change the receiving decision.

The local synthesis connects these design contributions to scoped evidence, separate specialist authority and the next engineering decision. In :5, both this account and a PSS comparison containing the same client Work and schedule grounds select delivery: EUR 42,050 against EUR 42,200. An already adequate account has no missing connection for this Method to repair. For the fixed lot and known options, further analogy or business-model development has no demonstrated decision benefit. For the changed question of continuing stock availability, that exploration can reveal different allocations and provider arrangements.

The accepted trade-off is to maintain the grounds and allocations needed for the bounded choice while deferring broader opportunity search. Each claim used in the decision still needs applicable support. Bounding the use too narrowly can hide an alternative; use the richer PSS treatment to reconsider the range of arrangements. No comparative time saving or industrial performance advantage is established by the worked arithmetic. Reopen the depth choice when a changed use, overlooked actor or continuing task, or evidence of a better feasible arrangement defeats the existing account. Reopen only the affected provider or engineering claim when a local capability, allocation or evidence condition changes.

SYSE.8:12 - Relations

• A.15.6 supplies the general project-focus and system-of-interest distinctions. SYSE.1 specializes that result for an engineering project; SYSE.16 supplies the operational use-context account; and SYSE.17 supplies consequence-bearing Systems and unresolved consequences. Compatible current results can be supplied directly; the relations do not impose a lifecycle order.
• A SYSE.8 account supplies only its supported provider-arrangement claims and design constraints to the Agents performing linked-concept, realization, or architecture-decision Work. Those Agents apply SYSE.2 to compare linked use and System concepts, SYSE.3 to develop the recursive realization network, or SYSE.6 to decide the engineered architecture.
• A.2.3 defines promise content and its acceptance-facing structure. A.6.P:4.11a recovers the actual referent or relation hidden by service or access wording. Neither pattern selects a provider arrangement.
• Organization Change Engineering changes provider organization and capability; Operations Management coordinates continuing provision; and Platform Engineering changes shared enabling Systems and the Methods used to provide or evolve them. Neighboring practices—for example, strategy, commercial analysis, finance, law, safety, security, environmental engineering, or governance—retain their own decisions and authority.
• Application profiles retain specialized offering and provider Methods—for example, software, electrical, mechanical, building, ship, transport, medical, industrial, or public-sector Methods—when their subjects, risks, evidence, or working moves differ.

SYSE.8:End

SYSE.9 - Use or Request Specialist Engineering Results

Status: Stable

SYSE.9:0 - Use This When

Use this pattern when an engineering decision needs a result from another professional practice, but the project is asking for a document, meeting, review, or job title instead of saying what the decision needs. Typical requests such as get architecture approval, send it to safety, or ask the electrical team leave the specialist question, scope, evidence, and later use unclear.

Start with the receiving engineering decision and inspect the relevant available specialist result. Return the useful answer it supports, with the limit that matters; a qualified judgement or narrower engineering conclusion can complete this use. A missing result for a stronger claim becomes a request only when its obtainable contribution warrants the whole acquisition burden through A.15.9 and C.11.DUA. Bound a selected request by the question, configuration, evidence, acceptance, authority, and intended use.

For a low-consequence exchange, the useful answer or selected request may fit in two ordinary sentences. When later reliance needs several contributions recovered together, keep a professional-contribution account connecting the actual request, expected performer, performed Work, returned result, evidence, acceptance, and receiving use where those facts matter. An inactive request needs no field or explanation. The account describes these facts and their relations. Capability, assignment, authority, Work, and result remain independently supported.

Use SYSE.17 when the first problem is finding affected Systems, SYSE.10 when research, model, experiment, or trial evidence must be qualified, and SYSE.4 when the project needs an assurance result. SYSE.9 coordinates the request, return, and engineering use. The applicable specialist DPF or direct source supplies the specialist Method, whether the question concerns, for example, law, medicine, safety, security, economics, human factors, manufacturing, software, or a physical science.

SYSE.9:0.1 - Terms and Distinctions

The terms below keep the contribution separate from the organizational labels used to find it:

A sentence such as “the refrigeration engineer supplied the compressor operating envelope” is often enough. For a consequential decision, keep the Agent, capability basis, relevant assignment, Work, Method, returned result, evidence, authority boundary, and receiving use recoverable. Agents perform the contribution Work; discipline and profession names help find Methods and candidate Agents.

SYSE.9:1 - Problem Frame

Whole-System decisions combine results from unlike practices. For example, controller selection may depend on refrigeration performance, electrical protection, control stability, maintainability, acoustics, and safety. Each specialist result can concern a different boundary, configuration, interval, characteristic, evidence standard, and authority relation.

A project loses these differences when it exchanges department names and documents. Recurring examples are an architect assumed to decide every cross-cutting question, a safety specialist asked to approve a design beyond the available evidence, an AI Agent’s report treated as the decision, and a scheduled review treated as completed Work.

The opposite failure is administrative overload. For example, a small calculation acquires a responsibility matrix, fixed role catalogue, approval workflow, and document template, yet the receiving engineer still cannot say what result would change the decision. The remedy begins with the engineering question, not with an organization chart.

SYSE.9:2 - Problem

Producing or using a specialist result raises the following questions where they affect this receiving use. An available qualified result can finish the answer before new production is considered. If acquisition is selected, a request may leave the performer or Method unresolved while naming the resulting limit.

1. Which engineering decision or Work is waiting, and what could change because of the result?
2. What should the specialist return, and what kind of result will it be?
3. What subject does the result concern? For a System claim, which configuration, environment, use, interval, and assumptions bound it?
4. What Method, inputs, and evidence can answer the question, and where do they stop applying?
5. Which Agent can perform the Work within a current capability envelope, with the needed access and resources?
6. Which assignment, permission, authority, commitment, or responsibility relations matter, and what independently supports each one?
7. What will the receiver do with the return—for example, rely on it within a stated limit, reject it, request repair, or reopen the receiving decision?

When these questions remain hidden, documents move and approval fields fill while the engineering decision stays unsupported. A useful return may instead identify a blocker, such as missing evidence, capability, authority, input, or an applicable Method, together with the decision that cannot yet proceed.

SYSE.9:3 - Forces

• Specialists need freedom to use their own Methods, while the receiving decision must compare results without erasing their limits.
• A contribution kind can remain useful when its performer changes, but capability, access, authority, workload, and conflicts depend on the current Agent.
• Assignment can make Work admissible without showing that Work occurred or produced an adequate result.
• Early collaboration reduces translation loss; independent criticism can expose shared assumptions. The consequence and conflict of interest determine which arrangement is needed.
• Informal conversation is often enough for a small reversible choice; high-consequence reliance needs recoverable scope, provenance, evidence, authority, and acceptance.
• Bounded contribution Work may be performed by any Agent with supported current capability, including a human, collective, AI, or robotic Agent. Allocate the Work from that evidence rather than from a species label or automation claim.
• A discipline evolves over years, while a project requests and performs dated Work now. These are related but not successive stages of one process.

SYSE.9:4 - Solution

Use the available specialist result within its supported scope for the engineering decision. Select a new contribution only when its obtainable value warrants acquisition. For that branch, bound the request, retain the supplier’s Method, enable a capable Agent, and assess the return before relying on it.

SYSE.9:4.1 - Perform the Move

1. Name the receiving decision. State the question, alternatives, deciding Agent, Work that will use the result, and consequence of delay or error.
2. Use the present result and select any further acquisition. Inspect what the available result supports for this decision and return its useful answer and material limit. If further inquiry is live, use A.15.9 and C.11.DUA to compare its attainable contribution with preparation, qualification, supplier Work, delivery, interpretation, delay, displaced work, and alternatives. For a selected request, name the bounded calculation, constraint, objection, observation, or other result that supplies that contribution. A competent specialist review may already supply this answer. Use that return; reconstruct only a missing connection that can change its use, rather than requiring another account of the same result.
3. Bound the result. Name its subject and the applicability dimensions that could change the answer. For a System claim these may include the actual or intended System, configuration, part, environment, affected System, use, interval, scale, and assumptions.
4. Retain the supplier’s Method and evidence. For a selected acquisition, the specialist practice identifies its Method, source family, inputs, observations, uncertainty, and non-use boundary. A missing Method limits the promised result; investigating it is another acquisition choice under step 2.
5. Choose and enable the performing Agent. Check current capability and the conditions that affect this Work, such as access, workload, conflicts, resources, and tools. Establish an assignment only when it matters. Establish permission, authority, commitment, or responsibility separately and from its own governing relation.
6. Perform and identify the Work. Keep planned Work distinct from dated Work. Record the enacted Method, inputs, performer, relevant assignment, and production of the result. A ticket, calendar entry, generated activity trace, or tool label does not prove this Work.
7. Assess and use the return. Check its subject, configuration, provenance, evidence, uncertainty, limits, and acceptance conditions. Accept it within a stated reliance limit, reject it, request repair, choose another contribution when its acquisition is worthwhile, or retain the blocker in the useful answer.
8. Observe and reopen. Use later evidence—for example from integration, realization, operation, affected Systems, or assurance—to reopen the smallest affected request, assignment, Method use, result, or engineering decision.

Step 2 can finish with the supported answer; steps concerning a new request or Work open only for that branch. Several Agents may perform specialist Work concurrently and return partial results iteratively. A title cannot replace a requested result, an assignment cannot replace Work, and a produced result cannot replace its assessment and use.

SYSE.9:4.2 - Record the Result

Use an ordinary sentence for a small reversible exchange. Where further reliance needs a shared account, include only the following content that changes its interpretation; a missing-result limit need not become a request or an omission certificate:

Several requests may serve one decision, but each result retains its own subject, Method, performer, authority boundary, evidence, and use. The account is an episteme for reasoning and coordination; it is not the Work or the world-side relations it describes.

SYSE.9:4.3 - What Changes in Practice

Instead of “sending the model to safety” or “waiting for architecture approval,” engineers request a result that a capable Agent can produce and a receiving decision can use. Missing inputs, capability, authority, evidence, or applicability become visible before they turn into late integration failures.

Useful returns include the requested supported result, a bounded objection that narrows or rejects the current proposal, and a blocker. If no current Agent can produce the needed result, the next decision may, for example, develop capability, obtain an external contribution, change the Method, or change the architecture. Those are subsequent organization, capability, procurement, or engineering decisions; SYSE.9 makes the need visible without absorbing those practices.

Distinguish a missing result within an adequate contribution arrangement from a failure of that arrangement. A bounded trial can answer a timing question when capability, access and decision rights are already established. Repeated incompatible requests to the same specialists, unavailable shared capacity, or unsettled rights to change a common design instead raise a work- or organization-design question. Name which receiving decisions the present arrangement cannot support, the affected Work and the constraint to change. The first useful return is that bounded design need for the responsible organization or capability practice. Preserve the specialist results and current decisions that remain supported while that wider question is resolved.

SYSE.9:5 - Worked Case: Contributions to a Heat-Pump Controller Decision

A project is deciding whether a heat-pump controller should use direct compressor modulation alone or coordinate modulation with thermal storage. Its first coordination table contains rows labelled controls, electrical, acoustics, service, and safety. Files have been uploaded, but the deciding engineer cannot tell which configuration each result concerns or whether any result can change the decision.

The project first resolves the title rows into the results below and inspects the uploaded files for their actual support. An adequate result is reused. For each still-missing contribution, the project selects a request only when the obtainable improvement to the decision warrants its full acquisition burden. Several individually worthwhile requests must also fit together within the decision window and shared specialist capacity:

SYSE.9:5.1 - Use the Qualified Return Already Available

Suppose inspection finds an electrical return E17 that already identifies the controller, inverter and wiring editions for both candidate arrangements, states the constraints, supplies adequate grounds and names its acceptance and decision-right boundaries. Those conditions match the receiving decision. The ordinary return can be: “E17’s qualified electrical constraints apply to both configurations considered here. Use those constraints in the controller comparison within E17’s stated limits.” This completes the electrical contribution; it does not claim the controls, acoustics or release results. Repeating the electrical review or rebuilding its account would supply no missing ground.

SYSE.9:5.2 - Select a Worthwhile Missing Contribution

The controls request exposes a different situation. An AI Agent has produced an optimization report, and its provider interface labels the run verified. The assignment covered parameter search, not validation, physical trial or the architecture decision. The missing connection is from the proposed parameter set, through an applicable stability assessment and observations, to the claim that the named controller configuration may enter trial. Recovering that connection identifies the needed contribution.

For this illustrative decision, suppose an existing controller remains an admissible fallback. A controls specialist has a suitable stability check and controller-in-the-loop protocol. Preparation, execution, interpretation and return require six hours, and an exclusive bench slot permits completion before the decision. The project estimates EUR 900 for the complete burden, including displaced Work, and EUR 1,600 for the obtainable decision contribution relative to the fallback. These are stated decision assumptions, not measured trial success. The comparison supports obtaining the contribution while the separate time and resource conditions hold.

The selected request names the proposed configuration, the stability and trial-entry question, the required observations, the decision time and an acceptable return of either a supported conclusion or a material limit. The specialist retains the controls Method. The selected Work supplies observations that SYSE.10 qualifies; the engineer then uses the returned result for the controller choice. The provider label supplies none of that missing qualification. If the useful return cannot arrive in time, reconsider acquisition for this decision and use the supported fallback when the other conditions permit it. Later research needs its own receiving use.

The refrigeration team returns a blocker: the supplier data and available tests do not cover the low-ambient, high-storage-charge region used by one candidate. The project can run another trial, restrict the operating envelope, choose another compressor, or change the storage strategy. Refusing an unsupported approval has made the next engineering choices clearer.

The deciding engineer uses each accepted result only within its stated scope. The project neither merges the specialist Methods nor transfers all authority to a “chief architect.” Later commissioning observations reopen only the claims and architecture choices they can affect.

SYSE.9:5.3 - Recognize a Changed Work-Design Question

Now suppose several controller projects repeatedly compete for the same controls specialist and bench. Product teams can change a shared controller release, but no agreed arrangement settles joint priorities or who may authorize those changes. The earlier assumption that a selected request can obtain an exclusive slot and return under established decision rights no longer holds across this work.

Another request for a controls report cannot settle those shared constraints. Return the design need: establish how these projects obtain controls analysis, bench access and decisions on the common release. Work or organization design must compare arrangements, using actual process demands, stakeholder constraints, capability and authority. Its burden includes gathering that evidence, comparing and enabling arrangements, transition and observation in use. It can propose, for example, a shared service with agreed priorities or capability in the product teams; neither proposal establishes its feasibility by being named.

The bounded-result Method still identifies what each engineering decision needs and preserves an E17 or controls result wherever its conditions remain applicable. The wider Method must resolve the recurring arrangement. Keep those two contributions connected: an organization chart does not qualify a controller, and a qualified controller result does not establish shared capacity or decision rights.

SYSE.9:6 - Bias Annotation

Formal engineering literature often proposes arrangements such as fixed role catalogues, review boards, and maturity ladders, especially for regulated public or military programmes. Software practice often proposes cross-functional teams, fast feedback, DevOps, and platform arrangements. These are candidate Methods and organization arrangements for their domains, not evidence that one arrangement fits every engineering project.

Evidence about a candidate Agent can come, for example, from credentials, prior Work, professional membership, and tool-supported trials. Use each source only for the capability or relation it supports; current capability, assignment, authority, performed Work, and result adequacy remain separately established. Apply the same rule to human, collective, AI, and robotic Agents: allocate bounded Work from current evidence and observe the result.

Public sources such as standards, university courses, and publications show declared practice and public attention. They do not by themselves establish enacted prevalence or better project results. When comparative field evidence is not affordably available, state the expert estimate and its uncertainty.

SYSE.9:7 - Conformance Checklist

Check the conditions needed by the claimed result. A reuse-only answer asserts no new supplier Work; a selected request or performed Work retains the applicable conditions below.

• The receiving decision, deciding Agent, relying Work, and consequence are named.
• A useful available answer and its material limit can finish the use, including a return from an adequate existing specialist review. Any new request has an obtainable contribution worth its whole acquisition burden and states a bounded result rather than a title or document.
• Subject, configuration, environment, interval, assumptions, and non-use boundary prevent application to the wrong case.
• A selected acquisition retains the supplier’s Method, inputs, expected evidence, and acceptance conditions, or names the missing basis without automatically assigning an inquiry.
• The performing Agent has a supported capability envelope and the needed access and resources; assignment, permission, authority, commitment, and responsibility remain separate claims.
• Dated Work, enacted Method, performer, production relation, and returned result are recoverable when the decision consequence requires them.
• The receiver accepts within a reliance limit, rejects, requests repair, selects another contribution, or records the blocker and affected decision.
• A missing result remains distinct from a recurring capacity or decision-right problem. The latter reaches the responsible work- or organization-design practice with the affected decisions and constraint to change.
• Reopen conditions name the later change that can invalidate the result instead of requiring a generic periodic review.

SYSE.9:8 - Common Failures and Repairs

SYSE.9:9 - Consequences

Specialist results arrive in a form that an engineering decision can use. Missing capability, inputs, authority, and evidence become visible early; dissent and applicability limits survive integration; and a performer can change without redefining a discipline.

Consequential contributions require more explicit scope, provenance, and acceptance than title-based coordination. The account becomes unnecessary administration if it is kept without a receiving decision, so use ordinary sentences for small reversible exchanges and add structure only where it changes reliance or action.

SYSE.9:10 - Rationale

Whole-System decisions depend on results from unlike professional practices. The FPF distinctions between local system-role kinds, assignment, capability, Method, Work, production, evidence, deontic relations, and decisions help engineers establish how each result was obtained and how it may be used.

Engineers begin with the integrating decision, use available support, select worthwhile further acquisition, preserve each specialist Method and authority boundary, and make the useful answer or blocker available. Using the results together does not merge the contributing practices into one discipline.

Professional culture and project Work remain different structures. A discipline may vary, select, and retain new Methods over years. A project may select one of those Methods for intended use before it is enacted. Claim actual project use only after capable Agents perform dated Work under the needed enabling arrangements and enact the Method; accepted results and later evidence separately support continued use.

SYSE.9:11 - SoTA and Source Use

The working question is: for this engineering decision, what specialist answer can be used now, what additional contribution is worth obtaining, and does obtaining it require a change to the work arrangement? The selected line is proportionate decision support with an explicit connection from specialist result to receiving use. Use an adequate established review directly; recover a consequential missing connection; take an unsettled contribution arrangement to the Method that can change it.

A serious alternative is a competent specialist review using applicable reports, understood limitations and established decision rights. NASA’s Systems Engineering Handbook, Revision 2 (2016), §6.8 already scales decision analysis to the problem and considers whether uncertainty reduction warrants its cost and delay. Adapt its proportionate use of evidence to specialist requests, retaining its wider analysis when the whole comparison of engineering alternatives needs it. The table applies both answers to the same heat-pump conditions.

The local constructive move connects the receiving claim to the specialist’s Method, performed Work, actual result and permitted reliance, adding detail only where that connection is missing. This makes the next useful action recoverable when files or title-shaped requests obscure it. An established review that already supplies the connection achieves the same result without extra apparatus. The deliberate trade-off is narrow scope: this pattern exposes and coordinates the needed contribution; specialist analysis, ranking whole engineering alternatives and changing organizations remain substantive supplying work. The worked comparison supports this conditional choice, not a measured general advantage in speed or project success.

Three further source contributions change that choice or its limits:

• Adapt: Grote et al. (2025), institutional abstract. The authors propose deriving role bundles from process and stakeholder evidence, assessing relevance, effort and complexity. It is a serious organization-design alternative for :5.3, rather than a title catalogue. Its wider evidence burden is warranted when the arrangement is the question; require no such reconstruction to reuse E17. The abstract reports three industrial cases and limits from workshop judgement, clustering and regulated transfer. It supports this boundary comparison, not reproduction or validation of the full algorithm.
• Adapt: Waterson et al. (2025), pp. 1–7 distinguish choices of action from points where their consequences must be judged. Steps 5–7 and the controls case use that distinction to separate parameter search, trial evidence and deciding authority. Its exploratory models and experiments leave allocation criteria open. Reject treating that proposal as an established assignment of legal responsibility or as evidence that an AI output carries decision authority.
• Adopt: METR’s 24 February 2026 study-design update shows why selection, changed tasks, quality and concurrent work constrain a productivity interpretation. It is failure evidence against inferring current task capability or value from an aggregate AI productivity claim. Step 5 therefore requires grounds for this Work, and :5.2 still needs controls qualification. Its software observations do not qualify refrigeration or controller behaviour.

Reopen the affected reliance when configuration, capability, authority or available time breaks the connection to the receiving decision. Recompare the chosen way of working when an adequate review supplies the same return with less burden, or recurring failures show that bounded requests leave the contribution arrangement unresolved. A later source changes the choice only through the claim or Method contribution it can support.

SYSE.9:12 - Relations

• A.15.9 and C.11.DUA govern bounded result use and the value and feasibility of further acquisition. The engineering decision retains its configuration, integration, protection, and acceptance conditions.

• The cited FPF patterns A.2, A.2.1, A.2.2, C.3, F.4, F.6, and E.10.ROLE distinguish System recognition, local system-role kinds, classification, assignment, capability, and Work attribution. SYSE.9 uses those distinctions; it does not create an engineering-title ontology.

• C.20 identifies an admitted U.Discipline as a durable practice-and-knowledge whole. A profession name remains a Plain retrieval cue until the relevant culture, classification, institution, credential, or authority relation is identified. The Agent, rather than either label, performs the contribution Work.

• A.3.1, A.3.2, A.15.1, A.15.2, and A.15.PROD distinguish Method, MethodDescription, planned Work, dated Work, and result production. A request, assignment, Work record, returned result, delivery, acceptance, and use remain different objects or relations.

• A.2.8, A.2.8.PER, and the applicable domain governors keep commitment, permission, authority, and responsibility separate. Use A.6.RCD when a needed relation has no admitted governor.

• Work guided by SYSE.7 maintains decision-usable descriptions; Work guided by SYSE.10 qualifies research, model, experiment, and trial results; Work guided by SYSE.4 builds an assurance result. These results can contribute to one engineering decision without becoming one Method or a mandatory temporal sequence.

• Work guided by SYSE.9 can produce a specialist result for a SYSE.6 decision only for the stated question and conditions. The result neither entails the architecture decision nor transfers the deciding Agent’s authority. If it is unavailable or outside scope, the receiver uses another supported source or records the missing result.

• Organization Change Engineering supplies Methods for changing positions, units, assignments, authority, and capabilities when the contribution arrangement must change. Operations Management supplies Methods for coordinating continuing Work. Administrative Work maintains recurring records, access, and schedules. Procurement or provider Work obtains an external contribution. These remain distinct from requesting and using the specialist result.

• An applied engineering profile should specialize this pattern only when its Systems, risks, evidence, or professional Methods change the working move. A profession label by itself adds no profile pattern.

SYSE.9:End

SYSE.10 - Assess Research, Model, and Trial Results for an Engineering Decision

Status: Stable

SYSE.10:0 - Use This When

Use this pattern when an engineering decision relies on a knowledge or evidence input such as a theory, heuristic, model, simulation result, benchmark result, experiment, prototype trial, test result, operating observation, or research paper, but the project has not said what engineering claim the input supports, where that support stops, or how the decision changes.

Begin with one sentence: “This decision may rely on this claim about this subject, configuration, use, and interval.” Then connect each source or produced result to that claim and state whether it supports, contradicts, narrows, or leaves the claim unresolved. The first useful result is a bounded engineering claim assessment that names the decision effect and the stronger nearby claim that remains unsupported.

A small reversible choice may need only that sentence and its source. A fuller assessment is useful, for example, when several evidence bases disagree, the result must survive handoff or delay, automation obscures provenance, or an error would be costly. The assessment is an episteme about evidence use and its decision effect. It cites the separately identified sources, subjects, Work, results, and any assurance or acceptance decision on which it relies.

Use A.10 directly when ordinary evidence reliance needs no Systems Engineering specialization. Use C.28 for causal, interventional, or counterfactual support; C.11 when deciding whether one further probe is worth its cost before a local choice; and a specialist experimental-design Method for a set or sequence of experiments. For an ordinary assessment that must explain an extension or combination, use the inference construction in SYSE.4:4.4 and the combination rules in SYSE.4:4.6, as applied in :4.1.1 below. Their use here needs no assurance conclusion. Use the wider SYSE.4 Method when assurance or a release-facing consequence is the actual question. Scientific and specialist practices retain their own research Methods.

SYSE.10:0.1 - Terms and Distinctions

The same research word can name a Method, dated Work, a result, or a publication. Restore the object and relation needed by the engineering claim:

A dashboard or report may display several of these objects together. Identify each object and relied-on relation before using the display in an engineering decision.

SYSE.10:1 - Problem Frame

Engineering decisions often precede complete knowledge. Models make alternatives cheap to explore; experiments and trials expose selected parts of reality; operating observations arrive only after use. Each can be valuable without supporting the whole decision.

For example, a heat-transfer model can compare storage concepts while saying little about installation error. A controller bench can expose timing and interface faults while omitting occupants and seasonal operation. A field trial can support one configuration in one environment while leaving rare failures and another variant unresolved. A formal proof can establish a property of a formal object while leaving the implementation-to-model correspondence unsupported.

Projects fail in both directions. Scientific or mathematical prestige is promoted to a universal engineering law, so “the model says” or “research proves” dictates the design. Or useful partial knowledge is rejected because it cannot settle the whole outcome. The engineering move is to use the strongest claim supported by the current basis, state the stronger claim it does not support, and show what changes in the decision.

SYSE.10:2 - Problem

A decision-usable assessment answers seven questions:

1. Which decision and alternative can change?
2. What claim about which subject, configuration, environment, use, interval, scale, and criterion is at issue?
3. What theory, model, observation, prior result, or other source is current, and what are its transfer limits?
4. Which Agent performed the dated Work that produced each result, which Method did that Work apply, and which inputs, tools, and physical or simulated subject did it use?
5. Why does the result support or challenge this claim, and which extension or joint premises does that inference need?
6. What could overturn the reliance—for example, a rival explanation, shared assumption, configuration mismatch, failed trial, or affected-System consequence?
7. What decision effect follows—for example, a changed choice or constraint, another probe, postponement, redesign, or stop—and what later change reopens the assessment?

Without these answers, validated, verified, passed, peer reviewed, and AI confidence become authority labels. Conversely, not proved becomes an excuse to ignore a well-scoped result that should change a reversible choice.

SYSE.10:3 - Forces

• Waiting for exhaustive evidence can destroy opportunity; relying on an unbounded claim can create avoidable harm and rework.
• Useful models omit detail deliberately. The missing structure matters only when it can overturn the decision.
• Simulations and formal analyses run quickly; later physical conditions such as manufacture, installation, wear, environment, and use may dominate the eventual result.
• Different practices use verification and validation for different subjects and relations. One universal ladder hides the current engineering question.
• More evidence costs time and can repeat one shared assumption. C.11 governs one next local probe; specialist experimental design governs a non-myopic set or sequence.
• Independent criticism can expose common-mode error; collaboration can repair subject and interpretation mismatch. Neither arrangement is always superior.
• AI Agents can generate artifacts such as models, tests, scenarios, and summaries at scale. The same scale can amplify source opacity, benchmark leakage, hidden tool changes, and integration errors.
• Counterevidence—including failed trials, abstentions, contradictions, and out-of-envelope results—can matter more than the positive cases favored by publication and project reporting.

SYSE.10:4 - Solution

Assess each engineering claim against the results actually available, preserve the distinction between model behavior and physical evidence, and supply a supported reliance limit to the receiving decision. An authorized Agent uses C.11 or a specialist experimental-design Method when further evidence is a live alternative: the choice determines whether to obtain it and, if so, which Work to undertake. This choice and any resulting probe or experiment design remain separate from the later assessment of available results described here.

SYSE.10:4.0.1 - Keep Different Decision Inputs Distinct

Keep each decision input’s kind explicit. An evidence-bearing result keeps its kind; state how it bears on a named claim under A.10. An objective, reward, loss, or heuristic enters C.11 as the evaluative or choice-rule input it actually supplies; a number does not make it evidence. A novelty or surprise characterization remains a characteristic claim. Use SYSE.10 to assess the engineering claim and its evidence use. The deciding Agent separately applies C.11 to choose a current option or record a next-probe result.

SYSE.10:4.1 - Perform the Move

1. Name the decision and claim. State the alternatives, deciding Agent, consequence, needed interval, and claim whose support can change the choice. Bind the claim to a subject, configuration, environment, use, interval, scale, and criterion.
2. Recover the current knowledge basis. Identify the relevant source epistemes and editions, including explanations, hypotheses, heuristics, models, mathematical lenses, observations, prior Work, and contradictory results. State their currentness and transfer limits. Evidence does not define the claim it supports.
3. State what each result can distinguish. Name the rival claims or alternatives, applicable conditions, inputs and controls, measurements, sensitivity, uncertainty, and the result that would leave the decision unchanged. If the live problem is choosing one further probe, use C.11; for an experiment set or sequence, use a specialist experimental-design Method.
4. Qualify model and representation use. State the modeled subject, purpose, assumptions, omissions, parameters, boundary conditions, solver or inference Method, verification, calibration, validation, uncertainty, sensitivity, and extrapolation boundary needed by this claim. Use C.29 for a mathematical correspondence and loss account.
5. Identify Work, observations, and measurements. Keep planned Work separate from dated Work. Name the performing Agent, enacted Method, tools, resources, subject configuration, inputs, controls, disturbances, result production, calibration, measurement interval, uncertainty, and missing data to the degree the claim needs.

6. Explain the inference and construct the evidence use. Start with the result’s own claim and show why it bears on the receiving engineering claim. Reuse a sufficient direct result or specialist argument with its conditions. Where the receiving claim extends or combines results, construct the missing connection through

   4.1.1. Retain the target, polarity, actual grounding subject when relevant, source scheme, scope, relevance window, provenance and unsupported use. Use C.28 for a causal or counterfactual step.

7. Compare and criticize. Try to make the relied-on results hold while the receiving claim fails. Examine the consequential extension or joint premise, including shared assumptions, implementation-to-model gaps, configuration mismatch, rival explanations, contradictory results, selection effects, extrapolation and affected-System evidence omitted by the original study. Keep an unsupported inference distinct from evidence that actually contradicts the claim.
8. Record the assessment and decision effect. State what is supported, contradicted, narrowed, or unresolved; the reliance limit; residual uncertainty; and the stronger blocked claim. Then state the resulting engineering action—for example, choose, narrow, postpone, redesign, seek evidence, or stop. The assessment itself supplies neither the decision nor its authority.
9. Stop and reopen deliberately. State why the current basis is enough for this decision. Record a compatible C.11 result or specialist experimental-design result when further evidence is chosen. Name the later change that would matter, such as a change to a relied-on source, configuration, environment, use, Method, capability, observation, or claim.

Evidence-producing Work may overlap, iterate, or occur in another order. A physical trial can precede simulation during reverse engineering; operating evidence can reopen theory and architecture; a formal check and bench trial can address different claims concurrently.

SYSE.10:4.1.1 - Explain What Makes the Results Sufficient

Use the developed inference and combination instructions in SYSE.4:4.4 and SYSE.4:4.6 for the part of this assessment that is missing. The receiving result remains an engineering claim assessment. These instructions do not require the other assurance activities when no assurance claim is being made.

Work backward from the needed claim. Recover what the receiving decision actually requires. A temperature claim and a compressor-cycling claim may both be necessary; evidence for one cannot compensate for the other. Identify which available result addresses each necessary premise or operating case. When several arguments instead offer alternative grounds for the same claim, determine whether any one is sufficient. A source may generate a candidate, explain a phenomenon or report an association without supplying the support this decision needs. Keep that useful contribution in its own role.

Follow each contribution forward. State what its Method and performed Work directly establish under their own conditions. Then explain the consequential step to the receiving claim. For an exact qualified measurement against the same criterion, the comparison itself may finish the assessment. A sufficient specialist argument can be cited with its applicability and limits; neither a second diagram nor a new trial is required.

An extension needs its actual reason. For example, a prediction about an installed controller needs a justified correspondence between the model’s inputs and the installed configuration. A component limit needs a reason that interactions and operating conditions preserve it in the whole System. Follow A.1.1 for model applicability and C.28 for causal support when those contributions are missing. State which premise has support and which remains an assumption, why that assumption is allowable for this use, and which inference loses support if that premise is false. An assumption cannot substitute for evidence required by the receiving rule. Unknown units, configuration or timing cannot be repaired by relabeling the result.

Explain the join. Check that the necessary results apply together: the same configuration and operating cases, compatible definitions and units, and no omitted interaction on which the conclusion depends. Use the domain’s combination rule and its qualifications. Bounds on consecutive parts of one path can bound its total only when they cover that whole path under compatible conditions; component averages or confidence ratings do not supply those bounds. Do not add uncertain quantities or multiply confidence values without the appropriate measurement or probability relation. Two accounts copied from one trace do not add an independent observation. Preserve shared premises so that a correction can reach every dependent use.

Challenge the reason and return the surviving claim. Could every listed result still be true while the required claim is false? An untested operating region, unrepresented interaction or different interpretation of the same word may expose that possibility. Resolve an action-changing challenge using the available domain results or keep the whole claim unresolved while retaining supported parts. A failed bridge removes its support; it establishes a contrary physical claim only with further grounds. When several necessary premises are established and their joining rule suffices, return the bounded assessment and its decision effect. Stop there unless a separately selected inquiry could change that use. Section :5.2 works this join, and :5.3 changes one premise without discarding the independent result.

SYSE.10:4.2 - Record the Result

Use one claim-and-decision sentence for a small reversible choice. For several evidence bases or consequential reliance, record:

The assessment may cite supporting records—for example, model cards, trial reports, measurement records, or evidence graphs—instead of copying them. Keep the assessment tied to the receiving decision.

SYSE.10:4.3 - What Changes in Practice

Engineers stop asking whether a model is validated or a test passed in the abstract. They ask which claim about which configuration is supported for which use, which nearby claim remains unsupported, and how the decision changes. A usable assessment explains the step from each relied-on result to the claim and why the necessary contributions hold together. It can therefore retain a valid result while withdrawing a conclusion that depended on a failed transfer or shared premise.

Different inputs change different parts of the decision. For example, a theory can generate an alternative, a heuristic can guide search, a simulation result can reject an infeasible region, a failed trial can expose an interface assumption, and an operating observation can reopen a model-use claim. Each input keeps its governed kind and epistemic status. Additional evidence is obtained only after an authorized Agent chooses the probe or experiment design under the applicable Method.

SYSE.10:5 - Worked Case: Evidence for a Heat-Pump Controller Increment

A heat-pump project is deciding whether to integrate a first controller increment that coordinates compressor modulation with thermal storage. The claim is:

For the named controller, sensor, and plant configurations, the controller keeps supply-water temperature within the declared comfort envelope and avoids harmful compressor cycling in selected low-ambient and tariff-response situations inside the qualified compressor-map region.

The project uses several unlike results:

SYSE.10:5.1 - Finish with an Exact Sufficient Result

Suppose the immediate question is whether the completed one-hour trial met its declared 40–45 °C supply-water criterion. Its qualified measurement result gives 41.0–44.0 °C with a conservative 0.2 °C uncertainty bound covering that recorded interval and the named setup. The resulting 40.8–44.2 °C range lies inside the criterion. The engineer can finish: “The temperature criterion was met in this recorded trial under its qualified measurement conditions; use that result in the increment assessment.” This does not yet assess another operating interval or the cycling criterion. Repeating the measurement or creating a full account adds no required contribution to this direct question.

SYSE.10:5.2 - Construct the Missing Join for the Increment

Now consider the stronger receiving claim: the named increment can keep supply water within 40–45 °C and space compressor restarts by at least ten minutes over the selected low-ambient and tariff-response use. For this constructed example, professional qualification supplies the following results. The numerical limits are stipulated case inputs, not reported heat-pump performance or general design limits.

Let E be the common qualified envelope: the named plant, compressor, controller binary and interfaces; the selected low-ambient loads and tariff transitions; storage charge from 20% to 60%; and the specified continuous operating interval without power reset or override of the restart limiter. The engineer receives:

• M17, a qualified model-based prediction: supply water remains within 40.6–43.6 °C throughout E provided the sensed-state age at physical actuation is at most 1.0 s. The prediction treatment already includes the relevant numerical, input, parameter, model-discrepancy and transfer uncertainties. Its evidence and applicability argument are available; a numerically verified solver alone would not supply this result.
• S6, B12 and P5, qualified timing and installation results: sensor acquisition and filtering contribute at most 0.5 s of state age; execution and command delivery add at most 0.2 s; command-to-physical-actuation adds at most 0.2 s. The reports use consecutive endpoints on the same event path, include the relevant waiting and integration effects, and bound those intervals for the same E. Installation checks connect the actual binary, sensor, interface and plant configuration to those named in M17. These are conservative bounds, not averages or percentiles from incompatible runs.
• L4, a separately qualified limiter result: consecutive actual compressor restarts remain at least ten minutes apart throughout E. Its clock, logic, interface and override conditions are established separately; its conclusion does not depend on M17’s temperature prediction or the sensor update rate.

Combine the timing results before using M17. Because the three timing segments cover the complete event path under the same conditions, their bounds give a state-age bound of 0.5 + 0.2 + 0.2 = 0.9 s. This use of conservative bounds needs complete path coverage and simultaneous applicability; it does not require statistical independence. The result satisfies M17’s 1.0 s premise. The installed configuration correspondence and E then permit the prediction to support the temperature claim: its 40.6–43.6 °C range lies within 40–45 °C. L4 supplies the different necessary cycling premise. Their common applicability lets the engineer support the conjunction of these two criteria for the stated use. M17 and L4 are complementary grounds, not two votes for one claim.

The engineer returns that bounded technical recommendation to the deciding Agent. The argument deliberately depends on the supplied professional qualifications; the addition above does not derive a measurement Method or validate the model. The results leave seasonal reliability, higher storage charge, another compressor and unexamined installation or maintenance consequences outside the supported claim. Specialist criticism of an inaccessible recovery action still matters to its own integration or assurance question. Passing these two criteria does not settle every condition of integration, commissioning or permission.

If an available specialist assessment already supplies this complete inference for the same configuration, criteria and E, use that assessment and its limits directly. Section :4.1.1 is needed only for the missing connection; it does not demand reconstructing an adequate argument in a second form.

SYSE.10:5.3 - Change the Premise and Keep the Independent Result

The selected sensor configuration now supplies one update every two seconds after filtering, whereas M17’s qualified configuration used two updates per second. The applicable sensor-age bound becomes 2.0 s. With the unchanged downstream bounds, the available whole-path bound is 2.4 s, which no longer establishes M17’s premise of at most 1.0 s. The model’s old temperature prediction remains a result for its old conditions; it no longer supports the current installed temperature claim. This loss of support does not show that the actual water temperature violates 40–45 °C.

Retain the valid downstream timing results and L4’s independently established restart limit. The conjunction needed for the original favorable recommendation is unresolved because its temperature premise is missing; the passing cycling result cannot compensate. Copied plots of M17 or additional summaries of its traces do not repair that premise. The engineer returns this precise limitation and withholds the favorable assessment for the changed increment. Choosing a supported narrower use, changing the estimator, obtaining a suitable model result or repeating a controller-in-the-loop trial is a separate engineering or inquiry choice. Only a selected, feasible and worthwhile continuation under C.11 or the specialist Method creates further Work. Its returned result can then reopen the affected assessment; an empty evidence field creates no experiment.

An AI Agent also proposes fault scenarios and a trace summary. One proposed scenario invents an interface state absent from the configuration. Reject that proposal for this use. The summary can help locate traces, but the assessment relies on their actual results and justified connections. A generated confidence score neither supplies the missing state-age premise nor decides assurance, acceptance or release.

SYSE.10:6 - Bias Annotation

Sources such as official verification procedures, software test automation, peer-reviewed papers, sophisticated models, and AI benchmarks can contribute useful Methods or results. Their prestige, publication, conformance label, mathematical form, or benchmark score does not establish a universal evidence order or the project’s effectiveness.

Across physical, cyber-physical, biological, and social-system cases, the relied-on evidence may depend on configuration, calibration, integration, environment, use, or affected-System consequences that a software test or simulation does not cover. Failed trials and actual project practice can matter more than published positive cases.

Demanding definitive proof can be as harmful as overclaiming when no affordable study can settle the choice. Use the best current assessment, state its epistemic status, make the decision reversible where possible, and name the observations that would reopen it.

SYSE.10:7 - Conformance Checklist

• The receiving decision, alternatives, deciding Agent, consequence, and claim are named.
• The claim has a subject, configuration, environment, use, interval, scale, criterion, and stronger nearby claim that remains unsupported.
• Theory, model, simulation, experiment, trial, observation, evidence use, assurance, and decision remain different objects or relations.
• Source editions, Work, performer, Method, model assumptions, physical grounding, observations, measurement uncertainty, and transfer limits are recoverable to the degree the reliance needs.
• Each evidence use explains why the result bears on the target claim and retains polarity, scope, provenance, relevance window and unsupported use; causal reliance uses C.28.
• An extended or combined claim has its consequential premises, joining rule and applicability grounds; supported parts remain usable when the whole is unresolved. A sufficient direct result or specialist argument can finish the assessment without duplicate reconstruction.
• Rival explanations, common assumptions, contradictions, negative results, configuration mismatch, and affected-System evidence have been sought in proportion to the decision consequence.
• The assessment states what is supported, contradicted, narrowed, or unresolved and how the decision changes; it is not treated as authority or acceptance.
• A further local probe comes from C.11, an experiment set or sequence from a specialist Method, and the stopping and reopen conditions are explicit.

SYSE.10:8 - Common Failures and Repairs

SYSE.10:9 - Consequences

Research and model results guide decisions within their stated limits. Tests and trials address specific claims; negative and partial results can change concepts, architecture, and realization Work early.

The cost is preserving configuration identity, assumptions, measurement provenance, uncertainty, evidence polarity, and unsupported uses. Some decisions remain unresolved or receive a narrower operating envelope. Too little evidence can shift harm to other Systems; too much low-value testing can delay the project. The Agents performing Work guided by SYSE.17, SYSE.4, specialist Methods, or Methods for choosing further probes retain their respective decision authority.

SYSE.10:10 - Rationale

Engineering claim assessment connects heterogeneous knowledge and evidence results, actual configurations, and decisions. It uses the FPF patterns for evidence, measurement, causal use, mathematical lenses, dynamics, assurance, decisions, and currentness.

An authorized Agent chooses further probes using C.11 or a specialist Method and records a choice or experiment-design result. Assessment Work keeps descriptions, simulation results, and observations of actual Systems separate, preserves configuration and extrapolation boundaries, and returns a claim-specific result to the receiving engineering Work.

Research and engineering remain neighboring practices. Inquiry Work can produce, for example, explanations, observations, models, and Method candidates; engineering Work uses them while choosing and realizing changes in Systems, and later trials or operation can revise the inquiry account. Neither practice is a temporal stage or subtype of the other.

SYSE.10:11 - SoTA and Source Use

Receiving question. With the available qualified results in :5, what technical recommendation can the engineer return for the two increment criteria, and what changes when the sensor premise changes? Compare a specialist assessment centred on credible model prediction with the bounded combination of heterogeneous results in :4.1.1. Keep the same configuration, criteria, evidence access and required professional preparation.

A serious model-based answer is supplied by Riedmaier, Danquah, Schick and Diermeyer, Unified Framework and Survey for Model Verification, Validation and Uncertainty Quantification (published online 2020; journal volume 2021), §§2.5, 3.3 and 8.1–8.4. Adapt its use-specific prediction, uncertainty treatment and selection among VV&UQ approaches. Validation conditions and application conditions may differ; credible prediction must account for that difference. Its approach already has conditional applicability and trade-offs. A generic validation label is not the alternative being compared.

Choice and accepted cost. Use a sufficient specialist answer directly. Otherwise use this assessment to explain the remaining connection between unlike qualified results and the receiving engineering claim. It makes a partial technical result, a missing joint premise and their decision effect recoverable without first requiring a new model of every contribution. A competent specialist may already provide exactly that argument; in that case the answers coincide and a separate account has no demonstrated benefit.

When direct comparative evidence is unavailable and obtaining it would cost more than its value to the decision, use qualified expert judgement with an explicit epistemic status, assumptions and limits.

The narrower construction retains real dependence on domain qualification. It does not calculate M17’s error model, establish the timing bounds or prove L4’s behavior. When those results are missing, obtain the applicable technical contribution or return the gap. Count its acquisition, specialist access, computation, integration and later maintenance burden whichever assessment form is chosen. The worked comparison explains a conditional construction; it supplies no measured project saving or general superiority of one Method.

Two further source contributions change the stop or the permitted inference:

• Schwarzburg et al., On the factors influencing confidence in models and simulations for decision-making: a survey (2024), §§5.2–5.3: retain the distinction between reported confidence and qualified support. Its forty-response convenience sample and exploratory constructs concern confidence in use. They do not turn confidence into a physical temperature bound. This limits the confidence-score shortcut in :5.3; it is not a calibrated rule for combining the case’s results.
• Huan, Jagalur and Marzouk, Optimal experimental design: Formulations and computations, v2 (2024 article; 2026 corrected version), abstract: adapt the scope distinction among design criteria, computation and non-myopic sequential design policies. Use current C.11:4.2, step 5, for a worthwhile next local inquiry; return a coupled experiment programme to a specialist Method. This changes :4.1 step 9 and the continuation in :5.3. The abstract supplies this boundary, not the full numerical design procedure.

Reopen the selected assessment arrangement when the receiving claim exceeds an available result’s qualified domain, a necessary contribution or joining rule changes, or a sufficient specialist answer becomes available with less total reconstruction. Reopen the technical VV&UQ choice when a changed application or uncertainty question defeats its assumptions; the bounded assessment cannot repair that defect by changing labels. A new publication matters when it changes one of these contributions or limits, not merely because it is newer.

SYSE.10:12 - Relations

• C.2.1, A.3.1, A.3.2, A.3.3, and C.29 distinguish source and result epistemes, Methods, MethodDescriptions, dynamics, and mathematical-lens use without making them physical results.
• C.11 governs the choice of one next local probe among available options. A specialist experimental-design Method governs a set or sequence of experiments. An authorized Agent applies one of those Methods in separate decision or experimental-design Work and supplies its result to assessment Work. The Agent performing assessment Work applies SYSE.10; that assessment Work does not include the distinct Work that chooses the probe or produces the experiment plan.
• A.15.1, A.15.2, F.6, and A.15.PROD distinguish planned Work, dated Work, performer attribution, and result production. A procedure, model, report, or status does not establish Work.
• C.16, C.16.P, and A.18 govern measurement, characteristics, scales, units, uncertainty, and admissible operations. A.10, G.6, and G.11 govern evidence use, provenance, and currentness; C.28 governs causal and counterfactual support.
• SYSE.4:4.4 supplies the explanation of a consequential inference and SYSE.4:4.6 the distinction among joint premises, alternative arguments and shared evidence. This assessment can use those instructions without making an assurance claim. B.3, A.21, G.4, and the applicable acceptance and permission patterns govern the separate assurance, gate and consequence-bearing results.
• Assessment Work can produce evidence for SYSE.6, SYSE.4, or SYSE.19 only when the claim, configuration, horizon, and receiving decision match. Evidence neither authorizes nor entails those decisions.
• Results from engineering Work—for example realization, integration, operation, configuration change, specialist Work, or affected-System inquiry—become evidence only through their source and evidence-use relations. Adjacency between pattern names creates no such relation or temporal order.
• Applied engineering profiles should specialize Methods for modeling, simulation, experiments, tests, trials, or evidence use only when a domain-specific fact—such as the engineered-System kind, physical mechanism, regulation, characteristic, scale, or consequence—changes the working move. A domain noun by itself adds no profile pattern.

SYSE.10:End

Part III - Obtaining Engineering Results, Recursive Realization, Platforms, Independent Constituents, and Evolvability

SYSE.24 - Choose How the Project Will Obtain a Needed Engineering Result

Status: Stable

SYSE.24:0 - Use This When

Use this pattern when a project needs one engineering result but someone has already assumed we will build it, we will buy it, a supplier will do it, or an AI agent can handle it. The assumed answer may be attractive, yet the other ways of obtaining the same result have not been described on a comparable basis.

Start by naming the result and its actual kind. It may be, for example, an engineered System, one usable System configuration, a reusable Method or MethodDescription, access to a capability, performed provider Work, or an engineering episteme. State who will use or rely on the result, what acceptance means for that use, and when the result must exist or the Work must occur.

The first useful comparative result is a written comparison of at least two complete arrangements that would produce, perform, transfer, or make the same result available. One C.11 ChoiceResult then says: choose one arrangement or a retained tie-set now, reject the current set, perform one worthwhile probe, or reroute to another named question. Each arrangement says what result would exist or occur, which Agents would perform which Work, which Methods and Systems they would use, what relations would provide ownership or access, and what integration, configuration, assurance, support, capability, and exit conditions the project would accept.

An arrangement is complete enough for comparison when its omitted burden cannot reverse the choice. Purchase is a possible transfer or agreement inside an arrangement. An AI Agent is a possible performer inside an arrangement. Method development is an enabling branch unless the sought result is a Method or MethodDescription; in that case use A.15.6 to decide whether the Method is the project Method-of-interest for the current question. The short labels above identify parts or cues, while the comparison alternatives are whole arrangements.

The constructive move is to work backwards from receiving acceptance to the results, Work, means, and access that can make it possible; vary where those contributions are supplied; then work forwards through each proposed arrangement to expose incompatible joins and unavailable conditions. Sections 4.2–4.3 develop this move. A list of supplier or technology names is useful input, but does not perform it.

Do not create a second account when an existing engineering or acquisition comparison already supplies this result under the same conditions. When only one arrangement is lawful or available, state that constraint and its supported basis; do not invent a rival to satisfy a table. Its feasibility may still need work. If a real obtaining choice remains but no second comparable arrangement can yet be constructed, return the precise comparison gap rather than claim that the sole described arrangement is best.

Use SYSE.5 when the unresolved question is only how functions could be borne. Use SYSE.3 to develop a retained arrangement’s first unsupported realization branch, or earlier when that branch must be understood to compare its feasibility. Use SYSE.8 when the project is designing an offering and the provider arrangement that will sustain another System’s use. Specialist decisions—for example, commercial, financial, legal, governance, organization, operations, asset, and capability-development decisions—remain with their specialist practices.

SYSE.24:0.1 - Precision Restoration

An Agent performs Work. Other participants—for example, tools, equipment, supplied Systems, materials, data, and the changed subject—retain their own relations. Name the decision-making person, team, organization, or other sufficiently agentic System and use the applicable FPF agency, assignment, and authority patterns when the decision relies on that Agent.

SYSE.24:1 - Problem Frame

Several recurring failures make this difficulty visible, often only after commitment. Internal development begins because building is prestigious or familiar. A polished supplier demonstration is accepted as if integration, configuration, assurance, migration, support, and exit were already included. Outsourcing is treated as removal of engineering responsibility. A continuing provider relation is compared with a one-time purchase price. An AI Agent is placed beside a department as a short label. Comparison becomes meaningful only after each label is expanded into an arrangement that names Work, Methods, means, assignments, integration, and acceptance.

The practical difficulty is not merely make versus buy. It is constructing several ways of obtaining the same result so that each way exposes the burdens and dependencies that can change the engineering choice. Until that happens, general decision theory receives a false OptionSet: its rows seek different results, use different acceptance conditions, and hide different Work.

SYSE.24:2 - Problem

An engineering result can be obtained through many arrangements. For example, a project may adapt a System it already has, acquire a ready product and integrate it, commission a custom result, obtain continuing provider Work or access, develop the result with its own Agents, or combine several contributions. The same visible result can depend on very different conditions, such as interfaces, provider capabilities, data custody, rights, configuration evidence, support, internal capability, and recovery arrangements.

Label-only make-or-buy tables hide these differences. Developed acquisition practice already addresses integration, qualification, support, and mixed arrangements; use those contributions where they answer the question. The failure addressed here occurs when a project reduces that practice to a few familiar labels, for example by placing a purchase price beside a fully burdened internal estimate, comparing an external demonstration with an internal production configuration, omitting integration or continued-access burdens, omitting assurance, and treating contract award as if the System, access, Work, or episteme had already been accepted and used.

The opposite failure is an exhaustive procurement programme before the engineering question is clear. A project team can spend months choosing contract or tender forms while the needed result, acceptance basis, interfaces, and capability consequences remain unsettled. The first pass therefore starts from one result and stops at the smallest decision that changes the team’s next Work.

SYSE.24:3 - Forces

The following eight tensions recur in this decision.

SYSE.24:4 - Solution

SYSE.24:4.1 - Name one receiving result and one decision

State the result being sought and its actual kind; the receiving use and affected Systems; the configuration, operating conditions, horizon, and acceptance claims; the deciding Agent and the commitment it may authorize; and the latest useful decision date. If the proposed result alternates among owning a product, accessing it, performing Work, developing capability, and possessing an account, select the result that changes this commitment. The other objects may be needed inside an arrangement, but they are not interchangeable success conditions.

Make acceptance operational enough to work backwards from it. Identify what the receiver must be able to do with the result, which important conditions it must cover, and what would show that the received subject is the one described. For an engineering episteme, identify the observations and interpretive relation needed by the receiving decision. For performed Work, identify the occurrence, subject, window, and result or effect relied on. For access, identify the actual capability, eligible user, usable window, capacity, and permitted use. An access entitlement is not evidence that the task can finish within that window. For a System configuration, include the relevant interfaces and operating states, not merely a catalogue identifier.

Use existing qualified acceptance and specialist results. This pattern does not invent safety criteria, measurement validity, legal rights, or operating commitments. When the project system-of-interest or intended use itself is unsettled, return to A.15.6, SYSE.1, SYSE.16, and SYSE.2. When one criterion is unresolved, name that input and preserve the other usable parts. A conditional comparison can show which alternatives depend on its answer; it cannot authorize reliance that requires the missing answer.

Protect the conditions that cannot be traded away. State the relevant horizon explicitly: first acceptance, three years of changed configurations, repeat interpretation of retained data, or another actual use. Longer support and ownership can cost more without helping a one-time result; conversely, a cheap first result may fail a continuing need. Keep any proposed change of acceptance or horizon as a separate authorized question.

SYSE.24:4.2 - Construct alternatives by changing what is supplied

C.38 supplies the result-first comparison discipline. C.39 supplies the general move from a receiving result back to its prerequisites and forward through their connections. Here the engineering construction varies which result is supplied at each consequential boundary, who performs the remaining Work, and which means or access make that Work possible. The following development is an obtaining Method, not a prescribed lifecycle.

SYSE.24:4.2.1 - Recover how the accepted result could be produced

Begin at the receiver’s last consequential use. Ask what must have been produced or performed immediately before that use can meet acceptance. Find a domain Method or a qualified existing result that supplies it. Then ask what that operation consumes: physical inputs, observations, an identified configuration, skilled performance, authority, access, and enabling Systems as applicable. Continue backwards only through conditions that can change feasibility or the present choice. Stop at an input that is available under the needed conditions, or at an exact unsupported contribution whose acquisition must be compared. Calling an input available requires more than finding its description or owner.

For example, a pipe-replacement decision may need an interpreted condition account. That requires an interpretation Method applied to qualified observations with segment identity and uncertainty, while the observations require suitable inspection Work, calibration, equipment, and pipe access. The receiver might obtain the completed account, obtain observations and interpret them, or obtain means and perform collection as well. This is how different alternatives arise from the receiving result. Beginning with an inspection device would prematurely select one position in that construction.

Use the actual technical suppliers. SYSE.5:4.1–4.1.1 develops candidate functional and bearer organizations and explains how their interactions can realize the outside effect. Keep that causal account intact when the obtaining alternatives use it; do not derive a new physical or analytical Method merely by drawing a Work sequence. SYSE.8:4.1 can supply an offering’s promised result, receiving use, provider structure, and support conditions. SYSE.3:4.1–4.4 can expose an enabling realization branch when its availability changes the comparison. A useful existing account can supply several of these results.

The backward account distinguishes three things that often get confused: a result needed at a boundary, Work that can produce that result, and means used in that Work. A qualified measurement account is not an instrument; a maintained controller configuration is not a licence; a MethodDescription is not an Agent’s demonstrated capability to apply it. Owning the means can be unnecessary when qualified Work supplies the result. Supplying only the means can leave a substantial receiving-side capability and assurance branch.

SYSE.24:4.2.2 - Move a consequential supply boundary and close the remaining Work

Construct one plausible way through the account using known Methods and available or explicitly proposed contributions. Then change a boundary whose position affects this decision. The following transformations are useful because they change what the receiver must still make possible:

These transformations can produce ready-product, custom-provider, internal-development, continuing-service, reuse, and mixed arrangements. Those familiar labels help discovery; they do not determine the construction. Generate a second alternative by changing a material contribution, not by renaming the performer while retaining the same unsupported assumptions.

For every moved boundary, follow what has moved and what has remained. Commissioning an assembled unit may move fabrication and assembly while leaving site integration, verification, and operator preparation with the receiver. Leasing a laboratory may leave setup, qualified operators, calibration, and interpretation unchanged. Having a provider perform the test may move those operations but leave the receiving project responsible for supplying the correct article and deciding whether the resulting evidence is sufficient. Add those residual operations to the arrangement until it can reach the same acceptance condition.

Do not divide an operation merely because several providers are available. A division can break necessary coupling, obscure responsibility for the delivered result, or introduce more interface Work than it saves. Compare a combined qualified contribution with the split alternative. Conversely, an unnecessarily large package can require a scarce supplier or make change dependent on unrelated parts. SYSE.5 supplies a technical redesign when a different functional organization is needed; commercial and organization practices supply their own packaging, responsibility, and agreement decisions.

Describe each candidate as one possible future. Identify which inputs are currently supported, which are credible proposals needing qualification, and which remain unknown. An AI Agent can occur in any arrangement as a performer of named Work, for example drafting code or classifying observations. The arrangement must also provide its inputs, access, qualified receiving checks, correction, resource burden, and stop conditions. The label AI neither closes an unsupported operation nor grants acceptance authority.

SYSE.24:4.2.3 - Let available contributions reshape the arrangement

A provider’s actual capability can change the useful division. If it supplies calibrated observations but cannot supply the required interpretation, either add a qualified interpreting contribution or retain a different provider arrangement. If the receiver cannot interpret the supplied format, compare obtaining a compatible output, adding a qualified conversion, moving interpretation, or choosing different means. A file conversion that discards required observations cannot repair their absence.

Likewise, a ready System may expose only a stable supervisory interface, making a supported component plus an internal supervisory layer feasible while an internal replacement of its protective logic is not. The result of this step is a small set of causally plausible whole arrangements and their decisive gaps. It is not yet evidence that all proposed conditions can be supplied together.

Stop generation when another variation is unlikely to change the next decision at acceptable cost, using C.19 and C.11 where exploration or probe worth is current. If the effort itself needs an enduring archive, Front, lineage, descriptors, or exploration telemetry, use C.18 for that result. C.18 does not supply the domain operation for constructing an obtaining arrangement.

SYSE.24:4.3 - Follow each arrangement forwards to receiving use

Walk from the proposed available inputs through the Work to the accepted result. At each consequential handover, compare what the supplying operation actually yields with what the receiving operation requires. This can expose a defect that isolated descriptions miss: both operations may be qualified while their configuration, timing, meaning, or authority assumptions are incompatible.

SYSE.24:4.3.1 - Make the material and evidential joins work

Use an ordinary representative case and a consequential exception from the declared use. For a System, follow its inputs, states, interactions, identification, and necessary recovery. For an account, follow observations through interpretation to the claims the receiver will use. For access or performed Work, follow eligibility, preparation, actual performance, result recognition, and return from an interrupted or unsuccessful attempt. This is a feasibility walkthrough of the proposed arrangement; stronger acceptance may require performed tests or other claim-specific evidence under SYSE.4.

At a consequential join, establish compatible subject and configuration identity, physical or informational interface, units and meaning, necessary state, timing, and scope of evidence. Include custody, permitted use, and responsibility where the receiver relies on them. Carry the supplying result’s limits into the next operation. If one provider’s analysis assumes a calibration that the field team did not perform, the complete account remains unsupported even though both provider descriptions look complete.

Repair a failed join by changing something that can cause it to work: supply a different intermediate result, add a qualified transformation or preparation, move the operation to a capable performer, revise the technical interface, or obtain a larger qualified contribution. Re-run the affected continuation and update its time, evidence, support, and resource burden. A new adapter is an engineering contribution with its own realization and qualification needs; its name is not the repair. If no supported transformation is known, preserve that gap and its effect on the choice.

SYSE.24:4.3.2 - Establish that the necessary conditions can coexist

Place prerequisite Work and simultaneous contributions in the relevant windows. Distinguish elapsed time from person-time, equipment occupancy, and a contractual response interval. A sequential interpretation step starts when usable observations and its other prerequisites are available, not when collection is commissioned. Work may overlap only when its inputs, state, and resource conditions permit overlap.

Overlay demand on shared people, test facilities, data preparation, environments, and provider capacity. Two branches can each fit their own estimate while requiring the same specialist during the only permitted outage. A proposed reserve must be available at the same time as the resources it complements. Include preparation, acceptance, correction, and consequential recovery where the selected estimates do not already include them; do not count the same burden twice.

Use OPS.10:4 or a suitable domain operating Method when capacity or service feasibility is load-bearing. Request the actual result needed: for example, a finite schedule for the supplied readiness times and joint resources, an infeasibility bound, or a qualified service forecast. A total-load bound is necessary but does not establish that precedence and simultaneous-resource conditions can be met. A mean forecast is not a hard deadline guarantee. Use the returned result under its conditions and retain the operating authority separately.

The same reasoning applies to access and continued support. Equipment available on Monday is not usable for a Friday task if calibration expires on Thursday; an export permission that ends at termination may not allow the transition Work to finish. If a needed person or provider is unavailable, compare rescheduling, reserving the joint window, changing the division of Work, supplying equivalent qualified means, or changing the current commitment. Add the consequences of the repair to the whole arrangement. Do not silently move its deadline, acceptance condition, or another System’s protected Work.

SYSE.24:4.3.3 - Continue through the horizon the choice actually protects

After first acceptance, follow the changes, maintenance, repeat use, recovery, and exit that matter within the declared horizon. Ask which Work must still occur, who can perform it, which configuration and knowledge it requires, and which access or support must remain available. Retained source or raw data helps only if the receiver has the rights, Method, means, and capability to make the required use. Provider independence for reanalysis of held observations does not imply independence for future collection.

When a support relationship ends, construct the needed continuation: preserve an interpretable configuration, transfer knowledge, qualify a replacement, maintain a limited compatibility path, or deliberately end the use. Include transition and concurrent support where they affect the choice. A sale, export clause, or retirement date does not itself perform that Work. SYSE.8 supplies a provider arrangement where continuing provision is the unresolved question; SYSE.13–14 supply configuration and controlled change, and the applicable retirement Method supplies a needed closure. Do not require an elaborate exit programme for a result whose accepted use has already ended and leaves no relevant obligation.

SYSE.24:4.3.4 - Keep a common account of the constructed arrangements

Use the following questions to recover the arrangements for comparison. They summarize the construction; answering the table alone does not show that the described parts can work together.

An unknown can remain unknown when its plausible answers cannot reverse the present choice or the feasibility claim used by it. Otherwise identify the affected claim and obtain the missing contribution, compare conditional outcomes, or choose a bounded probe. Uncertainty belongs to a named part of the arrangement; it is neither a reason to discard valid parts nor a licence to treat the whole as established.

SYSE.24:4.4 - Restore parity and compare the whole alternatives

Apply the same acceptance, environment, configuration boundary, horizon, and burden categories to every arrangement. Compare ready demonstrations and proposed internal development against representative project conditions. For a provider arrangement count its fee and the receiving team’s residual integration, acceptance, retained risks, change, and exit Work. For internal development include unavailable capability, opportunity cost, qualification, support, and time until use. If two candidates share an enabling contribution, retain its feasibility condition in both and avoid counting it twice within either whole.

First eliminate an arrangement whose demonstrated consequence violates a protected condition. Keep a decisive unknown distinct from a demonstrated failure. Then compare the supported survivors under the decision owner’s preferences, including uncertainty about time and consequences. A narrower account cannot win by omitting the Work that made its competitor expensive. If filling a gap changes the arrangement, compare the repaired whole and its new burden rather than keeping the old price with the new capability.

Do not force unlike consequences into one weighted total when that would hide a protected condition or non-compensable loss. Retain a tie-set or partial order when appropriate. Use ranges or conditional consequences where those are what the evidence supports. If a supplier’s uncertain lead time crosses the last usable date, neither the average lead time nor a cheap price establishes the required timely result.

Apply C.11.CRC when the missing input is a finite change’s contribution relative to the project’s present configuration. Name S0, the change Δ, the realizable S1, and the obtaining decision that consumes the comparison. That Method supplies a configuration-relative contribution claim. It does not construct the obtaining arrangement or make the final choice.

SYSE.24:4.5 - Obtain exact specialist contributions and handle an incomplete return

Use A.15.9 and SYSE.9 when the arrangement needs a professional contribution. Give its owner the receiving result and decision, relevant subject and configuration, use and time window, exact question, supplied evidence, and what an objection or unresolved answer would change. The specialist retains the Method and authority for that contribution. The receiving engineer supplies enough context to make the answer usable and tests its fit when it returns.

Inspect a returned contribution for subject, configuration, window, assumptions, evidence, authority, and receiving use. A provider may answer about equipment availability while leaving operator availability unanswered. Accept the supported part as equipment evidence; leave the joint performance claim open. A legal answer about data ownership does not establish export timing, format, or interpretive capability. Request only the missing consequence that can change the choice, with the last time its answer would still be useful.

If the owner cannot answer, does not answer by that time, or returns an incompatible result, use another qualified source where the needed claim permits it, change the arrangement, or restrict the current decision to Work that does not rely on the gap. Silence is not evidence that a provider lacks the capability, and it is not confirmation that the dependency will be available. A commitment requiring the missing result remains unsupported. A pre-authorized fallback may use another already-supported arrangement; otherwise return the constraint to the authorized decision owner. Continue unaffected analysis instead of restarting every branch.

When the missing contribution itself needs development, expose its enabling Work and burden through SYSE.3 or the specialist Method. If its feasibility is decisive, resolve or probe it before committing to the dependent whole. Requesting it is not receiving it, and requesting a professional judgement does not make the engineering team its authorized substitute.

SYSE.24:4.6 - Choose at the commitment the evidence supports

Pass the resulting OptionSet to C.11. State the DecisionSubject, comparison basis, ChoiceRule, belief state and relevant consequence model, available authority, and the worth of a possible probe. Produce one lawful ChoiceResult: choose an arrangement or retained tie-set now, reject the current set, probe again, or reroute to a named unresolved question.

Locate a probe at a consequence that can change the decision. Describe the observations it can discriminate, the continuation under each, its people, means, access, authority, cost, elapsed time, and stopping limit. A probe whose possible observations leave the same next action unchanged adds no decision value for this question. A probe can also be inappropriate when its result would arrive after the last useful commitment. Use the actual C.11 choice inputs rather than treating this observation alone as a complete worth calculation.

State what choosing now authorizes. Selecting an arrangement for bounded preparation does not authorize live operation, contracting, acceptance, or reliance on unperformed Work. If a remaining unsupported branch could still defeat the proposed irreversible commitment, a label such as first realization gap does not make that commitment sound. Resolve the branch, restrict the commitment, or return the conditional choice. For a retained arrangement whose next Work is now justified, SYSE.3 identifies and develops the first unsupported realization branch and the responsible next Work.

The ChoiceResult remains an episteme. Producing, performing, transferring, accepting, and using the result require their own Agents, Methods, Work, and direct relations. The comparison can establish a feasible way under stated premises without asserting that those events have already occurred.

SYSE.24:4.7 - Reconstruct only what a changed condition defeats

When observations or changed conditions can reverse the choice, recover the premise that changed and trace which operations and joins rely on it. Start with the same receiving result unless its owner changes the use or acceptance. A new instrument configuration can leave pipe access intact while defeating the interpretation qualification; a lost operator window can leave the equipment’s capability intact while defeating timely Work. Preserve the valid parts and repair the affected continuation.

Construct the new whole by the same moves: change the supplied result, performer, Method, means, access, sequence, or support boundary; then follow the repair forwards through interfaces and shared resources. Recheck every surviving candidate on the changed parity basis. A repair’s extra qualification days may make an option infeasible even when the technical defect can be fixed. Reusing the old quote, schedule, or evidence after changing their premises would compare a whole that nobody has proposed.

A changed horizon deserves the same treatment. Moving from one accepted account to repeated surveys changes future collection, maintenance, capability retention, data comparability, and support needs. Moving from a three-year to a six-year controller use can expose an unsupported update or replacement period. Compare an extended arrangement, a deliberate replacement, a different provider division, and any other feasible variant; do not assume that ownership or a longer subscription is sufficient. Strategy, assets, finance, and capability owners supply their consequential new inputs only where needed.

Return the new comparison and decision, or the precise gap that prevents it. A provider failure can reopen the obtaining arrangement while preserving the project system-of-interest. A changed receiving use may require a wider return to SYSE.1 or SYSE.2. Record observed use and the continuing conditions on which the retained arrangement relies so that the next change is assessed from evidence.

SYSE.24:4.8 - Keep the first useful result recoverable

Keep one account of the decision and authorized commitment; sought result and acceptance; constructed arrangements and their residual Work; compatible interfaces and joint conditions; qualified evidence and decisive gaps; common comparison and ChoiceResult; next realization or specialist contribution; and conditions that reopen it. Existing architecture, provider, operating, and acquisition accounts may carry this content.

A comparative choice needs materially different alternatives. If only one candidate can be made comparable, state whether another way is excluded by evidence or remains unknown. Return the constraint or exact missing contribution. The amount of description is adequate when the receiving decision can be made without a decision-changing omitted burden, not when every possible lifecycle question has been filled.

SYSE.24:4.9 - Recognition, assurance, and what changes in practice

Recognition. The pattern applies when the team is arguing about buying equipment, doing Work internally, or using a provider while it is still unclear how each proposal reaches the receiver’s result. A small backward construction and forward walkthrough can expose the real alternative or the first decisive missing result.

Assurance. A plausible arrangement is weaker than a qualified feasibility claim, which is weaker than performed and accepted Work. Stronger reliance requires current capability, compatible configuration and evidence, feasible joint conditions, actual rights and authority where relied on, and the receiving use’s required acceptance evidence. Increase assurance at the claims the commitment consumes.

The practical change is that the team can generate alternatives by moving meaningful supply boundaries, discover the receiving Work each move creates, repair an incompatible or unavailable contribution, and compare the resulting wholes. It can also explain why a previously selected arrangement no longer works after a configuration, resource, provider, or horizon change.

SYSE.24:5 - Worked Cases

SYSE.24:5.1 - Climate control for a new greenhouse configuration

Small equipment company GreenHeat-4 needs a climate-control System for greenhouse GH-2. Until identity inception, GreenhouseClimateControl-GH2 remains the designator for the intended System in the WorkPlan and descriptions. The receiving use is control of heating, ventilation, misting, and shading during cold-night, rapid- solar-rise, and failed-humidity-sensor conditions. Acceptance requires bounded temperature and humidity performance, no unsafe actuator command after the sensor failure, identified software and controller configuration, recoverable observations, and a supported fallback to manual operation. GreenHeat-4’s authorized management team may choose the obtaining arrangement within its approved equipment budget; electrical-safety acceptance remains with the named specialist authority.

The team works backwards from the protected greenhouse behaviour. Actuator commands require a supported local control and protective function; greenhouse-specific optimization can supply supervisory demands only within that function’s qualified envelope. Integration must identify the sensor and actuator configuration, and acceptance must cover the failed-sensor return to safe local or manual operation. These are consequences of the supplied controls-engineering account, not conclusions obtained from a procurement label.

The team first asks who could supply the accepted controller configuration and its integration. It then moves the supply boundary: obtain a custom whole, produce that whole internally, or retain the ready protective controller and change its supervisory complement. The latter is a distinct alternative only if the actual interface permits the needed optimization without invalidating the protective behaviour. GreenHeat-4’s engineering team develops four complete arrangements:

For the hybrid, the forward account follows a greenhouse demand through the supervisory interface to local control, then follows a failed or absent demand back to the supported fallback. It also joins the controller configuration and exported observations to the acceptance evidence. The ready controller’s evidence alone does not establish these joins. The same integrator and laboratory constraints are included in the survivors’ estimates; buying a controller does not remove commissioning or acceptance Work.

The parity basis includes the same three operating conditions, commissioning date, interface set, configuration evidence, assurance burden, data access, support horizon, internal capability consequence, expected change latency, and exit condition for all four arrangements. The internal-only and commissioned-custom arrangements do not survive the commissioning-date condition. The ready-controller and hybrid arrangements remain a provisional tie-set for the obtaining decision; their unresolved protected claims prevent commitment to commissioning either one.

The two survivors have different burdens. The ready-controller arrangement is estimated at EUR 84,000, nine weeks, and eighteen days of GreenHeat-4 engineering Work; later greenhouse-specific changes require a vendor release expected to take four to six weeks. The hybrid arrangement is estimated at EUR 96,000, eleven weeks, and thirty-two days of internal engineering Work; if the supervisory interface remains supported, the controls team can make a greenhouse-specific change within five working days. The operating plan expects at least three such changes during the next three years.

The management team is authorized to commit up to EUR 7,000, forty engineering hours, two hardware-in-the-loop laboratory days, and five elapsed working days to the obtaining decision. Those limits fit the remaining one-week decision reserve without moving the commissioning date. The electrical-safety specialist may authorize the failed-sensor injection in the laboratory; that authorization does not extend to a greenhouse trial.

The management team uses this ChoiceRule: preserve the failed-sensor, configuration-identity, and commissioning- date conditions first. Probe only when the probe stays within the stated limits and every possible outcome changes what the team may lawfully do. If both arrangements survive, choose the hybrid only when its added price is no more than EUR 15,000 and its added internal burden is no more than fifteen engineering days; otherwise choose the ready- controller arrangement.

The proposed replay costs EUR 5,500, thirty-two controls-engineering hours, eight integrator hours, two laboratory days, and five elapsed working days. It uses the intended sensor and actuator interfaces and injects the failed- humidity-sensor condition while checking configuration export and the supported supervisory API. Its possible observations and execution outcomes have four decision effects:

• an unsafe local fallback or a configuration export that cannot reidentify the tested controller and software rejects both survivors and returns the team to arrangement generation;
• a safe fallback and usable configuration export combined with failed supervisory timing or withdrawn API support rejects the hybrid and retains the ready-controller arrangement;
• a safe fallback, usable configuration export, and supported API within the timing limit retain both survivors; the price-and-burden branch of the ChoiceRule then selects the hybrid arrangement; and
• an interrupted or inconclusive replay that cannot settle the protected claims within the authorized limits leaves those claims unresolved. The team stops that probe and returns reroute to the commissioning-plan decision; extending the probe, moving commissioning, or committing despite the gap needs its own supported decision. An unknown result is not recorded as a demonstrated controller failure.

ChoiceResult-GH2-1 is probe again. Choosing either arrangement without the replay would leave a protected acceptance claim unsupported, while rejecting both would discard a survivor that one bounded replay can retain. This worked case stops at that first useful result. APP-SYSE-04 continues the case through performed replay and a later choice. In this case the replay must settle the protected acceptance gap before commitment to an implementation arrangement. After an arrangement is retained, SYSE.3 develops its first unsupported realization branch; it can also be used earlier if a proposed probe’s own means or capability are unsupported.

SYSE.24:5.2 - Obtain a pipeline-condition account rather than an inspection device

WaterUtility-North must decide which pipe sections enter its next replacement programme. The sought result is engineering episteme PipeConditionAccount-2027 for twelve kilometres of buried pipe; an inspection device is only one possible means. Acceptance requires stated coverage, location error, uncertainty for wall-loss estimates, blind-sample checks, raw observation access, configuration and date of the inspected pipe segments, and a supported relation from observations to replacement decisions.

The backward construction reaches an identified interpretation of calibrated observations, then the field Work that can obtain those observations from the selected pipe segments. It stops at suitable instruments, calibration, qualified field performance, and usable access. Moving the supply boundary yields four arrangements: obtain the account, own means and perform collection and interpretation, obtain qualified collection and interpretation without equipment ownership, or obtain compatible observations and interpret them internally. The utility’s engineering team compares these arrangements:

• a specialist provider’s field team performs inspection Work and supplies interpreted results but keeps the raw data;
• the utility acquires inspection equipment; its engineering team develops internal capability, performs the Work, and maintains the equipment and analysis Method;
• the utility leases equipment while the provider’s qualified field team operates it and the provider’s analysts supply raw observations and interpreted results; and
• a provider’s field team performs data collection while the utility’s engineering team controls the interpretation Method, acceptance checks, and continuing data custody.

The whole arrangements expose different calibration Systems, field access, operating interruption, performer capability, data rights, configuration identification, blind-sample evidence, support, future repeatability, internal capability, cost, and exit conditions. A purchase price is not compared with a provider invoice alone. The internal arrangement includes training, qualification, equipment maintenance, field Work, analysis, and the cost of delaying the replacement decision. The provider arrangements include acceptance and rework conditions, raw-data access, repeatability, and recovery if the provider leaves the market.

The utility needs the account once within three months and has no present inspection-equipment capability. Its asset-replacement board is authorized to choose the inspection arrangement within a EUR 250,000 ceiling and to allocate at most thirty utility analyst-days. Operations separately authorizes pipe access and interruption; the board cannot supply that result itself.

The equipment-purchase arrangement fails the time condition. The interpretation-without-raw-data arrangement fails the evidence-custody and exit conditions. The Finance result compares funding, the Operations result states pipe-access and interruption conditions, and the legal-practice result states data and remedy terms. The board uses those results but does not replace their Methods or authorities.

For the survivors, the field capability evidence supports the stated instrument family, pipe material, and collection Method. The Operations account supplies feasible access and interruption windows for either arrangement; a field release still has to establish that the actual day’s conditions match that basis. This is not a presently unsupported claim that the windows can exist. The board’s choice permits arrangement preparation within its authority, while access release and inspection remain separate Work.

The forward walkthrough follows each segment identifier and calibration state into the raw observations and then the analysis. The open format retains the observations, configuration, and uncertainty inputs the utility Method needs; the utility’s analysis replay uses that format. The two identified analysts can supply the twenty-four required analyst-days in the four-week interpretation window after collection without displacing protected operational Work. The thirty-day ceiling is therefore not being mistaken for an available schedule. The two survivors are compared on the same basis:

The board’s ChoiceRule first rejects any arrangement that misses acceptance, raw-data custody, or the three- month limit. Among survivors, it prefers the arrangement that the utility can reproduce after provider exit when its total price stays within EUR 200,000 and its internal burden stays within thirty analyst-days. If the utility capability evidence or either resource limit fails, the rule retains provider interpretation instead; if both interpretation claims fail, it returns probe again on one shared blind dataset.

The evidence supports the utility-interpretation branch. ChoiceResult-PCA-2027-1 is choose now: the provider’s field team performs collection and the utility’s engineering team controls the interpretation Method, acceptance checks, and raw-data custody. A further probe would not change which arrangement survives because the utility capability and both resource limits have already been checked on the common basis. The choice records the qualified basis for field collection and interpretation and their conditions. The next realization Work establishes the actual access release and ready field configuration under the supplied Operations conditions; it does not use the obtaining choice as permission to interrupt service. A failure of those conditions reopens the affected arrangement. Contracting, field Work, blind-sample acceptance, acceptance of PipeConditionAccount-2027, and pipe-replacement decisions still require their applicable Work.

SYSE.24:5.3 - Changed instrument configuration defeats one arrangement

Before mobilization in the pipeline case, the specified inspection instrument becomes unavailable. The provider offers configuration B. The same pipe segments, three-month deadline, budget, and acceptance conditions remain. Configuration B supplies a different calibration representation and wall-loss observation schema. The field team and provider analysts have representative B evidence that meets the supplied conditions; the utility analysts’ earlier replay covered configuration A. Its six successful blind samples do not establish B competence or compatibility.

Trace the changed premise. Field access and segment identity remain valid. The join from observations to the utility’s interpretation Method is unsupported, so the old EUR 185,000 and twenty-four-day arrangement is no longer a complete candidate for B. The team constructs three possible repairs from that join:

• obtain A-compatible observations through a qualified provider conversion;
• adapt and qualify the utility interpretation for B before applying it; or
• move B interpretation to the already qualified provider while retaining raw-data custody and utility acceptance Work.

The provider confirms that its export can preserve A’s column names, but has not established that it preserves the calibration meaning needed by the utility Method. The requested substantive answer does not arrive by the last useful decision date. The export answer is retained as a file-format fact; the interpretation claim remains unknown. The team does not equate silence with impossibility, and does not rely on the unqualified conversion.

The responsible specialists supply a bounded adaptation and qualification plan requiring eight additional utility analyst-days and EUR 9,000 before interpretation. These are stipulated requirements of this proposed repair, not measured general costs of a configuration change or a guarantee of successful qualification. The repaired total is EUR 194,000 and thirty-two analyst-days. The price still meets the board’s preference, but the whole exceeds its thirty-day allocation. No qualified additional performer or change to that allocation is available within the decision window. Checking only the price or counting the eight days separately would preserve an infeasible candidate.

The provider-interpretation arrangement remains supported for B at EUR 230,000, eight utility analyst-days, and eight elapsed weeks, including its qualification, raw-data return, and eighteen-month analysis support. The revised operating account confirms that these eight weeks still fit before the unchanged due date, including the time already spent seeking the conversion answer. The board’s existing rule therefore returns choose now for that arrangement for B. It accepts the stated reanalysis dependency rather than claiming that the former independence survived. It retains the utility’s qualified A Method and earlier data for uses they still support. A later qualified conversion or development proposal can reopen the B comparison; it does not retroactively support the rejected commitment.

SYSE.24:5.4 - A longer use requires a different support arrangement

Suppose GreenHeat later needs the retained controller arrangement for six years rather than the three-year horizon compared in §5.1. The first-use result and failed-sensor criterion remain, but the known vendor support ends after year three. Source access to the internal supervisory layer does not supply controller updates, replacement hardware, or qualification of future configurations.

The engineering team follows those unsupported continuations and constructs two bounded alternatives: obtain qualified support through year six, or retain the three-year arrangement and prepare a replacement before its support ends. The first needs an actual support offer covering the controller and interface configurations. The second needs a feasible replacement, data and configuration continuity, migration and requalification Work, and an overlap window that the greenhouse operation can tolerate. Both include the receiving team’s continuing Work and the relevant financial consequences. A promise to decide in year three supplies neither alternative.

With no six-year support commitment and no qualified replacement account yet available, the current result is reroute to those exact support and realization contributions. The three-year comparison remains useful for its original horizon, but cannot justify a six-year reliance. If a six-year commitment must be made now, the deciding Agent must obtain a feasible whole or change the commitment under its authority; extending the heading on the old account is not a support solution.

SYSE.24:6 - Bias Annotation

The pattern favours one decision-usable result over a complete procurement programme and comparable whole arrangements over familiar labels. Constructing from acceptance makes residual Work and hidden dependencies visible, but can take more effort than reusing an adequate existing acquisition or realization account. Use that existing account when it already answers the question.

The pattern does not develop the specialist Methods for market engagement, tender, contracting, law, public accountability, finance, organization, capability development, or post-award operations. Their qualified contributions remain necessary where the obtaining choice relies on them. The engineering construction also depends on actual domain Methods; drawing connections cannot establish their physical or analytical validity.

Preserving non-dominated or conditional alternatives can delay a familiar commitment. The useful limit is the smallest decision-changing gap and its last useful return time, not indefinite exploration or a requirement for certainty about every later event.

SYSE.24:7 - Conformance Checklist

The following eleven requirements form this pattern’s complete conformance checklist.

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

The following rows document recurring failures and their repairs.

SYSE.24:9 - Consequences

Projects gain a comparable choice before architecture, integration, supplier, capability, and assurance commitments become difficult to reverse. Reuse, acquisition, provider Work, access, internal development, and mixed arrangements can be considered without pretending that their short labels identify equivalent objects.

The cost is that an apparently simple purchase decision becomes an engineering decision with explicit interfaces, configuration, evidence, support, capability, and exit. Another practice may have to answer a named question first, so the first result may be a retained tie-set or one worthwhile probe rather than an immediate winner.

SYSE.24:10 - Rationale

General decision theory can compare options only after they answer the same decision question and carry a shared comparison basis. C.38 supplies the general arrangement comparison and C.39 the construction of a usable whole from available contributions. The domain move developed here is constructing complete ways of obtaining an engineering result across a designated project system-of-interest and its builder arrangements when those structures matter, together with provider and internal Work, interfaces, configuration, assurance, and continuing change.

The obtaining arrangement is the unit of comparison. Comparing whole arrangements keeps their different contributions visible: an AI Agent can perform Work in several arrangements; Method development can enable an arrangement or be the sought result of a separate project.

The pattern stops before procurement becomes a universal Systems Engineering Method. Specialist areas—for example, market engagement, contracting, incentives, tender, public authority, finance, organization, and provider operation—have their own problem families and evidence. Systems Engineering keeps their consequences connected to the engineered result without taking over their decisions.

SYSE.24:11 - SoTA Echoing

The following source contributions have different force: standards scope, professional guidance, research synthesis, and an economic model. Their use here does not establish universal effectiveness of this obtaining Method or transfer a specialist decision into Systems Engineering.

SYSE.24:11.1 - Compare with a developed acquisition and implementation account

A strong professional baseline can already answer much of this question. NASA’s design-solution and product- implementation guidance considers alternatives, enabling resources, qualification of reused products, readiness, and the support needed after delivery. SWE-033 additionally addresses mixed software arrangements and comparable assurance. Applying those contributions fully to GreenHeat would already prevent comparing a controller’s catalogue price with a fully burdened internal-development estimate, or assuming that a purchased controller’s prior evidence automatically covers the greenhouse configuration.

The additional use of this pattern is to make the receiver’s obtaining construction explicit when that account is still missing: identify the accepted outside result, change which intermediate result or Work is supplied, close the residual receiving operations, and test their joints and common conditions. In GreenHeat this exposes the supported local-protection/supervisory division as a candidate requiring its own interface evidence. In the pipeline case it exposes an account, observations, performed inspection, and access to equipment as different possible supply boundaries rather than equivalent outputs. General selection receives these constructed arrangements only after their consequences are made comparable.

This is a conditional contribution, not a claim that competent NASA, procurement, or domain practitioners lack such reasoning. If their existing account already supplies the whole comparison and continuation, use it directly. Re-describing it in this vocabulary would add cost without improving the decision. The worked cases show the proposed Method’s operation under stated inputs; they do not measure a time saving or comparative field effectiveness.

SYSE.24:12 - Relations

• A.15.6, SYSE.1, SYSE.16–17, and SYSE.2 supply project focus, receiving use, environment, affected Systems, and linked use-and-System concepts where those questions remain. Consume their actual result and acceptance scope; a changed obtaining provider alone need not reopen the project focus.
• C.38 supplies result-first comparison of ways of obtaining or developing a result. C.39 supplies the backward and forward construction of the whole and selective repair after change. Sections 4.2–4.3 supply the engineering operation that varies supplied results, residual Work, means, and access. C.18 preserves an open-ended generation effort only when needed; C.19 governs its exploration policy. Neither supplies the technical Method missing from an arrangement.
• SYSE.5:4.1–4.1.1 supplies functional/bearer alternatives and their joint functioning. This pattern consumes that technical account and constructs ways of obtaining its result; a supply-boundary change that requires another technical organization returns that exact question. SYSE.6 supplies consequent architecture decisions and their rationale.
• SYSE.8:4.1 supplies offering and provider accounts, including continuing provision, access, custody, and ordinary and exception Work. This pattern consumes their supported result, conditions, and residual receiver obligations. An adequate existing provider comparison is reused without another account.
• A.15.9 and SYSE.9 obtain an exact professional contribution for a named receiving use. The incomplete or missing return is handled in §4.5. SYSE.10 supplies a qualified research, model, experiment, or trial result where a worthwhile probe is the next contribution.
• C.11 supplies the bounded choice from the constructed options, preference, belief, outcome, probe-worth, and authority inputs. C.11.CRC supplies a missing configuration-relative contribution comparison only; neither replaces the arrangement construction.
• SYSE.3:4.1–4.7 supplies the first unsupported realization branch and next justified Work. It is used after retention or during comparison when a decisive feasibility premise requires it. The remaining branch cannot be hidden behind choose-now when it defeats the actual commitment.
• OPS.10:4 supplies qualified capacity and timing results. OCE.4–6 supply organization contributions, positions, and enabling assignments where change is needed. HCD.2:4 and E.23.CDI supply capability- development comparison where later human Work depends on learning. Their outputs retain their assumptions, authority boundaries, and distinction between a proposed arrangement and observed performance.
• SYSE.12 and SYSE.25–29 supply platform questions when the result is a supported practitioner path; SYSE.18 supplies independently governed constituent questions; SYSE.23 supplies project and builder evolvability where these change the obtaining alternatives. Each returns the particular support, compatibility, or change consequence this comparison consumes.
• SYSE.13–14 and SYSE.4 govern configuration, change and release, and claim-specific assurance. A.13, A.15.1, A.2.1, F.6, and the authority patterns distinguish actual Agent, assignment, Work, attribution, and permission facts from the arrangement’s possible-future description.
• Strategy, Finance, Governance, Administration, Enterprise Asset Management, commercial and legal practices, and application practices retain their own Methods, evidence, and decisions. Section 4.5 states the exact result needed at their receiving boundary; Systems Engineering connects its consequence to the whole.

SYSE.24:End

SYSE.3 - Plan the Next System-Realization Action (Recursive Realization Network)

Status: Stable

SYSE.3:0 - Use This When

Use this pattern when a grounded engineering architecture candidate or decision exists, but one realization branch is unsupported: the capable System, Method or enabling condition needed to produce or change the engineered System remains unresolved.

Name that branch, its proposed transformer System or the need to find one, the missing support and one next planned action. Expand only when interacting branches or building the builder changes that action; name the earlier answer to revisit if the branch proves infeasible.

The result is a provisional realization-network description and a distinct WorkPlan. Performed Work, actual change, feasibility and an obtaining network require their own evidence. If the architecture or function bearer is still open, return to the architecture patterns. If the question concerns production, capability, operations, organization, configuration or assurance beyond this first action, use the specialist return in :4.6.

SYSE.3:0.1 - Terms and Distinctions

SYSE.3:1 - Problem frame

An architecture can name suitable bearers for required functioning while fabrication, adaptation, integration, configuration, installation or qualification remains unsupported. A product tree, WBS, schedule or toolchain diagram can then look like a realization argument. Engineers may plan Work for a System that does not exist, assign it to a label with no capable holder, or discover late that a selected interface, material or access condition cannot be realized.

The useful gain is a bounded feasibility question: identify the first unsupported dependency, plan an attainable action and use its result to revise only the affected earlier answer. The pump case in :5.1 shows how an inquiry into a supplier and fixture can precede fabrication without expanding into a complete production-network plan.

Use this pattern after the architecture has at least one candidate bearer for every required functioning at issue. Otherwise keep the architecture question open with A.6.F, C.30 and C.32. Use A.3.4 for an actual bounded change, the A.15 family for Work and production claims, and E.18 or E.18.NET only when their selected-structure conditions are met. Use Operations Management or project-portfolio practice when the live question is queue, capacity, priority or shared-resource coordination.

When a source names a builder or enabling means—for example, a manufacturer, platform or toolchain—recover the System and its contribution to the current branch. Establish assignment, capability, Method, Work order and enabling relations separately under :4.2–4.6. Use the local TransformerSystemRole when that contribution needs the distinction; a source label alone supplies none of those claims.

SYSE.3:2 - Problem

An architecture candidate proposes an organization of the System, but it does not make that organization exist. For example, a selected module, interface, placement, control relation, or configuration may depend on changes to pre-existing materials and Systems, first constitution of new Systems, integration Work, and Systems capable of performing that Work. Those transformer Systems can themselves need new capabilities, tools, Methods, resources, configuration, or prior change.

A single decomposition rarely exposes all of these dependencies. A component tree follows the proposed System; a WBS follows intended Work; an organization chart follows one organization; a platform inventory or diagram follows selected technical means. None alone answers which actual Systems can perform the needed Work under the stated conditions. The engineering difficulty is to connect these descriptions without merging architecture, intended change, transformer capability, WorkPlan, performed Work, and evidence into one diagram.

SYSE.3:3 - Forces

SYSE.3:4 - Solution

SYSE.3:4.1 - Start from one named architecture result

Start with one current architecture result for one described holon:

1. the current C.30 architecture question and claim;
2. one C.32 candidate configuration or one C.32.PAD project architecture decision;
3. the selected structures, constraints, assumptions, and expected architecture gain that matter to realization; and
4. the next use for which feasibility must be known.

The input may remain modal. A candidate structure is not an obtaining ArchitectureRelation, and a project decision does not make the decided structure actual. Keep the architecture result and the realization account as separate claims. When provider capability, continuing provision, access, custody, responsibility, or recovery can change realization, use only the supported claims and design constraints from a compatible SYSE.8 provider-arrangement account for the same subject, configuration, use, horizon, decision, and evidence window. Without a compatible current account, use a qualified direct source for the claim needed by this branch or record the missing result. The account supplies supported provider claims and design constraints. Establish the provider arrangement, provider Systems, performed Work, responsibility, and authority separately when the branch uses them.

Check the architecture boundary before proceeding. If the candidate lacks a bearer for required functioning, reopen the bearer question under A.6.F and C.32. Continue here when the candidate has a proposed functional and structural answer but the Systems and Work needed to constitute, change, integrate, or qualify it remain uncertain.

SYSE.3:4.2 - Describe one realization branch

Write one branch in ordinary language. Include only the distinctions that change the feasibility question:

• the architecture result to be realized;
• the pre-existing System, material, assembly, description, or other referent that would be changed, or the identity and completion conditions for a System that does not yet exist;
• the intended change, production result, interface state, integration state, or configuration relation;
• the proposed transformer System or unresolved need for one and the local TransformerSystemRole condition it would meet for this Work;
• the needed Method, capability envelope, resource, tool or platform contribution, access condition, interface, integration, and configuration relation; and
• the fact or specialist result that would make the branch usable, require its repair, or reopen an earlier answer.

Keep modal and actual claims apart. An intended change belongs in a plan or description until an actual continuing referent, boundary, conditions, and before/during/after facts satisfy A.3.4. When the proposed System does not yet exist, describe changes to pre-existing materials or assemblies and use A.15.PROD later for independently grounded identity inception and production completion. Do not describe transformation of a future System before it exists.

The claim that a candidate transformer will perform the Work is also modal. Name the candidate holder System, or the unresolved need for one, and the local TransformerSystemRole condition in the WorkPlan. Use A.2.1 only when an assignment occurrence actually obtains, and use A.2.2 only when the holder’s capability has a recoverable Work family, envelope, measures, qualification window, and currentness condition. Treat a job title, supplier category, tool list, past success, or Method description as possible evidence inputs; establish the capability claim through its Work family, envelope, measures, qualification window, and currentness.

SYSE.3:4.3 - Find the first unsupported answer

Use the A.1.STM long mantra to keep the architecture result, intended outside use, and builder dependencies in attention. Read the logical dependency backward and find the first unsupported answer that prevents one credible next realization action. First means logically first for this dependency, not earliest in a calendar or prescribed process. Use these six working questions to classify the first gap:

Record the first gap even when later gaps are already suspected. Use it to choose the next action.

SYSE.3:4.4 - Recurse only when the next action depends on it

Open another branch when the current transformer System, capability, Method, tool, or platform contribution must itself be brought about or changed before the current branch can proceed. Apply the same questions to that branch. Do not introduce fixed builder levels: a transformer System can serve several branches or projects, and evidence from a later branch can change an earlier branch claim.

When several branches must be considered together, begin with a Plain provisional realization-network description. Name the proposed members and the missing cross-branch relation or binding. Use E.18 only for one selected transformation-flow structure whose identity is established. Use E.18.NET only after at least two independent member structures, the obtaining cross-flow relation occurrences, the endpoint bindings, applied constraints, and the current use frame are recoverable. Until then, the episteme describes a proposed realization network; it is not the selected network itself. When a cross-branch arrow uses a generic cue—for example creates, builds, uses, supplies, or depends on—replace it with the actual production, participation, use, evidence, integration, configuration, supply, or other relation through the pattern that defines it. If the relation kind or case facts are not yet available, keep the dependency as a provisional claim and name what must be established.

When a formal flow description uses DesignRunTag, keep each tag local to one leaf-position binding under E.18/E.18.NET. Represent wider dependencies and Work order through the direct relations that establish them.

SYSE.3:4.5 - Plan the next Work separately

Create or amend one A.15.2 WorkPlan after the first unsupported answer is visible. The smallest useful WorkPlan needs one substantive PlanItem that states:

• the present EntityOfConcern and planning horizon;
• the intended Work or investigation;
• the candidate performer System and local SystemRole-kind conditions;
• the Method, capability threshold, resources, tools, access, and dependencies needed for that Work; and
• the result or evidence that will update the branch or reopen an earlier answer.

The next Work can take different forms—for example, investigating a supplier, qualifying a capability, developing a fixture, changing a transformer System, obtaining a specialist result, integrating a bounded slice, or revising the architecture candidate. Select the action that resolves the first unsupported answer; do not schedule every visible branch.

The WorkPlan states intended Work and its conditions. Establish every later assignment, capability, resource availability, relation, Work occurrence, transformation, and result through its direct evidence and pattern. When Work is later performed, use A.15.1 and F.6 for its performer and attribution, A.3.4 for actual changes, and A.15.PROD for production, identity-inception, or completion claims. Compare the resulting facts with the plan only when that separate question is current.

SYSE.3:4.6 - Obtain specialist results without absorbing their Methods

Keep the realization branch connected while leaving specialist decisions with the practice that can make them. Examples include:

Name the contribution that an enabling arrangement actually makes. For example, identify the bounded contribution of a platform, team, supplier, administrative service, or configuration repository. When no maintained receiving pattern exists, retain the unresolved specialist need and the decision it blocks.

SYSE.3:4.7 - Stop at one actionable gap and name the affected earlier answer

The project-local result is a RecursiveRealizationArrangementResult@Project, a U.Episteme containing a provisional realization-network description plus a distinct U.WorkPlan. It identifies the unsupported branch, proposed transformer and enabling Systems, gaps, result dependencies and the earlier answers each gap can reopen. The first result can be stated in five lines:

1. Architecture input: the named candidate or decision and the selected structures at issue.
2. Unsupported branch: the intended result or change whose realization is not yet supported.
3. Missing support: the proposed transformer System or unresolved need for one and the capability, Method, resource, platform contribution, interface, integration, or configuration result still needed.
4. Next Work: one WorkPlan item that can resolve that gap.
5. Affected earlier answer: the branch, architecture answer, linked concept, or project-focus claim to reopen if the result defeats it.

Stop when these five lines make the next action and affected earlier answer clear. Expand only when interacting branches or build-the-builder recursion changes that next action.

Reuse the branch description and distinct WorkPlan already supplied by an implementation-preparation account when they identify the unsupported branch, the attainable next action and the earlier answer that adverse evidence would reopen. Add only a missing decision or relation. The five lines above are a way to expose that reasoning, not a second required record. When the next decision concerns readiness to make, buy or reuse the product, use the applicable implementation Method and its wider readiness conditions; this first-gap result does not discharge them. The comparison in :11.1 works this choice through the pump case.

When feasibility evidence arrives, update the branch description and WorkPlan. If one branch fails but another admissible branch remains, repair or replace that branch. If no admissible realization remains, reopen the architecture candidate or decision. Reassess the linked use-and-system concept under SYSE.2 only when its use or concept claim must change, and reassess the project-system choice under SYSE.1 only when the project focus or boundary must change. Cost already incurred supplies no reason to preserve an unsupported answer.

SYSE.3:5 - Archetypal Grounding

SYSE.3:5.1 - Pumping station under flood risk

FloodPumpStation-7 : U.System exists at configuration FPS7-C18. SYSE.2 supplies a compatible station concept for changing that station so it can move water under the selected flood load without unacceptable downstream harm. StationArchitectureDecision-7, a compatible SYSE.6 result, selects StationArchitectureCandidate-7 with a changed discharge assembly, interfaces, placement, and control relations. The architecture has proposed bearers for the required station functioning; the open question is how to realize the changed assembly. Station7ProviderArrangementAccount-R1, a compatible SYSE.8 result, supplies only current provider, access, custody, and recovery claims that bear on the supplier branch. It establishes no supplier capability, assignment, Work, or production result. The first use produces this filled five-line result:

1. Architecture input: StationArchitectureCandidate-7, including the selected discharge interface, placement, material, geometry, and tolerance claims.
2. Unsupported branch: ManifoldRealizationBranch-1; a pre-existing discharge-manifold blank must be changed, and a newly constituted mounted subassembly must satisfy those claims.
3. Missing support: SupplierWeldCell-4 is the candidate transformer System for later welding Work. The branch still needs a capability result for the selected material and geometry and a feasible positioning fixture.
4. Next Work: the WorkPlan contains FixtureAndSupplierFeasibilityInvestigation-1. Its intended performer is StationRealizationEngineeringTeam-2, not the supplier weld cell whose later production capability is being investigated.
5. Affected earlier answer: if no fixture-and-weld branch meets the selected interface and access conditions, reopen the C.32 comparison of interface, material, module split, and placement alternatives.

For this case, the PlanItem records the following intended Work and conditions:

Station7RecursiveRealizationArrangement-R1 : U.Episteme is the case result. Its EntityOfConcern is StationArchitectureDecision-7 for the bounded station-realization question. It cites the provisional realization-network description and the distinct WorkPlan, names ManifoldRealizationBranch-1 as the first unsupported branch, records the proposed transformer and enabling Systems, and names the earlier architecture claim that the fixture-and-weld gap can reopen. It establishes neither an obtaining realization network nor performed Work.

If the fixture itself must be developed, that need opens one recursive branch for a toolmaking System and its capability. The engineer stops there unless this branch changes the immediate investigation. If no admissible weld or fixture branch remains, the engineer reopens the C.32 comparison of interface, material, module split, and placement alternatives. The engineer reassesses the linked station concept under SYSE.2 only if the concept or outside-use claim must change. The fixture does not become part of the pump merely because realization needs it. The supplier’s shop title does not establish welding capability, and the WorkPlan does not establish that welding Work or manifold change occurred.

SYSE.3:5.2 - Manufacturer’s ERP-enabled planning change

The architecture candidate concerns one deployed production-planning System. It names the software bearer, interfaces to order and shop-floor Systems, selected data and decision relations, and the planning functions that those Systems are expected to support.

The first unsupported branch is the change from current product, order, and resource descriptions to the configuration and integration state required by the candidate. PlanningIntegrationTeam-2 is the candidate transformer System for RepresentativePlanningDataIntegrationWork-1: mapping one representative data family and configuring its source-to-planning interface. The planned holder-dependent capability requirement is the ability of that team to apply BoundedPlanningDataMappingMethod-v1 under the actual source semantics, access, timing, and configuration conditions. This is WorkPlan content until A.2.2 supplies a current capability result and A.2.1 supplies an assignment occurrence when one is needed.

MigrationToolService-3 is a separate proposed tool or service contribution to that Work: access to a named mapping-execution interface under the selected configuration. This case attributes no transformer assignment or data-mapping capability to that service label. If a later claim relies on it as an acting System, the engineer applies System recognition before making separate claims about its role, capability, and Work. The immediate WorkPlan item names PlanningIntegrationTeam-2 as intended performer of the representative-slice feasibility investigation and asks for RepresentativeIntegrationFeasibilityAccount-1 plus any organization- design result needed to make the slice feasible.

If the gap concerns who may change source definitions, which organization holds an assignment, or which authority relation applies, the engineer obtains that result from Organization Engineering or Governance rather than encoding it as a technical interface. If the branch cannot preserve the required decision timing or data meaning, the engineer reopens the C.32 comparison of interface, placement, and responsibility structures. The engineer reassesses the linked planning concept under SYSE.2 only when the planning-use claim must change. The words platform and migration pipeline establish neither integration capability nor one universal Work order.

SYSE.3:5.3 - Occupied building retrofit

SYSE.2 supplies the continuing building, the occupied-use claim, and a candidate concept through the occupied region, safe-entry, egress, and essential-service interfaces. C.30 and C.32 supply candidate building zones, service paths, interfaces, and load-bearing relations. Temporary access, work-area isolation, and construction sequencing remain realization and WorkPlan questions.

The first unsupported branch is how a contractor System can reach and change the selected building region while the occupied-use boundary and essential services remain supported. The candidate transformer System is one contractor team. Access-equipment Systems remain separate resources or participating Systems unless their relation to the team is independently established. The missing support is a capability claim under the occupied configuration, access, isolation, load, and service-continuity conditions. The first WorkPlan item is a contractor-capability and temporary-access investigation for those conditions.

If no admissible access arrangement remains, the engineer reopens the C.32 comparison of zones, service paths, placement, and interfaces. The engineer reassesses the linked occupied-use concept under SYSE.2 if continuing occupancy or the use boundary must change. A construction sequence is plan content; it is not the building concept, the changed building, or evidence that the Work has occurred.

SYSE.3:6 - Biases to Watch

Two recurring biases matter here. Diagram-made feasibility treats a product tree, schedule, or toolchain description as proof that capable transformers and relations obtain; return to the first unsupported branch. Endless builder recursion expands every dependency before choosing useful Work; recurse only when the added branch changes the next action.

SYSE.3:7 - Conformance Checklist

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

SYSE.3:9 - Consequences

Engineering participants gain an early feasibility result without waiting for a complete WorkPlan. One unsupported branch becomes visible together with the System and Work needed to resolve it. Recursive build-the-builder dependencies can be added where they change the next action, while architecture candidates remain open to repair.

The cost is explicit incompleteness. A provisional realization-network description can contain unresolved Systems, capabilities, Methods, relations, and specialist needs. Maintaining the distinction between that episteme, a WorkPlan, and actual Work takes care, but it prevents planned or drawn dependencies from being mistaken for physical feasibility.

SYSE.3:10 - Rationale

Systems Engineering connects a proposed System to the Systems and Work that can make or change it. The systems mantra keeps outside use, architecture, and transformer dependencies in view. In this pattern, engineers inspect those dependencies toward the first unsupported branch and relate later observed Work and change through their own facts. These are two views of the case, not one calendar sequence.

The recursive account is deliberately demand-driven. An exhaustive description of every supplier, tool, team, capability, and possible dependency would be expensive and unstable. One unsupported branch plus one WorkPlan item is already enough to change what the project does next. Further recursion is justified only by that next decision.

SYSE.3:11 - SoTA-Echoing

The manufacturing, portfolio, integration and platform sources above support particular contributions; their domain results do not establish the superiority of the combined Method. The same-question choice below determines when its bounded first result is useful and when an implementation Method already supplies enough.

SYSE.3:11.1 - Choose the next action with an implementation-preparation alternative

Question and common basis. In the pump case in :5.1, what can the engineering team plan next before committing the manifold to fabrication? Compare the two ways using the same architecture, material and geometry claims, supplier statements, access conditions and feasibility window. Both require the team’s capability fit and access before the investigation can begin. Count source retrieval, specialist coordination, recording and the preparation still needed later, rather than equating a shorter description with less total effort.

A serious alternative is the NASA Systems Engineering Handbook, §5.1, Product Implementation, especially §§5.1.1.1 and 5.1.1.2.1–5.1.1.2.2. Adopt its review of implementation inputs, personnel skills and enabling products, and its distinct make, buy and reuse duties. It permits tailoring preparation to complexity; reuse requires fitness for the new requirements and environment. Its enabling-product questions already expose the missing fixture and qualification evidence in this case.

Selection and accepted cost. For this narrow planning question, use the first unsupported dependency together with an explicit stopping condition and a named return. The stopping condition limits the fixture inquiry to dependencies that change its next action; the named return directs adverse evidence to the architecture choice it actually changes. These are requirements on the reasoning, not benefits conferred by another form. If the implementation-preparation account already supplies them through its branch description and WorkPlan,

4.7 reuses those results; rewriting the account in five lines adds no gain. If they are missing, add the bounded dependency and return to the existing account.

This choice deliberately defers completeness of production preparation. Obtaining a first action leaves personnel, enablers, quality controls, verification inputs and implementation records to be established for the eventual make, buy or reuse decision. Their later effort remains in the comparison. When that wider readiness is the present question, the implementation Method supplies the stronger result. The worked comparison supports this conditional choice; it supplies no measured time saving or general ranking of the two Methods.

Reopen the choice when a second interacting branch or shared-resource constraint can change the selected action, when the remaining preparation can no longer be deferred, or when another implementation Method supplies the same bounded decision with less total work. Use :4.4 or the specialist return in :4.6 for the changed dependency; do not preserve a separate SYSE.3 account merely because it was started.

SYSE.3:12 - Relations

• A compatible SYSE.6 architecture decision supplies only the selected structures, constraints, alternatives, accepted losses, and reopen conditions needed by this realization question. A compatible SYSE.8 provider- arrangement account supplies only supported provider claims and design constraints that change a branch. Each use rechecks subject, configuration, use, horizon, evidence window, and availability; otherwise it uses a qualified direct source or records the missing result.
• C.30 supplies the grounded architecture question and claims; C.32 supplies candidate configurations over selected structures; C.32.PAD supplies a project architecture decision when that question is current. A missing architecture function bearer reopens the bearer question under A.6.F and C.32.
• A.1.STM keeps the outside-use, architecture, and realization questions in attention while the engineer finds the first unsupported answer and later relates observed Work and change through independently grounded facts. It supplies neither Work order nor an actual realization network.
• A.2 supplies the local TransformerSystemRole kind; A.2.1 supplies an obtaining assignment; A.2.2 supplies holder-dependent capability and its envelope, measures, qualification window, and currentness. Candidate wording and WorkPlan content establish none of these facts.
• A.15.2 supplies a WorkPlan for intended Work. A.15.1 and A.3.1 govern actual Work and enacted Method. A.3.4 governs actual bounded change, and A.15.PROD governs subject-specific production results and completion claims when those distinct questions are current.
• E.18 supplies one selected transformation-flow structure. E.18.NET supplies a selected network only after independent members, obtaining relation occurrences, endpoint bindings, constraints, and use frame are established. Before that boundary, keep a provisional description and name the missing discriminator.
• SYSE.11 may use only the recursive realization arrangement from a compatible result for the same increment boundary. It does not perform Work, establish platform use or constituent commitments, or make the proposed System actual.
• Feasibility, integration, configuration, cost, delay, and evidence results can change the smallest branch, architecture, concept, use, or project-focus claim to which they apply. Platform Engineering, Organization Change, Operations, portfolio selection, configuration, safety, security, governance, law, finance, and other specialist practices retain their Methods and decisions.

SYSE.3:End

SYSE.11 - Integrate a System for One Bounded Use

Status: Stable

SYSE.11:0 - Use This When

Use this pattern when locally completed parts or changes have accumulated, but their joint operation has not yet established that one actual engineered System is usable for a stated purpose. Integration is the broader engineering concern; this pattern develops the bounded move from available contributions to a configuration that supports one receiving use. It includes choosing the integration progression, correcting discovered incompatibilities and assessing the resulting whole.

Begin with the actual System, its current configuration and the needed use. Recover an adequate existing integration strategy and assessment before constructing what is missing. A strategy can supply the grouping, assembly and check order directly. A current qualified result covering the same configuration and use can finish the assessment directly; neither a new trial nor another record is required merely to use this pattern. Otherwise choose the smallest joint change that can support the use, expose its consequential interactions early, perform the integration Work and use the resulting observations to assess the changed System.

The first useful result is a bounded usability assessment: an episteme stating what the actual System can support, on what grounds, for which configuration, conditions and interval, and with what limits and fallback. The changed System, the Work and transformations that produced its configuration, and this assessment remain distinct. Permission and release are separately governed decisions.

Finish when that result answers the receiving question. If a further change or inquiry could improve a live decision, use C.11.CRC when its finite contribution comparison is missing, then C.11 for the choice. A lack of information about an optional feature does not by itself require further observation.

Use SYSE.14 for authorization or release, SYSE.4 for a load-bearing assurance claim, and Operations Management for continuing queues, allocation or operating control. Specialist assembly, protection and test techniques remain with the practices that qualify them; the integration strategy connects their results and conditions.

SYSE.11:0.1 - Terms and Distinctions

SYSE.11:1 - Problem Frame

Engineering Work often produces local completion before it produces a usable whole. A manufactured part can match its drawing while failing an installed interface. Software can satisfy component-test conditions while, for example, its controller interface, sensor relation, physical plant, operator procedure, or evidence basis remains incompatible. A prototype can demonstrate one effect without supporting the configuration and operating envelope needed by the next decision.

No one lifecycle or cadence governs all of these dependencies. Work on, for example, physical parts, software, evidence, platforms, suppliers, configuration, and operation can overlap at different cadences. Engineers select one bounded integration boundary, connect the contributing Work and transformations to it, observe use, and return a result that can support the next decision within that use boundary.

SYSE.11:2 - Problem

A claimed increment is not decision-usable until the responsible engineers can answer:

1. Which actual System and starting configuration are changing?
2. Which receiving use, operating conditions, affected Systems, and interval bound the result?
3. Which changes belong inside the increment—for example, physical, software, description, procedure, or interface changes—and which remain alternatives?
4. Which input results are needed—for example, results from realization, platform, constituent coordination, configuration, specialist, or authority Work—and were they available before the Work that relied on them?
5. Which Agents performed which dated Work by which Methods, and which actual transformations and relations obtained?
6. What integration and operating observations support usability, and what claims remain unsupported?
7. What fallback, stop, separate assurance or release decision, and later change can reopen the result?

Without these distinctions, done becomes a proxy for actuality. Engineers can ship incompatible parts, overread a component test, confuse a release record with use, or keep adding features without producing a configuration that anyone can use.

SYSE.11:3 - Forces

• A small increment shortens feedback, while its use can still depend on relations outside the changed parts.
• Software and descriptions may change quickly; Work involving, for example, procurement, fabrication, access, integration, and physical observations often changes more slowly.
• Each contributor needs a local completion condition, but no local completion proves usability of the containing System.
• Some changes are easy to reverse; others alter scarce equipment, permits, safety conditions, or independently governed Systems.
• Automated tools can help Agents assemble records, compare configurations, and run checks rapidly. Establish the governed use, acceptable loss, and authority boundary separately.
• The receiving use needs a supported System configuration while engineers preserve alternatives for future change.

SYSE.11:4 - Solution

Work back from the receiving use to the relations that must hold together. Choose a feasible progression that reveals consequential incompatibility before it becomes expensive to correct. Establish those relations, correct discrepancies and assess the resulting configuration using evidence that actually covers the use.

SYSE.11:4.1 - Perform the Move

1. Name the System and use. State the actual System, starting configuration, receiving use, affected Systems, operating envelope, interval, required behavior and deciding Agent. Distinguish a demonstrated episode from a claim about later use or continuing availability.
2. Recover a sufficient strategy or construct the missing connection. Inspect an existing specialist plan for the same starting state, intended configuration, interactions and use. Follow it where it is adequate. Where the grouping or progression remains unsupported, use :4.1.1 to connect the needed behavior to the joint change, intermediate configurations, integration Work and checks.
3. Establish the inputs before relying on them. Use realization, platform, coordination, configuration and specialist results only for matching subjects, uses and evidence windows. Close an unsupported branch, replace it with a qualified source or retain it as a blocker. Later Work cannot justify an earlier input retroactively. Resolve conflicting demands on shared equipment, access or people before scheduling both uses.
4. Prepare the next integration and its test of progress. Name the actual items, relations and starting conditions, available means, expected behavior, unacceptable result, stop and practical fallback. Select the specialist procedure and observations that can distinguish a successful integration from a consequential mismatch. Reuse sufficient existing evidence; a planned check alone establishes nothing about the result.
5. Perform Work and identify actual change. Keep the performing Agents, dated Work, enacted Methods and results traceable to the relevant subjects. Identify the actual transformations and resulting configuration separately from Work records and descriptions.
6. Check the interaction and act on the result. Use :4.1.2 to proceed, correct and reintegrate, revise the progression or stop. Carry an intermediate result forward only within its demonstrated or otherwise justified scope. Perform the remaining whole-use observation when the assessment needs it.
7. Construct the usability assessment. Use SYSE.10:4.1 steps 6–8 and :4.1.1 for a missing trial-to-use inference or join between results; :4.1.3 below identifies its inputs here. Return the supported use, limits, unsupported claims, fallback and condition for reconsideration. Obtain separately governed assurance, permission, release or specialist results when the receiving decision needs them.
8. Choose later work only when it can matter. A repair needed for the current integration returns through step 6. A further modernization or inquiry is a separate choice. Use C.11.CRC when the finite contribution of realizable alternatives is unclear, and C.11 to compare that contribution with cost, delay and reversibility. Select further observation only when a feasible result could change the live choice or its warranted use. Otherwise finish with the current assessment.

Fabrication, software integration, preparation of the trial environment and assessment construction may overlap. Reliance still requires the particular input to be established before the Work or decision that uses it.

SYSE.11:4.1.1 - Choose the Joint Change and Integration Progression

Derive the boundary from the behavior. Follow the needed behavior through the available architecture and interaction account: what receives the demand, what acts, what it acts on, and what feedback or external participation makes the result possible? Locate where an included change invalidates an existing relation or assumption. A changed controller can require a sensor mapping and an operating procedure even when neither is listed as a feature. Conversely, a proposed diagnostic sensor can remain outside when the existing qualified protection and evidence already support this use. Retain unchanged contributions on their applicable grounds. The boundary is sufficient when the needed behavior has no unsupported consequential dependency, not when every component has been changed or every desirable feature included.

If the behavior or an essential interaction is unknown, return that concrete question to the responsible design or specialist work. SYSE.3 can develop an unsupported realization branch; it does not turn an unknown interaction into a feasible integration merely by placing it in a WorkPlan. An unavailable required item prevents the dependent step, but may leave independent preparation or a useful partial integration possible. Keep the partial result’s purpose explicit.

Choose what to bring together first. Look for an interaction whose failure would defeat the use or make later rework costly. Determine the smallest available configuration in which that interaction can be exercised meaningfully. It may be an actual subset, an existing test rig with a qualified substitute, or the whole System. A substitute is useful only for the behavior it represents: a controller rig can expose signal polarity while leaving hydraulic loading unanswered. Select the later check that must establish the missing correspondence.

Compare feasible progressions where the choice matters. One whole assembly can avoid the expense of substitutes and repeated setup when the few interactions are already well understood. Integration by functional subsets can expose an uncertain interaction sooner and allow independent Work to continue, but needs suitable tools, interfaces between subsets and a final check of their joint behavior. Adding items as they arrive can shorten waiting, yet lose that advantage if it hides the critical interaction or repeatedly dismantles scarce equipment. Use the architecture, expected fault localization, availability, safe access, total setup and correction burden, and the receiving deadline to choose. No matrix, fixed assembly direction or universal batch size is required.

Connect each step to the next. For each consequential intermediate configuration, explain what it lets the engineers learn or perform, what counts as sufficient progress, and which later operation uses that result. Include the enabling means and any external commitments on which that step depends. Do not treat a passed software check as completion of an unexamined physical relation. Do not repeat a qualified unchanged check unless the new integration can defeat its premise.

The resulting strategy needs only enough detail to guide the actual Work and justify its progression. When an existing strategy already makes these choices adequately, use it directly. When a delivery delay, changed interface or new operating condition defeats its rationale, revise the affected grouping or order before continuing; the calendar alone cannot authorize the next step.

SYSE.11:4.1.2 - Correct a Discrepancy and Establish Progress

Compare the observed interaction with the expected behavior under the identified configuration and test conditions. If they agree, establish the progression condition and continue. If they disagree, contain the affected operation using its qualified stop or fallback and preserve the observation that distinguishes the failure. Keep independent successful results available.

Locate the first unsupported or contradicted relation along the exercised interaction. Check what was actually installed and connected, the meaning of the exchanged signal or material, the test conditions and the measurement basis. A discrepancy can arise from an actual incompatibility, an incorrect description or an invalid test; those require different repairs. Use a discriminating observation or specialist diagnosis when the available evidence cannot decide between them. Do not declare the nearest component faulty merely because its output is where the mismatch became visible.

Give the responsible engineering practice the demonstrated discrepancy and the behavior to restore. A wiring or mapping correction may be local; a newly discovered pressure interaction may require a design change and revised fabrication. Identify the resulting actual configuration, then repeat the failed check and the checks whose grounds that correction can invalidate. The comparison with the old result determines this scope; it is neither every test nor only the originally failing one by default.

Proceed when the corrected interaction meets the next step’s condition and no unresolved discrepancy can defeat that reliance. A fix record alone does not show this. If correction is infeasible in the available window, reconsider the boundary, substitute or fallback under its own supported use, or stop. Repeated fixes that expose the same unmodelled interaction reopen the architecture or strategy, rather than just adding another repetition of the same test.

SYSE.11:4.1.3 - Turn Integration Evidence into a Bounded Use Assessment

Give SYSE.10 the required behavior, actual resulting configuration, qualified observations and specialist results, the grounds linking them, and the intended use and interval. If one sufficient result already covers that claim, use it. Otherwise its inference Method develops the missing connection, including why results about different parts hold together and why a trial applies beyond its observed conditions.

Ask the consequential question: could all these observations be true while the proposed use still failed? A rig can be correct while installed wiring differs; a station can pass a trial while a required external buffer is unavailable for the later event. Resolve that premise or return a narrower supported claim. Explain which part is observed, which extension rests on qualified domain knowledge, and which future condition must hold. An evidence window does not itself supply a reason for extrapolation.

Return the assessment when it answers the receiving question, even when the answer is that the intended use remains unsupported. If a later premise changes, reopen the dependent inference and retain unaffected results. Loss of support is not by itself proof of physical failure. The ordinary assessment Method does not require the separate assurance activities in SYSE.4 unless an assurance claim is actually being made.

SYSE.11:4.2 - Record the Result

Use the existing configuration, integration and assessment records where they already carry the needed content. The following are questions to keep answerable, not a mandatory second form.

SYSE.11:4.3 - What Changes in Practice

Engineers choose integration Work to expose the interactions that determine whole-System use. They can explain why a partial result permits the next step, what must be repaired after a mismatch, and why the final evidence supports the selected use. Sufficient existing strategies and assessments remain usable directly. Finishing the increment does not depend on starting another modernization.

SYSE.11:5 - Worked Case: A Flood-Pump Station for Bounded Emergency Discharge

This constructed case supplies qualified specialist procedures and results as inputs. Its numbers illustrate integration and inference; they are not a pump design or operating procedure.

SYSE.11:5.1 - The Use Determines What Must Change Together

A municipal flood-pump station operates in C18. For the next flood-risk month, engineers are asked whether an updated configuration can discharge at least 0.75 m³/s during an attended emergency episode lasting no more than 30 minutes, within the specified inlet-level, head, power and fluid envelope E. Correct response to the pressure signal and the station’s stop function are also required. The request for a month of readiness must distinguish conditional fitness for an episode from a guarantee of availability throughout that month.

The new discharge manifold changes the hydraulic resistance. The selected controller package supplies the corresponding operating settings, and its pressure-input mapping must match the installed transmitter. Those three changes belong together: retaining the old settings or an incompatible mapping would defeat the hydraulic qualification for the new manifold. The operator’s existing procedure receives the changed configuration and limits. The proposed bearing-temperature sensor remains outside: existing qualified protection and maintenance conditions already cover this bounded duty, and no required behavior currently depends on the added sensor.

The engineers recover the realization arrangement, integration platform readiness, temporary collector-buffer commitment and current configuration basis. An earlier unsupported fixture-and-weld branch has been resolved through feasibility Work: a fixture design and current toolmaking/welding capability now support the chosen fabrication Method. The actual fixture and manifold still have to be made. Platform evidence is available before the controller trial; later participation will supply its own observations.

The station remains the same actual System under its reidentification rule: its stable boundary, foundation and pump train continue. C19 names the resulting configuration, not another System or the description of the change. Restoring C18 remains feasible with the retained manifold, settings and a qualified four-hour reinstatement procedure. It restores only C18’s previously supported lower-duty use; it neither instantly undoes C19 nor meets the new 0.75 m³/s requirement. An urgent need outside either supported use requires a separate municipal response.

SYSE.11:5.2 - Expose the Interaction Before the Scarce Station Window

The manifold needs two days of fabrication; the controller, input hardware and existing qualified integration rig are available now. The station has one planned outage window. The engineers compare two feasible strategies. Waiting and testing everything only after assembly would avoid a rig setup, but a signal incompatibility found then would consume the scarce outage and could require reinstatement. An early pressure-input/controller/drive check costs half a day on the existing rig and can distinguish that incompatibility while fabrication continues. They choose the latter. A new full hydraulic simulator would add cost without settling a remaining question that the planned station trial and available hydraulic qualification cannot already address.

The defect is an interaction mismatch: both local items could have passed checks using their own signal conventions. Correcting the conversion changes the installed configuration basis; it does not require refabricating the unaffected manifold. Conversely, a hydraulic mismatch would return to the relevant design or fabrication question. The teams’ dated Work and its results remain distinct from the manifold’s transformation through welding, cooling and rework, and from the station’s transformation from C18 to C19.

The progression condition is substantive: correct range, direction and stop response permit the subsequent installed check, which then permits the whole-use trial under its own conditions. A correction entry cannot substitute for these results. If the manifold arrives late, the rig result remains useful for its tested configuration, but neither C19 nor emergency-discharge fitness has thereby been established. The team revises the outage plan instead of treating software completion as permission to proceed.

SYSE.11:5.3 - Explain the Trial-to-Use Inference

The whole-station trial lasts 30 minutes at the qualification’s reference condition in E. Its lowest indicated discharge is 0.82 m³/s. The qualified measurement bound is 0.02 m³/s, so the observed lower bound is 0.80 m³/s. Correct signal response and the independent stop function have been established in the installed configuration. Those facts establish the tested episode; they do not alone cover every condition in E or the following month.

The available specialist result H19 supplies the missing hydraulic extension. For this installed geometry, controller settings and correct pressure mapping, it bounds the reduction from the trial’s lower flow bound to any permitted episode in E at 0.03 m³/s. Its qualified scope includes the pump’s allowed service condition and the stated one-month application window, with a current pre-use condition check and confirmation of the buffer relation. It includes the relevant interaction and model uncertainty; the trial’s measurement bound is handled separately. How those hydraulic and service bounds were established remains the specialist’s work, not a number inferred from the short trial. If H19 is unavailable or does not cover these conditions, that extension remains unsupported.

Following SYSE.10:4.1.1, the engineers work backward from the required 0.75 m³/s and forward from the actual results. The trial lower bound and H19’s compatible one-sided reduction give 0.80 − 0.03 = 0.77 m³/s, which meets the criterion with 0.02 m³/s margin. Configuration inspection and the installed signal check make H19 applicable. The separately established stop behavior is also necessary; a flow margin cannot compensate for its failure. The buffer must participate under the conditions used by both trial and extension.

The resulting technical assessment supports an attended episode of at most 30 minutes in E during the named month, in unchanged C19, with its qualified service condition and buffer participation confirmed before use. It does not guarantee that the station, power or buffer will be available for every flood event, nor support greater head, longer operation or all-season reliability. The municipal decision-maker receives that conditional fitness result and the still-open availability question. Release and authorization remain separate; if the receiving decision requires unconditional month-long readiness, this assessment does not answer it.

SYSE.11:5.4 - Change One Premise and Keep the Surviving Result

The buffer operator later withdraws the commitment covering the remaining month. The trial observations, mapping correction, installed configuration and independent stop result remain valid for their recorded conditions. H19’s hydraulic statement and the conditional fitness assessment also survive. What must be withdrawn is the recommendation to count on C19 for a later event under the former buffer commitment. This does not prove that the station has lost hydraulic capacity or that the earlier trial failed.

The engineers withhold that recommendation for an event lacking confirmed buffer participation. A new compatible commitment can restore the missing premise; a different discharge route instead needs qualification of its changed hydraulic conditions. Repeating the old trial while the temporary buffer is present would not establish its later availability. Reinstatement of C18 remains possible only through its actual restoration Work and within its lower-duty limits.

For the original completed integration, no extra load-window observation is selected merely because the bearing-sensor option lacks evidence. Another run in E would not qualify that sensor’s placement or maintenance, and H19 already supplies the required flow extension. With no live challenge to that basis, repeating it does not justify another buffer reservation for the current choice. The engineers finish with the supported C19 assessment and its limits. A later proposal for longer duty, a changed service condition or a credible sensor alternative can create a new choice; then C.11 compares a feasible inquiry’s decision effect with its burden. The later buffer withdrawal creates a concrete coordination problem, not a generic obligation to collect more pump data.

Countercase. A document bundle is approved while no actual configuration, integration Work or supporting use evidence exists. Identify the missing contribution; approval alone does not produce a usable increment.

SYSE.11:6 - Bias Annotation

A passed gate or successful software build can be mistaken for evidence of whole-System use. Recover what its underlying checks actually establish and supply the missing interaction or applicability grounds. Conversely, waiting for a complete physical assembly can postpone feedback that an available subset could already provide. Choose the integration boundary from the useful evidence and its total burden.

Institutional status and labels supplied by, for example, vendors, tools, or standards can support particular claims, but they do not establish actual integration or use. Automation can support bounded Work and checks; the receiving Agent still selects the use and any authority relation remains separately supported.

SYSE.11:7 - Conformance Checklist

• One actual System, starting configuration, bounded use, required behavior, conditions, interval and deciding Agent are named.
• The joint change and progression have a reason grounded in the needed behavior and interactions, or a sufficient existing strategy supplies that reason.
• Inputs match the subjects, uses and evidence windows and were available before the Work or decisions that relied on them.
• The actual integration and any correction establish the conditions for the next dependent step; a partial result is not overread as whole-use fitness.
• Work, transformation, actual configuration and the claims in its description remain distinguishable.
• The assessment explains what supports the whole-use claim and any extension beyond observed conditions, using a sufficient direct result or SYSE.10.
• Fallback is feasible for its own supported use; unresolved discrepancies and unsupported claims have a concrete stop or return.
• Separately governed assurance, permission, release and specialist decisions retain their own grounds.
• If later modernization or inquiry is selected, its separate comparison and choice justify the attainable contribution and burden. Otherwise the current result can finish.
• Reopen conditions identify the configuration, use, evidence or relation whose change matters.

SYSE.11:8 - Common Failures and Repairs

SYSE.11:9 - Consequences

An early interaction check can expose a repair while independent Work continues. Intermediate configurations also cost setup, qualification and repeated checks; they are worthwhile when that burden is justified by what they reveal or make possible. A sufficient existing strategy can avoid new planning, and a simple well-understood assembly may need no intermediate rig. The assessment preserves which use has support when a configuration or external relation changes. These are conditional engineering gains, not a measured universal reduction in time or failure rate.

SYSE.11:10 - Rationale

An engineered System changes through actual Work and transformations. A bounded increment exposes compatibility and use evidence before a larger commitment. Continuing modernization preserves the System’s temporal identity and repeatedly returns evidence to engineering decisions.

SYSE.11:11 - SoTA and Source Use

The working question is how to obtain a justified bounded-use result from available parts and local results when some consequential interactions have not yet been established. The same question includes the case in which a competent specialist has already supplied an adequate integration strategy and assessment.

The selected line combines use-driven integration progression with explicit assessment of the resulting whole. It adopts established interaction engineering rather than deriving a strategy from the vocabulary of Work or evidence alone. NASA’s Product Integration and SEBoK’s System Integration are substantive candidates for this work: they develop the choice and execution of an integration strategy. DORA’s CI/CD line is a serious alternative for software changes, with a potentially reusable rapid-feedback contribution in mixed systems. The conditional choices below compare those complete arrangements under the same available inputs.

The source choices have bounded roles:

• Adopt and adapt: NASA, Product Integration, §5.2.1.2 supplies preparation, assembly/activation order, enabling means, interface checks and revision when delivery conditions change. It supports the construction in :4.1.1–:4.1.2. Its programme documentation and lifecycle organization are not mandatory outputs of this bounded pattern.
• Adopt and adapt: SEBoK, System Integration, Integration Strategy and Process Approach supplies intermediate aggregates, strategy alternatives and their risk, availability and test burdens. Its distinction between developmental integration and production assembly remains source-local. SYSE.11 instead follows the named actual System and receiving use, including a modification in operation; the qualified assembly and design practices still supply their own Methods.
• Adopt within software scope; adapt the feedback contribution where correspondence holds: DORA, Continuous integration connects small integrated changes with rapid tests and prompt repair or reversion after failure. Continuous delivery develops deployability on demand, supported by technical, organizational and architectural capabilities. It is distinct from deploying every change. Reject transferring a software cadence or automated test’s coverage to unrepresented physical use.
• Adopt the concurrent and iterative application principle: SEBoK, Applying the Systems Approach, Application Principles supports concurrent, iterative and evolutionary work. Its lifecycle presentation does not establish a fixed serial execution or a defect of the method. Section :4.1 preserves overlap while making particular reliance dependencies explicit.

The public construction here connects the selected integration results to SYSE.10’s ordinary assessment and, only when another choice is live, to C.11. The worked margin and changed buffer premise show the bounded consequence of that connection. They do not establish empirical superiority over a competent professional integration programme. Qualification of domain models, equipment and tests remains real work in every arrangement; the pattern does not remove its cost by naming its result.

Reopen the comparison when a qualified existing strategy covers a previously missing interaction, an earlier check fails to represent the installed relation, the cost or timing of intermediate integration changes, or a different use invalidates the assessment’s extension. A demonstrated lower-burden arrangement preserving the same useful result also changes the selection. A newer source or a faster tool alone does not.

SYSE.11:12 - Relations

• A compatible SYSE.3 result supplies only the realization arrangement needed by this increment. Every relied- on unsupported branch must be closed, replaced by a qualified result, or retained as a blocker before Work uses it.
• A compatible SYSE.12 result supplies pre-use platform capability and condition claims. Later participation or provision Work produces later evidence and cannot justify the earlier input retroactively.
• A compatible SYSE.18 decision identifies the selected constituent arrangement and its unresolved dependencies. Rely on an obtaining commitment or observed coordination only when the accompanying evidence supports that claim; the decision alone supplies neither. SYSE.13 supplies configuration and effectivity claims for the same Systems and use. Constituent outputs and the receiving Agent’s authority need their own basis.
• A.15.1, A.2.1, and A.3.1 distinguish Work, assignment, and enacted Method. A.3.4 distinguishes actual transformations, and A.15.PROD governs claimed result production.
• C.11.CRC constructs a finite contribution comparison when a proposed change’s contribution relative to the current configuration is not already explicit. C.11 governs the next choice. Neither result is the later Work or transformation.
• SYSE.10:4.1 steps 6–8 and :4.1.1 supply the ordinary assessment inference and combination of results. Its SYSE.4:4.4/:4.6 instructions can be used without importing the separate assurance activities.
• A bounded usability assessment can inform SYSE.4 within its supported use and evidence window. SYSE.14 retains release and evidence-continuity authority.
• Operations, Maintenance, Platform Engineering, safety, security, law, governance, finance, and other specialist practices retain their Methods and decisions.

SYSE.11:End

SYSE.12 - Develop or Retain an Engineering Platform for Practitioner Work

Status: Stable

SYSE.12:0 - Use This When

Use this pattern when engineers cannot reliably model, compute, build, integrate, test, release, or observe an engineered System because shared enablers—such as tools, data, models, automated or physical facilities, provider Work, and support arrangements—are treated as incidental infrastructure or as a product with no named practitioner Work.

Begin with one practitioner Work family and the engineering result it must produce. Identify the actual Systems that enable or obstruct that Work, the capability practitioners need, the capability claimed for each platform or provider System, the conditions under which those Systems participate or provide a result, and the burden or failure that should change. Then choose whether to retain or change the enabling arrangement for that engineering result.

For a decision made before the relying Work, assess platform readiness and record a platform readiness assessment based only on evidence already available. After practitioner Work, the responsible Agent reassesses the platform and records a platform-use assessment based on observed participation, provision, burden, failure, and engineering results. Both assessments are epistemes. Each names the System, capability, Work, relation, result, and evidence it is about without replacing any of them. The later assessment can revise later reliance but cannot retroactively support the earlier assessment.

Use SYSE.25–SYSE.29 directly when the missing result is a task-grounded platform improvement, a supported use path, an interface or contribution change, a qualified control placement, or a migration and retirement result. The selected service-software Methods in SYSE.30–SYSE.41 supply professional results for build, feedback, artifacts, environments, data change, deployment, exposure, reliability, recovery, repetitive burden, and capacity. Use those results to support the relevant platform claims, keeping evidence of pre-use readiness separate from observations of later use.

Use Organization Change Engineering when positions, assignments, authority, or organization architecture are the changed subject; Operations Management for continuing queues, support cases, capacity, and provider Work. When the professional move is not supplied by the common language or the selected service-software Methods, use a qualified application-profile Method—for example, for a laboratory, compiler, manufacturing cell, clinical environment, electrical bench, or ship facility. The software selection is not complete software engineering.

SYSE.12:0.1 - Terms and Distinctions

When a source says service, recover its claim—for example, a capability, promised result, performed provision, or participation in Work. Name the holder or participants and supporting evidence. A promise alone does not establish performed provision.

SYSE.12:1 - Problem Frame

Engineering results depend on more than the architecture of the project system-of-interest. Systems such as model repositories, simulation and calculation environments, manufacturing cells, test benches, configuration and evidence stores, AI assistants, integration environments, and data spaces can change what engineers can observe and do. Provider and support arrangements can do the same. One platform can help one Work family and obstruct another.

Buying tools or forming a platform team does not establish that the resulting arrangement can support the named practitioner Work. Platform engineering starts with that Work and consequences for the project system-of-interest or its use, then develops the actual enabling arrangement. Platform Work and engineering Work on the project system-of-interest may occur simultaneously; their dependency is not a lifecycle stage or evidence that one System is part of the other.

SYSE.12:2 - Problem

A decision about an engineering platform requires answers to seven questions:

1. Which practitioner Agents, Work family, Method, result, configuration, and interval are being served?
2. Which actual Systems, provider Agents, interfaces, resources, and configurations form the current enabling arrangement, and which future candidates exist only in plans or descriptions?
3. What capability does the practitioner need, which System holds each claimed platform or provider capability, and under what envelope and currentness conditions?
4. Which conditions and direct relations actually matter—for example, access, participation, provision, availability, resource use, promise, support, exception, or fallback?
5. Which practitioner or System consequences should change—for example, effort, delay, error, rework, recovery, evidence continuity, or a result involving the project system-of-interest?
6. Which credible complete arrangements form the current decision alternatives—for example, retaining, changing, composing, obtaining, building, branching, bypassing, or retiring—and who has authority to choose among them?
7. What can be supported before practitioner Work, what is observed only later, and what change reopens each assessment?

Without these distinctions, platform teams can optimize adoption, ticket closure, or local automation while moving integration burden to practitioners, concentrating failure, and degrading the engineering result.

SYSE.12:3 - Forces

• Shared capabilities and provider Work reduce duplication, while different engineering profiles need different interfaces, evidence, and physical means.
• Case-independent access can shorten feedback, while consequential changes still require separate permission and assurance.
• Recommended arrangements reduce routine burden, while novel Work needs extension, bypass, and exception conditions.
• Automation lowers repeated effort, while hidden automation can erase provenance, uncertainty, or recovery.
• Practitioners need stable participation and provision, while Systems designated as project systems-of-interest, Methods, descriptions, and evidence demands keep changing.
• A maintained platform needs product care, but platform-local metrics cannot replace practitioner results or results involving the project system-of-interest.

SYSE.12:4 - Solution

Choose an enabling arrangement for one named practitioner Work result, including retaining the current arrangement when its use is supported. Develop only the selected changes. State the capability, conditions, participation or provision relations, and evidence separately, then reassess the platform from observed use.

SYSE.12:4.1 - Perform the Move

1. Name practitioner Work and result. State the practitioner Agents or inclusion rule, Work family, Method, subject, expected result, current configuration, interval, and receiving decision.
2. Recover the current enabling arrangement. Identify actual Systems—such as tools, model or data stores, compute resources, AI assistants, laboratories, manufacturing cells, integration environments, evidence stores, or support Systems—only where their relations change the Work. Name provider Agents, interfaces, resources, conditions, and failures.
3. Separate capability holders. State the capability demanded of practitioners and the holder, Work family, envelope, measures, qualification window, currentness, and evidence for each platform or provider capability. Support each capability claim with evidence that bears on the named holder performing the Work family in that envelope. Administrative or descriptive records count only when their evidence relation supports that claim.
4. State conditions and direct relations. Name the conditions that bound the claim—for example, access, configuration, performance, evidence continuity, support, exception, fallback, cost, or resource conditions. Then state each direct relation used by the decision: platform participation in Work; production of a named result by a named Work occurrence; supply of the result or access to it from a named provider to a named receiver; receipt or use by that receiver; resource availability or use; applicable promise content; or another governed relation.
5. Use Method repertoire and architecture when they change the choice. A compatible SYSE.15 result can supply available Methods and applicability limits; a compatible SYSE.20 result can supply Method, Work, enablement, and conflict structures. Otherwise use a qualified source or name the missing result.
6. Generate and choose among real alternatives. Build a C.11 option set from feasible complete arrangements. Candidates may retain the current arrangement, change a capability or relation, compose existing Systems, obtain or build a part, branch for a profile, preserve a bypass, or retire a harmful arrangement. Name the deciding Agent, authority, accepted losses, and questions outside that authority. Compare them for the same practitioner result and period of reliance, including continuing provider, maintenance, and recovery Work as well as practitioner effort. Use SYSE.24 when the obtaining comparison is unresolved and SYSE.25 when the improvement mechanism needs investigation.
7. Perform selected platform-development Work. When step 6 selects a change, record the performing Agents, assignments when relevant, Methods, temporal extents, results, actual transformations, resulting configuration, and evidence. A decision record does not change the platform. When the current arrangement is retained, continue to the readiness or use assessment that the receiving decision needs without creating development Work.
8. Issue the pre-use readiness assessment. State only capability and condition claims supported before the practitioner Work, with their evidence cutoff, currentness window, limits, fallback, and stop.
9. Observe use and issue a later assessment. Identify the practitioner Work occurrence and the actual platform participation, provision Work, or resource relation. Observe the consequences needed by the decision—for example, burden, delay, error, rework, recovery, evidence continuity, or results involving the project system-of-interest. Record the later assessment separately and use it only for later decisions.
10. Return and reopen locally. Supply only the supported claims needed by each receiving decision—for example, capability, condition, participation, provision, use, failure, or platform-change claims. Reopen only the claim affected by a changed Work, Method, practitioner population, configuration, provider, condition, evidence basis, or consequence for the project system-of-interest.

Platform development, practitioner Work, support, change of the project system-of-interest, and evidence Work can overlap. Every claimed use still needs an obtaining relation, and later evidence cannot justify earlier reliance retroactively.

SYSE.12:4.2 - Record the Result

SYSE.12:4.3 - What Changes in Practice

Platform investment begins with an engineering result and observable practitioner Work. Engineers can improve a shared enabling System while keeping capability, Work, participation, evidence, operations, organization change, administration, application-profile engineering, and decisions about the project system-of-interest distinct.

SYSE.12:5 - Worked Case: Platform Support for Flood-Pump Integration

Engineers integrating a flood-pump controller must reconcile identifiers among the model build, hardware-in-the-loop bench, controller configuration, and evidence repository by hand. One missed link delays the station integration result and makes recovery difficult.

The actual engineering platform includes the model-build System, bench, and evidence repository in configuration C4. A support Agent provides recovery Work but is not made a part of the platform merely by supporting it. A platform description records the structure; it is not the platform System.

For the next controller-integration campaign, each candidate must return evidence tied to the same model, controller and bench configurations, preserve access to that evidence, and permit recovery after an interrupted assembly. The competent incumbent records and checks the correspondence manually. It can still produce the required result; the observed missed link and repeated copying across revisions are reasons to compare a repair.

The engineers compare retaining that arrangement, strengthening its manual correspondence check, adding configuration-and-evidence links, replacing the bench, and obtaining bounded evidence-provision Work from another provider. Strengthening the manual check avoids maintaining new bindings but leaves reconciliation in each attempt. The linking option carries identifiers from their originating configurations into the assembled evidence; it removes repeated copying but requires a provider to maintain the bindings when formats or configurations change. Bench replacement would require requalification; no identified bench limitation makes that work necessary for this repair. Outside provision is competitive only if it returns the same configuration-linked evidence with the required access and recovery; otherwise the engineers still perform the join. Manual fallback remains part of the linking option.

The authorized Agent chooses the bounded linking change because revisions recur during this campaign and preserving correspondence at evidence creation addresses the observed failure. The Agent accepts continuing binding-maintenance and recovery Work. Retaining the manual arrangement could be preferable for an infrequent job with adequate checks and support. This choice predicts a useful repair; its total burden advantage remains to be assessed. The decision record does not change the platform.

A platform-engineering team configures identifier bindings, repository links, and recovery hooks. This dated Work is distinct from the actual transformation of the continuing platform from C4 to C5 and from the evidence that describes the change. A support Agent then performs a recovery exercise.

The readiness assessment, issued after the exercise and before controller integration, states that:

• C5 is current;
• the bench and repository are available in their named configurations;
• the configuration-and-evidence links passed the checks already performed;
• the manual fallback remains executable; and
• automated repository export remains unsupported and blocks only Work that needs automated export recovery.

During later controller-integration and flood-discharge trial Work, engineer Agents use the C5 platform while its model-build, bench, and evidence-store Systems provide their named functions. The observed relations support platform participation in those Work occurrences; they do not assign the engineers’ Work to the equipment. The supplier’s fixture-fabrication Work uses another arrangement, so the same participation claim does not apply there.

The later use assessment records that the engineers’ evidence-assembly effort for controller integration fell from the stated local baseline of six person-hours to two and a half, while a repository outage took 45 minutes to recover and the export gap remained. The provider’s continuing binding-maintenance effort has not yet been measured on the same basis. Thus the observations support the local assembly saving, not a claim that total Work fell. Assess that claim using comparable provider and practitioner Work over the selected campaign; the 45-minute outage duration alone is not a measure of recovery effort.

If obtaining those observations is not worth its cost for the next decision, leave the total-burden claim open and decide from the supported result and accepted maintenance obligation. A later finding that provider Work outweighs the assembly saving reopens the improvement claim; it does not erase the verified links or completed integration. These constructed observations support only this case and can change later platform decisions. They cannot retroactively justify the earlier controller-integration reliance.

Countercase. A repository and continuous-integration server are installed, but no practitioner Work, participation, provision, or engineering result is observed. Record the installed Systems and the proposed enabling arrangement; do not infer platform capability or adoption from installation.

SYSE.12:6 - Bias Annotation

Software platform practice supplies useful ideas about self-service, configured defaults, fast feedback, and product care. Vendor catalogues and team-topology literature can also make a tool or team appear to be the whole platform. Physical and cross-domain engineering adds other platform participants—for example, laboratories, manufacturing cells, configuration and calibration Systems, evidence stores, provider Work, and recovery arrangements.

Use publicity, university coverage, procurement, installation, usage counts, or satisfaction as evidence only for the claims each can support. When broad prevalence or causal effect cannot be measured affordably, use the best available case evidence and state its epistemic status.

SYSE.12:7 - Conformance Checklist

• Practitioner Agents or population, Work, Method, result, configuration, interval, and receiving decision are named.
• Source-local service wording is interpreted for the claim being made, such as capability, provision, or participation.
• Capability holders and envelopes are supported, and each direct relation states its participants and conditions.
• Alternatives include retaining the current arrangement, a bounded change, a branch or bypass, and stopping or retiring where credible; authority and accepted losses are explicit.
• Platform-development Work, actual transformation, resulting configuration, and evidence remain distinct.
• A readiness assessment uses only evidence available before practitioner Work.
• A later use assessment identifies actual participation or provision and cannot justify the earlier reliance retroactively.
• Practitioner burden, recovery, evidence continuity, and results involving the project system-of-interest can reopen the smallest affected platform claim.

SYSE.12:8 - Common Failures and Repairs

SYSE.12:9 - Consequences

This move exposes hidden enabling dependencies and practitioner burden and can reduce repeated integration and evidence Work. It also adds continuing Work to maintain, support, configure, observe, and recover the platform. Shared capabilities can also create coupling, provider monopoly, or failure concentration, so profile branches and fallbacks preserve alternatives where those risks matter.

SYSE.12:10 - Rationale

Engineering capability is a holder’s ability to perform a named Work family or produce a result class within a declared envelope, measure set, qualification window, and currentness condition. A chosen Method may constrain that envelope or be tested for fit, but it is not the capability’s target. A platform is useful only through actual relations to practitioner Work. Engineers can make and assess claims about the platform’s architecture, configuration, evidence, use, and evolution for that Work.

SYSE.12:11 - SoTA and Source Use

Which enabling arrangement should support this engineering Work, and what justifies retaining or changing it? For ordinary internal software provision, the DORA/CNCF approach of developing a platform around users’ tasks is a sufficient starting answer when its provider capabilities and supported use already cover the Work. It develops a small useful offering with users, composes existing provision, and learns from task outcomes. Adopt that answer within its conditions.

For Work spanning software tools, physical facilities and separately performed provider Work, this pattern selects an authored synthesis: carry that task-oriented development into the actual enabling arrangement, qualify each relied-on capability and relation, and separate readiness before use from later observations. Its gain is a supported decision about which Work the arrangement can enable: a bench, repository and support provider can contribute different qualified results, and a missing export or changed maintenance burden reopens only dependent claims. The accepted cost is identifying those dependencies and maintaining their qualifications. This is a constructive answer for mixed engineering Work, not evidence that it outperforms qualified direct provision.

The serious local alternative is to retain competent provision or repair its manual interaction without developing a shared platform capability. It avoids new binding, interface and support obligations and can win for infrequent or highly variable Work. The synthesis earns its added effort when repeated coordination or cross-provider dependencies change the relying decision. If the direct source treatment or incumbent already carries those distinctions adequately, reuse it.

In :4.1 step 6, this means comparing complete arrangements for the same result and period, including continuing provider Work. The case in :5 selects identifier links while accepting their maintenance obligation and keeps a measured practitioner saving separate from an unmeasured total-burden claim. SYSE.24 supplies the obtaining comparison; this pattern joins its result to capability, participation and evidence timing.

Reopen the affected choice when a changed input or provider breaks the relied-on correspondence or access, when comparable continuing burden reverses the accepted trade-off, or when a supported alternative supplies the same result with fewer obligations. Reopen the cross-profile synthesis only when a new use or comparative source defeats the particular dependency or evidence distinction being carried across profiles.

SYSE.12:12 - Relations

• SYSE.25–SYSE.29 construct the bounded improvement, supported interaction, interface/contribution change, control placement, and migration results named above. Enter the Method for the missing result.

• SYSE.30–SYSE.41 supply the selected service-software professional Methods. Apply each result to the platform capability and practitioner task for which its conditions and evidence hold.

• SYSE.8 supplies a providing-System concept when missing; SYSE.18 handles integration across independent decisions; SYSE.24 compares whole obtaining arrangements.

• A compatible SYSE.15 result supplies a bounded Method repertoire and applicability limits; it neither selects nor enacts the platform Method.

• A compatible SYSE.20 result supplies Method, Work, enablement, and conflict structures; it neither turns an enabling dependency into a level nor selects the platform change.

• A.2.2 governs holder-dependent capability. A.6.P:4.11a recovers service wording into promise, capability, bearer, dated Work, participation or provision relation, condition, and evidence claims without creating a generic service object.

• A.15.1, A.2.1, and A.3.1 distinguish Work, assignment, and enacted Method. A.3.4 distinguishes actual transformation, A.15.PROD claimed result production, and A.22 descriptions of selected platform structure.

• SYSE.11 may use a readiness assessment only for capability, conditions, and participation or provision claims supported before its Work. A later use assessment updates later decisions and cannot support that input retroactively.

• Neighboring DPFs retain their own Methods and decisions. These include Organization Change, Operations, Administration, application-profile engineering, security, safety, law, finance, procurement, and governance whenever the current question belongs there.

SYSE.12:End

SYSE.18 - Decide Whether and How to Integrate Systems Governed by Different Agents

Status: Stable

SYSE.18:0 - Use This When

Use this pattern when one use depends on several actual Systems, but decisions that can change that use—for example, a constituent’s operating condition, configuration, commitment, interface, or later modification—belong to different Agents. The integrating Agent cannot command every change that can defeat the use.

Begin with the shared use and the actual constituent Systems that can defeat it. For each constituent, state how it affects that use, who can decide the relevant change, what authority that Agent has, and which configuration, interface, commitment, evidence, or withdrawal condition the decision relies on. Then compare arrangements for the same use, separating changes already within authority from proposals that require another Agent’s decision. A useful current decision can authorize preparation or retain the existing arrangement while a particular dependency remains unresolved.

The first useful result is a bounded constituent-integration decision. It states the selected coordination alternative, the deciding Agent’s authority, decisions required from other Agents, accepted losses, unsupported dependencies, and next Work. If integration Work is later performed, identify that Work, its actual transformation or newly obtaining relation, and the observed-coordination claim separately from the decision episteme.

Use ordinary architecture and integration patterns when one deciding Agent controls every constituent change that can alter the use. Use the neighboring practice that owns a different question—for example, Organization Change when an organization is the System being changed, Corporate Governance for ownership and governing-body decisions, Operations Management for continuing allocation and coordination Work, or a configuration or other specialist pattern for its own subject.

SYSE.18:0.1 - Terms and Distinctions

A System described, for example, as an owner, operator, integrator, supplier, or decision maker is an Agent only when the agency claim is warranted. State the direct predicate and participants for every relied-on claim. Use the applicable pattern when the decision depends on agency, authority, a commitment, performed Work, capability, or evidence; state constituent participation and the shared use separately.

SYSE.18:1 - Problem Frame

For example, district drainage can depend on separately governed pump stations, gates, drainage networks, dispatch Systems, provider organizations, and public infrastructure. A product can likewise depend on independently evolving software, communication, payment, and energy Systems or regulatory organizations. Each constituent can remain useful elsewhere and change for reasons outside the integrating project.

Drawing a larger boundary does not create authority or interoperability. A model or interface description can carry claims. An agreement can institute a commitment. A meeting is Work. A governing body is a System whose participating Agents may make authorized decisions. For constituent Work, identify its performing Agent; for another Agent’s decision, identify that Agent’s authority.

SYSE.18:2 - Problem

An integrating team needs answers to seven practical questions:

1. Which shared use, conditions, interval, and engineering decision are at issue?
2. Which actual Systems can defeat the use by changing, failing, withdrawing, or withholding a result?
3. Which direct relation connects each System to the shared use, and what does that relation change?
4. Which Agent controls each relevant decision, and what authority, permission, or escalation relation obtains?
5. Which configurations, interfaces, capacities, timings, commitments, and evidence make coordination possible?
6. What can the integrating Agent change, and which decisions must come from other Agents?
7. What actual observation would show that the changed arrangement works for this use?

Missing answers produce four recurring errors: interface syntax is mistaken for interoperability, an agreement for performance, a constituent label for parthood, or an integration team for authority over Systems it does not govern.

SYSE.18:3 - Forces

Recurring tensions include:

• The shared use needs coherent results; constituents retain other uses, priorities, owners, and decision centres.
• Integration benefits from stable interfaces and commitments; Systems and environments continue to change.
• Receiving decisions need comparable evidence; every source keeps its provenance, limits, and authority.
• One Agent can compare shared-use options while several Agents separately permit constituent changes.
• Some coordination can be agreed in advance; operating conditions can require continuing reconfiguration.
• A broad account reveals dependencies, while the current decision must remain feasible within actual authority.

SYSE.18:4 - Solution

Recover the constituent arrangement from the shared use, make distributed decisions and dependencies explicit, and choose one bounded coordination alternative within the deciding Agent’s authority.

SYSE.18:4.1 - Perform the Move

1. Bound the shared use. State the result, operating conditions, interval and decision to be made. Identify the losses that this decision may accept and the conditions it must preserve. Begin with an adequate current account when one exists; use this Method only for the missing or changed connection.
2. Recover constituents by consequence. Follow the result back to the Systems whose participation, failure, change or withdrawal could defeat it. State what each contributes or constrains and why that matters here. Preserve an observed participant whose identity is still unknown; distinguish that uncertainty from an unknown existence claim or a future intended System.
3. Trace the relied-on connection. Follow one representative use through the constituent results and interfaces. Match what the receiving operation needs with what the supplying System can provide, under the same configuration and conditions. Section :4.1.1 explains how to turn a mismatch into a design question.
4. Recover the relevant decisions. Identify who can change each decisive condition, what authority or permission obtains, and which other uses constrain that choice. An unresolved authority claim can leave comparison possible while preventing authorization of the corresponding change.
5. Construct alternatives around the mismatch. Change the receiving operation, supplied result, interface, allocation, timing or means of recovery that produces the failure. Keep a sufficient existing arrangement among the alternatives. For another Agent’s proposed change, identify the needed decision and the consequence if it is refused or delayed; :4.1.2 explains the comparison.
6. Select a bounded continuation. Compare admissible alternatives for the same result and interval. State what the selected arrangement gains, what it gives up and which unresolved condition limits the decision. Reuse sufficient analysis. Select further inquiry by what it could change and its attainable cost and delay, using SYSE.9 and C.11.DUA when needed. A required permission or physical qualification still governs use.
7. Make the decision usable by its participants. Explain the choice, consequences and remaining freedom to the people who must decide or perform the affected work. Resolve a consequential mismatch of understanding through :4.1.3. Record the decision within the deciding Agent’s authority, required outside decisions, accepted losses, next Work and reconsideration conditions.
8. Follow authorized enactment and selective change. When integration Work occurs, retain its performer, Method, actual change, configuration and evidence. Observe the shared use at the scope needed for the receiving claim. Section :4.1.4 connects changed conditions to the decision that relied on them.

Constituent operation, engineering, governance, and integration can be simultaneous; only stated dependencies and temporal relations establish order. Finish when the current decision and its useful continuation are supported. An integration decision need not wait for the later installation or operating observation.

SYSE.18:4.1.1 - Find the condition that breaks the shared use

Start at the required result and work backward to its necessary contributions, then follow a concrete occurrence forward. At an interface, identify the supplying and receiving Systems, what passes between them, and the condition that makes it usable. For a timed contribution, distinguish when it is produced, received, acted on and needed. Compatible message formats can still carry a late, stale or inapplicable result.

Compare needs and provision on the same basis. A receiving operation may need six hours after a notice while its provider promises only four hours before an outage. The missing two hours then becomes a specific question: can the provider give earlier notice, can the receiver respond sooner, or can another arrangement support the use during the interval? Those proposals alter different things and require different decisions. A notice commitment is evidence about an obligation; observations and qualification establish what response can be relied on under the stated conditions.

Include a constituent’s competing uses when they consume the same capacity or determine its availability. Two individually sufficient offers may be incompatible when they reserve the same resource at the same time. Use SYSE.13 for configuration correspondence, SYSE.9 for a needed specialist result and SYSE.20 when the issue is joint Work or resource use. Retain a compatible supplied result rather than repeating its production. If the necessary condition cannot be established, carry that precise dependency into the comparison.

SYSE.18:4.1.2 - Compare arrangements that could actually supply the use

Generate an alternative by naming the changed connection and following its consequences to the whole result. For a proposed buffer, derive the quantity to be held over the unsupported interval, where it goes, when it is available and how normal operation resumes. For a replacement provider, follow the new result through the receiving operation, including transfer and qualification. For a changed commitment, establish what its bearer would have to decide and perform. Narrowing the use is a different offered result; its loss needs acceptance by whoever may decide that scope.

Separate three questions for each proposal: would the arrangement satisfy the required use under its stated premises; can its necessary changes be authorized and supplied in time; and does its benefit warrant the whole burden? A technically workable proposal awaiting another Agent’s agreement can remain a conditional alternative. It cannot serve as an already available fallback. Conversely, a requested change refused by one Agent does not preclude an admissible change within another’s authority.

Eliminate a proposal from the present operating choice when it violates a protected condition. Compare the remaining arrangements on the same horizon, including acquisition, transition, operation and later reversal where they matter. Keep unlike losses explicit. A weighted score is useful only with an applicable comparison rule; it cannot turn missing permission or an unacceptable physical consequence into a compensable cost. SYSE.6:4 supplies the fuller comparison when the choice fixes project-shaping structures across later work. Here the additional question is which independent decisions and commitments make each arrangement possible.

Preserve a tie or conditional result when the present basis cannot settle the choice. Name the particular outside decision, professional result or affordable inquiry that could settle it. If no attainable answer is needed for the current useful decision, stop with that decision and its limit. Prefer a sufficient unchanged arrangement over a new one whose extra burden buys no needed result.

SYSE.18:4.1.3 - Explain the technical choice and resolve its effect on others

Take the proposed arrangement to the affected decision makers and practitioners with its reason: the shared result, the condition currently defeating it, the alternatives considered and the change proposed for their own contribution. Ask them to apply it to a representative occurrence and a relevant failure or change. What would each do, what input would they rely on, and what would they return to the next participant?

Compare these accounts at the consequential joins. If one participant interprets an acknowledgement as a promise of capacity while another means only receipt of a message, repair that misunderstanding before relying on the exchange. If everyone understands but a provider cannot reserve the resource, the missing result is provision or a different arrangement. If a participant lacks the professional means to perform the action, obtain that contribution or revise the proposal. More explanation alone cannot supply either resource or skill.

Keep a substantive objection available to change the technical choice. Resolve the local decision within established authority; obtain another participant’s decision for the part they control. Use the relevant negotiation, organization or governance Method when that becomes the unresolved question. Agreement to discuss a proposal remains different from commitment to perform it. The explanation can finish when the affected participants can use the same conditions and identify their own decisions, actions and return conditions; it need not make every participant an expert in every constituent System.

SYSE.18:4.1.4 - Follow changes through the connection that depended on them

Select observations for the reliance being made. A description-consistency result can support comparison of models. A claim that the configured Systems coordinate in operation needs corresponding operating evidence; SYSE.11 supplies the integration and qualification Method. Reuse adequate evidence at its actual scope. Record a later observed-coordination claim separately from the earlier decision and each commitment’s fulfilment.

When a constituent changes, identify which relied-on condition changes and follow its receiving uses. Revised notice time can invalidate a buffer’s duration even when the buffer’s measured capacity remains valid. A new interface version can require qualification of an exchange without reopening unrelated ownership decisions. Continue through affected dependencies until a compatible result or explicit gap bounds the consequence. Retain unaffected claims and independent work.

For a selected fallback, establish the trigger, deciding authority, available means and bounded result before relying on it. If continuing constituent evolution requires repeated selection during operation, arrange the needed observations and decision authority with the operating practice. Automating that selection adds its own qualification question. A single successful exercise does not establish the ability to manage every later configuration or unannounced withdrawal.

SYSE.18:4.2 - Record the Result

The first useful decision does not wait for implementation. Identify the earlier decision, performed Work, and later observed-coordination claim separately. An observed coordination result does not establish that every constituent commitment was fulfilled.

SYSE.18:4.3 - What Changes in Practice

Engineers can explain why a proposed arrangement could support the shared use, compare the available ways to repair a failed connection, and identify which decisions and professional results each way still needs. The receiving practitioner gets the reason for the choice and the condition that would change it. An unsupported dependency has a specific consequence and next question; an already sufficient arrangement can be retained.

SYSE.18:5 - Worked Case: Emergency Discharge Across Four Independently Governed Systems

This illustrative case concerns a district’s planned emergency-discharge provision. The quantities, permissions and engineering qualifications below are stipulated inputs for comparing arrangements; they are not field measurements or a flood-control design supplied by this pattern.

Four existing Systems affect the use: a flood-pump station, an upstream gate, a municipal drainage network and an emergency-dispatch System. Their respective owner, river-control agency, municipal operator and regional dispatch agency control different decisions. The station integrator may install qualified station-side equipment and use an already agreed dispatch escalation. It cannot change the gate envelope or the municipal operator’s commitments. The use requires accommodation of up to 50 m³/h while preserving the supplied hydraulic, discharge-quality and gate limits.

The municipal operator commits to notice received at the station at least four hours before a planned interruption of drainage reception. The station’s qualified fallback is ready no later than six hours after receipt of that notice; this bound includes dispatch acknowledgement and mobilization. The agreed dispatch response is already included in those six hours, so invoking escalation cannot be counted as a second time saving. Unannounced outages require a different contingency and lie outside this particular decision.

SYSE.18:5.1 - Derive and compare the alternatives

The decisive timeline starts at receipt of the notice. Municipal reception remains available through hour 4; the fallback can receive the flow from hour 6. The unsupported interval is therefore hours 4–6. With no other outflow during that interval, 50 m³/h × 2 h = 100 m³ must be held. This is a storage-volume requirement, not yet a qualified buffer design. For a varying flow, the corresponding quantity is the accumulated net inflow over the unsupported interval.

A supplier offers an existing mobile buffer with 120 m³ of usable storage, qualified for the stated medium and connection. The supplied hydraulic assessment supports its inlet rate, location and recovery path; the 120 m³ is available storage after its required reserves. It can be installed before the required date within the station integrator’s delegated budget. The fallback has qualified spare capacity to empty it after hour 6 without losing the continuing 50 m³/h service. These are necessary specialist and provision inputs; the volume calculation supplies none of them.

The same decision compares the following arrangements for the same service interval:

The buffer is selected for preparation because it is the only currently supplied arrangement in this comparison that meets the required use by the date. Its extra cost and maintenance are accepted within the delegated budget. The selection makes no claim that buffering is generally cheapest or superior to earlier notice. An available six-hour notice agreement could reverse that choice by avoiding the buffer’s burden.

SYSE.18:5.2 - Connect the decision to performance and a changed condition

The integrator explains the timeline and choice to station, municipal and dispatch participants. In their walkthrough, dispatch initially describes acknowledgement as confirmation of the fallback’s readiness. The station team points to the six-hour mobilization: acknowledgement starts and tracks that work; readiness has its own confirmation. They correct the receiving instruction and retain the agreed escalation for a missed acknowledgement. The municipality’s four-hour commitment remains unchanged.

The decision now authorizes the installation and its necessary qualification. It does not yet establish installed availability. In the example’s later performance, the team installs the buffer and completes the required checks; a representative exercise under the stated load supports storage, transition to the fallback and recovery. SYSE.11 can use that configuration-specific evidence. The earlier decision, installation Work, actual availability and observed coordination remain separately identifiable.

Now suppose the municipal operator proposes changing notice to two hours, with every other case premise unchanged. The fallback still needs six hours from receipt. Required storage would become 50 m³/h × 4 h = 200 m³. The existing buffer’s 120 m³ qualification survives, but it does not establish support for this changed use. The integrator reopens the arrangement and the municipal decision; it cannot authorize that operator’s notice change. It may seek a larger qualified provision, an accepted narrower use or another adequate arrangement. Until one is supplied, the changed service claim remains unsupported. Unrelated gate limits and the original arithmetic remain usable within their original conditions.

If a subsequent occasion retains the original notice, flow, configuration and permissions, an adequate current account can support the same bounded decision without another modelling project or exercise. Recheck a changed or expired qualification when the receiving reliance requires it.

SYSE.18:5.3 - A different mismatch needs a different remedy

An order-fulfilment service uses an independent stock provider and payment provider. A compatible message format does not settle whether a stock response reserves an item until payment completes. Following one order exposes the dependency: stock may disappear between the response and the sale. Queueing the response does not create a reservation. Compare obtaining a time-bounded reservation from the stock provider, a supported confirmation-and-compensation arrangement, or a narrower service promise. Each needs its own operational semantics, authority and evidence. If those means are absent, this Method returns that precise gap; the drainage buffer offers no transferable guarantee of transactional correctness.

When the full pattern is unnecessary. Use ordinary architecture, configuration, integration and Work patterns when one Agent controls every decision that can change the integration result. Reuse an adequate constituent-coordination decision when the present use and its relied-on conditions are unchanged.

SYSE.18:6 - Bias Annotation

Systems-of-Systems literature is influenced by defence, formal model federation, and software orchestration. Use each source for the Method and case it actually studies. A cross-domain constituent classification, governance form, representation, or integration Method needs its own evidence. Official attention and conformance describe publications or declared rules; project use and effectiveness need evidence from performed Work and outcomes.

Compare several decision centres by their actual authority, operations, outcomes, and feedback. Distributed and centralized arrangements can each help or harm; the label decides nothing.

SYSE.18:7 - Conformance Checklist

• One shared use, conditions, interval, affected Systems, current decision, and deciding Agent are stated.
• Every constituent is an actual System included because its participation, output, failure, change, or withdrawal can alter the use.
• Each relied-on relation has its own predicate and participants; no umbrella contribution relation replaces it.
• Independence is stated for named decisions and relations, not as an absolute property.
• Every deciding Agent, assignment when relevant, authority, permission, conflict, and escalation is stated.
• Interface syntax is supplemented by configuration-bound exchange and use evidence where interoperability is claimed.
• Alternatives address the same receiving result or expose an accepted scope change; the comparison preserves protected conditions, competing uses, whole burden and unresolved premises.
• The selected continuation remains within the deciding Agent’s authority and names outside decisions and unsupported dependencies. A conditional alternative is not relied on as an available fallback.
• Affected practitioners can recover the choice and its reasons for their own action; a material objection, missing resource or missing professional means receives its appropriate continuation.
• Any claimed coordination change identifies performing Agent, Method, dated Work, actual change or relation, configuration, representative observation, and evidence limits.
• The decision episteme, performed Work, world-side change, and observed-coordination claim are identified and grounded separately.

SYSE.18:8 - Common Failures and Repairs

These recurring failures hide a relation, deciding Agent, or evidence boundary:

SYSE.18:9 - Consequences

Distributed authority and unsupported dependencies become visible before integration fails. The integrating Agent can make a bounded useful change within its authority. The conditions relied on by the shared use and the monitoring Work needed to maintain them become explicit.

The cost is negotiation and maintenance of constituent claims. Keep the account focused on Systems that can affect the shared use, and reopen only the claims a change affects.

SYSE.18:10 - Rationale

Shared use depends on actual relations among Systems while authority and evolution remain distributed. Treating every constituent as an owned component hides withdrawal and decision boundaries. Engineers can act through named interfaces, commitments, buffers, and fallbacks. Separate decisions, Work, changes, and observations make bounded integration possible.

SYSE.18:11 - SoTA and Source Use

The professional question is how to choose a workable shared-use arrangement when constituent changes and resources are controlled independently. This pattern selects a bounded comparison of consequences, feasible configurations and independent decisions. It preserves useful current arrangements and develops only the connection needed for the decision. The selection is conditional on that scope, not a claim of universal effectiveness.

A serious alternative is a formal mission-configuration analysis. Raz et al. 2024, sections III–V, connect a mission description, spatial and temporal feasibility, and analysis of candidate configurations. That connected construction is useful when several allocations and shared resources make informal comparison unreliable. Their example is notional and the analytical choice remains domain-specific. Section :4.1.2 retains feasibility before preference; it adds the independent authorization and provision needed for the present engineering use.

For the four-System case, both approaches can expose the two-hour interval. The short timeline and comparison already settle the current bounded choice with the supplied engineering results. A new formal model would add construction and maintenance without a demonstrated change to this decision. The accepted loss is weaker coverage of many interacting configurations. Reopen this depth choice when multiple concurrent demands, alternative constituent allocations or coupled changes defeat the inspectability of the small comparison. Use the fuller analysis where its result can change the choice; a model still requires compatible source data and its outputs do not grant a participant’s permission.

The following contributions answer different parts of the problem:

Reconsider a used claim when a relevant source correction, stronger comparative result or observed use failure changes its configuration, authority, outcome or transfer premise. Preserve useful unaffected contributions.

SYSE.18:12 - Relations

• A compatible SYSE.6 result supplies architecture constraints for the same shared use. Ground constituent participation, commitments, authority, and interoperability under their direct patterns.
• A.1.SCR governs actual System recognition; A.22 governs selected structures; E.18.NET governs a transformation-flow network only when its members and relations are independently established.
• A.6.P, A.2.2, A.2.8, and A.10 separately govern service wording, capability, commitment, and evidence claims.
• A.2.1, A.2.8.PER, A.15.1, A.3.1, A.3.4, and A.15.PROD govern assignment, permission, Work, Method, actual change, and production claims. Another Agent’s decision authority still needs its own direct claim.
• A specialist practice retains its own decisions and authority—for example, Organization Change, Corporate Governance, Operations, Configuration, Maintenance, safety, security, law, finance, or contracting.
• SYSE.11 can use a compatible observed-coordination claim for the same constituent Systems, configuration, shared use, and interval. Ground any later fulfilment or authority claim separately.

SYSE.18:End

SYSE.23 - Choose What to Change So Later System Changes Become Easier

Status: Stable

SYSE.23:0 - Use This When

Use this pattern when an engineer or manager says that a product or product family must become more evolvable, but the next change is still slow, expensive, unsafe, or hard to assure. The limiting condition may be in the project system-of-interest, its family architecture, a builder or enabling System, an engineering platform, a Method, an Agent’s capability, the Work that enacts a change, or a relation among them. Calling all of these the system hides both the present difficulty and the architecture change worth funding.

Here, the builder arrangement comprises the named Systems, Agents, Methods, Work, services, configurations, and direct relations used to make, change, verify, release, or support the project system-of-interest for the selected future-change family. An account of that arrangement identifies each participant and relation.

The first useful result has three parts:

1. a grounded account of the project system-of-interest and its builder arrangement that keeps five claim kinds separate: characteristics of obtaining selected structures, capabilities of named holders for named Work, results and resources of change-Work occurrences, claims about a joint arrangement with named participants and relations, and supported causal or contribution claims;
2. separate specifications of possible-future selected structures for the project system-of-interest and builder arrangement, including the genuine holonic levels, non-holonic dependencies, and Work relations that matter to the decision; and
3. one replayable ChoiceResult for a bounded investment or reconfiguration.

First move. Name one class of future change the project expects to make: for example, add a sensor variant, replace a supplier component, adapt to a new operating environment, reuse evidence across configurations, or change the release Method. State the available basis: actual observations where available, otherwise the qualified model or estimate supporting the prospective account. Distinguish what is observed, estimated and unresolved. Classify each claim: does it concern an architecture characteristic, a holder capability, a result or resource of change Work, a constraint in the joint arrangement of the project system-of-interest and builders, or a supported or suspected contribution? Keep obtaining structures and actual Work separate from proposed structures and expected results. If the sentence still says only the system is hard to change, the decision is not ready.

In practitioner-facing prose here, an Agent means an admitted System considered in an agent role, with enough agency for the named decision or Work, scope, and period; A.13 supplies the underlying agency result. System identity, local system-role classification, capability, assignment, authority, and actual performance remain separate claims. C.11 uses DecisionSubject for the person, team, organization, or other collectivity whose choice is recorded.

Use C.25 when the immediate task is to repair one composite quality claim. Use C.30 and C.32 when the immediate task is to characterize or choose one architecture independently of the relation between the project system-of-interest and builder arrangement. Use SYSE.6 when the current option set concerns only the engineered-System architecture. Use SYSE.12 when the practical result needed is one engineering-platform service. When the needed change is primarily organizational or concerns human capability, use the relevant Organization Change Engineering or Human Capability Development DPF result when available; otherwise name the specialist help needed and use a qualified source. Use SYSE.21 when cultural continuation is the current question.

SYSE.23:0.1 - Short Practitioner Use

For a first pass, use one expected change family and one decision horizon:

1. State the change to be made, the project system-of-interest when it already exists or the intended-system claim when it does not, the configurations affected, the horizon, protected consequences, resources, DecisionSubject, chooser granularity, and authority.
2. Classify each current claim before assigning a quality bearer. Separate architecture characteristics, holder capabilities, change-Work results and resources, joint-arrangement claims, and causal or contribution claims.
3. Recover three structures when they matter: genuine part–whole or membership levels with their scale and cross-level conflicts; non-holonic dependencies or service relations between the project system-of-interest and builder arrangement; and first–then or overlapping Work.
4. Keep obtaining architecture relations and current observations separate from specifications and expected characteristics of possible-future structures.
5. Develop alternatives that change different selected structures of the project system-of-interest or builder arrangement. Show how each alternative changes option reachability, change cost, assurance, rollback, and displaced burden.
6. Compare the finite changes through C.11.CRC. Then carry the full C.11 decision record: stable OptionSet, shared comparison basis, ChoiceRule, probe cost and value when relevant, and one ChoiceResult permitted by that rule.
7. Plan, authorize, perform, and observe the chosen change separately. Later Work can support or defeat the earlier claims; the decision record does not make the architecture change occur.

This attention order is not a universal Method unfolding. Development of the project system-of-interest, development of its builders, platform service, Method change, evidence Work, and capability development can overlap, recur, or remain separate Work wholes.

SYSE.23:1 - Problem Frame

An engineered System does not become easier to evolve in isolation. A replaceable module may still require a fixture the factory lacks. A configurable product family may outrun test and evidence reuse. A simulation platform may generate variants that manufacturing cannot build or service. A flexible Method may depend on skills, permissions, or data that the assigned Agents do not have. Conversely, a costly redesign of the project system-of-interest may add little when the actual bottleneck is a slow builder or unavailable test service.

Evolvability is therefore an entry word, not a ready-made scalar or one universal quality bearer. An architecture-characteristic claim concerns an identified selected structure of a System, family relation, platform, or Method. A capability claim concerns a named holder and target Work under stated conditions. Lead time, rework, defects, and consumed effort may be results or resources of bounded change Work. A claim about the joint arrangement of the project system-of-interest and builders identifies its participating Systems, Methods, Agents, and relations. A claim that one architecture change caused or contributed to a Work result needs its own support. These claims may be compared, but they do not become the same kind.

The structures also differ. The project system-of-interest and a builder System can each have genuine constructive part–whole levels. Actual family members can participate in a membership structure. A component- level change can create a simultaneous whole-System or family-level conflict. Those are genuine level claims only when the part–whole or membership relation, scale, and horizon are stated. A dependency between the project system-of-interest and builder arrangement, a provider relation, or a platform service is non-holonic unless another relation establishes otherwise. Build-the-builder Work that precedes testing of the project system-of-interest is temporal Work order, not a level.

SYSE.23:2 - Problem

The first failure assigns every evolvability quantity to an unnamed system. Evidence from one software module, prototype, team, or change occurrence is then reported as a characteristic of the product family, factory, engineering platform, Method repertoire, organization, and culture. No one can tell whether the claim concerns architecture, capability, Work performance, a joint arrangement, or causal contribution.

The second failure chooses a familiar mechanism before the claim subject is known. Mechanisms such as modularity, standard interfaces, automation, digital twins, feature flags, AI coding, continuous delivery, or reusable tests are treated as universal answers. Each can help one change family and damage another through latency, coupling, option loss, verification load, supplier dependence, configuration growth, security exposure, or maintenance burden.

The third failure describes a desired architecture as if it already obtained. A roadmap contains a configurable platform and automatic evidence reuse, so current lead-time claims are calculated from those possible-future features. The investment decision then uses benefits that only the investment could create.

The fourth failure demands open-ended improvement without a bounded horizon or stop. Candidate generation grows, but admissibility, integration, safety, cost, environmental consequences, and selection do not improve. More variants become more inventory and assurance debt.

SYSE.23:3 - Forces

The recurring tensions are:

• Reachability and control. More admissible variants can preserve future options, while uncontrolled variation increases configuration, integration, safety, and service burden.
• Modularity and system performance. Looser coupling can localize change, while added interfaces, indirection, mass, latency, or duplicated capability can damage current performance.
• Gain in the project system-of-interest and builder debt. A shortcut in the project system-of-interest can deliver one increment quickly while making later manufacturing, integration, evidence, or maintenance Work harder.
• Platform reuse and local difference. A shared platform can reduce repeated Work, while forcing unlike profiles through one service can erase constraints that matter.
• Change speed and evidence continuity. Small reversible changes shorten feedback, while assurance and configuration evidence must still refer to the changed System and use.
• Automation and authority. AI and robotic Agents can generate, implement, or test more variants, while assignment, review, permission, release, and responsibility remain separate.
• Exploration and exploitation. A project needs alternatives and stepping stones, while a current decision needs a finite budget, protected losses, and a stop condition.
• Project intervention and cultural continuation. One successful reconfiguration can justify local use, while it does not establish discipline-wide selection, prevalence, or retention.

SYSE.23:4 - Solution

Classify the current claims before deciding what should change. Recover the obtaining structures of the project system-of-interest and builder arrangement, including genuine levels where they matter. Keep their non-holonic relations separate from temporal Work structure. Specify possible-future structures separately, compare materially different investments against the current arrangement, and return one replayable architecture ChoiceResult whose later consequences can be observed.

Local mantra. An expected change exposes a current difficulty. The team identifies whether the difficulty is an architecture characteristic, capability limit, change-Work result or resource, joint-arrangement constraint, or suspected contribution. Several views show genuine levels, dependencies between the project system-of-interest and builder arrangement, and Work order or overlap without merging them. Alternatives that change either side are compared from one current basis. A bounded choice is recorded; later Agents perform Work and supply observations.

SYSE.23:4.1 - Perform the Move

1. Bind the future-change question. Name what the decision concerns. When the designated project system-of-interest already exists, cite a compatible SYSE.1 result and the plan or decision that designates it. When the System is still intended, keep its designator and expected change or use in a WorkPlan, decision, System description, or other claim episteme until identity inception. When a System family is in scope, identify the family, its actual member Systems, possible-future specifications, membership relation, and effectivity basis without calling the family another System. Add current configurations, expected change family, use, environment, affected Systems, horizon, frequency or scale of change, protected characteristics, resource limits, receiving decision, DecisionSubject, chooser granularity, and authority. The expected changes must be concrete enough that an engineer can tell what counts as admitted, completed, failed, or out of scope.
2. Classify the claim before naming its subject. Use one of five working forms:
   • an architecture-characteristic claim about an identified selected structure and its bearer;
   • a capability claim about a named holder, target Work, conditions, and evidence;
   • a result or resource claim about a bounded change-Work occurrence or a declared class of comparable Work;
   • a claim about a joint arrangement with the named project system-of-interest, builder Systems, Methods, Agents, and direct relations; or
   • a causal or contribution claim that connects a changed structure or capability to a later result. Identify the world-side subject independently. Treat descriptions, role labels, organization charts, Method accounts, and dashboard rows as epistemes or presentation elements used by Work.
3. Qualify each claim on its own basis. For an architecture characteristic or C.25 quality bundle, state the bearer, selected structure, change family, scale, reference scheme, window, constraints, mechanism, evidence, uncertainty, and unsupported stronger claim. For capability, state holder and target Work. For change Work, state the Work occurrence, enacted Method, result and resource coordinates, configuration, and conditions. For a joint arrangement, state participants and relations. Keep causal contribution separate from co-occurrence, sequence, and correspondence. Do not compare claims that use different subjects, change families, scales, or horizons without a declared comparison relation.
4. Recover three different structures. For each view, state its EntityOfConcern, relation type, scale, horizon, and decision use.
   • In the holonic or membership view, identify constructive parts and wholes or actual family members. Record simultaneous cross-level conflicts when a local change improves one level while burdening another.
   • In the system-of-interest–builder relation view, identify the direct dependencies, correspondences, provider, service, interface, or enabling relations used by this decision. Do not infer part–whole from dependence.
   • In the Work view, identify first–then, overlap, concurrency, and recurrence among Work occurrences. Do not infer a level from earlier Work. Leave a view unused when it cannot affect this decision.
5. Separate current facts from possible-future specifications. For every proposed change—for example, a module boundary, interface, product-family rule, fixture, test service, automation, Method change, or provider arrangement—write a possible-future architecture specification and the later Work and observation needed to establish it. Keep expected characteristics separate from current readings.
6. Find the constraining relation and its evidence. Ask which proposed change to the project system-of-interest is unreachable, too costly, too slow, too hard to assure, or too hard to roll back under the current builder arrangement. State the selected structure of the project system-of-interest, the builder structure or service, their direct relation, the affected result, evidence, uncertainty, and moved burden. When a causal contribution is needed, state the mechanism and the comparison or intervention basis; do not promote co-occurrence or earlier order into causation.
7. Develop alternatives on both sides. Include the incumbent and materially different changes such as a boundary or interface of the project system-of-interest, family configuration rule, builder fixture or manufacturing cell, test and evidence platform, release Method, supplier arrangement, or a change spanning both sides. In product–production cases, include production-process and production-System reconfiguration when they constrain product-family change across generations. State which selected structure each alternative changes and which constraints it leaves untouched.
8. Compare finite changes. Use C.32.ACS to choose a few optimization indicators and monitored guardrails with their actual claim subjects and scales. Apply C.11.CRC to each realizable finite change relative to the current configuration of the project system-of-interest and builder arrangement. Preserve result and resource vectors, implementation Work, interactions, uncertainty, reversibility, future-option effects, and displaced burdens. Do not score possible option reach as an already realized operating result.
9. Return a replayable investment choice. Freeze the viable OptionSet. State one shared preference order or evaluative measure, BeliefState, and OutcomeModel. When another probe is live, state its action set, budget, cost, and expected decision value. Apply one ChoiceRule and emit one ChoiceResult from the current C.11 result set: choose the incumbent or a change to the project system-of-interest, builder arrangement, or both; retain a tie-set; reject the current set; request a probe; or reroute and end this decision pass because the question, authority, or needed input lies elsewhere. Record protected losses, budget, dependencies, why the ChoiceRule permits this result, and overturn conditions. The choice may issue an implementation request, but it does not authorize or perform the change.
10. Realize and observe separately. Assigned Agents later perform separately identified Work that changes the project system-of-interest, a builder System, platform, Method, or organization arrangement under its own authority and enacted Method. Observe representative future changes through measures relevant to this decision—for example, reachability, lead time, rework, defect introduction, evidence reuse, rollback, consequences for the project system-of-interest, provider burden, or newly exposed constraints. Revise only the claims and architecture decisions that the observations support or defeat. Send human capability demand to Human Capability Development and cultural-continuation evidence to SYSE.21 rather than hiding either inside an evolvability score.

SYSE.23:4.1.1 - Make the future change concrete enough to diagnose

The short move above starts with an expected change family. Construct that input from a current use need, a supported SYSE.22 correspondence, a supplier or operating change, or a recurring difficulty in actual change Work. Do not begin with “adopt microservices” or “buy a digital platform”; those already select a means.

Describe a representative change as a difference between two usable configurations under stated conditions. Name the changed behaviour or interface, the members or installations affected, the result needed from the changed System, and how successful completion would be recognized. Include the configuration that must continue to operate during transition. A supplier replacement, a network-loss mode and a different service environment are different scenarios even when all are called “add a variant.”

Select scenarios that could distinguish the investment alternatives. A near-term change can expose present burden; a consequential different change can reveal whether the proposed mechanism generalizes; a protected operating or recovery condition can expose its unacceptable loss. Give projected frequency or scale only when there is a basis for it. When future demand is uncertain, compare the investment under several plausible demands and say where the preference changes.

The question can be narrower than general evolvability: “make the next supplier replacement possible while six released configurations remain supportable.” If that is the present need, a general platform may be unwarranted. If the source is a SYSE.22 probe result, preserve exactly what it settled. A pass for local fallback in two configurations does not establish compatibility with a new compressor supplier or justify cross-variant evidence reuse.

SYSE.23:4.1.2 - Trace what has to change and why

Work one scenario through the current arrangement. Begin at the proposed change in functioning, configuration or interface and ask what must be revised, reproduced, obtained, checked and supported for the result to become usable. Follow the action-changing dependencies across target parts, descriptions, production means, tests, release and service. Use the realization branch construction in SYSE.3:4.2–4.4 rather than reconstructing a complete builder hierarchy. A branch can stop at an adequate supplied result.

Explain each consequential propagation. A new protocol may require an adapter because its timing differs; an evidence result may need renewal because its configuration basis changed; a rig may require requalification because its emulator now represents a different physical response. “Everything depends on everything” gives no place to intervene. Conversely, an unchanged interface name does not show that timing, failure behaviour or support demands remain unchanged.

Distinguish two mechanisms that often get mixed:

• Change propagation: modifying one description, interface or implementation requires compatible changes elsewhere before the new configuration can be used.
• Operational propagation: a disturbance or failure in one part affects another during use.

A boundary can reduce one propagation while worsening the other. An adapter may localize future firmware changes yet add response delay or another failure mode. A shared test service may reduce duplicated setup while making several projects depend on its availability. Retain both consequences where they matter.

For every apparent bottleneck, compare the required contribution with what the current arrangement supplies. A slow task can result from intrinsic technical work, repeatable setup, waiting for a shared resource, missing capability, unresolved authority or unavailable evidence. Each suggests a different intervention. The number of touched modules and elapsed time of one change are observations, not a causal decomposition. Use the five claim kinds in §4.1 to keep the supported constraint distinct from the suspected explanation.

The useful intermediate result is a small set of constraining relations and their effects on the chosen scenarios. It can be written directly on the existing architecture or realization account: what change demands what contribution, why, from which System or performer, under which condition, and with what support or gap. Do not model an entire organization when one interface and rig correspondence decides the question.

SYSE.23:4.1.3 - Construct mechanisms on both sides of the constraint

For each limiting relation, ask which premise an intervention could change. Keep the incumbent as the common basis and construct materially different responses. The following alternatives illustrate how to reason.