SYSE.6 - Decide and Reopen the Engineering Architecture

SYSE.6:0 - Use This When

Use this pattern when an engineering project has several architecture candidates, yet local design choices are accumulating without one recoverable decision about the project-shaping structures of the engineered System. Use it also when an earlier architecture decision still appears in a record, but changed conditions—for example, use, integration, configuration, evidence, or operation—may have made its accepted losses and open refinements stale.

The intended result is an engineering architecture decision that selects one option, fixes the project-shaping constraints, and states when to reconsider it. In FPF this is an ArchitectureDecisionRelation@Project supplied by C.32.PAD, not a second decision kind. In this Systems Engineering specialization, the decision uses the required engineering content recorded below: each candidate’s use, functional organization, bearers, interfaces, realization, integration, affected-System consequences, and evidence. The decision names the selected option, explicit constraints, and results needed by later engineering Work.

First move. Name the architecture question, the decision subject, and the smallest project-shaping structure choice that two current candidates answer differently. When the choice requires authority, cite the separate authority relation; an assignment or architecture record does not supply it.

This pattern begins after candidate development and ends with a decision plus conditions for reconsideration. Use C.32 and SYSE.5 to develop the candidates, SYSE.7 to maintain architecture descriptions, C.32.PAD directly when no Systems Engineering specialization changes the choice, and SYSE.4 to qualify the decision or identify the basis it still lacks. Release approval and evidence that the intended architecture now obtains remain separate decisions and claims.

SYSE.6:0.1 - Terms and Distinctions

Name in this pattern	What it denotes
engineering architecture	The selected structures of an engineered System that shape consequential engineering choices, such as its functional allocation, interfaces, control, or redundancy. For a realized System, `C.30` identifies the `ArchitectureRelation` between that System and each actual selected `U.Structure`. Architecture descriptions state claims about these structures; proposals describe possible future arrangements and the conditions for their realization.
architecture candidate	An episteme that proposes selected-structure content, consequences, and conditions for one architecture option. It does not make an architecture relation obtain.
engineering project architecture decision relation	The `ArchitectureDecisionRelation@Project` supplied by `C.32.PAD` for an actual engineered System or intended referent and a recoverable composite project `U.Work`. It links the decision subject, candidate basis, selected option, constraints, accepted losses, and reconsideration conditions. The relation does not create the intended System or perform implementation Work.
chosen architecture	The structural option selected by the architecture decision, whether retained or intended to be realized. The decision record describes that choice and its constraints. Claims about future realization state what is intended; later observations establish the actual structure.
architecture characteristic criterion	One decision-specific criterion row supplied by `C.32.ACS`, with the characteristic, bearer, scale or qualitative frame, use, conditions, protected loss, and guardrail or comparison use needed by the decision. A quality word or metric name is not a criterion row.
architecture evaluation result	The result of an eval program under `C.32.ACE`, with its subject, configuration, conditions, parity frame, observations, and limits. It informs a decision; it does not select an option.
engineering architecture residual	An unresolved mismatch, loss, unsupported dependency, or omitted consequence tied to selected-structure content, a bearer or affected System, use and operating conditions, and a receiving engineering decision. The tie to that decision distinguishes a residual from an unrelated open task.
accepted loss	A disadvantage or unresolved residual that the decision subject knowingly accepts for the declared option, scope, horizon, and protected characteristics. Acceptance does not erase the consequence or establish permission from another decision subject.
open refinement	Decision content that leaves named lower-scope or neighboring structure choices undecided while fixing the project-shaping constraints they must satisfy. Interface, evidence, and affected-System claims retain their own Methods and grounds.
reopen condition	A stated event or observation—for example, a source or configuration change, characteristic crossing, failed dependency, or changed use—that requires the named decision subject to reconsider the decision. The condition opens reconsideration; the later decision remains a separate occurrence.

Words such as architecture, style, pattern, platform, modular, open, integrated, distributed, AI-native, and evolutionary are recognition cues until the current claim identifies the selected structures, criteria, Method, decision relation, or observed change meant.

SYSE.6:1 - Problem Frame

Engineering architecture decisions coordinate many later choices without deciding every detail. They can fix a functional allocation, module boundary, interface grammar, placement, control boundary, redundancy principle, product-family variation policy, evidence boundary, or other selected structure that several realization and specialist decisions must respect.

The decision sits between possible futures and physical realization. Its grounds may include, for example, current descriptions, comparisons, estimates, experiments, or specialist returns. Later Work may produce a different actual structure or expose consequences that were not visible. The architecture decision must close enough choice for current engineering Work while preserving alternatives and explicit conditions for revision.

SYSE.6:2 - Problem

Without a bounded architecture decision, local choices become a de facto architecture. Contributors—for example, component suppliers, software teams, construction specialists, operators, safety specialists, or providers of supporting Systems—each optimize their own structure. Their decisions can be individually reasonable and jointly incompatible. Burdens such as interface, placement, configuration, assurance, or affected-System consequences appear only during integration or operation.

An oversized architecture decision causes the opposite failure. It fixes low-level details without the local knowledge needed to choose them, substitutes centralized approval for specialist contribution, and makes every revision look like a whole-project exception. A broad quality catalogue or one score does not solve the problem: characteristics have different bearers, Scales, conditions, evidence, and protected losses.

A decision record can hide both failures. A file can be complete while the candidate basis is narrow, accepted losses are absent, the selected structure is unclear, or no observation can reopen the decision. Engineers then preserve documentation instead of maintaining a current engineering choice.

SYSE.6:3 - Forces

The decision must manage these recurring tensions:

Current engineering contributors need stable constraints, while architecture knowledge and operating conditions continue to change.
Whole-System coherence requires cross-boundary constraints, while detailed choices need local specialist knowledge and room to vary.
A small characteristic set makes trade-offs visible, while omitted affected Systems or scales can move the burden outside the chosen boundary.
Early estimates are cheaper than realization, while integration and operating evidence are often more decision-relevant.
Architecture moves such as modularity, reuse, distribution, or standardization can reduce one burden while increasing others—for example, coordination, evidence, latency, supply, cost, or failure-coupling burdens.
Current contributors need one selected option as a common decision basis, while rejected or deferred alternatives can remain valuable when the environment, technology, or evidence changes.
AI-assisted synthesis and analysis can widen and criticize alternatives, while authority, accepted loss, and the engineering decision still require an identified decision subject and adequate grounds.
A decision that is easy to supersede supports continuing change, while a decision with no stable identity or effectivity cannot coordinate implementation and configuration.

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

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

Result position	Required content
bounded decision	Composite project Work, actual engineered System or intended referent, decision subject, use, configuration, operating envelope, horizon, question, and intended receiving decisions.
candidate basis	Compatible `SYSE.5` alternatives or qualified direct sources; provider-arrangement, affected-System, specialist, realization, configuration, and evidence conditions material to the choice.
selected structures	Obtaining structures or possible-future claim content, affected relations, selected option, fixed project-shaping constraints, and open refinements.
criteria and evidence	Decision-specific `C.32.ACS` rows, any `C.32.ACE` results, comparison or choice result, sources, observations, uncertainty, and limits.
trade-offs	Expected gains, accepted losses, unresolved residuals, rejected or retained alternatives, protected characteristics, and affected-System consequences.
engineering returns	Named constraints, questions, and result conditions supplied to receiving decisions—for example, realization, integration, configuration, description, specialist, assurance, supporting-System, operation, or maintenance decisions.
continuation	Observations and source changes that call for reconsideration, the decision subject and authority for that reconsideration, the supersession condition, and comparison of later actual structures with decision content.

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.

SYSE.6:5 - Worked Case: Architecture Decision for the Heat-Pump Plant Controller

Engineers using SYSE.5 have produced two viable alternatives for an occupied-building heat-pump plant. In alternative A, local unit controllers carry protection and normal regulation while a supervisor sends bounded set-points. In alternative B, thermal storage and a tariff scheduler carry most time-shifting while local controllers retain protection and regulation. Both can satisfy the current use concept; their structures and unresolved evidence differ.

The project must choose the controller architecture for plant configuration HP-2 for the next three heating seasons. Its architecture board is the decision subject; a separate project relation gives the board authority to make this decision. The board’s assignment and the decision record do not create that authority. The resulting ArchitectureDecisionRelation@Project selects these project-shaping structures:

local protection remains within each unit boundary and does not depend on supervisor or utility communication;
the supervisor can coordinate set-points only inside declared unit operating envelopes;
plant-state and command interfaces carry units, timestamps, quality, validity, fallback, configuration, and effectivity conditions;
a later storage branch can enter only through the declared thermal, control, configuration, and assurance interfaces.

The architecture board compares protection independence, room-comfort response, grid-flexibility response, integration burden, energy and cycling consequences, maintenance access, and continuing change. Each criterion names its bearer and conditions. Current evidence supports alternative A. Alternative B remains a future option because storage-cycling, plant-space, supply, and economic claims are not yet sufficient for the current commitment.

The accepted loss is less global optimization than the most centralized candidate predicts. The decision protects local fail-safe behavior and records the operating evidence that can reopen the balance. Algorithm choice, hardware supplier, detailed state estimator, and user-interface design remain open refinements provided they preserve the fixed structures and guardrails.

The controller and integration teams use the fixed structures while shaping controller, bench, installation, and integration Work with SYSE.3. Configuration and interface-version Work uses SYSE.13; utility-signal authority and service conditions are handled with SYSE.18. Model and trial results are assessed through SYSE.10, and the assurance question is handled through SYSE.4. The Agents performing these neighboring Work occurrences apply their respective Methods, and each Work occurrence produces its own result for its named receiving use. The architecture decision only supplies relevant constraints and questions. The architecture board reconsiders the decision if communication-loss trials violate local protection, room-comfort or cycling observations cross their guardrails, the utility changes signal semantics, storage enters current project scope, or the installed structure diverges materially from the selected option. A new decision then names the changed configuration, remaining horizon, unresolved evidence gaps, and operating envelope. It may supersede the earlier decision.

The architecture decision does not make the plant configuration obtain. After integration, observations of the actual installed Systems and relations are compared with the decision content. A different wiring, fallback, or control allocation is an implementation divergence even if the architecture record was left unchanged.

SYSE.6:6 - Biases to Watch

Three recurring biases matter here. Record-presence bias treats a complete diagram or file as a current decision; recover the selected option, constraints, accepted losses, effectivity, and reopen conditions. Single-score bias lets a modularity measure, connection count, maturity level, or aggregate score hide different bearers and losses; compare decision-specific criteria. Software-transfer bias imports a software architecture example as a general engineering rule; recheck the physical realization, operating conditions, and evidence of the engineered System.

Agents—for example, people, teams, organizations, robots, or sufficiently agentic AI Systems—may contribute to synthesis, modeling, criticism, evaluation, or implementation when they have the needed capability and assignment. The decision still names the decision subject, authority, accepted losses, evidence, and affected Systems. Application DPFs supply subject-specific Methods—for example, Methods for physics, safety, software, medicine, electrical or civil engineering, shipbuilding, manufacturing, law, environment, or economics.

SYSE.6:7 - Conformance Checklist

ID	A conforming use…
`CC-SYSE6-1`	names the composite project Work, actual engineered System or intended referent, decision subject, use, configuration, horizon, and receiving decisions.
`CC-SYSE6-2`	identifies project-shaping selected structures and relation claims rather than using important or hard to change as an architecture definition.
`CC-SYSE6-3`	admits candidates only with explicit functional, bearer, interface, realization, integration, affected-System, and evidence consequences or bounded residuals.
`CC-SYSE6-4`	defines decision-specific architecture-characteristic criteria before relying on eval results or scores.
`CC-SYSE6-5`	compares coherent alternatives and exposes gains, accepted losses, unknowns, and burdens moved elsewhere.
`CC-SYSE6-6`	returns one `C.32.PAD` decision relation and grounds the architecture claim, description, actual architecture, Work, and evidence through their own kinds and relations.
`CC-SYSE6-7`	distinguishes fixed project-shaping constraints from open refinement and preserves specialist authority.
`CC-SYSE6-8`	names each result needed by receiving Work—for example, a realization, configuration, specialist, description, assurance, supporting-System, operating, or maintenance result.
`CC-SYSE6-9`	states observable reopen conditions, the decision subject for reconsideration, and the question reopened.
`CC-SYSE6-10`	later checks the actual configuration and structures separately from the decision content and its publication.

SYSE.6:8 - Common Failures and Repairs

Failure	Symptom	Repair
Local choices as architecture	Interfaces, modules, suppliers, and software partitions accumulate without a joint decision.	Select the project-shaping structures and make one bounded `C.32.PAD` decision relation with explicit receiving Work.
Architecture as everything important	The decision includes every design detail and unresolved issue.	Keep only selected structures coordinating several choices or protected characteristics; leave named refinement open.
Hard-to-change definition	Costly change alone makes an item architectural.	Name the selected structure, current alternatives, consequences, and decision use; difficulty is one possible characteristic.
Quality catalogue	Generic qualities are scored without bearers, conditions, Scales, or protected losses.	Create a small `C.32.ACS` criteria set for the current decision and preserve non-equivalent readings.
Metric as selector	A dashboard or eval result chooses the architecture automatically.	Interpret the reading under its subject and parity frame, then use the direct comparison and decision patterns.
Modularity as universal good	More modules, fewer connections, an open standard, or one supporting System is assumed better.	Compare decision-relevant consequences—for example, function bearing, coupling, cohesion, substitution, integration, evidence, cost, supply, or change—under the stated use.
Candidate without realization	A plausible structure lacks a needed realization dependency—for example, a transformer System, capability, interface realization, integration relation, or evidence return.	Record a bounded residual or return the unsupported branch to `SYSE.3`; do not hide it in an architecture label.
Organization mirroring shortcut	Current teams or communication links are copied into technical architecture by analogy.	Use `C.32.CONWAY` only for a stated influence or correspondence question; keep organization and engineered-System structures distinct.
Record as decision	An ADR or diagram exists, but selected option, relation, losses, and effectivity are unclear.	Recover the decision relation first; publish it afterward through the description and publication patterns.
Decision as actual structure	Possible-future selected content is reported as installed architecture.	Inspect the actual Systems and obtaining relations after Work; keep divergence and evidence separate.
Frozen architecture	Later integration or operation contradicts the basis, but the old record remains authoritative.	Apply the named reopen condition and supersede the smallest affected decision.
Whole-project exception	Any local refinement or residual requires centralized architecture approval.	Preserve the fixed/open boundary and escalate only changes that cross a declared structure, guardrail, or affected decision.

SYSE.6:9 - Consequences

Engineering contributors gain a current structural commitment that is strong enough to coordinate their Work and narrow enough to preserve local design knowledge. Accepted losses and unresolved residuals become visible. Realization, configuration, assurance, operation, and maintenance receive explicit questions and return conditions. The architecture can evolve through superseded decisions rather than through undocumented drift.

The cost is deliberate comparison and continuing maintenance of decision identity, descriptions, evidence, and effectivity. Some candidates remain open longer, and a preferred local solution can be rejected because it moves an unacceptable burden elsewhere. That cost is bounded by selecting only the project-shaping structures and the smallest evidence capable of changing the decision.

SYSE.6:10 - Rationale

C.32.PAD already supplies the transdisciplinary architecture decision relation. This specialization changes the Systems Engineering move: candidates must expose use, functional organization, actual or intended bearers, physical and informational interfaces, realization and integration feasibility, affected Systems, and specialist evidence. The decision turns the selected option into constraints and result conditions for realization, configuration, integration, assurance, operation, maintenance, and later checks of the actual structure.

SYSE.6:11 - SoTA and Source Use

Module boundaries and interfaces create trade-offs in architecture characteristics. Relate each choice and its accepted limitations to realization and integration, retain the reasons for the decision, and reconsider it when those relations change. The receiving project determines which characteristics and interface constraints matter.

Source line	Use here	Epistemic boundary
Ford, Parsons, Kua, and Sadalage, Building Evolutionary Architectures, 2nd ed. and Richards and Ford, Fundamentals of Software Architecture, 2nd ed., 2025	Supplies the current practitioner line for guided incremental architecture change, contextual characteristics, trade-offs, objective evaluation, and reopening.	The examples are software-centred. Their general Method is already generalized by `C.30`–`C.32`; software mechanics, team topologies, pipelines, and metric sets are not transferred as universal Systems Engineering rules.
Monetti, Lundström, and Maffei 2025, Grønvald et al. 2026, Eichenwald et al. 2024, Ghanjaoui et al. 2024, and Meixner et al. 2024	Supports early assembly and realization feedback, explicit positive and negative modularity consequences, sparse economic evidence, and return from production feasibility to architecture.	The studies are bounded manufacturing and company cases. They do not establish universal modularity savings, one product/process/resource ontology, or automatic architecture-to-Work derivation.
Demir, Chouseinoglou, and Tarhan 2024	Supports the recurrence of architecture-decision participation, information-sharing, tracking, and rationale problems.	The 101-practitioner self-report survey is software-specific and does not establish a cross-domain decision Method or causal superiority of one authority arrangement.
Lynch et al. 2025	Supports the distinction among an authorized decision, later observation, a reopen condition, and later re-evaluation.	The three natural-resource cases do not supply universal triggers, decision rights, or responses. The receiving engineering use must establish its own observations, consequences, evidence, authority, and choice.
Becker et al. 2025 with the 2026 METR update, Agarwal, He, and Vasilescu 2026, and Pradas Gomez et al. 2025	Supports AI participation in bounded software and engineering-design Work with task-dependent gains, review needs, and integration consequences.	Use the evidence for bounded, task-dependent AI contribution. Complete-process autonomy, productivity transfer, independent problem selection, authority or responsibility transfer, and architecture adequacy remain separate claims.
Current FPF `C.30`–`C.32`, especially `C.32.ACS`, `C.32.ACE`, `C.32.PAD`, `C.32.ADR`, `C.32.CONWAY`, `C.31`, and comparison, choice, evidence, Work, and architecture-description patterns	Supplies the normative ontology, general criteria/eval/candidate/decision machinery, and description boundary used directly.	This DPF uses the `C.32.PAD` schema and general evolutionary-architecture Method, then adds the engineered-System admission and result-return specialization stated in the Solution and Rationale.

Recheck an affected AI allocation or evidence claim when the tool generation, task distribution, engineering profile, or quality outcome changes.

SYSE.6:12 - Relations

SYSE.5 describes how to produce explicit allocation choices and conflicts. Practitioners using SYSE.6 recheck a compatible result’s subject, configuration, horizon, evidence, and conditions before using it as a candidate-set input; generation does not select.
A compatible SYSE.8 account can supply provider-arrangement constraints that change this architecture decision. Recheck its subject, configuration, use, horizon, evidence window, and availability. If it does not fit, use a qualified direct source or record the missing result. Keep the described offering or arrangement, provider Systems, performed Work, consequences, responsibility, and authority as distinct objects.
A compatible SYSE.7 account or SYSE.10 assessment supplies evidence only when it can change this decision at the same configuration and horizon. A compatible SYSE.9 account supplies a specialist result for its receiving question and conditions. During decision Work, a conditional SYSE.9 request names the question, subject, conditions, authority, and desired result. Evidence and specialist results inform the choice; the decision subject retains the authority to make it. If an input does not fit, use a qualified direct source or record the missing result.
C.32.PAD supplies the decision relation and the distinction among selected option, affected structures, Method and Work consequences, publication projection, and reopen conditions. C.32.ACS defines criteria rows; C.32.ACE defines eval programs and results; direct comparison and choice patterns govern their own claims.
SYSE.6 can supply selected-structure constraints and reconsideration conditions to SYSE.3, SYSE.13, and SYSE.18 when they constrain the receiving design choice. The Agent performing each receiving Work applies its Method to generate and compare that Work’s own alternatives and checks subject, configuration, horizon, and compatibility. If the decision result does not fit, use a qualified direct source or record the missing result.
Practitioners use SYSE.4 in assurance Work to qualify the engineering decision or identify the basis it still lacks. That assurance result is separate from architecture selection and from later acceptance, permission, release, and observed use success.
C.32.ADR, C.30.AD, E.17, and E.24.PUB govern decision projection, architecture description, source-backed publication, and audience availability. A current decision can exist without one particular file, and a file can persist after the decision is superseded.
Application DPFs retain subject-specific architecture Methods and safeguards for engineered-System profiles—for example, software, electrical, mechanical, civil, ship, medical, manufacturing, or human–AI engineering.