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.