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

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

Status: Stable

SYSE.24:0 - Use This When

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

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

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

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

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

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

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

SYSE.24:0.1 - Precision Restoration

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

SYSE.24:1 - Problem Frame

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

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

SYSE.24:2 - Problem

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

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

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

SYSE.24:3 - Forces

The following eight tensions recur in this decision.

SYSE.24:4 - Solution

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SYSE.24:5 - Worked Cases

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SYSE.24:6 - Bias Annotation

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

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

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

SYSE.24:7 - Conformance Checklist

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

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

The following rows document recurring failures and their repairs.

SYSE.24:9 - Consequences

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

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

SYSE.24:10 - Rationale

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

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

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

SYSE.24:11 - SoTA Echoing

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

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

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

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

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

SYSE.24:12 - Relations

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

SYSE.24:End

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

Status: Stable

SYSE.3:0 - Use This When

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

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

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

SYSE.3:0.1 - Terms and Distinctions

SYSE.3:1 - Problem frame

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

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

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

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

SYSE.3:2 - Problem

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

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

SYSE.3:3 - Forces

SYSE.3:4 - Solution

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

Start with one current architecture result for one described holon:

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

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

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

SYSE.3:4.2 - Describe one realization branch

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

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

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

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

SYSE.3:4.3 - Find the first unsupported answer

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

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

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

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

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

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

SYSE.3:4.5 - Plan the next Work separately

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

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

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

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

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

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

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

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

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

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

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

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

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

SYSE.3:5 - Archetypal Grounding

SYSE.3:5.1 - Pumping station under flood risk

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

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

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

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

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

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

The architecture candidate concerns one deployed production-planning System. It names the software bearer, interfaces to order and shop-floor Systems, selected data and decision relations, and the planning functions that those Systems are expected to support.

The first unsupported branch is the change from current product, order, and resource descriptions to the configuration and integration state required by the candidate. PlanningIntegrationTeam-2 is the candidate transformer System for RepresentativePlanningDataIntegrationWork-1: mapping one representative data family and configuring its source-to-planning interface. The planned holder-dependent capability requirement is the ability of that team to apply BoundedPlanningDataMappingMethod-v1 under the actual source semantics, access, timing, and configuration conditions. This is WorkPlan content until A.2.2 supplies a current capability result and A.2.1 supplies an assignment occurrence when one is needed.

MigrationToolService-3 is a separate proposed tool or service contribution to that Work: access to a named mapping-execution interface under the selected configuration. This case attributes no transformer assignment or data-mapping capability to that service label. If a later claim relies on it as an acting System, the engineer applies System recognition before making separate claims about its role, capability, and Work. The immediate WorkPlan item names PlanningIntegrationTeam-2 as intended performer of the representative-slice feasibility investigation and asks for RepresentativeIntegrationFeasibilityAccount-1 plus any organization- design result needed to make the slice feasible.

If the gap concerns who may change source definitions, which organization holds an assignment, or which authority relation applies, the engineer obtains that result from Organization Engineering or Governance rather than encoding it as a technical interface. If the branch cannot preserve the required decision timing or data meaning, the engineer reopens the C.32 comparison of interface, placement, and responsibility structures. The engineer reassesses the linked planning concept under SYSE.2 only when the planning-use claim must change. The words platform and migration pipeline establish neither integration capability nor one universal Work order.

SYSE.3:5.3 - Occupied building retrofit

SYSE.2 supplies the continuing building, the occupied-use claim, and a candidate concept through the occupied region, safe-entry, egress, and essential-service interfaces. C.30 and C.32 supply candidate building zones, service paths, interfaces, and load-bearing relations. Temporary access, work-area isolation, and construction sequencing remain realization and WorkPlan questions.

The first unsupported branch is how a contractor System can reach and change the selected building region while the occupied-use boundary and essential services remain supported. The candidate transformer System is one contractor team. Access-equipment Systems remain separate resources or participating Systems unless their relation to the team is independently established. The missing support is a capability claim under the occupied configuration, access, isolation, load, and service-continuity conditions. The first WorkPlan item is a contractor-capability and temporary-access investigation for those conditions.

If no admissible access arrangement remains, the engineer reopens the C.32 comparison of zones, service paths, placement, and interfaces. The engineer reassesses the linked occupied-use concept under SYSE.2 if continuing occupancy or the use boundary must change. A construction sequence is plan content; it is not the building concept, the changed building, or evidence that the Work has occurred.

SYSE.3:6 - Biases to Watch

Two recurring biases matter here. Diagram-made feasibility treats a product tree, schedule, or toolchain description as proof that capable transformers and relations obtain; return to the first unsupported branch. Endless builder recursion expands every dependency before choosing useful Work; recurse only when the added branch changes the next action.

SYSE.3:7 - Conformance Checklist

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

SYSE.3:9 - Consequences

Engineering participants gain an early feasibility result without waiting for a complete WorkPlan. One unsupported branch becomes visible together with the System and Work needed to resolve it. Recursive build-the-builder dependencies can be added where they change the next action, while architecture candidates remain open to repair.

The cost is explicit incompleteness. A provisional realization-network description can contain unresolved Systems, capabilities, Methods, relations, and specialist needs. Maintaining the distinction between that episteme, a WorkPlan, and actual Work takes care, but it prevents planned or drawn dependencies from being mistaken for physical feasibility.

SYSE.3:10 - Rationale

Systems Engineering connects a proposed System to the Systems and Work that can make or change it. The systems mantra keeps outside use, architecture, and transformer dependencies in view. In this pattern, engineers inspect those dependencies toward the first unsupported branch and relate later observed Work and change through their own facts. These are two views of the case, not one calendar sequence.

The recursive account is deliberately demand-driven. An exhaustive description of every supplier, tool, team, capability, and possible dependency would be expensive and unstable. One unsupported branch plus one WorkPlan item is already enough to change what the project does next. Further recursion is justified only by that next decision.

SYSE.3:11 - SoTA-Echoing

The manufacturing, portfolio, integration and platform sources above support particular contributions; their domain results do not establish the superiority of the combined Method. The same-question choice below determines when its bounded first result is useful and when an implementation Method already supplies enough.

SYSE.3:11.1 - Choose the next action with an implementation-preparation alternative

Question and common basis. In the pump case in :5.1, what can the engineering team plan next before committing the manifold to fabrication? Compare the two ways using the same architecture, material and geometry claims, supplier statements, access conditions and feasibility window. Both require the team’s capability fit and access before the investigation can begin. Count source retrieval, specialist coordination, recording and the preparation still needed later, rather than equating a shorter description with less total effort.

A serious alternative is the NASA Systems Engineering Handbook, §5.1, Product Implementation, especially §§5.1.1.1 and 5.1.1.2.1–5.1.1.2.2. Adopt its review of implementation inputs, personnel skills and enabling products, and its distinct make, buy and reuse duties. It permits tailoring preparation to complexity; reuse requires fitness for the new requirements and environment. Its enabling-product questions already expose the missing fixture and qualification evidence in this case.

Selection and accepted cost. For this narrow planning question, use the first unsupported dependency together with an explicit stopping condition and a named return. The stopping condition limits the fixture inquiry to dependencies that change its next action; the named return directs adverse evidence to the architecture choice it actually changes. These are requirements on the reasoning, not benefits conferred by another form. If the implementation-preparation account already supplies them through its branch description and WorkPlan,

4.7 reuses those results; rewriting the account in five lines adds no gain. If they are missing, add the bounded dependency and return to the existing account.

This choice deliberately defers completeness of production preparation. Obtaining a first action leaves personnel, enablers, quality controls, verification inputs and implementation records to be established for the eventual make, buy or reuse decision. Their later effort remains in the comparison. When that wider readiness is the present question, the implementation Method supplies the stronger result. The worked comparison supports this conditional choice; it supplies no measured time saving or general ranking of the two Methods.

Reopen the choice when a second interacting branch or shared-resource constraint can change the selected action, when the remaining preparation can no longer be deferred, or when another implementation Method supplies the same bounded decision with less total work. Use :4.4 or the specialist return in :4.6 for the changed dependency; do not preserve a separate SYSE.3 account merely because it was started.

SYSE.3:12 - Relations

• A compatible SYSE.6 architecture decision supplies only the selected structures, constraints, alternatives, accepted losses, and reopen conditions needed by this realization question. A compatible SYSE.8 provider- arrangement account supplies only supported provider claims and design constraints that change a branch. Each use rechecks subject, configuration, use, horizon, evidence window, and availability; otherwise it uses a qualified direct source or records the missing result.
• C.30 supplies the grounded architecture question and claims; C.32 supplies candidate configurations over selected structures; C.32.PAD supplies a project architecture decision when that question is current. A missing architecture function bearer reopens the bearer question under A.6.F and C.32.
• A.1.STM keeps the outside-use, architecture, and realization questions in attention while the engineer finds the first unsupported answer and later relates observed Work and change through independently grounded facts. It supplies neither Work order nor an actual realization network.
• A.2 supplies the local TransformerSystemRole kind; A.2.1 supplies an obtaining assignment; A.2.2 supplies holder-dependent capability and its envelope, measures, qualification window, and currentness. Candidate wording and WorkPlan content establish none of these facts.
• A.15.2 supplies a WorkPlan for intended Work. A.15.1 and A.3.1 govern actual Work and enacted Method. A.3.4 governs actual bounded change, and A.15.PROD governs subject-specific production results and completion claims when those distinct questions are current.
• E.18 supplies one selected transformation-flow structure. E.18.NET supplies a selected network only after independent members, obtaining relation occurrences, endpoint bindings, constraints, and use frame are established. Before that boundary, keep a provisional description and name the missing discriminator.
• SYSE.11 may use only the recursive realization arrangement from a compatible result for the same increment boundary. It does not perform Work, establish platform use or constituent commitments, or make the proposed System actual.
• Feasibility, integration, configuration, cost, delay, and evidence results can change the smallest branch, architecture, concept, use, or project-focus claim to which they apply. Platform Engineering, Organization Change, Operations, portfolio selection, configuration, safety, security, governance, law, finance, and other specialist practices retain their Methods and decisions.

SYSE.3:End

SYSE.11 - Integrate a System for One Bounded Use

Status: Stable

SYSE.11:0 - Use This When

Use this pattern when locally completed parts or changes have accumulated, but their joint operation has not yet established that one actual engineered System is usable for a stated purpose. Integration is the broader engineering concern; this pattern develops the bounded move from available contributions to a configuration that supports one receiving use. It includes choosing the integration progression, correcting discovered incompatibilities and assessing the resulting whole.

Begin with the actual System, its current configuration and the needed use. Recover an adequate existing integration strategy and assessment before constructing what is missing. A strategy can supply the grouping, assembly and check order directly. A current qualified result covering the same configuration and use can finish the assessment directly; neither a new trial nor another record is required merely to use this pattern. Otherwise choose the smallest joint change that can support the use, expose its consequential interactions early, perform the integration Work and use the resulting observations to assess the changed System.

The first useful result is a bounded usability assessment: an episteme stating what the actual System can support, on what grounds, for which configuration, conditions and interval, and with what limits and fallback. The changed System, the Work and transformations that produced its configuration, and this assessment remain distinct. Permission and release are separately governed decisions.

Finish when that result answers the receiving question. If a further change or inquiry could improve a live decision, use C.11.CRC when its finite contribution comparison is missing, then C.11 for the choice. A lack of information about an optional feature does not by itself require further observation.

Use SYSE.14 for authorization or release, SYSE.4 for a load-bearing assurance claim, and Operations Management for continuing queues, allocation or operating control. Specialist assembly, protection and test techniques remain with the practices that qualify them; the integration strategy connects their results and conditions.

SYSE.11:0.1 - Terms and Distinctions

SYSE.11:1 - Problem Frame

Engineering Work often produces local completion before it produces a usable whole. A manufactured part can match its drawing while failing an installed interface. Software can satisfy component-test conditions while, for example, its controller interface, sensor relation, physical plant, operator procedure, or evidence basis remains incompatible. A prototype can demonstrate one effect without supporting the configuration and operating envelope needed by the next decision.

No one lifecycle or cadence governs all of these dependencies. Work on, for example, physical parts, software, evidence, platforms, suppliers, configuration, and operation can overlap at different cadences. Engineers select one bounded integration boundary, connect the contributing Work and transformations to it, observe use, and return a result that can support the next decision within that use boundary.

SYSE.11:2 - Problem

A claimed increment is not decision-usable until the responsible engineers can answer:

1. Which actual System and starting configuration are changing?
2. Which receiving use, operating conditions, affected Systems, and interval bound the result?
3. Which changes belong inside the increment—for example, physical, software, description, procedure, or interface changes—and which remain alternatives?
4. Which input results are needed—for example, results from realization, platform, constituent coordination, configuration, specialist, or authority Work—and were they available before the Work that relied on them?
5. Which Agents performed which dated Work by which Methods, and which actual transformations and relations obtained?
6. What integration and operating observations support usability, and what claims remain unsupported?
7. What fallback, stop, separate assurance or release decision, and later change can reopen the result?

Without these distinctions, done becomes a proxy for actuality. Engineers can ship incompatible parts, overread a component test, confuse a release record with use, or keep adding features without producing a configuration that anyone can use.

SYSE.11:3 - Forces

• A small increment shortens feedback, while its use can still depend on relations outside the changed parts.
• Software and descriptions may change quickly; Work involving, for example, procurement, fabrication, access, integration, and physical observations often changes more slowly.
• Each contributor needs a local completion condition, but no local completion proves usability of the containing System.
• Some changes are easy to reverse; others alter scarce equipment, permits, safety conditions, or independently governed Systems.
• Automated tools can help Agents assemble records, compare configurations, and run checks rapidly. Establish the governed use, acceptable loss, and authority boundary separately.
• The receiving use needs a supported System configuration while engineers preserve alternatives for future change.

SYSE.11:4 - Solution

Work back from the receiving use to the relations that must hold together. Choose a feasible progression that reveals consequential incompatibility before it becomes expensive to correct. Establish those relations, correct discrepancies and assess the resulting configuration using evidence that actually covers the use.

SYSE.11:4.1 - Perform the Move

1. Name the System and use. State the actual System, starting configuration, receiving use, affected Systems, operating envelope, interval, required behavior and deciding Agent. Distinguish a demonstrated episode from a claim about later use or continuing availability.
2. Recover a sufficient strategy or construct the missing connection. Inspect an existing specialist plan for the same starting state, intended configuration, interactions and use. Follow it where it is adequate. Where the grouping or progression remains unsupported, use :4.1.1 to connect the needed behavior to the joint change, intermediate configurations, integration Work and checks.
3. Establish the inputs before relying on them. Use realization, platform, coordination, configuration and specialist results only for matching subjects, uses and evidence windows. Close an unsupported branch, replace it with a qualified source or retain it as a blocker. Later Work cannot justify an earlier input retroactively. Resolve conflicting demands on shared equipment, access or people before scheduling both uses.
4. Prepare the next integration and its test of progress. Name the actual items, relations and starting conditions, available means, expected behavior, unacceptable result, stop and practical fallback. Select the specialist procedure and observations that can distinguish a successful integration from a consequential mismatch. Reuse sufficient existing evidence; a planned check alone establishes nothing about the result.
5. Perform Work and identify actual change. Keep the performing Agents, dated Work, enacted Methods and results traceable to the relevant subjects. Identify the actual transformations and resulting configuration separately from Work records and descriptions.
6. Check the interaction and act on the result. Use :4.1.2 to proceed, correct and reintegrate, revise the progression or stop. Carry an intermediate result forward only within its demonstrated or otherwise justified scope. Perform the remaining whole-use observation when the assessment needs it.
7. Construct the usability assessment. Use SYSE.10:4.1 steps 6–8 and :4.1.1 for a missing trial-to-use inference or join between results; :4.1.3 below identifies its inputs here. Return the supported use, limits, unsupported claims, fallback and condition for reconsideration. Obtain separately governed assurance, permission, release or specialist results when the receiving decision needs them.
8. Choose later work only when it can matter. A repair needed for the current integration returns through step 6. A further modernization or inquiry is a separate choice. Use C.11.CRC when the finite contribution of realizable alternatives is unclear, and C.11 to compare that contribution with cost, delay and reversibility. Select further observation only when a feasible result could change the live choice or its warranted use. Otherwise finish with the current assessment.

Fabrication, software integration, preparation of the trial environment and assessment construction may overlap. Reliance still requires the particular input to be established before the Work or decision that uses it.

SYSE.11:4.1.1 - Choose the Joint Change and Integration Progression

Derive the boundary from the behavior. Follow the needed behavior through the available architecture and interaction account: what receives the demand, what acts, what it acts on, and what feedback or external participation makes the result possible? Locate where an included change invalidates an existing relation or assumption. A changed controller can require a sensor mapping and an operating procedure even when neither is listed as a feature. Conversely, a proposed diagnostic sensor can remain outside when the existing qualified protection and evidence already support this use. Retain unchanged contributions on their applicable grounds. The boundary is sufficient when the needed behavior has no unsupported consequential dependency, not when every component has been changed or every desirable feature included.

If the behavior or an essential interaction is unknown, return that concrete question to the responsible design or specialist work. SYSE.3 can develop an unsupported realization branch; it does not turn an unknown interaction into a feasible integration merely by placing it in a WorkPlan. An unavailable required item prevents the dependent step, but may leave independent preparation or a useful partial integration possible. Keep the partial result’s purpose explicit.

Choose what to bring together first. Look for an interaction whose failure would defeat the use or make later rework costly. Determine the smallest available configuration in which that interaction can be exercised meaningfully. It may be an actual subset, an existing test rig with a qualified substitute, or the whole System. A substitute is useful only for the behavior it represents: a controller rig can expose signal polarity while leaving hydraulic loading unanswered. Select the later check that must establish the missing correspondence.

Compare feasible progressions where the choice matters. One whole assembly can avoid the expense of substitutes and repeated setup when the few interactions are already well understood. Integration by functional subsets can expose an uncertain interaction sooner and allow independent Work to continue, but needs suitable tools, interfaces between subsets and a final check of their joint behavior. Adding items as they arrive can shorten waiting, yet lose that advantage if it hides the critical interaction or repeatedly dismantles scarce equipment. Use the architecture, expected fault localization, availability, safe access, total setup and correction burden, and the receiving deadline to choose. No matrix, fixed assembly direction or universal batch size is required.

Connect each step to the next. For each consequential intermediate configuration, explain what it lets the engineers learn or perform, what counts as sufficient progress, and which later operation uses that result. Include the enabling means and any external commitments on which that step depends. Do not treat a passed software check as completion of an unexamined physical relation. Do not repeat a qualified unchanged check unless the new integration can defeat its premise.

The resulting strategy needs only enough detail to guide the actual Work and justify its progression. When an existing strategy already makes these choices adequately, use it directly. When a delivery delay, changed interface or new operating condition defeats its rationale, revise the affected grouping or order before continuing; the calendar alone cannot authorize the next step.

SYSE.11:4.1.2 - Correct a Discrepancy and Establish Progress

Compare the observed interaction with the expected behavior under the identified configuration and test conditions. If they agree, establish the progression condition and continue. If they disagree, contain the affected operation using its qualified stop or fallback and preserve the observation that distinguishes the failure. Keep independent successful results available.

Locate the first unsupported or contradicted relation along the exercised interaction. Check what was actually installed and connected, the meaning of the exchanged signal or material, the test conditions and the measurement basis. A discrepancy can arise from an actual incompatibility, an incorrect description or an invalid test; those require different repairs. Use a discriminating observation or specialist diagnosis when the available evidence cannot decide between them. Do not declare the nearest component faulty merely because its output is where the mismatch became visible.

Give the responsible engineering practice the demonstrated discrepancy and the behavior to restore. A wiring or mapping correction may be local; a newly discovered pressure interaction may require a design change and revised fabrication. Identify the resulting actual configuration, then repeat the failed check and the checks whose grounds that correction can invalidate. The comparison with the old result determines this scope; it is neither every test nor only the originally failing one by default.

Proceed when the corrected interaction meets the next step’s condition and no unresolved discrepancy can defeat that reliance. A fix record alone does not show this. If correction is infeasible in the available window, reconsider the boundary, substitute or fallback under its own supported use, or stop. Repeated fixes that expose the same unmodelled interaction reopen the architecture or strategy, rather than just adding another repetition of the same test.

SYSE.11:4.1.3 - Turn Integration Evidence into a Bounded Use Assessment

Give SYSE.10 the required behavior, actual resulting configuration, qualified observations and specialist results, the grounds linking them, and the intended use and interval. If one sufficient result already covers that claim, use it. Otherwise its inference Method develops the missing connection, including why results about different parts hold together and why a trial applies beyond its observed conditions.

Ask the consequential question: could all these observations be true while the proposed use still failed? A rig can be correct while installed wiring differs; a station can pass a trial while a required external buffer is unavailable for the later event. Resolve that premise or return a narrower supported claim. Explain which part is observed, which extension rests on qualified domain knowledge, and which future condition must hold. An evidence window does not itself supply a reason for extrapolation.

Return the assessment when it answers the receiving question, even when the answer is that the intended use remains unsupported. If a later premise changes, reopen the dependent inference and retain unaffected results. Loss of support is not by itself proof of physical failure. The ordinary assessment Method does not require the separate assurance activities in SYSE.4 unless an assurance claim is actually being made.

SYSE.11:4.2 - Record the Result

Use the existing configuration, integration and assessment records where they already carry the needed content. The following are questions to keep answerable, not a mandatory second form.

SYSE.11:4.3 - What Changes in Practice

Engineers choose integration Work to expose the interactions that determine whole-System use. They can explain why a partial result permits the next step, what must be repaired after a mismatch, and why the final evidence supports the selected use. Sufficient existing strategies and assessments remain usable directly. Finishing the increment does not depend on starting another modernization.

SYSE.11:5 - Worked Case: A Flood-Pump Station for Bounded Emergency Discharge

This constructed case supplies qualified specialist procedures and results as inputs. Its numbers illustrate integration and inference; they are not a pump design or operating procedure.

SYSE.11:5.1 - The Use Determines What Must Change Together

A municipal flood-pump station operates in C18. For the next flood-risk month, engineers are asked whether an updated configuration can discharge at least 0.75 m³/s during an attended emergency episode lasting no more than 30 minutes, within the specified inlet-level, head, power and fluid envelope E. Correct response to the pressure signal and the station’s stop function are also required. The request for a month of readiness must distinguish conditional fitness for an episode from a guarantee of availability throughout that month.

The new discharge manifold changes the hydraulic resistance. The selected controller package supplies the corresponding operating settings, and its pressure-input mapping must match the installed transmitter. Those three changes belong together: retaining the old settings or an incompatible mapping would defeat the hydraulic qualification for the new manifold. The operator’s existing procedure receives the changed configuration and limits. The proposed bearing-temperature sensor remains outside: existing qualified protection and maintenance conditions already cover this bounded duty, and no required behavior currently depends on the added sensor.

The engineers recover the realization arrangement, integration platform readiness, temporary collector-buffer commitment and current configuration basis. An earlier unsupported fixture-and-weld branch has been resolved through feasibility Work: a fixture design and current toolmaking/welding capability now support the chosen fabrication Method. The actual fixture and manifold still have to be made. Platform evidence is available before the controller trial; later participation will supply its own observations.

The station remains the same actual System under its reidentification rule: its stable boundary, foundation and pump train continue. C19 names the resulting configuration, not another System or the description of the change. Restoring C18 remains feasible with the retained manifold, settings and a qualified four-hour reinstatement procedure. It restores only C18’s previously supported lower-duty use; it neither instantly undoes C19 nor meets the new 0.75 m³/s requirement. An urgent need outside either supported use requires a separate municipal response.

SYSE.11:5.2 - Expose the Interaction Before the Scarce Station Window

The manifold needs two days of fabrication; the controller, input hardware and existing qualified integration rig are available now. The station has one planned outage window. The engineers compare two feasible strategies. Waiting and testing everything only after assembly would avoid a rig setup, but a signal incompatibility found then would consume the scarce outage and could require reinstatement. An early pressure-input/controller/drive check costs half a day on the existing rig and can distinguish that incompatibility while fabrication continues. They choose the latter. A new full hydraulic simulator would add cost without settling a remaining question that the planned station trial and available hydraulic qualification cannot already address.

The defect is an interaction mismatch: both local items could have passed checks using their own signal conventions. Correcting the conversion changes the installed configuration basis; it does not require refabricating the unaffected manifold. Conversely, a hydraulic mismatch would return to the relevant design or fabrication question. The teams’ dated Work and its results remain distinct from the manifold’s transformation through welding, cooling and rework, and from the station’s transformation from C18 to C19.

The progression condition is substantive: correct range, direction and stop response permit the subsequent installed check, which then permits the whole-use trial under its own conditions. A correction entry cannot substitute for these results. If the manifold arrives late, the rig result remains useful for its tested configuration, but neither C19 nor emergency-discharge fitness has thereby been established. The team revises the outage plan instead of treating software completion as permission to proceed.

SYSE.11:5.3 - Explain the Trial-to-Use Inference

The whole-station trial lasts 30 minutes at the qualification’s reference condition in E. Its lowest indicated discharge is 0.82 m³/s. The qualified measurement bound is 0.02 m³/s, so the observed lower bound is 0.80 m³/s. Correct signal response and the independent stop function have been established in the installed configuration. Those facts establish the tested episode; they do not alone cover every condition in E or the following month.

The available specialist result H19 supplies the missing hydraulic extension. For this installed geometry, controller settings and correct pressure mapping, it bounds the reduction from the trial’s lower flow bound to any permitted episode in E at 0.03 m³/s. Its qualified scope includes the pump’s allowed service condition and the stated one-month application window, with a current pre-use condition check and confirmation of the buffer relation. It includes the relevant interaction and model uncertainty; the trial’s measurement bound is handled separately. How those hydraulic and service bounds were established remains the specialist’s work, not a number inferred from the short trial. If H19 is unavailable or does not cover these conditions, that extension remains unsupported.

Following SYSE.10:4.1.1, the engineers work backward from the required 0.75 m³/s and forward from the actual results. The trial lower bound and H19’s compatible one-sided reduction give 0.80 − 0.03 = 0.77 m³/s, which meets the criterion with 0.02 m³/s margin. Configuration inspection and the installed signal check make H19 applicable. The separately established stop behavior is also necessary; a flow margin cannot compensate for its failure. The buffer must participate under the conditions used by both trial and extension.

The resulting technical assessment supports an attended episode of at most 30 minutes in E during the named month, in unchanged C19, with its qualified service condition and buffer participation confirmed before use. It does not guarantee that the station, power or buffer will be available for every flood event, nor support greater head, longer operation or all-season reliability. The municipal decision-maker receives that conditional fitness result and the still-open availability question. Release and authorization remain separate; if the receiving decision requires unconditional month-long readiness, this assessment does not answer it.

SYSE.11:5.4 - Change One Premise and Keep the Surviving Result

The buffer operator later withdraws the commitment covering the remaining month. The trial observations, mapping correction, installed configuration and independent stop result remain valid for their recorded conditions. H19’s hydraulic statement and the conditional fitness assessment also survive. What must be withdrawn is the recommendation to count on C19 for a later event under the former buffer commitment. This does not prove that the station has lost hydraulic capacity or that the earlier trial failed.

The engineers withhold that recommendation for an event lacking confirmed buffer participation. A new compatible commitment can restore the missing premise; a different discharge route instead needs qualification of its changed hydraulic conditions. Repeating the old trial while the temporary buffer is present would not establish its later availability. Reinstatement of C18 remains possible only through its actual restoration Work and within its lower-duty limits.

For the original completed integration, no extra load-window observation is selected merely because the bearing-sensor option lacks evidence. Another run in E would not qualify that sensor’s placement or maintenance, and H19 already supplies the required flow extension. With no live challenge to that basis, repeating it does not justify another buffer reservation for the current choice. The engineers finish with the supported C19 assessment and its limits. A later proposal for longer duty, a changed service condition or a credible sensor alternative can create a new choice; then C.11 compares a feasible inquiry’s decision effect with its burden. The later buffer withdrawal creates a concrete coordination problem, not a generic obligation to collect more pump data.

Countercase. A document bundle is approved while no actual configuration, integration Work or supporting use evidence exists. Identify the missing contribution; approval alone does not produce a usable increment.

SYSE.11:6 - Bias Annotation

A passed gate or successful software build can be mistaken for evidence of whole-System use. Recover what its underlying checks actually establish and supply the missing interaction or applicability grounds. Conversely, waiting for a complete physical assembly can postpone feedback that an available subset could already provide. Choose the integration boundary from the useful evidence and its total burden.

Institutional status and labels supplied by, for example, vendors, tools, or standards can support particular claims, but they do not establish actual integration or use. Automation can support bounded Work and checks; the receiving Agent still selects the use and any authority relation remains separately supported.

SYSE.11:7 - Conformance Checklist

• One actual System, starting configuration, bounded use, required behavior, conditions, interval and deciding Agent are named.
• The joint change and progression have a reason grounded in the needed behavior and interactions, or a sufficient existing strategy supplies that reason.
• Inputs match the subjects, uses and evidence windows and were available before the Work or decisions that relied on them.
• The actual integration and any correction establish the conditions for the next dependent step; a partial result is not overread as whole-use fitness.
• Work, transformation, actual configuration and the claims in its description remain distinguishable.
• The assessment explains what supports the whole-use claim and any extension beyond observed conditions, using a sufficient direct result or SYSE.10.
• Fallback is feasible for its own supported use; unresolved discrepancies and unsupported claims have a concrete stop or return.
• Separately governed assurance, permission, release and specialist decisions retain their own grounds.
• If later modernization or inquiry is selected, its separate comparison and choice justify the attainable contribution and burden. Otherwise the current result can finish.
• Reopen conditions identify the configuration, use, evidence or relation whose change matters.

SYSE.11:8 - Common Failures and Repairs

SYSE.11:9 - Consequences

An early interaction check can expose a repair while independent Work continues. Intermediate configurations also cost setup, qualification and repeated checks; they are worthwhile when that burden is justified by what they reveal or make possible. A sufficient existing strategy can avoid new planning, and a simple well-understood assembly may need no intermediate rig. The assessment preserves which use has support when a configuration or external relation changes. These are conditional engineering gains, not a measured universal reduction in time or failure rate.

SYSE.11:10 - Rationale

An engineered System changes through actual Work and transformations. A bounded increment exposes compatibility and use evidence before a larger commitment. Continuing modernization preserves the System’s temporal identity and repeatedly returns evidence to engineering decisions.

SYSE.11:11 - SoTA and Source Use

The working question is how to obtain a justified bounded-use result from available parts and local results when some consequential interactions have not yet been established. The same question includes the case in which a competent specialist has already supplied an adequate integration strategy and assessment.

The selected line combines use-driven integration progression with explicit assessment of the resulting whole. It adopts established interaction engineering rather than deriving a strategy from the vocabulary of Work or evidence alone. NASA’s Product Integration and SEBoK’s System Integration are substantive candidates for this work: they develop the choice and execution of an integration strategy. DORA’s CI/CD line is a serious alternative for software changes, with a potentially reusable rapid-feedback contribution in mixed systems. The conditional choices below compare those complete arrangements under the same available inputs.

The source choices have bounded roles:

• Adopt and adapt: NASA, Product Integration, §5.2.1.2 supplies preparation, assembly/activation order, enabling means, interface checks and revision when delivery conditions change. It supports the construction in :4.1.1–:4.1.2. Its programme documentation and lifecycle organization are not mandatory outputs of this bounded pattern.
• Adopt and adapt: SEBoK, System Integration, Integration Strategy and Process Approach supplies intermediate aggregates, strategy alternatives and their risk, availability and test burdens. Its distinction between developmental integration and production assembly remains source-local. SYSE.11 instead follows the named actual System and receiving use, including a modification in operation; the qualified assembly and design practices still supply their own Methods.
• Adopt within software scope; adapt the feedback contribution where correspondence holds: DORA, Continuous integration connects small integrated changes with rapid tests and prompt repair or reversion after failure. Continuous delivery develops deployability on demand, supported by technical, organizational and architectural capabilities. It is distinct from deploying every change. Reject transferring a software cadence or automated test’s coverage to unrepresented physical use.
• Adopt the concurrent and iterative application principle: SEBoK, Applying the Systems Approach, Application Principles supports concurrent, iterative and evolutionary work. Its lifecycle presentation does not establish a fixed serial execution or a defect of the method. Section :4.1 preserves overlap while making particular reliance dependencies explicit.

The public construction here connects the selected integration results to SYSE.10’s ordinary assessment and, only when another choice is live, to C.11. The worked margin and changed buffer premise show the bounded consequence of that connection. They do not establish empirical superiority over a competent professional integration programme. Qualification of domain models, equipment and tests remains real work in every arrangement; the pattern does not remove its cost by naming its result.

Reopen the comparison when a qualified existing strategy covers a previously missing interaction, an earlier check fails to represent the installed relation, the cost or timing of intermediate integration changes, or a different use invalidates the assessment’s extension. A demonstrated lower-burden arrangement preserving the same useful result also changes the selection. A newer source or a faster tool alone does not.

SYSE.11:12 - Relations

• A compatible SYSE.3 result supplies only the realization arrangement needed by this increment. Every relied- on unsupported branch must be closed, replaced by a qualified result, or retained as a blocker before Work uses it.
• A compatible SYSE.12 result supplies pre-use platform capability and condition claims. Later participation or provision Work produces later evidence and cannot justify the earlier input retroactively.
• A compatible SYSE.18 decision identifies the selected constituent arrangement and its unresolved dependencies. Rely on an obtaining commitment or observed coordination only when the accompanying evidence supports that claim; the decision alone supplies neither. SYSE.13 supplies configuration and effectivity claims for the same Systems and use. Constituent outputs and the receiving Agent’s authority need their own basis.
• A.15.1, A.2.1, and A.3.1 distinguish Work, assignment, and enacted Method. A.3.4 distinguishes actual transformations, and A.15.PROD governs claimed result production.
• C.11.CRC constructs a finite contribution comparison when a proposed change’s contribution relative to the current configuration is not already explicit. C.11 governs the next choice. Neither result is the later Work or transformation.
• SYSE.10:4.1 steps 6–8 and :4.1.1 supply the ordinary assessment inference and combination of results. Its SYSE.4:4.4/:4.6 instructions can be used without importing the separate assurance activities.
• A bounded usability assessment can inform SYSE.4 within its supported use and evidence window. SYSE.14 retains release and evidence-continuity authority.
• Operations, Maintenance, Platform Engineering, safety, security, law, governance, finance, and other specialist practices retain their Methods and decisions.

SYSE.11:End

SYSE.12 - Develop or Retain an Engineering Platform for Practitioner Work

Status: Stable

SYSE.12:0 - Use This When

Use this pattern when engineers cannot reliably model, compute, build, integrate, test, release, or observe an engineered System because shared enablers—such as tools, data, models, automated or physical facilities, provider Work, and support arrangements—are treated as incidental infrastructure or as a product with no named practitioner Work.

Begin with one practitioner Work family and the engineering result it must produce. Identify the actual Systems that enable or obstruct that Work, the capability practitioners need, the capability claimed for each platform or provider System, the conditions under which those Systems participate or provide a result, and the burden or failure that should change. Then choose whether to retain or change the enabling arrangement for that engineering result.

For a decision made before the relying Work, assess platform readiness and record a platform readiness assessment based only on evidence already available. After practitioner Work, the responsible Agent reassesses the platform and records a platform-use assessment based on observed participation, provision, burden, failure, and engineering results. Both assessments are epistemes. Each names the System, capability, Work, relation, result, and evidence it is about without replacing any of them. The later assessment can revise later reliance but cannot retroactively support the earlier assessment.

Use SYSE.25–SYSE.29 directly when the missing result is a task-grounded platform improvement, a supported use path, an interface or contribution change, a qualified control placement, or a migration and retirement result. The selected service-software Methods in SYSE.30–SYSE.41 supply professional results for build, feedback, artifacts, environments, data change, deployment, exposure, reliability, recovery, repetitive burden, and capacity. Use those results to support the relevant platform claims, keeping evidence of pre-use readiness separate from observations of later use.

Use Organization Change Engineering when positions, assignments, authority, or organization architecture are the changed subject; Operations Management for continuing queues, support cases, capacity, and provider Work. When the professional move is not supplied by the common language or the selected service-software Methods, use a qualified application-profile Method—for example, for a laboratory, compiler, manufacturing cell, clinical environment, electrical bench, or ship facility. The software selection is not complete software engineering.

SYSE.12:0.1 - Terms and Distinctions

When a source says service, recover its claim—for example, a capability, promised result, performed provision, or participation in Work. Name the holder or participants and supporting evidence. A promise alone does not establish performed provision.

SYSE.12:1 - Problem Frame

Engineering results depend on more than the architecture of the project system-of-interest. Systems such as model repositories, simulation and calculation environments, manufacturing cells, test benches, configuration and evidence stores, AI assistants, integration environments, and data spaces can change what engineers can observe and do. Provider and support arrangements can do the same. One platform can help one Work family and obstruct another.

Buying tools or forming a platform team does not establish that the resulting arrangement can support the named practitioner Work. Platform engineering starts with that Work and consequences for the project system-of-interest or its use, then develops the actual enabling arrangement. Platform Work and engineering Work on the project system-of-interest may occur simultaneously; their dependency is not a lifecycle stage or evidence that one System is part of the other.

SYSE.12:2 - Problem

A decision about an engineering platform requires answers to seven questions:

1. Which practitioner Agents, Work family, Method, result, configuration, and interval are being served?
2. Which actual Systems, provider Agents, interfaces, resources, and configurations form the current enabling arrangement, and which future candidates exist only in plans or descriptions?
3. What capability does the practitioner need, which System holds each claimed platform or provider capability, and under what envelope and currentness conditions?
4. Which conditions and direct relations actually matter—for example, access, participation, provision, availability, resource use, promise, support, exception, or fallback?
5. Which practitioner or System consequences should change—for example, effort, delay, error, rework, recovery, evidence continuity, or a result involving the project system-of-interest?
6. Which credible complete arrangements form the current decision alternatives—for example, retaining, changing, composing, obtaining, building, branching, bypassing, or retiring—and who has authority to choose among them?
7. What can be supported before practitioner Work, what is observed only later, and what change reopens each assessment?

Without these distinctions, platform teams can optimize adoption, ticket closure, or local automation while moving integration burden to practitioners, concentrating failure, and degrading the engineering result.

SYSE.12:3 - Forces

• Shared capabilities and provider Work reduce duplication, while different engineering profiles need different interfaces, evidence, and physical means.
• Case-independent access can shorten feedback, while consequential changes still require separate permission and assurance.
• Recommended arrangements reduce routine burden, while novel Work needs extension, bypass, and exception conditions.
• Automation lowers repeated effort, while hidden automation can erase provenance, uncertainty, or recovery.
• Practitioners need stable participation and provision, while Systems designated as project systems-of-interest, Methods, descriptions, and evidence demands keep changing.
• A maintained platform needs product care, but platform-local metrics cannot replace practitioner results or results involving the project system-of-interest.

SYSE.12:4 - Solution

Choose an enabling arrangement for one named practitioner Work result, including retaining the current arrangement when its use is supported. Develop only the selected changes. State the capability, conditions, participation or provision relations, and evidence separately, then reassess the platform from observed use.

SYSE.12:4.1 - Perform the Move

1. Name practitioner Work and result. State the practitioner Agents or inclusion rule, Work family, Method, subject, expected result, current configuration, interval, and receiving decision.
2. Recover the current enabling arrangement. Identify actual Systems—such as tools, model or data stores, compute resources, AI assistants, laboratories, manufacturing cells, integration environments, evidence stores, or support Systems—only where their relations change the Work. Name provider Agents, interfaces, resources, conditions, and failures.
3. Separate capability holders. State the capability demanded of practitioners and the holder, Work family, envelope, measures, qualification window, currentness, and evidence for each platform or provider capability. Support each capability claim with evidence that bears on the named holder performing the Work family in that envelope. Administrative or descriptive records count only when their evidence relation supports that claim.
4. State conditions and direct relations. Name the conditions that bound the claim—for example, access, configuration, performance, evidence continuity, support, exception, fallback, cost, or resource conditions. Then state each direct relation used by the decision: platform participation in Work; production of a named result by a named Work occurrence; supply of the result or access to it from a named provider to a named receiver; receipt or use by that receiver; resource availability or use; applicable promise content; or another governed relation.
5. Use Method repertoire and architecture when they change the choice. A compatible SYSE.15 result can supply available Methods and applicability limits; a compatible SYSE.20 result can supply Method, Work, enablement, and conflict structures. Otherwise use a qualified source or name the missing result.
6. Generate and choose among real alternatives. Build a C.11 option set from feasible complete arrangements. Candidates may retain the current arrangement, change a capability or relation, compose existing Systems, obtain or build a part, branch for a profile, preserve a bypass, or retire a harmful arrangement. Name the deciding Agent, authority, accepted losses, and questions outside that authority. Compare them for the same practitioner result and period of reliance, including continuing provider, maintenance, and recovery Work as well as practitioner effort. Use SYSE.24 when the obtaining comparison is unresolved and SYSE.25 when the improvement mechanism needs investigation.
7. Perform selected platform-development Work. When step 6 selects a change, record the performing Agents, assignments when relevant, Methods, temporal extents, results, actual transformations, resulting configuration, and evidence. A decision record does not change the platform. When the current arrangement is retained, continue to the readiness or use assessment that the receiving decision needs without creating development Work.
8. Issue the pre-use readiness assessment. State only capability and condition claims supported before the practitioner Work, with their evidence cutoff, currentness window, limits, fallback, and stop.
9. Observe use and issue a later assessment. Identify the practitioner Work occurrence and the actual platform participation, provision Work, or resource relation. Observe the consequences needed by the decision—for example, burden, delay, error, rework, recovery, evidence continuity, or results involving the project system-of-interest. Record the later assessment separately and use it only for later decisions.
10. Return and reopen locally. Supply only the supported claims needed by each receiving decision—for example, capability, condition, participation, provision, use, failure, or platform-change claims. Reopen only the claim affected by a changed Work, Method, practitioner population, configuration, provider, condition, evidence basis, or consequence for the project system-of-interest.

Platform development, practitioner Work, support, change of the project system-of-interest, and evidence Work can overlap. Every claimed use still needs an obtaining relation, and later evidence cannot justify earlier reliance retroactively.

SYSE.12:4.2 - Record the Result

SYSE.12:4.3 - What Changes in Practice

Platform investment begins with an engineering result and observable practitioner Work. Engineers can improve a shared enabling System while keeping capability, Work, participation, evidence, operations, organization change, administration, application-profile engineering, and decisions about the project system-of-interest distinct.

SYSE.12:5 - Worked Case: Platform Support for Flood-Pump Integration

Engineers integrating a flood-pump controller must reconcile identifiers among the model build, hardware-in-the-loop bench, controller configuration, and evidence repository by hand. One missed link delays the station integration result and makes recovery difficult.

The actual engineering platform includes the model-build System, bench, and evidence repository in configuration C4. A support Agent provides recovery Work but is not made a part of the platform merely by supporting it. A platform description records the structure; it is not the platform System.

For the next controller-integration campaign, each candidate must return evidence tied to the same model, controller and bench configurations, preserve access to that evidence, and permit recovery after an interrupted assembly. The competent incumbent records and checks the correspondence manually. It can still produce the required result; the observed missed link and repeated copying across revisions are reasons to compare a repair.

The engineers compare retaining that arrangement, strengthening its manual correspondence check, adding configuration-and-evidence links, replacing the bench, and obtaining bounded evidence-provision Work from another provider. Strengthening the manual check avoids maintaining new bindings but leaves reconciliation in each attempt. The linking option carries identifiers from their originating configurations into the assembled evidence; it removes repeated copying but requires a provider to maintain the bindings when formats or configurations change. Bench replacement would require requalification; no identified bench limitation makes that work necessary for this repair. Outside provision is competitive only if it returns the same configuration-linked evidence with the required access and recovery; otherwise the engineers still perform the join. Manual fallback remains part of the linking option.

The authorized Agent chooses the bounded linking change because revisions recur during this campaign and preserving correspondence at evidence creation addresses the observed failure. The Agent accepts continuing binding-maintenance and recovery Work. Retaining the manual arrangement could be preferable for an infrequent job with adequate checks and support. This choice predicts a useful repair; its total burden advantage remains to be assessed. The decision record does not change the platform.

A platform-engineering team configures identifier bindings, repository links, and recovery hooks. This dated Work is distinct from the actual transformation of the continuing platform from C4 to C5 and from the evidence that describes the change. A support Agent then performs a recovery exercise.

The readiness assessment, issued after the exercise and before controller integration, states that:

• C5 is current;
• the bench and repository are available in their named configurations;
• the configuration-and-evidence links passed the checks already performed;
• the manual fallback remains executable; and
• automated repository export remains unsupported and blocks only Work that needs automated export recovery.

During later controller-integration and flood-discharge trial Work, engineer Agents use the C5 platform while its model-build, bench, and evidence-store Systems provide their named functions. The observed relations support platform participation in those Work occurrences; they do not assign the engineers’ Work to the equipment. The supplier’s fixture-fabrication Work uses another arrangement, so the same participation claim does not apply there.

The later use assessment records that the engineers’ evidence-assembly effort for controller integration fell from the stated local baseline of six person-hours to two and a half, while a repository outage took 45 minutes to recover and the export gap remained. The provider’s continuing binding-maintenance effort has not yet been measured on the same basis. Thus the observations support the local assembly saving, not a claim that total Work fell. Assess that claim using comparable provider and practitioner Work over the selected campaign; the 45-minute outage duration alone is not a measure of recovery effort.

If obtaining those observations is not worth its cost for the next decision, leave the total-burden claim open and decide from the supported result and accepted maintenance obligation. A later finding that provider Work outweighs the assembly saving reopens the improvement claim; it does not erase the verified links or completed integration. These constructed observations support only this case and can change later platform decisions. They cannot retroactively justify the earlier controller-integration reliance.

Countercase. A repository and continuous-integration server are installed, but no practitioner Work, participation, provision, or engineering result is observed. Record the installed Systems and the proposed enabling arrangement; do not infer platform capability or adoption from installation.

SYSE.12:6 - Bias Annotation

Software platform practice supplies useful ideas about self-service, configured defaults, fast feedback, and product care. Vendor catalogues and team-topology literature can also make a tool or team appear to be the whole platform. Physical and cross-domain engineering adds other platform participants—for example, laboratories, manufacturing cells, configuration and calibration Systems, evidence stores, provider Work, and recovery arrangements.

Use publicity, university coverage, procurement, installation, usage counts, or satisfaction as evidence only for the claims each can support. When broad prevalence or causal effect cannot be measured affordably, use the best available case evidence and state its epistemic status.

SYSE.12:7 - Conformance Checklist

• Practitioner Agents or population, Work, Method, result, configuration, interval, and receiving decision are named.
• Source-local service wording is interpreted for the claim being made, such as capability, provision, or participation.
• Capability holders and envelopes are supported, and each direct relation states its participants and conditions.
• Alternatives include retaining the current arrangement, a bounded change, a branch or bypass, and stopping or retiring where credible; authority and accepted losses are explicit.
• Platform-development Work, actual transformation, resulting configuration, and evidence remain distinct.
• A readiness assessment uses only evidence available before practitioner Work.
• A later use assessment identifies actual participation or provision and cannot justify the earlier reliance retroactively.
• Practitioner burden, recovery, evidence continuity, and results involving the project system-of-interest can reopen the smallest affected platform claim.

SYSE.12:8 - Common Failures and Repairs

SYSE.12:9 - Consequences

This move exposes hidden enabling dependencies and practitioner burden and can reduce repeated integration and evidence Work. It also adds continuing Work to maintain, support, configure, observe, and recover the platform. Shared capabilities can also create coupling, provider monopoly, or failure concentration, so profile branches and fallbacks preserve alternatives where those risks matter.

SYSE.12:10 - Rationale

Engineering capability is a holder’s ability to perform a named Work family or produce a result class within a declared envelope, measure set, qualification window, and currentness condition. A chosen Method may constrain that envelope or be tested for fit, but it is not the capability’s target. A platform is useful only through actual relations to practitioner Work. Engineers can make and assess claims about the platform’s architecture, configuration, evidence, use, and evolution for that Work.

SYSE.12:11 - SoTA and Source Use

Which enabling arrangement should support this engineering Work, and what justifies retaining or changing it? For ordinary internal software provision, the DORA/CNCF approach of developing a platform around users’ tasks is a sufficient starting answer when its provider capabilities and supported use already cover the Work. It develops a small useful offering with users, composes existing provision, and learns from task outcomes. Adopt that answer within its conditions.

For Work spanning software tools, physical facilities and separately performed provider Work, this pattern selects an authored synthesis: carry that task-oriented development into the actual enabling arrangement, qualify each relied-on capability and relation, and separate readiness before use from later observations. Its gain is a supported decision about which Work the arrangement can enable: a bench, repository and support provider can contribute different qualified results, and a missing export or changed maintenance burden reopens only dependent claims. The accepted cost is identifying those dependencies and maintaining their qualifications. This is a constructive answer for mixed engineering Work, not evidence that it outperforms qualified direct provision.

The serious local alternative is to retain competent provision or repair its manual interaction without developing a shared platform capability. It avoids new binding, interface and support obligations and can win for infrequent or highly variable Work. The synthesis earns its added effort when repeated coordination or cross-provider dependencies change the relying decision. If the direct source treatment or incumbent already carries those distinctions adequately, reuse it.

In :4.1 step 6, this means comparing complete arrangements for the same result and period, including continuing provider Work. The case in :5 selects identifier links while accepting their maintenance obligation and keeps a measured practitioner saving separate from an unmeasured total-burden claim. SYSE.24 supplies the obtaining comparison; this pattern joins its result to capability, participation and evidence timing.

Reopen the affected choice when a changed input or provider breaks the relied-on correspondence or access, when comparable continuing burden reverses the accepted trade-off, or when a supported alternative supplies the same result with fewer obligations. Reopen the cross-profile synthesis only when a new use or comparative source defeats the particular dependency or evidence distinction being carried across profiles.

SYSE.12:12 - Relations

• SYSE.25–SYSE.29 construct the bounded improvement, supported interaction, interface/contribution change, control placement, and migration results named above. Enter the Method for the missing result.

• SYSE.30–SYSE.41 supply the selected service-software professional Methods. Apply each result to the platform capability and practitioner task for which its conditions and evidence hold.

• SYSE.8 supplies a providing-System concept when missing; SYSE.18 handles integration across independent decisions; SYSE.24 compares whole obtaining arrangements.

• A compatible SYSE.15 result supplies a bounded Method repertoire and applicability limits; it neither selects nor enacts the platform Method.

• A compatible SYSE.20 result supplies Method, Work, enablement, and conflict structures; it neither turns an enabling dependency into a level nor selects the platform change.

• A.2.2 governs holder-dependent capability. A.6.P:4.11a recovers service wording into promise, capability, bearer, dated Work, participation or provision relation, condition, and evidence claims without creating a generic service object.

• A.15.1, A.2.1, and A.3.1 distinguish Work, assignment, and enacted Method. A.3.4 distinguishes actual transformation, A.15.PROD claimed result production, and A.22 descriptions of selected platform structure.

• SYSE.11 may use a readiness assessment only for capability, conditions, and participation or provision claims supported before its Work. A later use assessment updates later decisions and cannot support that input retroactively.

• Neighboring DPFs retain their own Methods and decisions. These include Organization Change, Operations, Administration, application-profile engineering, security, safety, law, finance, procurement, and governance whenever the current question belongs there.

SYSE.12:End

SYSE.18 - Decide Whether and How to Integrate Systems Governed by Different Agents

Status: Stable

SYSE.18:0 - Use This When

Use this pattern when one use depends on several actual Systems, but decisions that can change that use—for example, a constituent’s operating condition, configuration, commitment, interface, or later modification—belong to different Agents. The integrating Agent cannot command every change that can defeat the use.

Begin with the shared use and the actual constituent Systems that can defeat it. For each constituent, state how it affects that use, who can decide the relevant change, what authority that Agent has, and which configuration, interface, commitment, evidence, or withdrawal condition the decision relies on. Then compare arrangements for the same use, separating changes already within authority from proposals that require another Agent’s decision. A useful current decision can authorize preparation or retain the existing arrangement while a particular dependency remains unresolved.

The first useful result is a bounded constituent-integration decision. It states the selected coordination alternative, the deciding Agent’s authority, decisions required from other Agents, accepted losses, unsupported dependencies, and next Work. If integration Work is later performed, identify that Work, its actual transformation or newly obtaining relation, and the observed-coordination claim separately from the decision episteme.

Use ordinary architecture and integration patterns when one deciding Agent controls every constituent change that can alter the use. Use the neighboring practice that owns a different question—for example, Organization Change when an organization is the System being changed, Corporate Governance for ownership and governing-body decisions, Operations Management for continuing allocation and coordination Work, or a configuration or other specialist pattern for its own subject.

SYSE.18:0.1 - Terms and Distinctions

A System described, for example, as an owner, operator, integrator, supplier, or decision maker is an Agent only when the agency claim is warranted. State the direct predicate and participants for every relied-on claim. Use the applicable pattern when the decision depends on agency, authority, a commitment, performed Work, capability, or evidence; state constituent participation and the shared use separately.

SYSE.18:1 - Problem Frame

For example, district drainage can depend on separately governed pump stations, gates, drainage networks, dispatch Systems, provider organizations, and public infrastructure. A product can likewise depend on independently evolving software, communication, payment, and energy Systems or regulatory organizations. Each constituent can remain useful elsewhere and change for reasons outside the integrating project.

Drawing a larger boundary does not create authority or interoperability. A model or interface description can carry claims. An agreement can institute a commitment. A meeting is Work. A governing body is a System whose participating Agents may make authorized decisions. For constituent Work, identify its performing Agent; for another Agent’s decision, identify that Agent’s authority.

SYSE.18:2 - Problem

An integrating team needs answers to seven practical questions:

1. Which shared use, conditions, interval, and engineering decision are at issue?
2. Which actual Systems can defeat the use by changing, failing, withdrawing, or withholding a result?
3. Which direct relation connects each System to the shared use, and what does that relation change?
4. Which Agent controls each relevant decision, and what authority, permission, or escalation relation obtains?
5. Which configurations, interfaces, capacities, timings, commitments, and evidence make coordination possible?
6. What can the integrating Agent change, and which decisions must come from other Agents?
7. What actual observation would show that the changed arrangement works for this use?

Missing answers produce four recurring errors: interface syntax is mistaken for interoperability, an agreement for performance, a constituent label for parthood, or an integration team for authority over Systems it does not govern.

SYSE.18:3 - Forces

Recurring tensions include:

• The shared use needs coherent results; constituents retain other uses, priorities, owners, and decision centres.
• Integration benefits from stable interfaces and commitments; Systems and environments continue to change.
• Receiving decisions need comparable evidence; every source keeps its provenance, limits, and authority.
• One Agent can compare shared-use options while several Agents separately permit constituent changes.
• Some coordination can be agreed in advance; operating conditions can require continuing reconfiguration.
• A broad account reveals dependencies, while the current decision must remain feasible within actual authority.

SYSE.18:4 - Solution

Recover the constituent arrangement from the shared use, make distributed decisions and dependencies explicit, and choose one bounded coordination alternative within the deciding Agent’s authority.

SYSE.18:4.1 - Perform the Move

1. Bound the shared use. State the result, operating conditions, interval and decision to be made. Identify the losses that this decision may accept and the conditions it must preserve. Begin with an adequate current account when one exists; use this Method only for the missing or changed connection.
2. Recover constituents by consequence. Follow the result back to the Systems whose participation, failure, change or withdrawal could defeat it. State what each contributes or constrains and why that matters here. Preserve an observed participant whose identity is still unknown; distinguish that uncertainty from an unknown existence claim or a future intended System.
3. Trace the relied-on connection. Follow one representative use through the constituent results and interfaces. Match what the receiving operation needs with what the supplying System can provide, under the same configuration and conditions. Section :4.1.1 explains how to turn a mismatch into a design question.
4. Recover the relevant decisions. Identify who can change each decisive condition, what authority or permission obtains, and which other uses constrain that choice. An unresolved authority claim can leave comparison possible while preventing authorization of the corresponding change.
5. Construct alternatives around the mismatch. Change the receiving operation, supplied result, interface, allocation, timing or means of recovery that produces the failure. Keep a sufficient existing arrangement among the alternatives. For another Agent’s proposed change, identify the needed decision and the consequence if it is refused or delayed; :4.1.2 explains the comparison.
6. Select a bounded continuation. Compare admissible alternatives for the same result and interval. State what the selected arrangement gains, what it gives up and which unresolved condition limits the decision. Reuse sufficient analysis. Select further inquiry by what it could change and its attainable cost and delay, using SYSE.9 and C.11.DUA when needed. A required permission or physical qualification still governs use.
7. Make the decision usable by its participants. Explain the choice, consequences and remaining freedom to the people who must decide or perform the affected work. Resolve a consequential mismatch of understanding through :4.1.3. Record the decision within the deciding Agent’s authority, required outside decisions, accepted losses, next Work and reconsideration conditions.
8. Follow authorized enactment and selective change. When integration Work occurs, retain its performer, Method, actual change, configuration and evidence. Observe the shared use at the scope needed for the receiving claim. Section :4.1.4 connects changed conditions to the decision that relied on them.

Constituent operation, engineering, governance, and integration can be simultaneous; only stated dependencies and temporal relations establish order. Finish when the current decision and its useful continuation are supported. An integration decision need not wait for the later installation or operating observation.

SYSE.18:4.1.1 - Find the condition that breaks the shared use

Start at the required result and work backward to its necessary contributions, then follow a concrete occurrence forward. At an interface, identify the supplying and receiving Systems, what passes between them, and the condition that makes it usable. For a timed contribution, distinguish when it is produced, received, acted on and needed. Compatible message formats can still carry a late, stale or inapplicable result.

Compare needs and provision on the same basis. A receiving operation may need six hours after a notice while its provider promises only four hours before an outage. The missing two hours then becomes a specific question: can the provider give earlier notice, can the receiver respond sooner, or can another arrangement support the use during the interval? Those proposals alter different things and require different decisions. A notice commitment is evidence about an obligation; observations and qualification establish what response can be relied on under the stated conditions.

Include a constituent’s competing uses when they consume the same capacity or determine its availability. Two individually sufficient offers may be incompatible when they reserve the same resource at the same time. Use SYSE.13 for configuration correspondence, SYSE.9 for a needed specialist result and SYSE.20 when the issue is joint Work or resource use. Retain a compatible supplied result rather than repeating its production. If the necessary condition cannot be established, carry that precise dependency into the comparison.

SYSE.18:4.1.2 - Compare arrangements that could actually supply the use

Generate an alternative by naming the changed connection and following its consequences to the whole result. For a proposed buffer, derive the quantity to be held over the unsupported interval, where it goes, when it is available and how normal operation resumes. For a replacement provider, follow the new result through the receiving operation, including transfer and qualification. For a changed commitment, establish what its bearer would have to decide and perform. Narrowing the use is a different offered result; its loss needs acceptance by whoever may decide that scope.

Separate three questions for each proposal: would the arrangement satisfy the required use under its stated premises; can its necessary changes be authorized and supplied in time; and does its benefit warrant the whole burden? A technically workable proposal awaiting another Agent’s agreement can remain a conditional alternative. It cannot serve as an already available fallback. Conversely, a requested change refused by one Agent does not preclude an admissible change within another’s authority.

Eliminate a proposal from the present operating choice when it violates a protected condition. Compare the remaining arrangements on the same horizon, including acquisition, transition, operation and later reversal where they matter. Keep unlike losses explicit. A weighted score is useful only with an applicable comparison rule; it cannot turn missing permission or an unacceptable physical consequence into a compensable cost. SYSE.6:4 supplies the fuller comparison when the choice fixes project-shaping structures across later work. Here the additional question is which independent decisions and commitments make each arrangement possible.

Preserve a tie or conditional result when the present basis cannot settle the choice. Name the particular outside decision, professional result or affordable inquiry that could settle it. If no attainable answer is needed for the current useful decision, stop with that decision and its limit. Prefer a sufficient unchanged arrangement over a new one whose extra burden buys no needed result.

SYSE.18:4.1.3 - Explain the technical choice and resolve its effect on others

Take the proposed arrangement to the affected decision makers and practitioners with its reason: the shared result, the condition currently defeating it, the alternatives considered and the change proposed for their own contribution. Ask them to apply it to a representative occurrence and a relevant failure or change. What would each do, what input would they rely on, and what would they return to the next participant?

Compare these accounts at the consequential joins. If one participant interprets an acknowledgement as a promise of capacity while another means only receipt of a message, repair that misunderstanding before relying on the exchange. If everyone understands but a provider cannot reserve the resource, the missing result is provision or a different arrangement. If a participant lacks the professional means to perform the action, obtain that contribution or revise the proposal. More explanation alone cannot supply either resource or skill.

Keep a substantive objection available to change the technical choice. Resolve the local decision within established authority; obtain another participant’s decision for the part they control. Use the relevant negotiation, organization or governance Method when that becomes the unresolved question. Agreement to discuss a proposal remains different from commitment to perform it. The explanation can finish when the affected participants can use the same conditions and identify their own decisions, actions and return conditions; it need not make every participant an expert in every constituent System.

SYSE.18:4.1.4 - Follow changes through the connection that depended on them

Select observations for the reliance being made. A description-consistency result can support comparison of models. A claim that the configured Systems coordinate in operation needs corresponding operating evidence; SYSE.11 supplies the integration and qualification Method. Reuse adequate evidence at its actual scope. Record a later observed-coordination claim separately from the earlier decision and each commitment’s fulfilment.

When a constituent changes, identify which relied-on condition changes and follow its receiving uses. Revised notice time can invalidate a buffer’s duration even when the buffer’s measured capacity remains valid. A new interface version can require qualification of an exchange without reopening unrelated ownership decisions. Continue through affected dependencies until a compatible result or explicit gap bounds the consequence. Retain unaffected claims and independent work.

For a selected fallback, establish the trigger, deciding authority, available means and bounded result before relying on it. If continuing constituent evolution requires repeated selection during operation, arrange the needed observations and decision authority with the operating practice. Automating that selection adds its own qualification question. A single successful exercise does not establish the ability to manage every later configuration or unannounced withdrawal.

SYSE.18:4.2 - Record the Result

The first useful decision does not wait for implementation. Identify the earlier decision, performed Work, and later observed-coordination claim separately. An observed coordination result does not establish that every constituent commitment was fulfilled.

SYSE.18:4.3 - What Changes in Practice

Engineers can explain why a proposed arrangement could support the shared use, compare the available ways to repair a failed connection, and identify which decisions and professional results each way still needs. The receiving practitioner gets the reason for the choice and the condition that would change it. An unsupported dependency has a specific consequence and next question; an already sufficient arrangement can be retained.

SYSE.18:5 - Worked Case: Emergency Discharge Across Four Independently Governed Systems

This illustrative case concerns a district’s planned emergency-discharge provision. The quantities, permissions and engineering qualifications below are stipulated inputs for comparing arrangements; they are not field measurements or a flood-control design supplied by this pattern.

Four existing Systems affect the use: a flood-pump station, an upstream gate, a municipal drainage network and an emergency-dispatch System. Their respective owner, river-control agency, municipal operator and regional dispatch agency control different decisions. The station integrator may install qualified station-side equipment and use an already agreed dispatch escalation. It cannot change the gate envelope or the municipal operator’s commitments. The use requires accommodation of up to 50 m³/h while preserving the supplied hydraulic, discharge-quality and gate limits.

The municipal operator commits to notice received at the station at least four hours before a planned interruption of drainage reception. The station’s qualified fallback is ready no later than six hours after receipt of that notice; this bound includes dispatch acknowledgement and mobilization. The agreed dispatch response is already included in those six hours, so invoking escalation cannot be counted as a second time saving. Unannounced outages require a different contingency and lie outside this particular decision.

SYSE.18:5.1 - Derive and compare the alternatives

The decisive timeline starts at receipt of the notice. Municipal reception remains available through hour 4; the fallback can receive the flow from hour 6. The unsupported interval is therefore hours 4–6. With no other outflow during that interval, 50 m³/h × 2 h = 100 m³ must be held. This is a storage-volume requirement, not yet a qualified buffer design. For a varying flow, the corresponding quantity is the accumulated net inflow over the unsupported interval.

A supplier offers an existing mobile buffer with 120 m³ of usable storage, qualified for the stated medium and connection. The supplied hydraulic assessment supports its inlet rate, location and recovery path; the 120 m³ is available storage after its required reserves. It can be installed before the required date within the station integrator’s delegated budget. The fallback has qualified spare capacity to empty it after hour 6 without losing the continuing 50 m³/h service. These are necessary specialist and provision inputs; the volume calculation supplies none of them.

The same decision compares the following arrangements for the same service interval:

The buffer is selected for preparation because it is the only currently supplied arrangement in this comparison that meets the required use by the date. Its extra cost and maintenance are accepted within the delegated budget. The selection makes no claim that buffering is generally cheapest or superior to earlier notice. An available six-hour notice agreement could reverse that choice by avoiding the buffer’s burden.

SYSE.18:5.2 - Connect the decision to performance and a changed condition

The integrator explains the timeline and choice to station, municipal and dispatch participants. In their walkthrough, dispatch initially describes acknowledgement as confirmation of the fallback’s readiness. The station team points to the six-hour mobilization: acknowledgement starts and tracks that work; readiness has its own confirmation. They correct the receiving instruction and retain the agreed escalation for a missed acknowledgement. The municipality’s four-hour commitment remains unchanged.

The decision now authorizes the installation and its necessary qualification. It does not yet establish installed availability. In the example’s later performance, the team installs the buffer and completes the required checks; a representative exercise under the stated load supports storage, transition to the fallback and recovery. SYSE.11 can use that configuration-specific evidence. The earlier decision, installation Work, actual availability and observed coordination remain separately identifiable.

Now suppose the municipal operator proposes changing notice to two hours, with every other case premise unchanged. The fallback still needs six hours from receipt. Required storage would become 50 m³/h × 4 h = 200 m³. The existing buffer’s 120 m³ qualification survives, but it does not establish support for this changed use. The integrator reopens the arrangement and the municipal decision; it cannot authorize that operator’s notice change. It may seek a larger qualified provision, an accepted narrower use or another adequate arrangement. Until one is supplied, the changed service claim remains unsupported. Unrelated gate limits and the original arithmetic remain usable within their original conditions.

If a subsequent occasion retains the original notice, flow, configuration and permissions, an adequate current account can support the same bounded decision without another modelling project or exercise. Recheck a changed or expired qualification when the receiving reliance requires it.

SYSE.18:5.3 - A different mismatch needs a different remedy

An order-fulfilment service uses an independent stock provider and payment provider. A compatible message format does not settle whether a stock response reserves an item until payment completes. Following one order exposes the dependency: stock may disappear between the response and the sale. Queueing the response does not create a reservation. Compare obtaining a time-bounded reservation from the stock provider, a supported confirmation-and-compensation arrangement, or a narrower service promise. Each needs its own operational semantics, authority and evidence. If those means are absent, this Method returns that precise gap; the drainage buffer offers no transferable guarantee of transactional correctness.

When the full pattern is unnecessary. Use ordinary architecture, configuration, integration and Work patterns when one Agent controls every decision that can change the integration result. Reuse an adequate constituent-coordination decision when the present use and its relied-on conditions are unchanged.

SYSE.18:6 - Bias Annotation

Systems-of-Systems literature is influenced by defence, formal model federation, and software orchestration. Use each source for the Method and case it actually studies. A cross-domain constituent classification, governance form, representation, or integration Method needs its own evidence. Official attention and conformance describe publications or declared rules; project use and effectiveness need evidence from performed Work and outcomes.

Compare several decision centres by their actual authority, operations, outcomes, and feedback. Distributed and centralized arrangements can each help or harm; the label decides nothing.

SYSE.18:7 - Conformance Checklist

• One shared use, conditions, interval, affected Systems, current decision, and deciding Agent are stated.
• Every constituent is an actual System included because its participation, output, failure, change, or withdrawal can alter the use.
• Each relied-on relation has its own predicate and participants; no umbrella contribution relation replaces it.
• Independence is stated for named decisions and relations, not as an absolute property.
• Every deciding Agent, assignment when relevant, authority, permission, conflict, and escalation is stated.
• Interface syntax is supplemented by configuration-bound exchange and use evidence where interoperability is claimed.
• Alternatives address the same receiving result or expose an accepted scope change; the comparison preserves protected conditions, competing uses, whole burden and unresolved premises.
• The selected continuation remains within the deciding Agent’s authority and names outside decisions and unsupported dependencies. A conditional alternative is not relied on as an available fallback.
• Affected practitioners can recover the choice and its reasons for their own action; a material objection, missing resource or missing professional means receives its appropriate continuation.
• Any claimed coordination change identifies performing Agent, Method, dated Work, actual change or relation, configuration, representative observation, and evidence limits.
• The decision episteme, performed Work, world-side change, and observed-coordination claim are identified and grounded separately.

SYSE.18:8 - Common Failures and Repairs

These recurring failures hide a relation, deciding Agent, or evidence boundary:

SYSE.18:9 - Consequences

Distributed authority and unsupported dependencies become visible before integration fails. The integrating Agent can make a bounded useful change within its authority. The conditions relied on by the shared use and the monitoring Work needed to maintain them become explicit.

The cost is negotiation and maintenance of constituent claims. Keep the account focused on Systems that can affect the shared use, and reopen only the claims a change affects.

SYSE.18:10 - Rationale

Shared use depends on actual relations among Systems while authority and evolution remain distributed. Treating every constituent as an owned component hides withdrawal and decision boundaries. Engineers can act through named interfaces, commitments, buffers, and fallbacks. Separate decisions, Work, changes, and observations make bounded integration possible.

SYSE.18:11 - SoTA and Source Use

The professional question is how to choose a workable shared-use arrangement when constituent changes and resources are controlled independently. This pattern selects a bounded comparison of consequences, feasible configurations and independent decisions. It preserves useful current arrangements and develops only the connection needed for the decision. The selection is conditional on that scope, not a claim of universal effectiveness.

A serious alternative is a formal mission-configuration analysis. Raz et al. 2024, sections III–V, connect a mission description, spatial and temporal feasibility, and analysis of candidate configurations. That connected construction is useful when several allocations and shared resources make informal comparison unreliable. Their example is notional and the analytical choice remains domain-specific. Section :4.1.2 retains feasibility before preference; it adds the independent authorization and provision needed for the present engineering use.

For the four-System case, both approaches can expose the two-hour interval. The short timeline and comparison already settle the current bounded choice with the supplied engineering results. A new formal model would add construction and maintenance without a demonstrated change to this decision. The accepted loss is weaker coverage of many interacting configurations. Reopen this depth choice when multiple concurrent demands, alternative constituent allocations or coupled changes defeat the inspectability of the small comparison. Use the fuller analysis where its result can change the choice; a model still requires compatible source data and its outputs do not grant a participant’s permission.

The following contributions answer different parts of the problem:

Reconsider a used claim when a relevant source correction, stronger comparative result or observed use failure changes its configuration, authority, outcome or transfer premise. Preserve useful unaffected contributions.

SYSE.18:12 - Relations

• A compatible SYSE.6 result supplies architecture constraints for the same shared use. Ground constituent participation, commitments, authority, and interoperability under their direct patterns.
• A.1.SCR governs actual System recognition; A.22 governs selected structures; E.18.NET governs a transformation-flow network only when its members and relations are independently established.
• A.6.P, A.2.2, A.2.8, and A.10 separately govern service wording, capability, commitment, and evidence claims.
• A.2.1, A.2.8.PER, A.15.1, A.3.1, A.3.4, and A.15.PROD govern assignment, permission, Work, Method, actual change, and production claims. Another Agent’s decision authority still needs its own direct claim.
• A specialist practice retains its own decisions and authority—for example, Organization Change, Corporate Governance, Operations, Configuration, Maintenance, safety, security, law, finance, or contracting.
• SYSE.11 can use a compatible observed-coordination claim for the same constituent Systems, configuration, shared use, and interval. Ground any later fulfilment or authority claim separately.

SYSE.18:End

SYSE.23 - Choose What to Change So Later System Changes Become Easier

Status: Stable

SYSE.23:0 - Use This When

Use this pattern when an engineer or manager says that a product or product family must become more evolvable, but the next change is still slow, expensive, unsafe, or hard to assure. The limiting condition may be in the project system-of-interest, its family architecture, a builder or enabling System, an engineering platform, a Method, an Agent’s capability, the Work that enacts a change, or a relation among them. Calling all of these the system hides both the present difficulty and the architecture change worth funding.

Here, the builder arrangement comprises the named Systems, Agents, Methods, Work, services, configurations, and direct relations used to make, change, verify, release, or support the project system-of-interest for the selected future-change family. An account of that arrangement identifies each participant and relation.

The first useful result has three parts:

1. a grounded account of the project system-of-interest and its builder arrangement that keeps five claim kinds separate: characteristics of obtaining selected structures, capabilities of named holders for named Work, results and resources of change-Work occurrences, claims about a joint arrangement with named participants and relations, and supported causal or contribution claims;
2. separate specifications of possible-future selected structures for the project system-of-interest and builder arrangement, including the genuine holonic levels, non-holonic dependencies, and Work relations that matter to the decision; and
3. one replayable ChoiceResult for a bounded investment or reconfiguration.

First move. Name one class of future change the project expects to make: for example, add a sensor variant, replace a supplier component, adapt to a new operating environment, reuse evidence across configurations, or change the release Method. State the available basis: actual observations where available, otherwise the qualified model or estimate supporting the prospective account. Distinguish what is observed, estimated and unresolved. Classify each claim: does it concern an architecture characteristic, a holder capability, a result or resource of change Work, a constraint in the joint arrangement of the project system-of-interest and builders, or a supported or suspected contribution? Keep obtaining structures and actual Work separate from proposed structures and expected results. If the sentence still says only the system is hard to change, the decision is not ready.

In practitioner-facing prose here, an Agent means an admitted System considered in an agent role, with enough agency for the named decision or Work, scope, and period; A.13 supplies the underlying agency result. System identity, local system-role classification, capability, assignment, authority, and actual performance remain separate claims. C.11 uses DecisionSubject for the person, team, organization, or other collectivity whose choice is recorded.

Use C.25 when the immediate task is to repair one composite quality claim. Use C.30 and C.32 when the immediate task is to characterize or choose one architecture independently of the relation between the project system-of-interest and builder arrangement. Use SYSE.6 when the current option set concerns only the engineered-System architecture. Use SYSE.12 when the practical result needed is one engineering-platform service. When the needed change is primarily organizational or concerns human capability, use the relevant Organization Change Engineering or Human Capability Development DPF result when available; otherwise name the specialist help needed and use a qualified source. Use SYSE.21 when cultural continuation is the current question.

SYSE.23:0.1 - Short Practitioner Use

For a first pass, use one expected change family and one decision horizon:

1. State the change to be made, the project system-of-interest when it already exists or the intended-system claim when it does not, the configurations affected, the horizon, protected consequences, resources, DecisionSubject, chooser granularity, and authority.
2. Classify each current claim before assigning a quality bearer. Separate architecture characteristics, holder capabilities, change-Work results and resources, joint-arrangement claims, and causal or contribution claims.
3. Recover three structures when they matter: genuine part–whole or membership levels with their scale and cross-level conflicts; non-holonic dependencies or service relations between the project system-of-interest and builder arrangement; and first–then or overlapping Work.
4. Keep obtaining architecture relations and current observations separate from specifications and expected characteristics of possible-future structures.
5. Develop alternatives that change different selected structures of the project system-of-interest or builder arrangement. Show how each alternative changes option reachability, change cost, assurance, rollback, and displaced burden.
6. Compare the finite changes through C.11.CRC. Then carry the full C.11 decision record: stable OptionSet, shared comparison basis, ChoiceRule, probe cost and value when relevant, and one ChoiceResult permitted by that rule.
7. Plan, authorize, perform, and observe the chosen change separately. Later Work can support or defeat the earlier claims; the decision record does not make the architecture change occur.

This attention order is not a universal Method unfolding. Development of the project system-of-interest, development of its builders, platform service, Method change, evidence Work, and capability development can overlap, recur, or remain separate Work wholes.

SYSE.23:1 - Problem Frame

An engineered System does not become easier to evolve in isolation. A replaceable module may still require a fixture the factory lacks. A configurable product family may outrun test and evidence reuse. A simulation platform may generate variants that manufacturing cannot build or service. A flexible Method may depend on skills, permissions, or data that the assigned Agents do not have. Conversely, a costly redesign of the project system-of-interest may add little when the actual bottleneck is a slow builder or unavailable test service.

Evolvability is therefore an entry word, not a ready-made scalar or one universal quality bearer. An architecture-characteristic claim concerns an identified selected structure of a System, family relation, platform, or Method. A capability claim concerns a named holder and target Work under stated conditions. Lead time, rework, defects, and consumed effort may be results or resources of bounded change Work. A claim about the joint arrangement of the project system-of-interest and builders identifies its participating Systems, Methods, Agents, and relations. A claim that one architecture change caused or contributed to a Work result needs its own support. These claims may be compared, but they do not become the same kind.

The structures also differ. The project system-of-interest and a builder System can each have genuine constructive part–whole levels. Actual family members can participate in a membership structure. A component- level change can create a simultaneous whole-System or family-level conflict. Those are genuine level claims only when the part–whole or membership relation, scale, and horizon are stated. A dependency between the project system-of-interest and builder arrangement, a provider relation, or a platform service is non-holonic unless another relation establishes otherwise. Build-the-builder Work that precedes testing of the project system-of-interest is temporal Work order, not a level.

SYSE.23:2 - Problem

The first failure assigns every evolvability quantity to an unnamed system. Evidence from one software module, prototype, team, or change occurrence is then reported as a characteristic of the product family, factory, engineering platform, Method repertoire, organization, and culture. No one can tell whether the claim concerns architecture, capability, Work performance, a joint arrangement, or causal contribution.

The second failure chooses a familiar mechanism before the claim subject is known. Mechanisms such as modularity, standard interfaces, automation, digital twins, feature flags, AI coding, continuous delivery, or reusable tests are treated as universal answers. Each can help one change family and damage another through latency, coupling, option loss, verification load, supplier dependence, configuration growth, security exposure, or maintenance burden.

The third failure describes a desired architecture as if it already obtained. A roadmap contains a configurable platform and automatic evidence reuse, so current lead-time claims are calculated from those possible-future features. The investment decision then uses benefits that only the investment could create.

The fourth failure demands open-ended improvement without a bounded horizon or stop. Candidate generation grows, but admissibility, integration, safety, cost, environmental consequences, and selection do not improve. More variants become more inventory and assurance debt.

SYSE.23:3 - Forces

The recurring tensions are:

• Reachability and control. More admissible variants can preserve future options, while uncontrolled variation increases configuration, integration, safety, and service burden.
• Modularity and system performance. Looser coupling can localize change, while added interfaces, indirection, mass, latency, or duplicated capability can damage current performance.
• Gain in the project system-of-interest and builder debt. A shortcut in the project system-of-interest can deliver one increment quickly while making later manufacturing, integration, evidence, or maintenance Work harder.
• Platform reuse and local difference. A shared platform can reduce repeated Work, while forcing unlike profiles through one service can erase constraints that matter.
• Change speed and evidence continuity. Small reversible changes shorten feedback, while assurance and configuration evidence must still refer to the changed System and use.
• Automation and authority. AI and robotic Agents can generate, implement, or test more variants, while assignment, review, permission, release, and responsibility remain separate.
• Exploration and exploitation. A project needs alternatives and stepping stones, while a current decision needs a finite budget, protected losses, and a stop condition.
• Project intervention and cultural continuation. One successful reconfiguration can justify local use, while it does not establish discipline-wide selection, prevalence, or retention.

SYSE.23:4 - Solution

Classify the current claims before deciding what should change. Recover the obtaining structures of the project system-of-interest and builder arrangement, including genuine levels where they matter. Keep their non-holonic relations separate from temporal Work structure. Specify possible-future structures separately, compare materially different investments against the current arrangement, and return one replayable architecture ChoiceResult whose later consequences can be observed.

Local mantra. An expected change exposes a current difficulty. The team identifies whether the difficulty is an architecture characteristic, capability limit, change-Work result or resource, joint-arrangement constraint, or suspected contribution. Several views show genuine levels, dependencies between the project system-of-interest and builder arrangement, and Work order or overlap without merging them. Alternatives that change either side are compared from one current basis. A bounded choice is recorded; later Agents perform Work and supply observations.

SYSE.23:4.1 - Perform the Move

1. Bind the future-change question. Name what the decision concerns. When the designated project system-of-interest already exists, cite a compatible SYSE.1 result and the plan or decision that designates it. When the System is still intended, keep its designator and expected change or use in a WorkPlan, decision, System description, or other claim episteme until identity inception. When a System family is in scope, identify the family, its actual member Systems, possible-future specifications, membership relation, and effectivity basis without calling the family another System. Add current configurations, expected change family, use, environment, affected Systems, horizon, frequency or scale of change, protected characteristics, resource limits, receiving decision, DecisionSubject, chooser granularity, and authority. The expected changes must be concrete enough that an engineer can tell what counts as admitted, completed, failed, or out of scope.
2. Classify the claim before naming its subject. Use one of five working forms:
   • an architecture-characteristic claim about an identified selected structure and its bearer;
   • a capability claim about a named holder, target Work, conditions, and evidence;
   • a result or resource claim about a bounded change-Work occurrence or a declared class of comparable Work;
   • a claim about a joint arrangement with the named project system-of-interest, builder Systems, Methods, Agents, and direct relations; or
   • a causal or contribution claim that connects a changed structure or capability to a later result. Identify the world-side subject independently. Treat descriptions, role labels, organization charts, Method accounts, and dashboard rows as epistemes or presentation elements used by Work.
3. Qualify each claim on its own basis. For an architecture characteristic or C.25 quality bundle, state the bearer, selected structure, change family, scale, reference scheme, window, constraints, mechanism, evidence, uncertainty, and unsupported stronger claim. For capability, state holder and target Work. For change Work, state the Work occurrence, enacted Method, result and resource coordinates, configuration, and conditions. For a joint arrangement, state participants and relations. Keep causal contribution separate from co-occurrence, sequence, and correspondence. Do not compare claims that use different subjects, change families, scales, or horizons without a declared comparison relation.
4. Recover three different structures. For each view, state its EntityOfConcern, relation type, scale, horizon, and decision use.
   • In the holonic or membership view, identify constructive parts and wholes or actual family members. Record simultaneous cross-level conflicts when a local change improves one level while burdening another.
   • In the system-of-interest–builder relation view, identify the direct dependencies, correspondences, provider, service, interface, or enabling relations used by this decision. Do not infer part–whole from dependence.
   • In the Work view, identify first–then, overlap, concurrency, and recurrence among Work occurrences. Do not infer a level from earlier Work. Leave a view unused when it cannot affect this decision.
5. Separate current facts from possible-future specifications. For every proposed change—for example, a module boundary, interface, product-family rule, fixture, test service, automation, Method change, or provider arrangement—write a possible-future architecture specification and the later Work and observation needed to establish it. Keep expected characteristics separate from current readings.
6. Find the constraining relation and its evidence. Ask which proposed change to the project system-of-interest is unreachable, too costly, too slow, too hard to assure, or too hard to roll back under the current builder arrangement. State the selected structure of the project system-of-interest, the builder structure or service, their direct relation, the affected result, evidence, uncertainty, and moved burden. When a causal contribution is needed, state the mechanism and the comparison or intervention basis; do not promote co-occurrence or earlier order into causation.
7. Develop alternatives on both sides. Include the incumbent and materially different changes such as a boundary or interface of the project system-of-interest, family configuration rule, builder fixture or manufacturing cell, test and evidence platform, release Method, supplier arrangement, or a change spanning both sides. In product–production cases, include production-process and production-System reconfiguration when they constrain product-family change across generations. State which selected structure each alternative changes and which constraints it leaves untouched.
8. Compare finite changes. Use C.32.ACS to choose a few optimization indicators and monitored guardrails with their actual claim subjects and scales. Apply C.11.CRC to each realizable finite change relative to the current configuration of the project system-of-interest and builder arrangement. Preserve result and resource vectors, implementation Work, interactions, uncertainty, reversibility, future-option effects, and displaced burdens. Do not score possible option reach as an already realized operating result.
9. Return a replayable investment choice. Freeze the viable OptionSet. State one shared preference order or evaluative measure, BeliefState, and OutcomeModel. When another probe is live, state its action set, budget, cost, and expected decision value. Apply one ChoiceRule and emit one ChoiceResult from the current C.11 result set: choose the incumbent or a change to the project system-of-interest, builder arrangement, or both; retain a tie-set; reject the current set; request a probe; or reroute and end this decision pass because the question, authority, or needed input lies elsewhere. Record protected losses, budget, dependencies, why the ChoiceRule permits this result, and overturn conditions. The choice may issue an implementation request, but it does not authorize or perform the change.
10. Realize and observe separately. Assigned Agents later perform separately identified Work that changes the project system-of-interest, a builder System, platform, Method, or organization arrangement under its own authority and enacted Method. Observe representative future changes through measures relevant to this decision—for example, reachability, lead time, rework, defect introduction, evidence reuse, rollback, consequences for the project system-of-interest, provider burden, or newly exposed constraints. Revise only the claims and architecture decisions that the observations support or defeat. Send human capability demand to Human Capability Development and cultural-continuation evidence to SYSE.21 rather than hiding either inside an evolvability score.

SYSE.23:4.1.1 - Make the future change concrete enough to diagnose

The short move above starts with an expected change family. Construct that input from a current use need, a supported SYSE.22 correspondence, a supplier or operating change, or a recurring difficulty in actual change Work. Do not begin with “adopt microservices” or “buy a digital platform”; those already select a means.

Describe a representative change as a difference between two usable configurations under stated conditions. Name the changed behaviour or interface, the members or installations affected, the result needed from the changed System, and how successful completion would be recognized. Include the configuration that must continue to operate during transition. A supplier replacement, a network-loss mode and a different service environment are different scenarios even when all are called “add a variant.”

Select scenarios that could distinguish the investment alternatives. A near-term change can expose present burden; a consequential different change can reveal whether the proposed mechanism generalizes; a protected operating or recovery condition can expose its unacceptable loss. Give projected frequency or scale only when there is a basis for it. When future demand is uncertain, compare the investment under several plausible demands and say where the preference changes.

The question can be narrower than general evolvability: “make the next supplier replacement possible while six released configurations remain supportable.” If that is the present need, a general platform may be unwarranted. If the source is a SYSE.22 probe result, preserve exactly what it settled. A pass for local fallback in two configurations does not establish compatibility with a new compressor supplier or justify cross-variant evidence reuse.

SYSE.23:4.1.2 - Trace what has to change and why

Work one scenario through the current arrangement. Begin at the proposed change in functioning, configuration or interface and ask what must be revised, reproduced, obtained, checked and supported for the result to become usable. Follow the action-changing dependencies across target parts, descriptions, production means, tests, release and service. Use the realization branch construction in SYSE.3:4.2–4.4 rather than reconstructing a complete builder hierarchy. A branch can stop at an adequate supplied result.

Explain each consequential propagation. A new protocol may require an adapter because its timing differs; an evidence result may need renewal because its configuration basis changed; a rig may require requalification because its emulator now represents a different physical response. “Everything depends on everything” gives no place to intervene. Conversely, an unchanged interface name does not show that timing, failure behaviour or support demands remain unchanged.

Distinguish two mechanisms that often get mixed:

• Change propagation: modifying one description, interface or implementation requires compatible changes elsewhere before the new configuration can be used.
• Operational propagation: a disturbance or failure in one part affects another during use.

A boundary can reduce one propagation while worsening the other. An adapter may localize future firmware changes yet add response delay or another failure mode. A shared test service may reduce duplicated setup while making several projects depend on its availability. Retain both consequences where they matter.

For every apparent bottleneck, compare the required contribution with what the current arrangement supplies. A slow task can result from intrinsic technical work, repeatable setup, waiting for a shared resource, missing capability, unresolved authority or unavailable evidence. Each suggests a different intervention. The number of touched modules and elapsed time of one change are observations, not a causal decomposition. Use the five claim kinds in §4.1 to keep the supported constraint distinct from the suspected explanation.

The useful intermediate result is a small set of constraining relations and their effects on the chosen scenarios. It can be written directly on the existing architecture or realization account: what change demands what contribution, why, from which System or performer, under which condition, and with what support or gap. Do not model an entire organization when one interface and rig correspondence decides the question.

SYSE.23:4.1.3 - Construct mechanisms on both sides of the constraint

For each limiting relation, ask which premise an intervention could change. Keep the incumbent as the common basis and construct materially different responses. The following alternatives illustrate how to reason.

Derive an alternative through the complete scenario. A target-only change is insufficient when the unchanged rig cannot represent the new behaviour. A builder-only change may work by accepting wider test and maintenance Work. A mixed change can reduce that wider burden, but it adds migration and coordination. Demonstrate those differences; the label “mixed” gives no presumption of superiority.

A builder can itself need a new fixture, Method, service or qualified performer. Apply SYSE.3:4.4 to that specific unresolved branch. Recursion ends when a compatible supported means is available, an attainable next inquiry is selected, or the investment is rejected or narrowed. It does not require developing every builder anew.

When architecture and team responsibilities must change together, involve the affected practitioners in the same technical reasoning. Explain the constraint that failed, the proposed boundary, what later decisions are fixed or still open, and the evidence that would overturn the proposal. Ask the production, test and service contributors to carry the scenario through their work and return an incompatibility they can substantiate. This is part of making the technical choice usable; a diagram or an announcement does not produce shared understanding. Organization redesign, assignments and authority still need their own decisions and Methods. SYSE.6:4.1 supplies the architecture decision’s fixed/open constraints and receiving uses.

SYSE.23:4.1.4 - Compare the transition as well as the possible future

An investment is useful only if the proposed arrangement can be reached and then used. For each serious option, identify a viable transition from the current configuration through any necessary coexistence to the intended arrangement. State which current service or production must continue, what can be taken out of use, what must be qualified before reliance, and what can be restored if the change fails. A physical change may require rework or replacement rather than an instantaneous rollback.

Examine the required contributions together. The controller boundary, rig adapter, evidence mapping and service procedure must agree on the same variant and interface semantics. Their readiness must fit the needed window. If the same engineer or facility supplies several contributions, compare the joint demand with its available capacity. Separately feasible plans cannot be added when they spend the same exclusive resource. SYSE.20 supplies reasoning about overlapping Work and usable partial results; SYSE.13 supplies the configuration and effectivity basis.

A staged investment can be preferable: first isolate one boundary and qualify its matching rig slice, then generalize only if a further change demonstrates sufficient reuse. For such a proposal, say what useful result the first commitment produces even if later expansion stops. Retain the incumbent where coexistence is necessary and affordable. Do not use expected capabilities of the finished platform to justify reliance during its own construction.

This comparison also exposes complementarity. Suppose an adapter alone cannot reduce release burden because the rig and evidence account still require a full rebuild; rig parameterization alone cannot localize that rebuild because the target remains coupled. Their joint change may remove the constraint. Count that joint benefit once. Conversely, removing one constraint can expose another, such as review capacity or service commissioning. Carry that remaining constraint into the alternative rather than reporting a whole improvement from the first local gain.

SYSE.23:4.1.5 - Judge future benefit against commitment and continuing burden

Compare each alternative for the same change scenarios, horizon and current arrangement. Keep current implementation and transition Work, recurring operation and maintenance of the new means, later target-change Work, and displaced protective Work visible. Use a single quantity only for genuinely commensurable terms; safety, comfort, evidence strength and option reach do not become hours or money by being in the same table.

For a bounded effort comparison, suppose equivalent admissible changes currently require 60 engineering hours each. A proposed means requires 240 hours to establish and 16 hours per later change. Under those stipulated conditions, with all differing effort included in those terms, its total is lower only when 240 + 16n < 60n, hence at six or more changes. At five, the totals are 320 and 300 hours. This calculation does not establish that six changes will be needed, that the effort estimates are supported, that other characteristics are equal, or that the transition fits the calendar. If recurring provider maintenance, qualification or adaptation differs, add those contributions before using the comparison.

When the benefit is preserving an option rather than saving repeated effort, name the future change that would otherwise become impossible or costly, the mechanism keeping it available, its carrying burden, and the event that makes it worth exercising. A reversible first commitment can be preferable under uncertainty. An unused option is not a realized operating gain, and preserving every imaginable option is not free.

Select one worthwhile additional observation only when it could change the choice. A model can settle a known resource bound; it cannot establish the service team’s ability to use a new commissioning procedure. A trial can reveal an integration difficulty; it need not justify a general causal claim. Use SYSE.10 for what the result supports and C.11.DUA when further inquiry’s value is uncertain. A qualified decision to retain the current arrangement is a substantive outcome.

SYSE.23:4.1.6 - Make the choice usable and learn from its actual consequences

The investment result names both what should change and which later change it is meant to enable. Give the receiving architect, platform provider or realization performer the selected constraint, intended result, accepted loss, unchanged protections, unresolved input and reconsideration condition. Use SYSE.24 if a needed fixture, service or other result can be obtained in materially different ways. Use SYSE.12 for the platform’s supported readiness and later observed-use account. Neither replaces this investment comparison.

In the resulting Work, observe the connection the investment was intended to improve. If the boundary localized the target change but the rig still required a full rebuild, one expected benefit failed. If change effort fell because an expert supplied unplanned help, retain the observed effort and help while qualifying the claim about the new means. Compare later change occurrences only to the extent their configurations, demands and support are comparable. A small observation can justify local correction without establishing the cause of a profession-wide trend.

Return a changed feasibility or burden premise to SYSE.22:4.1.6 only for the problem–option correspondences it affects. Return an architecture constraint to SYSE.6, a failed realization dependency to SYSE.3, or a platform-use failure to SYSE.12 when that is the precise receiver. If the intended future changes no longer matter, reconsider the investment’s purpose before optimizing the builder further. If the arrangement is being copied and retained beyond the project, use SYSE.21 for that different cultural question.

SYSE.23:4.2 - Record the Result

Record the following content for the stated decision using linked descriptions. Keep architecture, capability, Work, arrangement, contribution, decision, and observation records distinct; each claim keeps its own subject and scope. Include view-specific content only for views used in this decision.

SYSE.23:4.3 - What Changes in Practice

Managers can tie an evolvability investment to a named future-change family. Engineers can say what kind of claim failed, which current structure or Work result it concerns, which part–whole or membership level or system-of-interest–builder relation matters, what burden each alternative moves, and why the ChoiceRule permits the present result. They compare platform investment and redesign of the project system-of-interest on one declared basis.

SYSE.23:5 - Worked Case: Where to Invest for the Next Heat-Pump Controller Variants

The heat-pump controller project from SYSE.22:5 expects three changes over the next two years: support another compressor supplier, add a local fallback mode for buildings with unreliable networks, and reuse assurance evidence across controller configurations. Management says that the controller family must become more evolvable.

The following table is the complete current claim set used by this decision:

The team then fills three different architecture views:

The holonic and membership view exposes processor and evidence burdens at levels different from the interface change. The system-of-interest–builder relation view matters because the rig is not a part of the controller. The Work view matters because test readiness and review overlap determine calendar and assurance resources. None of the three can be inferred from another.

Three alternatives survive admission beside the incumbent:

1. Redesign the controller: isolate compressor and network dependencies behind versioned interfaces. This can localize later changes but adds interface translation, processor load, and an immediate verification burden.
2. Change the builder arrangement: parameterize the test rig and configuration/evidence pipeline for the known supplier and network-loss variants. This can shorten trial and evidence Work but leaves four coupled controller components unchanged.
3. Mixed bounded change: introduce one compressor boundary for the next supplier and parameterize only the corresponding rig and evidence slice. This preserves less future reach than a general redesign but limits current cost and provides evidence for the larger choice.

The deciding Agent applies C.11.CRC to compare each finite change with the current controller-and-builder configuration. For this case, the complete result-coordinate set contains admitted supplier and network variants, change lead time, defect reintroduction, evidence reuse, rollback time, comfort, energy, safety, and service error exposure. Resource coordinates include engineering time, rig outage, supplier Work, review load, capital, and later maintenance. The team does not add these to one evolvability score.

The choice below is an illustrative design comparison. In addition to the observations above, assume the team has obtained these option estimates for the same two-year horizon. All three changes fit the architecture budget and have an identified way to meet the declared guardrails; actual release still requires its own qualification.

These are comparison premises, not consequences of counting four coupled components. Without the estimated effect on evidence reuse and the comparative commitment burden, the earlier observations would not distinguish the mixed and builder-only options. Retain that unresolved comparison rather than claiming the same choice.

The architecture choice follows from those observations and estimates:

Reconsider controller redesign if evidence shows that the rig already supports the new supplier, or the builder-only change if controller coupling proves local and stable. Compare again under the changed premise; either finding can alter the relative burden without selecting a replacement by itself. A cheap probe that could reverse the survivor relation would change the result to probe_again; guardrail failure by every option would produce reject_current_set; missing authority would produce a reroute that ends the current decision pass without stopping unrelated Work. These are the conditions for reconsidering the choice.

Assigned Agents later perform redesign, platform, test, release, and observation Work under their own authorities. Two supplier-change occurrences provide observations about controller coupling, rig time, evidence reuse, and service burden. A failed transfer reopens only the claims and decision that used it; it does not erase the separate facts about released configurations.

The manufacturing coevolution studies used below support joint product-family and production-system work across generations. Applying that line to this test, release, and service arrangement is a bounded engineering synthesis. The case must be reopened if the transfer hides a software, Method, organization, or capability difference that changes the decision.

SYSE.23:5.1 - Follow the mixed proposal through its constraining relations

To make the choice above constructible, take the next supplier replacement as the representative change. In the current arrangement the supplier’s command and response differences enter four firmware components; the rig represents those differences through manual wiring and interface-specific scripts. The release account relates evidence to controller, interface, rig and test configurations. Changing only the component name in that account would not preserve its evidence claim.

The mixed proposal places the next supplier’s differences behind one versioned compressor boundary. Its contract specifies the command and response meanings, timing and failure behaviour relied on by the rest of the controller. The corresponding rig adapter must reproduce those same meanings and relevant dynamics. The evidence slice identifies what the boundary preserves, what changed, and which earlier observations remain applicable. These are the actual proposed joins. A matching connector or schema alone does not settle them.

The controller engineers can retain the other components only if the boundary preserves their relied-on behaviour under the required load. Test engineers can reuse a result only if the supplier change leaves the claim and its applicable conditions supported. Release team RT2 must obtain support or capability for the new evidence argument before it is relied on. The investment can include obtaining that contribution; the present capability gap cannot be erased by the investment decision. The coupled slice is viable for development when those bounded contributions can be obtained within the stated commitment and window.

The team also examines transition. Existing controllers continue using the old boundary and qualified test configuration while the new slice is prepared. Rig time for supporting them competes with time for adapting and qualifying the new slice. The comparison includes that contention and the service procedure for identifying which configuration is installed. A fast new adapter without this coexistence account would not supply the complete proposal evaluated in §5.

The resulting architecture request is therefore limited: establish the one boundary and its matching rig and evidence slice for the next supplier, preserve the stated protections and support for released configurations, and leave generalization to wider variants open. Controller, rig and release contributors receive the same interface assumptions and return any incompatibility to the investment choice. This completes the choice’s technical explanation while implementation and release retain their separate evidence and authority.

A changed future demand. Now retain the case’s current configuration facts but suppose the supplier has confirmed that only one final replacement is needed before this product line retires. There is no longer a supported programme of later replacements, and the retained configurations can be supported with the existing rig. The previous two-year improvement objective must be reconsidered: repeated-use savings no longer warrant the same generalization by themselves.

Assume, for this changed comparison, that a local supplier-specific adaptation can meet the same safety, comfort and effectivity conditions, remains supportable until retirement, and consumes less total implementation, test and maintenance effort than establishing the mixed slice. Under a rule to meet this one replacement with the least justified commitment, choose that bounded adaptation; retain the mixed design as possible material for a later use. These new comparison premises, rather than the word “retirement,” support the changed choice. If the local adaptation instead destroys required rollback or cannot support an installed member, it does not qualify and the investment question remains open.

The change does not invalidate the observations about four-component coupling or manual rig work. It changes the horizon and the value of reducing that work. Send that changed obtaining burden and family boundary to SYSE.22; preserve its earlier comfort and network-loss evidence where applicable. A future programme that again requires multiple supplier variants would reopen the investment’s purpose and comparison.

SYSE.23:5.2 - A manufacturing boundary that changes the method

Consider a constructed family of reusable containers. A new closure improves the target container’s leak performance, but its rim geometry cannot be formed by the current die. Installing a new die would stop the only press that also produces replacement containers for existing users. “The container is modular” and “the new die can be made” are individually plausible but do not establish a usable transition.

The engineers trace the closure change through rim geometry, tooling, press setup, leak evidence and service stock. They compare retaining the old closure, redesigning the closure to fit the existing rim, obtaining a compatible temporary production service, and changing the die while building adequate stock. A production specialist must supply the forming and capacity results; this pattern supplies no metal-forming calculation.

For this comparison, assume that the current closure fails a new required leak limit. Supplier quotations make temporary production and building enough stock for the die change exceed the authorized budget. Qualified results support the redesigned closure on the existing rim, its required leak performance, continued stock supply and total burden within that budget. The new-die option without that stock still lacks a way to preserve the needed supply during changeover. Under a rule to meet the leak limit, preserve supply and stay within budget, the bounded decision selects the closure redesign as the only admitted option in this set. Wider tooling changes remain conditional. If later demand needs a geometry the old rim cannot support, that target-side answer is no longer sufficient: the obtaining and capacity question becomes decisive. Use SYSE.24 for the service-versus-build comparison and the production practice’s own capacity method. A software-style instantaneous rollback would not answer the physical tooling or stock constraint.

SYSE.23:6 - Bias Annotation

Watch for these nine biases:

SYSE.23:7 - Conformance Checklist

All ten conditions below are required for a conforming use of this pattern.

SYSE.23:8 - Common Failures and Repairs

SYSE.23:9 - Consequences

The project gains a practical answer to where should we invest so that the named later changes become reachable and affordable? Redesign of the project system-of-interest, family architecture, builder reconfiguration, platform Work, Method change, and separately justified capability or organization work can be compared while keeping their subjects and relation types distinct. Genuine cross-level conflicts remain visible. Possible-future benefits do not enter the current baseline.

The cost is a more disciplined claim and architecture account. There may be no single evolvability number, and the best first decision may improve only one change family. Some constraints require a neighboring DPF or specialist source; a bounded project cannot establish profession-wide cultural continuation or unlimited open-endedness.

SYSE.23:10 - Rationale

C.25, C.30, C.32.ACS, C.32.HCS, C.32.MWA, and C.36 govern quality bundles, architecture relations, project criteria, holon-family starter material, several practice structures, and cultural evolution. For this engineering decision, relate the project system-of-interest and family to builder and enabling Systems, platform, Methods, Work, configuration, evidence, and consequences for named affected Systems. Then choose which selected structure to change for one future-change family.

The pattern keeps builder Work separate from Work on the project system-of-interest and retains genuine levels. It can use a constructive part–whole view of the project system-of-interest or a builder System, a family- membership view, a non-holonic system-of-interest–builder relation view, and a Work-order or overlap view because these answer different concerns. Each view states its EntityOfConcern and relations. Correspondences and contribution claims among views need their own basis.

SYSE.23:11 - SoTA and Source Use

Continued engineering can require changes in a target System, its builder platform or both. Relate those alternatives to product and problem portfolios, characterize the changes they make possible, and examine reversibility and the observations that would reopen a choice. Apply the builder question recursively when changing a builder requires changing its own means of construction.

A developed alternative may already connect the work this pattern needs. The evolutionary-architecture authors’ account combines incremental change, engineering support and protection of architectural concerns; the second edition extends its applied treatment. Its lesson here is to compare a complete change arrangement. The local investment question still needs the selected future changes, actual configurations and burden on the builders.

Likewise, May et al.’s (2023) Product-Production-CoDesign account, §§3–5 addresses product and production change across generations without requiring synchronized one-to-one lifecycles. It supplies a substantial manufacturing approach. Use its compatible result where it answers the question; do not claim target–builder coevolution as a distinction from all professional practice.

The current practice example Governing data products using fitness functions (2024) also combines platform-supported checks with domain-team responsibility and explicitly limits what basic checks establish. For this pattern, the receiving question is whether an observed or expected change supports the named investment, including transition and continuing burden. A check result remains evidence for its particular claim rather than a general evolvability verdict.

Assess currentness for each relied-on claim. Reopen a source row only when changed evidence alters the claim kind or subject, change family, architecture relation, transfer limit, decision, or observation used here. Recency alone does not make a Method or mechanism preferable.

SYSE.23:12 - Relations

• Receive a compatible SYSE.22 result containing the project focus, selected problem portfolio, System-family options, supported correspondences, unresolved mismatches, and replayable ChoiceResult. Accept or qualify that account even when its ChoiceRule permits a choose, reject, or reroute result instead of an experiment decision. If a needed input is missing, state which SYSE.23 decision it blocks. The input selects neither the claim subject nor the architecture investment.
• Use SYSE.3 for the recursive realization arrangement; SYSE.6 for the current engineered-System architecture; SYSE.7 for descriptions and provenance; SYSE.10 for evidence; SYSE.12 for engineering-platform capabilities; SYSE.13 for configuration and effectivity; SYSE.15 for the Method repertoire; and SYSE.20 for Method-and-Work structures. Each result keeps its own subject and use boundary.
• SYSE.23:4.1.1–4.1.6 explains how to turn a future-change scenario into a target–builder investment comparison, including propagation, transition, joint conditions and continuing burden. SYSE.22:4.1.6 receives a changed feasibility or burden premise only at the strength established by the investment or later Work.
• Use C.25 only after the quality bearer and Q-Bundle have been recovered. Use C.30 for obtaining architecture relations and selected structures, C.32.ACS for a small project criteria set, C.32.HCS for family-specific starter material, and C.32.MWA for several non-isomorphic Method, Work, subject, dependency, and cultural structures. None supplies the engineering decision that compares changes to the project system-of-interest and builder arrangement by itself.
• Use C.18 for archive and Front claims, C.11.CRC for finite configuration-relative contribution comparisons, and C.11 for the later choice. Keep generation, selection, architecture, capability, Work result, implementation, observation, and causal attribution distinct.
• Supply revision feedback to SYSE.3, SYSE.6, SYSE.11, SYSE.12, SYSE.15, or SYSE.20 only when later evidence crosses a stated limit or changes an assumption of the receiving result. Feedback is an input to another decision, not an automatic stage.
• Supply SYSE.23 → SYSE.21 only with a bounded Method or arrangement variant and observations relevant to later cultural work. A project choice or successful change establishes no transmission, cultural selection, or retention.
• Send a human capability demand to Human Capability Development only for a named human holder population, target Work, support arrangement, capability evidence, and horizon. Do not treat an AI or robot as a human holder, or turn a platform, Method, assignment, organization, or authority relation into a capability of that human population. Use A.15.1 and F.6 for actual Work performance and attribution, and use the pattern that defines the named assignment or authority relation.
• For organization or assignment reconfiguration, continuing flow and capacity, Method construction, or service intervention and restored use, use the relevant DPF result when available. Otherwise name the specialist help that is missing and use a qualified source. Similar change language does not merge Organization Change Engineering, Operations Management, Method Engineering, and Maintenance Engineering.

SYSE.23:End