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:

Claim kind and subject	Current claim	Evidence and limit
architecture characteristic of the selected compressor-control and network-interface structure in controller configuration `C17`	the current coupling exposes four firmware components to one compressor replacement	one recent replacement found those four changes; it does not establish the same coupling in every family member.
architecture characteristic of the `ControllerFamily-F7` membership and effectivity structure	six released variants remain admitted under current interface, configuration, and assurance rules	two proposed supplier/network combinations lack effectivity and evidence; specifications are not current family members.
result and resource claim for `RigChangeWork-41` on the hardware-in-the-loop rig	representing another compressor interface required eleven hours of manual rewiring and produced coverage for only two interface variants	this is a result and resource use of one Work occurrence under one rig configuration, not a quality of every platform or future test.
result and resource claim for the 2026 commissioning and recovery Work sample	manual parameterization produced repeated field errors and slow restoration	the service records bound the sample; they do not establish platform automation as the only cause or repair.
capability claim for release-team Agent `RT2`	`RT2` can review the current configuration, evidence, and rollback package but lacks supported capability for the proposed cross-variant evidence slice	the current Method account and observed review Work support this bounded claim; a report about the Method is not the team’s capability.
joint-arrangement claim for `C17`, rig `R4`, release Method `M2`, and team `RT2`	the compressor-interface coupling, rig adapter correspondence, test-service relation, and release-evidence dependency constrain the currently reachable supplier-change cases	the named participants and relations support the bounded arrangement claim; they do not establish how much each participant causes the observed Work result.
proposed causal-contribution claim about changing the compressor boundary and rig adapter	the mixed change is expected to reduce supplier-change lead time and improve evidence reuse	this is a possible-future contribution claim. Only later comparable change Work and observations can support or defeat it.

The team then fills three different architecture views:

View and `EntityOfConcern`	Obtaining relations	Decision use
holonic and membership view of controller `C17`, rig `R4`, and family `F7`	`C17` has processor board, I/O assembly, and network module as constructive parts. `R4` has a host, I/O rack, compressor emulator, and network-fault injector as constructive parts. Six actual controllers are members of `F7` under the current effectivity basis.	A versioned compressor boundary can localize component replacement while adding processor load at controller level and configuration/evidence burden at family-member level. Rig parameterization can reduce rewiring Work while adding maintenance and qualification burden at rig-whole level. These are simultaneous cross-level conflicts, not stages.
non-holonic system-of-interest–builder relation view of the `C17`–`R4` test arrangement	the controller compressor interface corresponds to a rig adapter; the rig provides a test service to release Work; the evidence pipeline depends on configuration identity	The controller does not contain the rig, team, or Method as parts. Changing either side can move the supplier-change and assurance burden.
Work view of the next supplier-change trial	adapter parameterization precedes closed-loop test; evidence review overlaps later testing; rollback preparation and service planning overlap the release decision	Earlier and overlapping Work constrain the investment, but their order creates no holonic level.

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:

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

Option	Next supplier replacement and evidence reuse	Irreversible commitment relative to the other eligible changes
Retain the incumbent	Neither improves.	No new investment, but it does not meet the present improvement objective.
Redesign the controller	Replacement work becomes more local. The unchanged rig and release arrangement still prevent the required cross-variant evidence reuse.	A broad interface redesign commits more controller and verification work than the mixed option.
Change the builder arrangement	Both improve. To reuse evidence while the four controller components remain coupled, this option parameterizes and qualifies their wider rig and evidence interactions.	The estimated committed adaptation and maintenance burden of that wider arrangement exceeds the mixed option’s, including the latter’s controller change.
Mixed bounded change	Both improve for the next supplier. The compressor boundary confines the corresponding rig and evidence change to one slice.	Less committed adaptation and maintenance burden than the builder-only option; less controller redesign than the general redesign. Wider future variants remain outside this commitment.

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:

`C.11` content	Filled result
`DecisionSubject` and granularity	The `ControllerFamily-F7` investment council at team level may allocate the approved two-year architecture budget. Safety and product-release authorities remain separately identified.
current `OptionSet`	Retain the incumbent arrangement; redesign the controller; change the builder arrangement; or make the mixed bounded change.
shared comparison basis	Safety, comfort, and rollback are hard guardrails. The `BeliefState` contains the observed four-component coupling, manual rig rewiring, service errors, current family/effectivity records, and bounded transfer uncertainty. The `OutcomeModel` uses the option estimates above to relate each finite change to the result and resource vectors over the two-year horizon. They remain estimates until subsequent Work supplies observations.
probe decision value	Feasible pre-choice probes are an additional supplier-interface simulation and a rig mock-up, bounded to four weeks and one rig outage. Neither can establish the coupled interface–rig–evidence result without constructing nearly the same slice as the mixed option; their expected information value does not justify their delay and cost.
`ChoiceRule`	Reject any option that violates safety, comfort, effectivity, or rollback guardrails. Among survivors, retain the non-dominated set and choose a change within budget that improves at least the next supplier replacement and evidence-reuse case while minimizing irreversible burden. Request a probe only when it can change the survivor relation enough to justify its cost. Reject the set if no option survives; reroute when the decision subject, authority, or comparison basis is missing.
`ChoiceResult`	`choose_now`: make the mixed bounded change. Under the stated comparison premises, it meets the present supplier-change and evidence-reuse objective with less irreversible burden than the other qualifying change, the builder-only option. No smaller pre-choice probe is worth its cost. The implementation request for one interface and one rig/evidence slice is a later record, not implementation or improved evolvability.

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.