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.