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

SYSE.22:0 - Use This When

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

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

The first useful result contains these four parts:

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

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

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

SYSE.22:0.1 - Terms and Distinctions

Name in this pattern	What it denotes
problem situation	The world-side condition or relation that can frustrate an interest or intended use.
problem record	A `ProblemCard` episteme describing a problem situation or unresolved claim for one decision and period.
problem archive	Retained problem records, weak signals, alternative formulations, and stepping stones kept for possible later inquiry under a stated retention rule. This is an open content set governed by that rule.
selected problem portfolio	The finite set of problem records receiving attention, resources, or experiments in the current decision horizon.
actual System configuration	A world-side System and its obtaining configuration during a stated interval.
possible-future System-family option	A specification of a candidate member, variant, or configuration under a named family architecture, membership rule, and effectivity basis.
System family	A family relation among member Systems or possible-future specifications under explicit membership and effectivity rules. The family is identified through that relation rather than reclassified as another System.
exploration archive	Retained candidate descriptions and lineage kept under a stated exploration-value rule.
Front	A non-dominated set identified for one candidate set, admission rule, comparator or dominance relation, characteristic set, and date.
decision OptionSet	The finite set admitted for one current `C.11` choice. Membership in an archive or Front supplies no automatic membership here.
problem–option correspondence	A supported claim stating how one option changes admission, comparison, consequence, evidence need, or next action for one selected problem.
experiment proposal	Possible-future content describing a bounded change and distinguishing observation whose expected decision value can be compared with its cost.

The following identities are kept separate throughout this pattern: record, world-side subject, possible-future specification, decision, planned Work, performed Work, and observation.

SYSE.22:1 - Problem Frame

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

Five recurring confusions make that mutual development hard to manage:

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

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

SYSE.22:2 - Problem

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

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

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

SYSE.22:3 - Forces

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

SYSE.22:4 - Solution

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

SYSE.22:4.1 - Pattern-Use Unfolding

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

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

SYSE.22:4.2 - Record the Result

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

Result position	Required content
decision boundary	Project System or System family, membership and effectivity basis, current use, environment, affected Systems, configuration, horizon, resources, chooser, authority, and receiving decision.
situation and claim basis	World-side occurrence, condition, or unresolved possibility; separate assertions, observations, evidence, source, interval, and uncertainty.
problem archive and portfolio	Retained and selected problem records, their different membership rules, lineage, resources, applicable premises, stops and reopen conditions; actual expiry where a qualification, right, resource or promised-use window ends.
System-family options	Actual Systems and configurations, family identity, architecture, variant and effectivity rules, possible-future specifications, realizability, and builder dependencies.
plural-search results	Exploration archive and each Front with its candidate set, retention or admission rule, comparator, characteristics, date, and currentness.
correspondences	Every decision-bearing problem–option claim, its source and uncertainty, plus unresolved mismatches.
choice or probe	Fixed `OptionSet`, shared comparison basis, choice rule, probe budget and value when relevant, result permitted by the choice rule, reason, and overturn conditions.
continuation	Retained alternatives, planned and performed later Work when it occurs, receiving results, and selective reopen relations.

SYSE.22:4.3 - What Changes in Practice

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

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

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

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

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

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

Problem record	System-family option	Decision-bearing correspondence
peak demand, now with recovery-time and occupied-temperature acceptance	cloud schedule specification	Network loss makes the option inadmissible without a qualified fallback; recovery time enters comparison.
network-loss continuity	local-fallback specification	Local forecasting can change continuity and recovery, but processor-load and fallback evidence are missing.
compressor cycling for the affected configuration	variable-speed-control specification and incumbent control	Variable speed can change cycling and energy use while increasing calibration and service burden.
speculative voice-control request, retained only in the archive	voice-gateway specification, retained only in the option archive	No current use or affected-System consequence gives this pair decision priority.

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

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

The fixed current OptionSet has three members:

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

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

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

The council uses one shared comparison basis:

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

Candidate next probe	Bounded burden	Distinguishing observations	Effect on the current decision
Scripted network-loss and cold-recovery trial	96 engineering hours, two hardware-in-the-loop bench days, one three-day reversible building-pilot window, and about one week of decision delay.	In each of two representative building configurations: no safety violation; occupied-zone recovery inside 20 minutes; and controller processor load below 70%. An established safety or comfort guard failure, or processor load at or above 70% in either configuration, is a contrary outcome even if the other configuration passes. Incomplete, uncertain or otherwise non-decisive observations remain unresolved only when no such failure has been established.	A pass admits local fallback and leaves it with variable-speed control in the survivor set while cloud-only is rejected. A contrary outcome rejects local fallback and leaves variable-speed control as the admitted next-development option. An unresolved outcome preserves the unresolved local-fallback status and requires a new bounded decision.
Variable-speed calibration trial	128 engineering hours, four calibration-rig days, the same single building-pilot allocation, and about two weeks of decision delay.	Calibration effort and service burden may fall or rise within the currently supported range; the trial does not observe network-loss recovery or local-fallback processor load.	Either bounded outcome refines the burden comparison for an already admitted option but leaves the local-fallback admission defect and survivor question unchanged.
No probe	No immediate trial resource use or delay; preserves the scarce pilot allocation and engineering capacity.	No new observation.	Retain the qualified current comparison: cloud-only fails the guard, variable-speed control remains admitted, and local fallback is retained only as an unresolved candidate, not admitted for use. Later development or adoption still belongs to its competent owner.

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

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

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

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

SYSE.22:6 - Bias Annotation

Watch for these six recurring biases:

Recurring bias	Likely drift	Repair
requirements-freeze bias	The approved backlog becomes the permanently current problem.	Recover the world-side situation and the receiving claim’s applicable premises, including real time limits; reopen only decisions affected by their change.
solution-fixation bias	Every observation becomes a modification of the incumbent design.	Reopen both problem formulations and family alternatives; admit a branch, replacement, or stop when supported.
archive-as-portfolio bias	Everything worth remembering receives current attention and budget.	Keep retention membership separate from current portfolio membership.
one-Front bias	Points from changed candidates or comparators are plotted as one improvement curve.	Identify each Front and its basis; make any cross-basis comparison separately.
novelty bias	A distant or AI-generated option is treated as useful or admissible by novelty alone.	State the reference set, admission rules, consequences, and evidence.
measurement maximalism	The project waits for field-wide prevalence or conclusive causal attribution before a reversible probe.	Use proportionate evidence with explicit uncertainty and limits.

SYSE.22:7 - Conformance Checklist

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

SYSE.22:8 - Common Failures and Repairs

Recurring failure	Repair
Backlog equals problem portfolio	Repair the selected `ProblemCard` values and state why each receives current attention.
Candidate specification equals future System	Keep the specification possible-future; state realization and later-test Work.
Addresses problem fills every correspondence cell	State the changed admission, coordinate, consequence, evidence need, or next action.
Archive equals Front	Preserve archive membership under its retention rule and Front membership under its comparator.
A changed Front is presented as improvement on the old Front	Identify both bases and make any cross-basis claim separately.
A probe choice is presented as family adoption	Identify later planning, authorization, Work, evidence, and adoption decision.
Every new source restarts the project	Trace the source claim to its receiving use and reopen only dependent results.

SYSE.22:9 - Consequences

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

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

SYSE.22:10 - Rationale

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

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

SYSE.22:11 - SoTA and Source Use

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

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

Source	Retained contribution	Use boundary
Dorst and Cross (2001), Creativity in the design process: co-evolution of problem–solution	Mutual development of problem and solution spaces in protocol studies of experienced industrial designers.	Use as bounded design-process evidence; establish the current System family and configuration separately.
Liker et al. (1996) and Sobek, Ward, and Liker (1999) on set-based concurrent engineering	Communication about design sets, delayed commitment, feasibility, and narrowing in automotive product development.	Transfer the set-based moves only where the receiving profile’s constraints and evidence support them.
Castle, Stock, and Gorochowski (2024), Engineering is evolution	Variation, expression, evaluation, selection, exploration, and exploitation as an engineering perspective.	Use the evolutionary analogy as a hypothesis source; ground the current engineering Method and cultural claims separately.
Taylor (2018), Evolutionary Innovations and Where to Find Them, and Adams et al. (2019), The MODES Toolbox	Exploratory, expansive, and transformational change and operational measures for open-ended dynamics.	Apply these distinctions only when a possibility-space or open-ended-engineering claim changes the current decision.
Zhang et al. (2025), Darwin Gödel Machine	An AI-engineering case retaining a lineage-bearing archive of coding-agent variants for later improvement.	Treat coding benchmarks as one application case; test transfer to physical Systems and causal claims separately.

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

SYSE.22:12 - Relations

SYSE.1, SYSE.16, and SYSE.17 supply project focus, operational environment, and affected-System consequences for compatible uses.
SYSE.2, SYSE.6, SYSE.7, SYSE.10, and SYSE.13 supply linked concepts, architecture decisions, descriptions, evidence, and family/configuration/effectivity identity.
SYSE.15 can supply a compatible engineering-Method repertoire. SYSE.21 can supply bounded observations of an enacted variant and its population; each claim keeps its own evidence and transfer boundary.
C.22.2 governs ProblemCard epistemes and C.22.PFR any world-side ProblematicForRelation. C.17, C.18, C.19, G.5, and G.11 govern characterization, archives and Fronts, live pools, selected sets, and use-qualified currentness. G.11 does not require a refresh plan or waiver for continued applicability; SYSE.19 and SYSE.23 retain changed-premise and claim-specific receiving rules.
C.11.CRC governs finite configuration-relative contribution comparisons and C.11 the bounded choice.
Supply the project focus, selected problem portfolio, System-family option set, correspondences, unresolved mismatches, and current ChoiceResult from SYSE.22 to the Agent using SYSE.23 for an investment or reconfiguration decision.
Feedback reopens SYSE.2, SYSE.6, or SYSE.13 only when the changed result crosses their stated reopen condition.
Problem Structuring and Decision Support, Strategy, Method Engineering, and Operations Management retain their domain Methods even when their Work uses the same archives or decisions.