SYSE.8:4.1 - Perform the Move

1. Bound the use and decision. Name the client-side use, intended change, receiving Systems, project system-of-interest or intended System referent, configuration, horizon, and decision. Use SYSE.1, SYSE.16, or SYSE.17 results only when they fit that subject, configuration, use, horizon, decision, and evidence window. Otherwise use a qualified direct source or record the missing result, then pause only the decision that needs it. These result dependencies do not prescribe the order of Work.
2. Recover the promise. State the consumer-facing promise content, eligibility or applicability, access terms when access is promised, acceptance conditions, and evidence needed to evaluate fulfilment. Keep each actual commitment, permission, delivery relation, acceptance relation, payment, and Work occurrence separate.
3. Name the subject. Identify what is transferred, accessed, changed, used, restored, or kept within a stated range or condition: for example, a machine, material lot, software edition, data, access point, temperature range, stock state, or performed Work. Keep non-System subjects in their recovered kinds.
4. Generate materially different candidates. Compare plausible arrangements such as product transfer with support, access or use provision, continuing availability responsibility, result-oriented provision, and mixed forms. Retain variety when evidence can still change the choice.
5. Develop the provider structure. For each candidate, identify the actual provider and partner Systems. Represent a provider that does not yet exist only as an intended referent in a possible-future claim. Record the relations and assignments that obtain. Then name the capabilities, Methods, recurring and exceptional Work, interfaces, resources, data, tools, shared enabling Systems, supply relations, and recovery arrangements that can change the decision. State the kind of each relation—for example, parthood, interaction, transfer, access, obligation, or contribution—and ground it independently of any intended referent.
6. Separate expected Work from responsibility and authority. For planned Work, name the intended performer Agent or the conditions for selecting one, together with the sought result. For Work that has occurred, identify the actual performer Agent and the Work independently; add assignment-bound attribution only when the receiving use needs it. Separately identify the System that holds or owns each asset; the Agent expected to bear or manage variability and failure exposure, observe or restore a condition, and receive each decision or evidence result; and any current responsibility, commitment, permission, legal duty, or authority relation.
7. Connect realization and continuing change. Identify the realization and change Work, its intended or actual performer Agents as applicable, and the Systems it uses or changes. Name the subjects changed—for example, the product, provider capability, interfaces, data, operating arrangement, or shared enabling Systems. State what later evidence or change will reopen the concept—for example, evidence from a new configuration, update, migration, maintenance event, partner change, or recovery attempt.
8. Obtain specialist results. Request a specialist result only when it can change the candidate—for example, a result from strategy, marketing, commercial analysis, finance, law, organization change, operations, supporting-System engineering, safety, security, or environmental engineering. Preserve its source and authority boundary.
9. Compare the candidates. Compare decision-relevant consequences—for example, client-side use, technical feasibility, architecture, capability, value, cost, financing, risk allocation, operational burden, changeability, evidence, or affected-System consequences. Keep non-equivalent measures separate unless an explicit aggregation Method preserves the distinctions used by the decision.
10. Record the bounded concept. Give each candidate one current disposition: select it, retain it for later comparison, branch it by a stated condition, or reject it. Record unsupported claims, needed specialist and realization results, responsibilities, evidence needs, and conditions for reconsideration. A conditional candidate is useful when it makes the next decision visible.

These numbered moves are a CGUS presentation of the Method under A.22.CGUS: they expose logical dependencies but do not prescribe Work order. Work such as use analysis, concept development, architecture, organization change, operations, commercial analysis, trials, or realization can overlap and reopen earlier decisions.