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