SYSE.6:4 - Solution

Apply C.32.PAD to the Systems Engineering decision. Compare candidates only when their engineering consequences are visible enough for the current commitment. Select the smallest set of project-shaping structures needed to coordinate later Work. State accepted losses and open refinements, then state which later results—for example, from realization, integration, configuration, specialist, assurance, or operating Work—can confirm or reopen the choice.

SYSE.6:4.1 - Perform the Move

1. Bind the architecture question. Name the actual engineered System or intended referent, composite project Work, decision subject, deciding Agent, use, configuration or variant, operating envelope, horizon, and the later decisions this architecture choice must coordinate. If the intended System does not yet exist, keep its referent in claim content as required by C.32.PAD. When the decision requires authority, cite the independently obtaining direct authority relation with its bearer, scope, basis, applicability, and interval. If that relation lacks a governing rule or does not obtain, candidate analysis may continue. Report the missing rule or authority relation; do not treat an assignment or record’s presence as authorization.
2. Select the project-shaping structures. Identify the selected structures whose alternatives can change several downstream choices or a protected characteristic. Examples include functional, constructive, placement, control, transformation-flow, information, evidence, Method, Work, and organization structures. Name each structure and the relation under discussion; important, cross-cutting, and hard to change are prompts, not membership tests.
3. Prepare candidates for the decision. Start with a compatible SYSE.5 account or a qualified direct source for functional organizations, candidate bearers, allocations, interfaces, and conflicts. Add provider-arrangement constraints from SYSE.8, description evidence from SYSE.7, specialist results from SYSE.9, and engineering claim assessments from SYSE.10 only when they fit the same subject, configuration, use, horizon, decision, and evidence window. For each input, state what it describes and which claim it can support. Evidence informs the decision but neither authorizes nor entails it; a specialist result answers only its receiving question under its stated conditions. If an input is unavailable or incompatible, use a qualified direct source or record the missing result. Keep a candidate only when its unsupported dependencies—for example, bearer, interface, realization, integration, configuration, or evidence dependencies—are visible as bounded residuals that the decision subject can knowingly accept.
4. Define the criteria before evaluating. Select a small set of C.32.ACS rows tied to this use and decision. For every characteristic, name the bearer, scale or qualitative frame, operating conditions, protected loss, comparison use, and guardrail or reopen reading when one is justified. Keep non-equivalent characteristics— for example, safety, performance, cost, resilience, changeability, or evidence burden—in separate rows unless the decision supplies and justifies an aggregation Method that preserves the distinctions it uses.
5. Compare coherent candidates. Compare whole proposals rather than isolated module choices. Include decision-relevant consequences—for example, expected functioning, physical principle, interfaces, placement, failure containment, realization and integration dependencies, supply and provider conditions, configuration continuity, operating and maintenance effects, affected Systems, evidence burden, or change consequences. Use A.19.CPM, C.11, or another direct comparison or choice pattern for the claim actually being made.
6. Challenge the preferred option. Ask which omitted structure or affected System could reverse the preference. Examine the relevant existing analyses and observations under their configuration, conditions, and claim limits. Before commissioning further Work, use C.11.DUA to compare it with proceeding on the present basis, narrowing the commitment, or stopping. Include what the inquiry could change, its cost and delay. Applicable evidence requirements govern that choice. The challenge may use specialist criticism, computation, simulation, prototype or bench tests, integration trials, or operating observation. For challenge Work whose result the decision uses, keep its performer, Method, configuration, conditions, and claim limits recoverable from that result; reuse the existing account where it is sufficient. Use an AI-produced ranking or architecture description as one input. The identified deciding Agent remains responsible for the choice. A claim of physical adequacy needs evidence about the physical System; selecting an option with stated residual uncertainty does not assert that stronger claim.
7. Make the decision relation explicit. Fill the current ArchitectureDecisionRelation@Project with the candidate basis, selected option, affected structures, criteria and trade-offs, accepted losses, rationale, consequences, effectivity and currentness claims, horizon, and rejected or retained alternatives. A bounded exception is a decision only when its scope, cost, protected loss, and reopen condition are explicit.
8. Fix constraints and preserve refinement freedom. State the decision-relevant constraints—for example, structure relations, interfaces, allocations, variation policies, or characteristic guardrails—that later Work must preserve. Separately state which implementation details and lower-scope structures remain open. Establish Work assignments, authority, commitments, and permissions through their own relations rather than through the architecture decision.
9. Name the engineering uses. Identify the receiving Work and the constraint or question it needs. Supply compatible selected-structure constraints and reconsideration conditions to SYSE.3, SYSE.13, and SYSE.18 only where they change the receiving design choice. During decision Work, use SYSE.9 to request a specialist contribution when one is needed. Use SYSE.7, SYSE.10, or SYSE.4 for a current description gap, evidence question, or assurance question. Each receiver rechecks subject, configuration, horizon, authority, and compatibility.
10. Design the continuation. For each material assumption or accepted loss, name the event or observation that calls for reconsideration—for example, a source change, actual-structure comparison, characteristic reading, failed interface, changed use, or affected-System consequence. Name the decision subject and the question to reconsider. A threshold crossing supplies an observation, not an automatic replacement decision.
11. Check what actually obtains. After realization or integration Work, compare the observed configuration and selected structures with the decision content. Record divergence and evidence separately from the decision and its description. Supersede the decision when the smallest material changed claim alters the selected option, accepted loss, fixed/open boundary, or receiving Work.
12. Stop at coordination sufficiency. Return when affected practitioners can tell what current structures and constraints guide their Work, what remains open, which losses are accepted, which result they must return, and what can reopen the choice. Do not wait for complete detailed design.

This list is a learning and reasoning aid, not a lifecycle or temporal order. Work such as candidate development, specialist analysis, realization preparation, evaluation, configuration, or architecture revision can overlap. A result dependency states which earlier result the receiving decision Work needs; it does not prescribe when each producing Work occurrence must finish.

SYSE.6:4.2 - Record the Result

Record the decision with C.32.PAD. For Systems Engineering use, include the following content in the decision relation and its cited subjects:

An ADR-like file or architecture description can publish parts of this result through C.32.ADR and C.30.AD. Identify its correspondence to the decision relation. Ground the actual architecture and later Work’s use of the decision independently.

SYSE.6:4.3 - What Changes in Practice

The engineering project stops collecting local choices and starts making a bounded, inspectable commitment across the structures that constrain several contributors. Downstream teams receive constraints and questions their Work must answer. Detailed design remains free where the decision leaves it open, and later integration or operating evidence can supersede the smallest affected decision rather than forcing either silent drift or a whole-project restart.