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

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. Then state what was actually observed. Was it a characteristic of an obtaining architecture, 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 only a suspected contribution? 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.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: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.

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.
• 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