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.