@rse/specbook 1.1.0 → 1.2.1

package/dst/specbook-format.yaml

@@ -9,53 +9,52 @@
 #   Modeling Purpose
 #   ----------------
 #
-#   This schema allows to specify a large variety documents for the
+#   This schema allows specifying a large variety of documents for the
 #   precise specification of solutions, systems and software.
 #
 #   Modeling Coverage
 #   -----------------
 #
-#   | "Standard" SpecBook Object        | PRD | StRS | SyRS | SRS | UIS | UISG | TCS | AD  |
-#   | --------------------------------- | --- | ---- | ---- | --- | --- | ---- | --- | --- |
-#   | META: Title                       |     |      |      |     |     |      |     |     |
-#   | --------------------------------- | --- | ---- | ---- | --- | --- | ---- | --- | --- |
-#   | REQS: Solution Vision             |  X  |  X   |      |     |     |      |     |     |
-#   | REQS: Solution Premises           |  X  |  X   |  X   |  X  |     |      |     |     |
-#   | REQS: Domain Glossary             |  X  |  X   |  X   |  X  |     |      |     |     |
-#   | REQS: User Personas               |  X  |  X   |  X   |  X  |  X  |      |     |     |
-#   | REQS: User Journey                |  X  |  X   |      |     |  X  |      |     |     |
-#   | REQS: Functional Requirements     |  X  |  X   |  X   |  X  |     |      |     |     |
-#   | REQS: Non-Functional Requirements |  X  |  X   |  X   |  X  |  X  |      |     |     |
-#   | REQS: Domain Rules                |     |  X   |  X   |  X  |     |      |     |     |
-#   | REQS: Domain Workflows            |     |  X   |  X   |  X  |     |      |     |     |
-#   | REQS: Use Cases                   |     |      |  X   |  X  |  X  |      |     |     |
-#   | --------------------------------- | --- | ---- | ---- | --- | --- | ---- | --- | --- |
-#   | DATA: Data Model                  |     |      |  X   |  X  |     |      |     |     |
-#   | DATA: State Model                 |     |      |  X   |  X  |     |      |     |     |
-#   | DATA: Authorization Model         |     |      |  X   |  X  |     |      |     |     |
-#   | --------------------------------- | --- | ---- | ---- | --- | --- | ---- | --- | --- |
-#   | APIS: Interface Model             |     |      |  X   |  X  |     |      |     |     |
-#   | APIS: Interface Datatypes         |     |      |      |  X  |     |      |     |     |
-#   | APIS: Interface Endpoints         |     |      |      |  X  |     |      |     |     |
-#   | --------------------------------- | --- | ---- | ---- | --- | --- | ---- | --- | --- |
-#   | UXUI: Interaction Concept         |     |      |      |     |  X  |  X   |     |     |
-#   | UXUI: Language Conventions        |     |      |      |     |  X  |  X   |     |     |
-#   | UXUI: Dialog Patterns             |     |      |      |     |  X  |  X   |     |     |
-#   | UXUI: Dialog Storyboard           |     |      |      |     |  X  |      |     |     |
-#   | UXUI: Visual Design               |     |      |      |     |  X  |  X   |     |     |
-#   | --------------------------------- | --- | ---- | ---- | --- | --- | ---- | --- | --- |
-#   | TEST: Test Cases                  |     |      |      |     |     |      |  X  |     |
-#   | --------------------------------- | --- | ---- | ---- | --- | --- | ---- | --- | --- |
-#   | ARCH: Context View                |     |      |      |     |     |      |     |  X  |
-#   | ARCH: Functionality View          |     |      |      |     |     |      |     |  X  |
-#   | ARCH: Information View            |     |      |      |     |     |      |     |  X  |
-#   | ARCH: Concurrency View            |     |      |      |     |     |      |     |  X  |
-#   | ARCH: Development View            |     |      |      |     |     |      |     |  X  |
-#   | ARCH: Deployment View             |     |      |      |     |     |      |     |  X  |
-#   | ARCH: Operations View             |     |      |      |     |     |      |     |  X  |
-#   | ARCH: Quality Perspectives        |     |      |      |     |     |      |     |  X  |
-#   | ARCH: Decision Record             |     |      |      |     |     |      |     |  X  |
-#   | ARCH: Technology Stack            |     |      |      |     |     |      |     |  X  |
+#   | "Standard" SpecBook Object             | PRD | StRS | SyRS | SRS | UIS | UISG | TCS | AD  |
+#   | -------------------------------------- | --- | ---- | ---- | --- | --- | ---- | --- | --- |
+#   | META: Title (TI)                       |     |      |      |     |     |      |     |     |
+#   | -------------------------------------- | --- | ---- | ---- | --- | --- | ---- | --- | --- |
+#   | REQS: Solution Vision (SV)             |  X  |  X   |      |     |     |      |     |     |
+#   | REQS: Solution Premises (SP)           |  X  |  X   |  X   |  X  |     |      |     |     |
+#   | REQS: Domain Glossary (DG)             |  X  |  X   |  X   |  X  |     |      |     |     |
+#   | REQS: User Personas (UP)               |  X  |  X   |  X   |  X  |  X  |      |     |     |
+#   | REQS: User Journey (UJ)                |  X  |  X   |      |     |  X  |      |     |     |
+#   | REQS: Functional Requirements (FR)     |  X  |  X   |  X   |  X  |     |      |     |     |
+#   | REQS: Non-Functional Requirements (NR) |  X  |  X   |  X   |  X  |  X  |      |     |     |
+#   | REQS: Domain Rules (DR)                |     |  X   |  X   |  X  |     |      |     |     |
+#   | REQS: Domain Workflows (DW)            |     |  X   |  X   |  X  |     |      |     |     |
+#   | REQS: Use Cases (UC)                   |     |      |  X   |  X  |  X  |      |     |     |
+#   | -------------------------------------- | --- | ---- | ---- | --- | --- | ---- | --- | --- |
+#   | DATA: Data Model (DM)                  |     |      |  X   |  X  |     |      |     |     |
+#   | DATA: State Model (SM)                 |     |      |  X   |  X  |     |      |     |     |
+#   | DATA: Authorization Model (AM)         |     |      |  X   |  X  |     |      |     |     |
+#   | -------------------------------------- | --- | ---- | ---- | --- | --- | ---- | --- | --- |
+#   | APIS: Interface Model (IM)             |     |      |  X   |  X  |     |      |     |     |
+#   | APIS: Interface Datatypes (ID)         |     |      |      |  X  |     |      |     |     |
+#   | APIS: Interface Endpoints (IE)         |     |      |      |  X  |     |      |     |     |
+#   | -------------------------------------- | --- | ---- | ---- | --- | --- | ---- | --- | --- |
+#   | UXUI: Interaction Concept (IC)         |     |      |      |     |  X  |  X   |     |     |
+#   | UXUI: Language Conventions (LC)        |     |      |      |     |  X  |  X   |     |     |
+#   | UXUI: Dialog Patterns (DP)             |     |      |      |     |  X  |  X   |     |     |
+#   | UXUI: Dialog Storyboard (DS)           |     |      |      |     |  X  |      |     |     |
+#   | UXUI: Visual Design (VD)               |     |      |      |     |  X  |  X   |     |     |
+#   | -------------------------------------- | --- | ---- | ---- | --- | --- | ---- | --- | --- |
+#   | ARCH: Context View (CV)                |     |      |      |     |     |      |     |  X  |
+#   | ARCH: Functionality View (FV)          |     |      |      |     |     |      |     |  X  |
+#   | ARCH: Technology Stack (TS)            |     |      |      |     |     |      |     |  X  |
+#   | ARCH: Development Aspects (DA)         |     |      |      |     |     |      |     |  X  |
+#   | ARCH: Concurrency View (CO)            |     |      |      |     |     |      |     |  X  |
+#   | ARCH: Deployment View (DV)             |     |      |      |     |     |      |     |  X  |
+#   | ARCH: Operations View (OV)             |     |      |      |     |     |      |     |  X  |
+#   | ARCH: Quality Perspectives (QP)        |     |      |      |     |     |      |     |  X  |
+#   | ARCH: Design Decisions (DD)            |     |      |      |     |     |      |     |  X  |
+#   | -------------------------------------- | --- | ---- | ---- | --- | --- | ---- | --- | --- |
+#   | TEST: Test Cases (TC)                  |     |      |      |     |     |      |  X  |     |
 #
 #   Legend:
 #   -   PRD:  Product Requirements Document                      (Cagan 2005)
@@ -67,21 +66,30 @@
 #   -   TCS:  Test Case Specification                            (ISO/IEC/IEEE 29119-3:2021)
 #   -   AD:   Architecture Description                           (ISO/IEC/IEEE 42010)
 #
-#   Design Decisions
-#   ----------------
+#   Modeling Decisions
+#   ------------------
+#
+# -     All artifacts have a unique 2-word name (e.g. "Context View") and a
+#       corresponding unique 2-letter identifier.
 #
 #   -   All object references are strictly back-references, i.e., later
-#       objects reference earlier ones.
+#       objects reference earlier ones. Only the "referenced" coverage
+#       constraints and the diagram node sets (e.g. the inputs of a "hub"
+#       diagram) name later objects.
 #
 #   -   The depth of the modeling aspects is at maximum at level 3, which
 #       means that all objects stay at level 1 and 2 and level 3 is mainly
 #       for properties. This leads to decent headings and a not too deep
 #       Table of Contents.
 #
+#   -   All artifacts are optional, so that the schema can back not only
+#       a full specification but also the individual document types of
+#       the modeling coverage matrix above on their own.
+#
 #   -   The traditional hard Software Requirements Specification (SRS)
 #       vs. Architecture Description (AD) document split is
 #       intentionally smoothed, so we can link from AD to SRS objects
-#       and in AI-times (where no longer dedicated teams write
+#       and in AI-times (where dedicated teams no longer write
 #       those documents separately) the AI should see one coherent
 #       specification document, too.
 #
@@ -93,9 +101,10 @@
     desc: >
         The top-level specification meta information.
         Some of the information is rendered onto the title page.
+    optional: true
     diagram:
         type: graph
-        nodes: "[[REQS:*]], [[DATA:*]], [[APIS:*]], [[UXUI:*]], [[TEST:*]], [[ARCH:*]]"
+        nodes: "[[REQS:*]], [[DATA:*]], [[APIS:*]], [[UXUI:*]], [[ARCH:*]], [[TEST:*]]"
         deep: true
         qualified: true
     props:
@@ -146,6 +155,7 @@
         desired future state it aims to achieve. Every vision aspect is
         stated in a concise (1-3 sentence) paragraph in an aspirational
         but unambiguous tone.
+    optional: true
     refs: >
         -   ISO/IEC/IEEE 29148:2018: Systems and software engineering -- Life cycle processes -- Requirements engineering (2018),
             https://www.iso.org/standard/72089.html
@@ -201,6 +211,7 @@
         resting on a premise are known and revisited once it turns out to be false. The
         artifact complements the Solution Vision: the vision states what the solution aims
         for, the premises state what it takes as given on the way there.
+    optional: true
     refs: >
         -   ISO/IEC/IEEE 29148:2018: Systems and software engineering -- Life cycle processes -- Requirements engineering (2018),
             https://www.iso.org/standard/72089.html
@@ -248,21 +259,6 @@
                         behave as agreed), or `Risk` (an uncertain event which, if it occurs,
                         harms the achievement of the vision).
                     value: enum(Assumption,Dependency,Risk)
-                -   name: TERMS
-                    desc: >
-                        Comma-separated references to the GLOSSARY terms the premise is about
-                        (e.g. the external system a dependency relies on), anchoring it in the
-                        ubiquitous language.
-                    value: list([[REQS:GL.TERM:*]])
-                    optional: true
-                -   name: OWNER
-                    desc: >
-                        Reference to the User Personas object (usually a `Stakeholder`) who
-                        vouches for the premise, i.e. who confirms an assumption, holds the
-                        agreement of a dependency, or owns the mitigation of a risk, omitted when
-                        nobody in particular is accountable.
-                    value: "[[REQS:UP.PERSONA:*]]"
-                    optional: true
                 -   name: LIKELIHOOD
                     desc: >
                         The likelihood that the premise fails, i.e. that the assumption turns out
@@ -286,22 +282,16 @@
                         detect it early (e.g. a fallback, a contract, a load test), omitted for
                         a premise whose failure is knowingly accepted.
                     optional: true
-                -   name: AFFECTS
-                    desc: >
-                        Comma-separated references to the FUNCTIONAL-REQUIREMENTS,
-                        NON-FUNCTIONAL-REQUIREMENTS, or DOMAIN-RULES objects resting on the
-                        premise, i.e. those to be revisited once it fails.
-                    value: list([[REQS:FR.*]], [[REQS:NR.*]], [[REQS:DR.RULE:*]])
-                    optional: true
 
 -   kind: REQS
     name: Domain Glossary
-    id: GL
-    file: 03-REQS-GL-Domain-Glossary.md
+    id: DG
+    file: 03-REQS-DG-Domain-Glossary.md
     desc: >
         The ubiquitous language of the domain, defining the meaning of each domain term in business
         language, together with its synonyms, its place in the hierarchy of terms, and the terms it
         has to be kept apart from, shared consistently across all Artifacts.
+    optional: true
     refs: >
         -   ISO 704:2022: Terminology work -- Principles and methods (2022),
             https://www.iso.org/standard/79077.html
@@ -311,7 +301,7 @@
             https://www.domainlanguage.com/ddd/
     diagram:
         type: grid
-        nodes: "[[REQS:GL.TERM:*]]"
+        nodes: "[[REQS:DG.TERM:*]]"
         properties:
             -   TYPE
         config:
@@ -337,7 +327,8 @@
             diagram:
                 type: hub
                 center: self
-                nodes: "[[REQS:GL.TERM:*]], [[REQS:DR.RULE:*]], [[DATA:DM.ENTITY:*]], [[REQS:UP.PERSONA:*]]"
+                nodes: "[[REQS:DG.TERM:*]], [[REQS:SP.PREMISE:*]], [[REQS:DR.RULE:*]], [[DATA:DM.ENTITY:*]],
+                    [[REQS:UP.PERSONA:*]]"
                 labeled: true
                 qualified: true
                 config:
@@ -364,7 +355,7 @@
                         that the terms form a hierarchy in which a rule governing the broader term
                         covers the narrower ones, too; at most one broader term, keeping the
                         hierarchy a tree.
-                    value: "[[REQS:GL.TERM:*]]"
+                    value: "[[REQS:DG.TERM:*]]"
                     optional: true
                     acyclic: true
                 -   name: DISTINCT-FROM
@@ -372,9 +363,17 @@
                         Comma-separated references to the GLOSSARY terms easily confused with this
                         one but deliberately *not* synonymous, listed on both terms of each pair,
                         with the distinction stated in the definitions.
-                    value: list([[REQS:GL.TERM:*]])
+                    value: list([[REQS:DG.TERM:*]])
                     optional: true
                     symmetric: true
+                -   name: PREMISES
+                    desc: >
+                        Comma-separated references to the SOLUTION-PREMISES objects about the
+                        term, i.e. the assumptions, dependencies, and risks concerning the thing
+                        or party it denotes (e.g. the dependency on the external system an
+                        `Actor` term names), anchoring every premise in the ubiquitous language.
+                    value: list([[REQS:SP.PREMISE:*]])
+                    optional: true
 
 -   kind: REQS
     name: User Personas
@@ -384,6 +383,7 @@
         The *archetypal* user profiles representing distinct user groups, capturing their goals,
         needs, behaviors, and context, complemented by the non-user stakeholders whose interests
         the solution has to serve.
+    optional: true
     refs: >
         -   Cooper: The Inmates Are Running the Asylum, 2nd ed. (2004),
             https://www.informit.com/store/inmates-are-running-the-asylum-why-high-tech-products-9780672326141
@@ -391,6 +391,15 @@
             https://www.wiley.com/en-gb/About+Face:+The+Essentials+of+Interaction+Design,+4th+Edition-p-9781118766576
         -   Pruitt/Adlin: The Persona Lifecycle: Keeping People in Mind Throughout Product Design (2006),
             https://www.sciencedirect.com/book/9780125662512/the-persona-lifecycle
+    diagram:
+        type: grid
+        nodes: "[[REQS:UP.PERSONA:*]]"
+        properties:
+            -   TYPE
+            -   ROLE
+        config:
+            size-node-width-max: 440
+            grid-columns-max: 4
     childs:
         -   kind: PERSONA
             desc: >
@@ -433,7 +442,7 @@
                         Comma-separated references to the GLOSSARY terms the persona embodies, i.e.
                         the domain roles it acts in and the domain concepts it primarily deals
                         with, so that every persona is anchored in the ubiquitous language.
-                    value: list([[REQS:GL.TERM:*]])
+                    value: list([[REQS:DG.TERM:*]])
                     optional: true
                 -   name: PROFICIENCY
                     desc: >
@@ -451,6 +460,14 @@
                         independently of the per-step pain points of the User Journey, which
                         record the friction within the target journey instead.
                     optional: true
+                -   name: PREMISES
+                    desc: >
+                        Comma-separated references to the SOLUTION-PREMISES objects the persona
+                        (usually a `Stakeholder`) vouches for, i.e. whose assumption it confirms,
+                        whose dependency agreement it holds, or whose risk mitigation it owns;
+                        omitted when the persona is accountable for no premise.
+                    value: list([[REQS:SP.PREMISE:*]])
+                    optional: true
 
 -   kind: REQS
     name: User Journey
@@ -461,6 +478,7 @@
         mapping their steps, touchpoints, and emotions over time. The journey is the *target*
         journey with the solution in place, so the friction it records is what the solution has
         to mitigate, not the status quo it replaces.
+    optional: true
     refs: >
         -   NN/g: Journey Mapping 101 (2018),
             https://www.nngroup.com/articles/journey-mapping-101/
@@ -536,6 +554,7 @@
         The concrete behaviors and capabilities the solution must provide, describing *what* the
         system does in terms of functions, features, and operations, while the quality bounds and
         constraints on them belong to the Non-Functional Requirements.
+    optional: true
     refs: >
         -   Mavin et al.: Easy Approach to Requirements Syntax (EARS) (2009),
             https://ieeexplore.ieee.org/document/5328509
@@ -577,6 +596,13 @@
                         time"), preserving the conscious decision rather than silently dropping it,
                         with the statement still phrased as it would be if in scope.
                     value: enum(MUST,SHOULD,COULD,WONT)
+                -   name: PREMISES
+                    desc: >
+                        Comma-separated references to the SOLUTION-PREMISES objects the
+                        requirement rests on, i.e. the assumptions, dependencies, and risks whose
+                        failure calls for revisiting it.
+                    value: list([[REQS:SP.PREMISE:*]])
+                    optional: true
 
 -   kind: REQS
     name: Non-Functional Requirements
@@ -585,6 +611,7 @@
     desc: >
         The quality attributes and constraints the solution must satisfy, such as performance,
         security, scalability, reliability, and usability.
+    optional: true
     refs: >
         -   ISO/IEC 25010:2023: Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- Product quality model (2023),
             https://www.iso.org/standard/78176.html
@@ -638,6 +665,13 @@
                         capability the requirement bounds or constrains.
                     value: list([[REQS:FR.*]])
                     optional: true
+                -   name: PREMISES
+                    desc: >
+                        Comma-separated references to the SOLUTION-PREMISES objects the
+                        requirement rests on, i.e. the assumptions, dependencies, and risks whose
+                        failure calls for revisiting it.
+                    value: list([[REQS:SP.PREMISE:*]])
+                    optional: true
                 -   name: METRIC
                     desc: >
                         The threshold or target by which the requirement is judged satisfied,
@@ -653,6 +687,7 @@
         The domain invariants, policies, and decision logic that must always hold true in the
         problem domain, independent of any single feature, constraining the Functional and
         Non-Functional Requirements.
+    optional: true
     refs: >
         -   Hay/Healy: Defining Business Rules ~ What Are They Really? (2000),
             https://www.businessrulesgroup.org/first_paper/br01c0.htm
@@ -728,7 +763,7 @@
                         Comma-separated references to the GLOSSARY terms the rule governs, i.e.
                         the domain terms its statement is about, so that every rule is anchored in
                         the ubiquitous language and every term shows the rules that hold for it.
-                    value: list([[REQS:GL.TERM:*]])
+                    value: list([[REQS:DG.TERM:*]])
                     optional: true
                 -   name: CONSTRAINS
                     desc: >
@@ -736,6 +771,13 @@
                         NON-FUNCTIONAL-REQUIREMENTS objects the rule constrains.
                     value: list([[REQS:FR.*]], [[REQS:NR.*]])
                     optional: true
+                -   name: PREMISES
+                    desc: >
+                        Comma-separated references to the SOLUTION-PREMISES objects the rule
+                        rests on, i.e. the assumptions, dependencies, and risks whose failure
+                        calls for revisiting it.
+                    value: list([[REQS:SP.PREMISE:*]])
+                    optional: true
 
 -   kind: REQS
     name: Domain Workflows
@@ -831,7 +873,7 @@
                     desc: >
                         Comma-separated references to the GLOSSARY terms of type `Activity` the
                         workflow realizes, anchoring it in the ubiquitous language.
-                    value: list([[REQS:GL.TERM:*]])
+                    value: list([[REQS:DG.TERM:*]])
                     optional: true
                 -   name: RULES
                     desc: >
@@ -919,6 +961,7 @@
         The discrete goals users pursue with the solution, each describing an actor's interaction to
         achieve a specific outcome, together with the concrete step-by-step flows for main,
         alternative, and exceptional paths.
+    optional: true
     refs: >
         -   Cockburn: Writing Effective Use Cases (2001),
             https://www.informit.com/store/writing-effective-use-cases-9780201702255
@@ -990,14 +1033,6 @@
                         (e.g. an access rule in an authentication step).
                     value: list([[REQS:DR.RULE:*]])
                     optional: true
-                -   name: TRANSITIONS
-                    desc: >
-                        Comma-separated references to the STATE-MODEL transition objects the
-                        scenarios of the use case trigger, i.e. whose state change a scenario
-                        step causes, so that every transition is exercised by at least one use
-                        case or test case.
-                    value: list([[DATA:SM.LIFECYCLE:*.TRANSITION:*]])
-                    optional: true
                 -   name: INCLUDES
                     desc: >
                         Comma-separated references to the other USE-CASES objects this use case
@@ -1079,6 +1114,7 @@
     desc: >
         The structure of named entities, with named attributes and directed relationships, of the
         data the solution manages, defining how information is organized and connected.
+    optional: true
     refs: >
         -   Chen: The Entity-Relationship Model -- Toward a Unified View of Data (1976),
             https://dl.acm.org/doi/10.1145/320434.320440
@@ -1115,7 +1151,7 @@
                         Comma-separated references to the GLOSSARY terms the entity materializes,
                         i.e. the domain terms whose information it carries, so that every entity
                         is anchored in the ubiquitous language and every term shows its data.
-                    value: list([[REQS:GL.TERM:*]])
+                    value: list([[REQS:DG.TERM:*]])
                     optional: true
             childs:
                 -   kind: ATTRIBUTE
@@ -1214,6 +1250,7 @@
         For each entity with a non-trivial lifecycle, the legal states it can occupy and the
         permitted transitions between them over its lifetime, making the forbidden moves as explicit
         as the allowed ones.
+    optional: true
     refs: >
         -   Shlaer/Mellor: Object Lifecycles: Modeling the World in States (1992)
         -   Harel: Statecharts: A Visual Formalism for Complex Systems (1987),
@@ -1308,9 +1345,6 @@
                         arrive at the very state it departs from (an internal transition, e.g.
                         `edit` on `Draft`). Any move not listed as a transition is implicitly
                         forbidden.
-                    referenced:
-                        -   "[[REQS:UC.USE-CASE:*]]"
-                        -   "[[TEST:TC.TEST-CASE:*]]"
                     props:
                         -   name: FROM
                             desc: The state (of the same lifecycle) the transition departs from.
@@ -1341,6 +1375,15 @@
                                 transition enforces, usually through its `GUARD`.
                             value: list([[REQS:DR.RULE:*]])
                             optional: true
+                        -   name: USE-CASES
+                            desc: >
+                                Comma-separated references to the USE-CASES objects whose
+                                scenarios trigger the transition, i.e. in which a scenario step
+                                causes the state change, tracing the transition into the use
+                                cases exercising it; omitted for a transition no use case
+                                triggers (e.g. one triggered by `Time` or by the system alone).
+                            value: list([[REQS:UC.USE-CASE:*]])
+                            optional: true
 
 -   kind: DATA
     name: Authorization Model
@@ -1354,6 +1397,7 @@
         actors of the state transitions, the actors of the use cases, and the prose of the domain
         rules. The model is closed: an operation not granted to a role is forbidden, exactly like
         a move not listed as a state transition.
+    optional: true
     refs: >
         -   Ferraiolo/Kuhn: Role-Based Access Controls, 15th National Computer Security Conference (1992),
             https://csrc.nist.gov/publications/detail/conference-paper/1992/10/13/role-based-access-controls
@@ -1372,6 +1416,7 @@
         qualified: true
         config:
             size-node-width-max: 440
+            graph-channel-width-max: 340
     childs:
         -   kind: ROLE
             desc: >
@@ -1386,7 +1431,7 @@
                 type: hub
                 center: self
                 deep: true
-                nodes: "[[DATA:AM.ROLE:*]], [[REQS:UP.PERSONA:*]], [[REQS:GL.TERM:*]], [[DATA:DM.ENTITY:*]],
+                nodes: "[[DATA:AM.ROLE:*]], [[REQS:UP.PERSONA:*]], [[REQS:DG.TERM:*]], [[DATA:DM.ENTITY:*]],
                     [[REQS:DR.RULE:*]]"
                 labeled: true
                 qualified: true
@@ -1403,12 +1448,12 @@
                         `Actor` denoting the external systems holding the role (e.g. a registration
                         system calling the machine-facing interface), as an external system is no
                         persona.
-                    value: list([[REQS:UP.PERSONA:*]], [[REQS:GL.TERM:*]])
+                    value: list([[REQS:UP.PERSONA:*]], [[REQS:DG.TERM:*]])
                 -   name: TERM
                     desc: >
                         Reference to the GLOSSARY term of type `Actor` the role grants, anchoring
                         the role in the ubiquitous language.
-                    value: "[[REQS:GL.TERM:*]]"
+                    value: "[[REQS:DG.TERM:*]]"
                     optional: true
                 -   name: INHERITS
                     desc: >
@@ -1583,6 +1628,7 @@
         nodes: "[[APIS:ID.TYPE:*]]"
         deep: true
         onlyConnected: true
+        labeled: true
         qualified: true
         config:
             size-node-width-max: 440
@@ -1745,6 +1791,7 @@
         nodes: "[[APIS:IE.ENDPOINT:*]], [[APIS:ID.TYPE:*]]"
         deep: true
         onlyConnected: true
+        labeled: true
         qualified: true
         config:
             size-node-width-max: 440
@@ -2003,6 +2050,15 @@
                 quality bound is a Non-Functional Requirement instead).
             referenced:
                 -   "[[UXUI:DP.PATTERN:*]]"
+            diagram:
+                type: hub
+                center: self
+                nodes: "[[UXUI:IC.PRINCIPLE:*]], [[REQS:UP.PERSONA:*]], [[REQS:UJ.JOURNEY:*.STEP:*]],
+                    [[UXUI:DP.PATTERN:*]]"
+                labeled: true
+                qualified: true
+                config:
+                    size-node-width-max: 440
             props:
                 -   name: CATEGORY
                     desc: >
@@ -2043,7 +2099,7 @@
         Concept states how it behaves, the Language Conventions how it talks, and the Visual Design
         how it looks. Domain terms are *defined* in the Domain Glossary and only *surfaced* here,
         while the conventions of the specification text itself and of code identifiers are out of
-        scope (they belong to the Development View).
+        scope (they belong to the Development Aspects).
     refs: >
         -   Podmajersky: Strategic Writing for UX (2019),
             https://www.oreilly.com/library/view/strategic-writing-for/9781492049388/
@@ -2102,7 +2158,7 @@
                         Comma-separated references to the GLOSSARY terms whose surfacing in the
                         user-facing text the convention governs, so that the Domain Glossary defines
                         the term and the convention states how it is written.
-                    value: list([[REQS:GL.TERM:*]])
+                    value: list([[REQS:DG.TERM:*]])
                     optional: true
                 -   name: EXAMPLE
                     desc: >
@@ -2151,6 +2207,7 @@
                 center: self
                 nodes: "[[UXUI:DP.PATTERN:*]], [[UXUI:IC.PRINCIPLE:*]], [[UXUI:DS.STORYBOARD:*]]"
                 deep: true
+                labeled: true
                 qualified: true
                 config:
                     size-node-width-max: 440
@@ -2232,7 +2289,7 @@
             desc: >
                 A single depicted dialog flow, named with a short (3-8 word) summary of the flow and
                 comprised of frames in sequence. A storyboard shows the concrete user interface of
-                one flow, as seen by its actors (the intent and the information exchanged is a Use
+                one flow, as seen by its actors (the intent and the information exchanged are a Use
                 Cases scenario instead, and a structure recurring across flows is a Dialog Pattern
                 instead).
             diagram:
@@ -2241,6 +2298,7 @@
                 nodes: "[[UXUI:DS.STORYBOARD:*]], [[REQS:UP.PERSONA:*]],
                     [[REQS:UC.USE-CASE:*.SCENARIO:*]], [[UXUI:DP.PATTERN:*]]"
                 deep: true
+                labeled: true
                 qualified: true
                 config:
                     size-node-width-max: 440
@@ -2352,6 +2410,7 @@
                 type: hub
                 center: self
                 nodes: "[[UXUI:VD.ELEMENT:*]], [[REQS:UP.PERSONA:*]], [[UXUI:IC.PRINCIPLE:*]], [[UXUI:VD.MOCKUP:*]]"
+                labeled: true
                 qualified: true
                 config:
                     size-node-width-max: 440
@@ -2429,135 +2488,16 @@
                         the design tool or a screenshot of an already existing user interface, so
                         that the look is seen rather than only read.
 
--   kind: TEST
-    name: Test Cases
-    id: TC
-    file: 22-TEST-TC-Test-Cases.md
-    desc: >
-        The verifiable conditions and steps used to confirm that requirements, domain rules, use
-        case scenarios, and state transitions are correctly implemented, with mandatory defined
-        inputs, mandatory expected outcomes, and optional pre- and post-conditions.
-
-        Test cases are not derived from use cases alone: a use case scenario describes an intent-level
-        flow, while a test case fixes the concrete data and the observable assertions that decide pass
-        or fail, and many test cases (e.g. of Non-Functional Requirements or of cross-session rules)
-        have no use case counterpart at all.
-    refs: >
-        -   ISO/IEC/IEEE 29119-3:2021: Software and systems engineering -- Software testing -- Part 3: Test documentation (2021),
-            https://www.iso.org/standard/79429.html
-        -   ISO/IEC/IEEE 29119-4:2021: Software and systems engineering -- Software testing -- Part 4: Test techniques (2021),
-            https://www.iso.org/standard/79430.html
-        -   ISTQB CTFL 4.0: Certified Tester Foundation Level Syllabus (2023),
-            https://istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/
-    diagram:
-        type: grid
-        nodes: "[[TEST:TC.TEST-CASE:*]]"
-        config:
-            size-node-width-max: 440
-            size-node-height-scale: 2
-            grid-columns-max: 4
-    childs:
-        -   kind: TEST-CASE
-            desc: >
-                A single verifiable test case, named with a short (3-8 word) summary and defined by
-                its mandatory input and expected outcome plus its optional pre- and post-conditions.
-
-                The test case is at verification level: it pins down what the objects it verifies
-                leave open, namely concrete data (e.g. `the correct six-digit token`), a boundary
-                or equivalence class (e.g. `one more question within the same minute`), and an
-                observable assertion, including the negative one (e.g. `the rejected question is
-                not stored and the earlier questions remain unchanged`).
-
-                A test case which merely rephrases a scenario in different words, adding none of these,
-                is redundant and should be sharpened or dropped. Conversely, one scenario can require
-                several test cases (one per boundary or equivalence class), and one test case can
-                verify a requirement, a rule, and a scenario at once.
-
-                A test case whose stimulus is a sequence rather than a single action carries the
-                procedure in its body as sequentially numbered, imperative steps, mirroring the
-                steps of a use case scenario (e.g. `1. The user logs in on device A. 2. The same
-                user logs in on device B.`), with `INPUT` naming the decisive stimulus among them.
-            diagram:
-                type: hub
-                center: self
-                nodes: "[[TEST:TC.TEST-CASE:*]], [[REQS:FR.REQUIREMENT:*]], [[REQS:NR.REQUIREMENT:*]],
-                    [[REQS:DR.RULE:*]], [[REQS:UC.USE-CASE:*.SCENARIO:*]], [[REQS:DW.WORKFLOW:*]],
-                    [[DATA:SM.LIFECYCLE:*.TRANSITION:*]], [[DATA:DM.ENTITY:*.ATTRIBUTE:*]],
-                    [[DATA:AM.ROLE:*.PERMISSION:*]], [[APIS:IE.ENDPOINT:*]],
-                    [[UXUI:DS.STORYBOARD:*.FRAME:*]]"
-                labeled: true
-                qualified: true
-                config:
-                    size-node-width-max: 440
-                    size-node-height-scale: 1.75
-            props:
-                -   name: VERIFIES
-                    desc: >
-                        Comma-separated references to the FUNCTIONAL-REQUIREMENTS or
-                        NON-FUNCTIONAL-REQUIREMENTS objects, the DOMAIN-RULES objects, the
-                        USE-CASES scenario objects, the STATE-MODEL transition objects, the
-                        DATA-MODEL attribute objects, the AUTHORIZATION-MODEL permission objects,
-                        the INTERFACE-ENDPOINTS objects, and/or the DIALOG-STORYBOARD frame objects
-                        the test case verifies, so that a scenario (in particular an `Exceptional`
-                        one, judged by its `OUTCOME`) is covered by an acceptance test beside the
-                        requirements it exercises, a rule (judged by the condition it states) is
-                        proven to hold, not just to be documented, a transition (judged by its
-                        `GUARD` and the resulting state) is proven to be permitted exactly as
-                        modeled, an attribute (judged by its `TYPE` and `CONSTRAINT`) is proven to
-                        reject the values outside its range, pattern, or invariant, a permission
-                        (judged by the operations it grants and, the model being closed, by the
-                        ones it denies) is proven to be enforced, an endpoint (judged by its
-                        arguments, options, and results) is proven to honor its contract, and a
-                        frame (judged by the dialog step it storyboards) is proven to be reachable
-                        and to behave as storyboarded.
-                    value: list([[REQS:*.REQUIREMENT:*]], [[REQS:DR.RULE:*]], [[REQS:UC.USE-CASE:*.SCENARIO:*]],
-                        [[DATA:SM.LIFECYCLE:*.TRANSITION:*]], [[DATA:DM.ENTITY:*.ATTRIBUTE:*]],
-                        [[DATA:AM.ROLE:*.PERMISSION:*]], [[APIS:IE.ENDPOINT:*]],
-                        [[UXUI:DS.STORYBOARD:*.FRAME:*]])
-                -   name: WORKFLOWS
-                    desc: >
-                        Comma-separated references to the DOMAIN-WORKFLOWS objects the test case
-                        walks through end to end, i.e. whose activities and handoffs its procedure
-                        steps cross in order, so that the collaboration across actors and sittings
-                        (not just the use cases of each single sitting) is proven to work as
-                        modeled; omitted for a test case confined to a single sitting.
-                    value: list([[REQS:DW.WORKFLOW:*]])
-                    optional: true
-                -   name: PRE-CONDITION
-                    desc: >
-                        The state or setup that must hold before the test is executed.
-                    optional: true
-                -   name: INPUT
-                    desc: >
-                        The mandatory, concrete input data or action applied during the test, i.e.
-                        the stimulus whose response the `EXPECTED` judges.
-                -   name: EXPECTED
-                    desc: >
-                        The mandatory, concrete, observable response of the solution to the `INPUT`
-                        (a message shown, a session issued, a submission rejected) that defines a
-                        passing test, as opposed to the `POST-CONDITION` which is the state left
-                        behind. When the test case verifies a NON-FUNCTIONAL-REQUIREMENTS object,
-                        the expected response restates the `METRIC` threshold of that requirement
-                        as the pass criterion (e.g. `p95 latency < 200 ms`) rather than a
-                        qualitative phrase (e.g. `remains responsive`).
-                -   name: POST-CONDITION
-                    desc: >
-                        The persisted state that must hold after the test completes (e.g. `the
-                        authorization token is in state used`), including the state that must not
-                        have changed (e.g. `no session token exists`), as opposed to the `EXPECTED`
-                        which is the immediate response, and omitted for a test whose input leaves
-                        no state behind.
-                    optional: true
-
 -   kind: ARCH
     name: Context View
     id: CV
-    file: 23-ARCH-CV-Context-View.md
+    file: 22-ARCH-CV-Context-View.md
     desc: >
         The relationships, dependencies, and interactions between the solution and its environment,
         defining the system's boundary by enumerating the external entities sitting at it. The
         artifact complements the Solution Vision: its `SCOPE` states what is deliberately *out* of
         the solution, the Context View enumerates what the solution touches *at* the boundary.
+    optional: true
     refs: >
         -   Rozanski/Woods: Software Systems Architecture, 2nd ed.: The Context Viewpoint (2011),
             https://www.viewpoints-and-perspectives.info/home/viewpoints/context/
@@ -2584,8 +2524,8 @@
         -   kind: ENTITY
             desc: >
                 A single external entity the solution interacts with, named with a short (2-5 word)
-                summary (e.g. `Payment Gateway`, `Identity Provider`, `End User`) and described in a
-                concise (1-3 sentence) paragraph by the relationship and dependency between the
+                summary (e.g. `Payment Gateway`, `Identity Provider`, `End User`) and described in
+                a concise (1-3 sentence) paragraph by the relationship and dependency between the
                 solution and the entity, plus a 1-sentence rationale ("why") for the entity being
                 part of the system context.
 
@@ -2593,8 +2533,8 @@
                 boundary: a party with a mere interest in the solution but no such exchange is a
                 `Stakeholder` persona of the User Personas instead, and a platform element the
                 solution deploys and operates itself (e.g. a managed database of its own) is a
-                Deployment View node instead -- only a party or system the solution merely
-                consumes or serves belongs to the system context.
+                Deployment View node instead -- only a party or system the solution merely consumes
+                or serves belongs to the system context.
             format:
                 maxTableColumns: 5
             props:
@@ -2623,7 +2563,7 @@
                         the domain (usually a term of type `Actor`, which covers an external system
                         as a party acting in the domain), anchoring every boundary entity in the
                         ubiquitous language.
-                    value: list([[REQS:GL.TERM:*]])
+                    value: list([[REQS:DG.TERM:*]])
                     optional: true
                 -   name: INTERFACE
                     desc: >
@@ -2660,10 +2600,12 @@
 -   kind: ARCH
     name: Functionality View
     id: FV
-    file: 24-ARCH-FV-Functionality-View.md
+    file: 23-ARCH-FV-Functionality-View.md
     desc: >
         The functional components of the solution, their responsibilities, interfaces, and primary
-        interactions, describing *what* the system does at runtime.
+        interactions, describing *how* the solution's runtime elements are structured and which
+        responsibility each owns, delivering the behaviors the Functional Requirements state.
+    optional: true
     refs: >
         -   Rozanski/Woods: Software Systems Architecture, 2nd ed.: The Functional Viewpoint (2011),
             https://www.viewpoints-and-perspectives.info/home/viewpoints/functional/
@@ -2674,6 +2616,7 @@
     diagram:
         type: graph
         nodes: "[[ARCH:FV.COMPONENT:*]]"
+        labeled: true
         properties:
             -   KIND
     childs:
@@ -2681,35 +2624,63 @@
             desc: >
                 A single functional component, named with a short (2-5 word) summary (e.g.
                 `Authentication Service`, `Order Processor`, `Notification Dispatcher`) and
-                described in a concise (1-3 sentence) paragraph by *what* it does and how it
-                collaborates with the components it depends on, plus a 1-sentence rationale ("why")
-                for the component's existence and boundary.
+                described in a concise (1-3 sentence) paragraph whose first sentence names the
+                single, primary responsibility the component owns (split into several components
+                otherwise) and which elaborates how the component fulfills it and collaborates
+                with the components it depends on, plus a 1-sentence rationale ("why") for the
+                component's existence and boundary.
             format:
                 maxTableColumns: 5
             diagram:
                 type: hub
                 center: self
-                nodes: "[[ARCH:FV.COMPONENT:*]]"
+                nodes: "[[ARCH:FV.COMPONENT:*]], [[REQS:FR.REQUIREMENT:*]], [[APIS:IM.INTERFACE:*]],
+                    [[DATA:DM.ENTITY:*]]"
+                labeled: true
+                qualified: true
                 properties:
                     -   KIND
                 config:
-                    size-node-width-max: 440
+                    size-node-width-max:    440
+                    size-node-height-scale: 1.75
             props:
                 -   name: KIND
                     desc: |
                         The kind of the functional component, one of:
                         -   `Component`: Cohesive unit of functionality with a defined interface.
-                        -   `Service`:   Independently deployable provider of functionality.
+                        -   `Service`:   Provider of functionality with an independent lifecycle.
                         -   `Module`:    Logical grouping of related functionality within a
                                          component.
                         -   `Connector`: Mediator that conveys interactions between components
                                          (e.g. bus, gateway).
                         -   `Subsystem`: Larger composite grouping several components.
                     value: enum(Component,Service,Module,Connector,Subsystem)
-                -   name: RESPONSIBILITY
+                -   name: PART-OF
                     desc: >
-                        The 1-sentence statement of the single, primary responsibility the component
-                        owns.
+                        Reference to the FUNCTIONALITY-VIEW object this component is contained
+                        in, expressing the composition hierarchy the kinds imply: a `Module`
+                        references the component it groups functionality within, and a component
+                        references the `Subsystem` it belongs to; omitted for a top-level
+                        component.
+                    value: "[[ARCH:FV.COMPONENT:*]]"
+                    optional: true
+                    acyclic: true
+                -   name: REALIZES
+                    desc: >
+                        Comma-separated references to the FUNCTIONAL-REQUIREMENTS objects the
+                        component realizes, i.e. whose capability its functionality delivers, so
+                        that every Functional Requirement is owned by at least one component.
+                    value: list([[REQS:FR.*]])
+                    optional: true
+                -   name: OWNS
+                    desc: >
+                        Comma-separated references to the DATA-MODEL entities the component owns,
+                        i.e. for which it is the single authoritative source of truth (other
+                        components access an owned entity through the owner's interfaces or hold
+                        derived copies only), so that every entity is owned by at most one
+                        component; omitted when the component owns no entity.
+                    value: list([[DATA:DM.ENTITY:*]])
+                    optional: true
                 -   name: PROVIDES
                     desc: >
                         Comma-separated references to the INTERFACE-MODEL objects the component
@@ -2718,138 +2689,382 @@
                         (e.g. a user interface or an internal module).
                     value: list([[APIS:IM.INTERFACE:*]])
                     optional: true
+                -   name: CONSUMES
+                    desc: >
+                        Comma-separated references to the INTERFACE-MODEL objects the component
+                        consumes, i.e. the `Provided` interfaces of other components and the
+                        `Required` interfaces offered by external entities, through which its
+                        dependencies are exercised; omitted when the component consumes no
+                        modeled interface.
+                    value: list([[APIS:IM.INTERFACE:*]])
+                    optional: true
                 -   name: DEPENDS-ON
                     desc: >
                         Comma-separated references to the FUNCTIONALITY-VIEW objects this component
-                        depends on at runtime.
+                        depends on at runtime, naming the target component only, while the
+                        interface through which a dependency is exercised is stated by `CONSUMES`
+                        where modeled.
                     value: list([[ARCH:FV.COMPONENT:*]])
                     optional: true
 
 -   kind: ARCH
-    name: Information View
-    id: IV
-    file: 25-ARCH-IV-Information-View.md
+    name: Technology Stack
+    id: TS
+    file: 24-ARCH-TS-Technology-Stack.md
     desc: >
-        The way the solution stores, manages, manipulates, and distributes information, defining the
-        static data structure and dynamic information flow.
+        The concrete technology products the solution is built upon, organized by tier and lifecycle
+        phase, recording for each component its chosen product, its purpose, and the alternatives
+        that were considered but not chosen.
+    optional: true
     refs: >
-        -   Rozanski/Woods: Software Systems Architecture, 2nd ed.: The Information Viewpoint (2011),
-            https://www.viewpoints-and-perspectives.info/home/viewpoints/information/
-        -   Kleppmann: Designing Data-Intensive Applications (2017),
-            https://dataintensive.net/
+        -   Starke/Hruschka: arc42 Template: Solution Strategy and Crosscutting Concepts (2005),
+            https://arc42.org/overview
+        -   Brown: The C4 Model: Container Diagram (2018),
+            https://c4model.com/diagrams/container
     diagram:
         type: grid
-        nodes: "[[ARCH:IV.ASPECT:*]]"
-        properties:
-            -   CONCERN
+        nodes: "[[ARCH:TS.TIER:*]]"
     childs:
-        -   kind: ASPECT
-            desc: >
-                A single information aspect, named with a short (2-5 word) summary (e.g. `Order
-                Persistence`, `Event Stream`, `Cache Coherency`) and described in a concise (1-3
-                sentence) paragraph by how the solution stores, manages, or distributes the
-                information and how its consistency is upheld, plus a 1-sentence rationale ("why")
-                for handling the information this way.
+        -   kind: TIER
+            desc: |
+                The architectural tier grouping the technology components belonging to it, named
+                with a short (1-2 word) summary mirroring the name of the Deployment View tier
+                referencing it through `STACK`, typically one of:
+
+                -   `Client`:     Runs on the client side (e.g. browser, desktop, mobile).
+                -   `Server`:     Runs on the server side (e.g. backend, application, API).
+                -   `Middleware`: Runs between client and server (e.g. message broker, gateway).
+                -   `Database`:   Runs as the data store (e.g. relational or document database).
+                -   `Common`:     Runs on several tiers alike (e.g. a language, a logging library,
+                                  or a shared module used by client and server), so a product
+                                  used on several tiers is a single component here instead of
+                                  one per tier; referenced by no Deployment View tier.
             diagram:
                 type: hub
                 center: self
-                nodes: "[[ARCH:IV.ASPECT:*]], [[DATA:DM.ENTITY:*]], [[ARCH:FV.COMPONENT:*]]"
-                qualified: true
+                hierarchy: true
                 properties:
-                    -   CONCERN
+                    -   PRODUCT
                 config:
                     size-node-width-max: 440
-            props:
-                -   name: CONCERN
-                    desc: >
-                        The information-handling concern the aspect addresses: `Persistence`,
-                        `Flow`, `Ownership`, `Consistency`, `Replication`, `Caching`, `Retention`,
-                        or `Migration`.
-                    value: enum(Persistence,Flow,Ownership,Consistency,Replication,Caching,Retention,Migration)
-                -   name: ENTITIES
-                    desc: >
-                        Comma-separated references to the DATA-MODEL entities the aspect governs.
-                    value: list([[DATA:DM.ENTITY:*]])
-                    optional: true
-                -   name: OWNER
-                    desc: >
-                        Reference to the FUNCTIONALITY-VIEW object that owns this information.
-                    value: "[[ARCH:FV.COMPONENT:*]]"
-                    optional: true
-                -   name: LIFECYCLE
+                    size-node-height-scale: 1.75
+            childs:
+                -   kind: COMPONENT
                     desc: >
-                        How the information comes into being, changes, and is disposed of (e.g.
-                        `created on order, retained 7 years, then purged`).
+                        A single technology component, named with a short (2-5 word) summary (e.g.
+                        `UI Framework`, `Web Server`, `Relational Database`) and described in a
+                        concise (1-3 sentence) paragraph by how the product is used within the
+                        solution and how it fits into the overall technology stack, plus a
+                        1-sentence rationale ("why") for choosing this product over the
+                        alternatives.
 
--   kind: ARCH
-    name: Concurrency View
-    id: CO
-    file: 26-ARCH-CO-Concurrency-View.md
-    desc: >
-        The concurrency structure of the solution, mapping functional components to processes and
-        threads, and defining how they coordinate and communicate.
-    refs: >
-        -   Rozanski/Woods: Software Systems Architecture, 2nd ed.: The Concurrency Viewpoint (2011),
-            https://www.viewpoints-and-perspectives.info/home/viewpoints/concurrency/
-        -   Kruchten: Architectural Blueprints -- The "4+1" View Model of Software Architecture (1995),
-            https://ieeexplore.ieee.org/document/469759
-        -   Schmidt et al.: Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects (2000),
-            https://www.wiley.com/en-us/Pattern+Oriented+Software+Architecture,+Volume+2,+Patterns+for+Concurrent+and+Networked+Objects-p-9781118725177
-    diagram:
-        type: grid
-        nodes: "[[ARCH:CO.UNIT:*]]"
-        properties:
-            -   KIND
-    childs:
-        -   kind: UNIT
-            desc: >
-                A single concurrency unit, named with a short (2-5 word) summary (e.g. `Web Worker
-                Pool`, `Background Scheduler`, `Ingest Queue Consumer`) and described in a concise
-                (1-3 sentence) paragraph by how it executes and how it avoids or manages contention,
-                races, and deadlocks, plus a 1-sentence rationale ("why") for the chosen concurrency
-                structure.
-            diagram:
-                type: hub
-                center: self
-                nodes: "[[ARCH:CO.UNIT:*]], [[ARCH:FV.COMPONENT:*]]"
-                qualified: true
-                properties:
-                    -   KIND
-                config:
-                    size-node-width-max: 440
-            props:
-                -   name: KIND
-                    desc: |
-                        The kind of the concurrency unit, one of:
+                        A component states one product in one role on one tier: the product used
+                        by several tiers alike belongs to the `Common` tier once, the lock-in
+                        carrying trade-off behind the choice is a Design Decisions decision
+                        referencing the component through `DECIDES`, and the functional components
+                        depending on the product reference it through `USED-BY`.
+                    diagram:
+                        type: hub
+                        center: self
+                        nodes: "[[ARCH:TS.TIER:*.COMPONENT:*]], [[ARCH:FV.COMPONENT:*]],
+                            [[ARCH:DD.DECISION:*]]"
+                        labeled: true
+                        qualified: true
+                        properties:
+                            -   PRODUCT
+                            -   PHASE
+                        config:
+                            size-node-width-max:    440
+                            size-node-height-scale: 1.75
+                    props:
+                        -   name: PRODUCT
+                            desc: >
+                                The concrete product, library, or framework chosen for this
+                                component (e.g. `VueJS`, `Node.js`, `PostgreSQL`).
+                        -   name: ALTERNATIVES
+                            desc: >
+                                Comma-separated names of the products which would also fit this
+                                component but were not chosen (e.g. `React, Svelte`): the
+                                rationale of the description states *why* the product won, this
+                                property states *against what*, so it is expected whenever the
+                                rationale compares the product against others; omitted when there
+                                was no real alternative.
+                            optional: true
+                        -   name: LICENSE
+                            desc: >
+                                The license under which the product is used (e.g. `MIT`,
+                                `Apache-2.0`, `AGPL-3.0`, `commercial`, `in-house`), the evidence
+                                for a Non-Functional Requirement of category `Compliance`;
+                                omitted when the license is of no concern to the solution.
+                            optional: true
+                        -   name: PHASE
+                            desc: |
+                                The lifecycle phases in which the component is relevant, one or
+                                more of:
+
+                                -   `Build-Time`:   Used during development, compilation, or
+                                                    packaging.
+                                -   `Run-Time`:     Used while the solution executes in
+                                                    production.
+                                -   `Operate-Time`: Used to operate the solution in production
+                                                    (e.g. for rollout, monitoring, or backup),
+                                                    referenced by the Operations View concerns
+                                                    through `TOOLS`.
+                            value: tags(Build-Time,Run-Time,Operate-Time)
+                        -   name: COVERAGE
+                            desc: |
+                                A comma-separated list of the aspects the component covers, drawn
+                                from the catalog of its `PHASE`: for `Build-Time` the *Build-Time
+                                Aspects* (the categories of the Development Aspects), for
+                                `Operate-Time` the *Operate-Time Aspects* (the categories of the
+                                Operations View concerns), and for `Run-Time` the *Client*,
+                                *Server*, *Middleware*, or *Database Aspects* of the component's
+                                `TIER` (a `Common` tier component draws from the catalogs of all
+                                tiers it serves), each defined below with its typical sub-aspects
+                                as an explanation only. The general goal is to achieve a maximum
+                                coverage of all aspects per tier and phase with the minimum total
+                                number of `PRODUCT`s.
+
+                                The *Build-Time Aspects* which usually have to be covered (the
+                                Development Aspects `CATEGORY` values):
+                                -   **Structure**:
+                                    Module Layout, Package Layout, Workspace.
+                                -   **Build**:
+                                    Compilation, Transpilation, Bundling, Packaging.
+                                -   **Dependency**:
+                                    Dependency Management, Lock File, Vulnerability Audit.
+                                -   **Codeline**:
+                                    Version Control, Branching, Merging, Versioning, Release
+                                    Tagging.
+                                -   **Standardization**:
+                                    Linting, Formatting, Type Checking, Coding Conventions.
+                                -   **Testing**:
+                                    Unit Testing, Integration Testing, End-to-End Testing,
+                                    Coverage Measurement.
+                                -   **Tooling**:
+                                    Task Running, Code Generation, Development Automation.
+
+                                The *Operate-Time Aspects* which usually have to be covered (the
+                                Operations View `CATEGORY` values):
+                                -   **Installation**:
+                                    Provisioning, Container Orchestration, Infrastructure as
+                                    Code.
+                                -   **Configuration**:
+                                    Configuration Management, Secret Management, Environment
+                                    Files.
+                                -   **Migration**:
+                                    Data Migration, Schema Migration, Environment Promotion.
+                                -   **Monitoring**:
+                                    Metrics, Health Checks, Dashboards, Tracing.
+                                -   **Logging**:
+                                    Log Collection, Log Retention, Log Inspection.
+                                -   **Alerting**:
+                                    Notification, Escalation, On-Call Paging.
+                                -   **Backup**:
+                                    Dumps, Snapshots, Backup Storage.
+                                -   **Recovery**:
+                                    Restore, Failover, Point-in-Time Recovery.
+                                -   **Upgrade**:
+                                    Rollout, Rolling Update, Rollback, Image Distribution.
+                                -   **Capacity**:
+                                    Scaling, Autoscaling, Capacity Planning.
+                                -   **Administration**:
+                                    User Administration, Data Retention, Certificate Rotation.
+                                -   **Incident**:
+                                    Troubleshooting, Diagnostics, Post-Mortem.
+                                -   **Support**:
+                                    Ticketing, Knowledge Base, Escalation.
+
+                                The *Client Aspects* which usually have to be covered (at least
+                                for clients in a Rich-Client architecture):
 
-                        -   `Process`:   An independent OS process with its own address space.
-                        -   `Thread`:    A thread of execution within a process.
-                        -   `Pool`:      A managed group of interchangeable workers.
-                        -   `Queue`:     An asynchronous buffer decoupling producers and consumers.
-                        -   `EventLoop`: A single-threaded cooperative scheduler of tasks.
-                    value: enum(Process,Thread,Pool,Queue,EventLoop)
-                -   name: HOSTS
-                    desc: >
-                        Comma-separated references to the FUNCTIONALITY-VIEW objects that run inside
-                        this concurrency unit.
-                    value: list([[ARCH:FV.COMPONENT:*]])
-                    optional: true
-                -   name: MULTIPLICITY
-                    desc: >
-                        How many instances of the unit run (e.g. `1`, `1 per CPU core`, `0..n
-                        auto-scaled`).
-                -   name: COORDINATION
-                    desc: >
-                        The mechanism by which the unit coordinates or communicates with other units
-                        (e.g. `shared queue`, `mutex`, `message passing`, `optimistic locking`).
+                                -   **Interface Theme**:
+                                    Style Reset, Shape, Color, Gradient, Shadow, Font, Icon.
+                                -   **Interface Widgets**:
+                                    Icon, Label, Text Paragraph, Image, Form, Text-Field,
+                                    Text-Area, Date Picker, Toggle, Radio Button, Checkbox,
+                                    Select List, Slider, Progress Bar, Hyperlink, Popup Menu,
+                                    Dropdown Menu, Toolbar, Tooltip, Tab, Pill, Breadcrumb,
+                                    Pagination, Badge, Alert, Panel, Modal, Table, Scrollbar,
+                                    Carousel.
+                                -   **Interface Layouting**:
+                                    Responsive Design, Media Query, Frame, Grid, Padding, Border,
+                                    Margin, Alignment, Force, Magnetism.
+                                -   **Interface Effects**:
+                                    Transition, Transformation, Keyframes, Easing Function, Sound
+                                    Effect, Physics.
+                                -   **Interface Interactions**:
+                                    Mouse, Keyboard, Touchscreen, Gesture, Clipboard, Drag & Drop.
+                                -   **Interface States**:
+                                    Rendered, Enabled, Visible, Focused, Warning, Error, Floating.
+                                -   **Interface Mask**:
+                                    Markup Loading, Markup Generation, Virtual DOM, Text, Bitmaps,
+                                    Vectors, 2D/3D Canvas, Accessibility.
+                                -   **Interface Internationalization**:
+                                    Text Internationalization (I18N).
+                                -   **Data Conversion**:
+                                    Value Formatting, Value Parsing, Localization (L10N).
+                                -   **Data Binding**:
+                                    Reactive, Observer, Unidirectional, Bidirectional, Incremental.
+                                -   **Presentation Model**:
+                                    Parameter Value, Command Value, State Value, Data Value, Event
+                                    Value, Value Validation, Presentation Logic.
+                                -   **Dialog Navigation**:
+                                    Deep Linking, Routing, Dialog Flow.
+                                -   **Dialog Automation**:
+                                    Dialog Macros, Click-Through, Smoke Testing.
+                                -   **Dialog Communication**:
+                                    Service, Event, Model, Socket, Hooks.
+                                -   **Dialog Life-Cycle**:
+                                    Component States, Component State Transitions.
+                                -   **Dialog Structure**:
+                                    Component, Model/View/Controller Roles, Hierarchical
+                                    Composition.
+                                -   **State Persistence**:
+                                    Local Storage, Cookies, Caching.
+                                -   **Business Model**:
+                                    Entity, Field, Relationship, Universally Unique Identifiers
+                                    (UUID).
+                                -   **Use-Case Authorization**:
+                                    User Experience, Dialog Restriction, User, Group, Role,
+                                    Use-Case, Data, Access.
+                                -   **Client Networking**:
+                                    Request/Response, Synchronization, Push, Pull, Pulled-Push,
+                                    REST, GraphQL, Authentication, Session.
+                                -   **Environment Detection**:
+                                    Runtime Detection, Feature Detection.
+
+                                The *Server Aspects* which usually have to be covered (at least
+                                for servers, sometimes called Thin-Servers, in a Rich-Client
+                                architecture):
+
+                                -   **Environment Detection**:
+                                    Operating System, Execution Platform, Network Topology,
+                                    Feature Toggles.
+                                -   **Argument Parsing**:
+                                    CLI Options, CLI Arguments, Bootstrapping Parameters.
+                                -   **Configuration Parsing**:
+                                    Configuration File, Environment Variables, Directives.
+                                -   **Process Daemonizing**:
+                                    Terminal Detaching, Host Process Detaching, PID File.
+                                -   **Process Management**:
+                                    Pre-Forking, Child Processes, Threads, Supervision.
+                                -   **Component Management**:
+                                    Component Structure, Instantiation, Component Life-Cycle.
+                                -   **Component Communication**:
+                                    Events, Hooks, Registry, Dependency Injection.
+                                -   **Server Networking**:
+                                    Socket Listening, Connection Acceptance, Request/Response,
+                                    Messaging.
+                                -   **Peer Information**:
+                                    Peer Identification, Peer Address, User Agent.
+                                -   **Session Handling**:
+                                    Session State, Session Security, Session Expiry.
+                                -   **User Authentication**:
+                                    Identity, Credentials, Tokens, Single Sign-On.
+                                -   **Request Validation**:
+                                    Syntax Validation, Semantic Validation, Sanitizing.
+                                -   **Request Processing**:
+                                    Dispatching, Routing, Context Determination.
+                                -   **Role Authorization**:
+                                    Role, Permission, Access Control.
+                                -   **Client Networking**:
+                                    Peer Connection, Request/Response, Publish/Subscribe.
+                                -   **Task Scheduling**:
+                                    Recurring Tasks, Cron, Job Queue.
+                                -   **Execution Tracing**:
+                                    Logging, Metrics, Measurement, Tracing.
+                                -   **Database Access**:
+                                    Object-Relational Mapping, Query Building, Entity Mapping.
+                                -   **Database Connectivity**:
+                                    Driver, Connection Pooling, Local/Remote Connection.
+                                -   **Database Schema**:
+                                    Schema Creation, Schema Upgrade, Schema Downgrade.
+                                -   **Database Bootstrapping**:
+                                    Mandatory Data, Domain Data, Seeding, Fixtures.
+
+                                The *Middleware Aspects* which usually have to be covered (at
+                                least for solutions with a dedicated tier between client and
+                                server):
+
+                                -   **Message Brokering**:
+                                    Publish/Subscribe, Queues, Topics, Delivery Guarantees,
+                                    Retention.
+                                -   **Request Routing**:
+                                    API Gateway, Reverse Proxy, Path Routing, Rewriting.
+                                -   **Load Balancing**:
+                                    Distribution, Health Checks, Sticky Sessions, Failover.
+                                -   **Transport Security**:
+                                    TLS Termination, Certificates, Mutual TLS, Firewalling.
+                                -   **Content Caching**:
+                                    Response Caching, Content Delivery, Compression.
+                                -   **Traffic Control**:
+                                    Rate Limiting, Throttling, Circuit Breaking, Retry.
+                                -   **Service Discovery**:
+                                    Registry, Naming, Configuration Distribution.
+                                -   **Identity Federation**:
+                                    OAuth, OpenID Connect, SAML, Token Exchange.
+
+                                The *Database Aspects* which usually have to be covered (at
+                                least for solutions with a data store of their own):
+
+                                -   **Storage Engine**:
+                                    Row Store, Column Store, Document Store, Key-Value Store,
+                                    Graph Store, Time Series, Binary Assets.
+                                -   **Transaction Management**:
+                                    ACID, Isolation Levels, Locking, Multi-Version Concurrency.
+                                -   **Query Language**:
+                                    SQL, Query DSL, Stored Procedures, Views.
+                                -   **Indexing**:
+                                    B-Tree, Hash, Full-Text Search, Geospatial, Vector.
+                                -   **Replication**:
+                                    Primary/Replica, Multi-Primary, Failover, Sharding.
+                                -   **Database Security**:
+                                    Encryption at Rest, Access Control, Auditing.
+
+                            value: tags(Structure,Build,Dependency,Codeline,Standardization,Testing,Tooling,
+                                Installation,Configuration,Migration,Monitoring,Logging,Alerting,Backup,
+                                Recovery,Upgrade,Capacity,Administration,Incident,Support,
+                                "Interface Theme","Interface Widgets","Interface Layouting","Interface Effects",
+                                "Interface Interactions","Interface States","Interface Mask",
+                                "Interface Internationalization","Data Conversion","Data Binding",
+                                "Presentation Model","Dialog Navigation","Dialog Automation",
+                                "Dialog Communication","Dialog Life-Cycle","Dialog Structure",
+                                "State Persistence","Business Model","Use-Case Authorization",
+                                "Client Networking","Environment Detection",
+                                "Argument Parsing","Configuration Parsing","Process Daemonizing",
+                                "Process Management","Component Management","Component Communication",
+                                "Server Networking","Peer Information","Session Handling",
+                                "User Authentication","Request Validation","Request Processing",
+                                "Role Authorization","Task Scheduling","Execution Tracing",
+                                "Database Access","Database Connectivity","Database Schema",
+                                "Database Bootstrapping",
+                                "Message Brokering","Request Routing","Load Balancing","Transport Security",
+                                "Content Caching","Traffic Control","Service Discovery","Identity Federation",
+                                "Storage Engine","Transaction Management","Query Language","Indexing",
+                                "Replication","Database Security")
+                            optional: true
+                        -   name: USED-BY
+                            desc: >
+                                Comma-separated references to the FUNCTIONALITY-VIEW objects using
+                                the product, the path along which a Deployment View node reaches
+                                the products running on it and along which swapping the product is
+                                impact-analyzed; omitted for a component not tied to particular
+                                functional components (e.g. a language or a build tool used by
+                                all).
+                            value: list([[ARCH:FV.COMPONENT:*]])
+                            optional: true
 
 -   kind: ARCH
-    name: Development View
-    id: DV
-    file: 27-ARCH-DV-Development-View.md
+    name: Development Aspects
+    id: DA
+    file: 25-ARCH-DA-Development-Aspects.md
     desc: >
         The architecture supporting the software development process, defining the module
-        organization, build approach, and codeline conventions.
+        organization, build approach, and codeline conventions. The artifact is absent when the
+        development conventions are governed outside the specification (e.g. by repository-level
+        contributor instructions).
+    optional: true
     refs: >
         -   Rozanski/Woods: Software Systems Architecture, 2nd ed.: The Development Viewpoint (2011),
             https://www.viewpoints-and-perspectives.info/home/viewpoints/development/
@@ -2859,7 +3074,9 @@
             https://www.informit.com/store/documenting-software-architectures-views-and-beyond-9780321552686
     diagram:
         type: grid
-        nodes: "[[ARCH:DV.ASPECT:*]]"
+        nodes: "[[ARCH:DA.ASPECT:*]]"
+        properties:
+            -   CATEGORY
     childs:
         -   kind: ASPECT
             desc: >
@@ -2867,23 +3084,125 @@
                 Layering`, `Build Pipeline`, `Branching Model`) and described in a concise (1-3
                 sentence) paragraph by the development convention or structure and the rule
                 developers must follow, plus a 1-sentence rationale ("why").
+
+                An aspect states a standing developer-facing rule about the source structure and
+                process: it names no concrete products (a Technology Stack `Build-Time` component
+                states the product choice), does not restate the runtime structure (a Functionality
+                View `Module` or `Subsystem` groups the logic), does not cover production
+                procedures (an Operations View concern does), and the trade-off that produced a
+                rule is a Design Decisions decision referencing the aspect through `AFFECTS`.
             props:
                 -   name: CATEGORY
                     desc: >
-                        The development concern the aspect governs: `Structure` (module/package
-                        organization), `Build` (compilation and packaging), `Dependency` (dependency
-                        management and layering rules), `Codeline` (branching, merging, versioning),
-                        `Standardization` (coding standards and conventions), or `Tooling`
-                        (development tools and automation).
-                    value: enum(Structure,Build,Dependency,Codeline,Standardization,Tooling)
+                        The development concern the aspect governs: `Structure` (the physical
+                        source module/package layout), `Build` (compilation and packaging),
+                        `Dependency` (the allowed dependency edges between the structures),
+                        `Codeline` (branching, merging, versioning), `Standardization` (coding
+                        standards and conventions), `Testing` (test conventions, layout, and
+                        coverage rules), or `Tooling` (development tools and automation).
+                    value: enum(Structure,Build,Dependency,Codeline,Standardization,Testing,Tooling)
+
+-   kind: ARCH
+    name: Concurrency View
+    id: CO
+    file: 26-ARCH-CO-Concurrency-View.md
+    desc: >
+        The concurrency structure of the solution, mapping functional components to processes and
+        threads, and defining how they coordinate and communicate. The artifact is absent when the
+        solution runs as a single sequential unit of execution and has no concurrency structure
+        worth describing.
+    optional: true
+    refs: >
+        -   Rozanski/Woods: Software Systems Architecture, 2nd ed.: The Concurrency Viewpoint (2011),
+            https://www.viewpoints-and-perspectives.info/home/viewpoints/concurrency/
+        -   Kruchten: Architectural Blueprints -- The "4+1" View Model of Software Architecture (1995),
+            https://ieeexplore.ieee.org/document/469759
+        -   Schmidt et al.: Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects (2000),
+            https://www.wiley.com/en-us/Pattern+Oriented+Software+Architecture,+Volume+2,+Patterns+for+Concurrent+and+Networked+Objects-p-9781118725177
+    diagram:
+        type: graph
+        nodes: "[[ARCH:CO.UNIT:*]]"
+        labeled: true
+        properties:
+            -   KIND
+    childs:
+        -   kind: UNIT
+            desc: >
+                A single concurrency unit, named with a short (2-5 word) summary (e.g. `Web Worker
+                Pool`, `Background Scheduler`, `Ingest Queue Consumer`) and described in a concise
+                (1-3 sentence) paragraph by how it executes and how it avoids or manages contention,
+                races, and deadlocks (including its start order and failure/restart behavior where
+                non-obvious), plus a 1-sentence rationale ("why") for the chosen concurrency
+                structure.
+
+                A unit executes work at runtime: a queue or channel between units is not a unit
+                but the coordination mechanism stated in `COORDINATION`, its contract an Interface
+                Model interface (e.g. of kind `MQTT` or `WebSocket`), and the platform element
+                hosting a managed broker a Deployment View `Managed` node -- only the executing
+                structure itself belongs to the Concurrency View.
+            diagram:
+                type: hub
+                center: self
+                nodes: "[[ARCH:CO.UNIT:*]], [[ARCH:FV.COMPONENT:*]], [[ARCH:DV.NODE:*]]"
+                labeled: true
+                qualified: true
+                properties:
+                    -   KIND
+                config:
+                    size-node-width-max:    440
+                    size-node-height-scale: 1.75
+            props:
+                -   name: KIND
+                    desc: |
+                        The kind of the concurrency unit, one of:
+
+                        -   `Process`:   An independent OS process with its own address space.
+                        -   `Thread`:    A thread of execution within a process.
+                        -   `Task`:      A lightweight cooperative task (e.g. coroutine, fiber).
+                        -   `Pool`:      A managed group of interchangeable workers.
+                        -   `EventLoop`: A single-threaded cooperative scheduler of tasks.
+                    value: enum(Process,Thread,Task,Pool,EventLoop)
+                -   name: PART-OF
+                    desc: >
+                        Reference to the CONCURRENCY-VIEW object this unit is contained in,
+                        expressing the containment the kinds imply: a `Thread`, `Task`, `Pool`, or
+                        `EventLoop` references the `Process` it executes within, and a `Task` the
+                        `EventLoop` or `Pool` scheduling it; omitted for a top-level unit.
+                    value: "[[ARCH:CO.UNIT:*]]"
+                    optional: true
+                    acyclic: true
+                -   name: HOSTS
+                    desc: >
+                        Comma-separated references to the FUNCTIONALITY-VIEW objects that run inside
+                        this concurrency unit; omitted when no modeled component runs inside it.
+                    value: list([[ARCH:FV.COMPONENT:*]])
+                    optional: true
+                -   name: MULTIPLICITY
+                    desc: >
+                        How many instances of the unit run (e.g. `1`, `1 per CPU core`, `0..n
+                        auto-scaled`).
+                -   name: COORDINATES-WITH
+                    desc: >
+                        Comma-separated references to the CONCURRENCY-VIEW objects this unit
+                        coordinates or communicates with at runtime, naming the peer unit only
+                        (e.g. a producer names the consumer it feeds through a shared queue),
+                        while the mechanism is stated by `COORDINATION`.
+                    value: list([[ARCH:CO.UNIT:*]])
+                    optional: true
+                -   name: COORDINATION
+                    desc: >
+                        The mechanism by which the unit coordinates or communicates with other
+                        units, usually those referenced in `COORDINATES-WITH` (e.g. `shared
+                        queue`, `mutex`, `message passing`, `optimistic locking`).
 
 -   kind: ARCH
     name: Deployment View
-    id: DP
-    file: 28-ARCH-DP-Deployment-View.md
+    id: DV
+    file: 27-ARCH-DV-Deployment-View.md
     desc: >
-        The environment into which the solution is deployed, mapping software elements to the
-        runtime platform, hardware, and network topology.
+        The environment into which the solution is deployed, partitioning it into tiers and mapping
+        software elements to the runtime platform, hardware, and network topology.
+    optional: true
     refs: >
         -   Rozanski/Woods: Software Systems Architecture, 2nd ed.: The Deployment Viewpoint (2011),
             https://www.viewpoints-and-perspectives.info/home/viewpoints/deployment/
@@ -2892,62 +3211,245 @@
         -   Brown: The C4 Model: Deployment Diagram (2018),
             https://c4model.com/diagrams/deployment
     diagram:
-        type: grid
-        nodes: "[[ARCH:DP.NODE:*]]"
+        type: graph
+        nodes: "[[ARCH:DV.NODE:*]]"
+        labeled: true
         properties:
+            -   TIER
+            -   AREA
             -   KIND
             -   PLATFORM
+        config:
+            size-node-width-max: 350
     childs:
+        -   kind: TIER
+            desc: >
+                A single deployment tier, named with a short (1-3 word) summary (e.g. `Client`,
+                `Server`, `Database`, `Data Center`) and described in a concise (1-3 sentence)
+                paragraph by the code or data it hosts and its spatial and network separation from
+                the other tiers, plus a 1-sentence rationale ("why") for the partitioning.
+
+                A tier is a logically and spatially distinct, network-connected, technology-induced
+                partition of the solution, the *horizontal* split when drawn (an `AREA` is the
+                *vertical*, domain-induced one): every node belongs to exactly one tier via its
+                `TIER`, a location-level tier (e.g. a data center) groups the tiers referencing it
+                via `PART-OF`, and a single deployment unit within a tier is a `NODE` -- only the
+                partition itself belongs here.
+            format:
+                type: concise
+            diagram:
+                type: hub
+                center: self
+                nodes: "[[ARCH:DV.TIER:*]], [[ARCH:DV.NODE:*]]"
+                labeled: true
+                qualified: true
+                properties:
+                    -   LOCATION
+                    -   KIND
+                config:
+                    size-node-width-max:    440
+                    size-node-height-scale: 1.75
+            props:
+                -   name: PART-OF
+                    desc: >
+                        Reference to the DEPLOYMENT-VIEW tier this tier is contained in (e.g. the
+                        `Server` and `Database` tiers reference the `Data Center` tier hosting
+                        them); omitted for a top-level tier.
+                    value: "[[ARCH:DV.TIER:*]]"
+                    optional: true
+                    acyclic: true
+                -   name: LOCATION
+                    desc: >
+                        Where the tier physically runs (e.g. `Hetzner data center Nürnberg, dev/QA/prod
+                        environments`, `attendee and operator devices`, `Cloudflare edge`); omitted
+                        when inherited from the `PART-OF` tier.
+                    optional: true
+                -   name: STACK
+                    desc: >
+                        Reference to the TECHNOLOGY-STACK tier whose products run in this tier;
+                        omitted when the Technology Stack is absent, has no matching tier, or the
+                        tier (e.g. a data center) groups other tiers only.
+                    value: "[[ARCH:TS.TIER:*]]"
+                    optional: true
+        -   kind: AREA
+            desc: >
+                A single deployment area, named with a short (1-3 word) summary (e.g. `Ordering`,
+                `Billing`, `Identity`) and described in a concise (1-3 sentence) paragraph by the
+                domain it covers and its separation from the other areas, plus a 1-sentence rationale
+                ("why") for the partitioning.
+
+                An area is a logically distinct, domain-induced partition of the solution deployed
+                as physical units of its own, the *vertical* split when drawn (a `TIER` is the
+                *horizontal*, technology-induced one): a node dedicated to the area references it via
+                its `AREA`, a node shared by several areas references none, and a domain grouping
+                without deployment units of its own is a Functionality View `Subsystem` instead. The
+                kind is absent when the solution is not split vertically.
+            optional: true
+            format:
+                type: concise
+            diagram:
+                type: hub
+                center: self
+                nodes: "[[ARCH:DV.AREA:*]], [[ARCH:DV.NODE:*]]"
+                labeled: true
+                qualified: true
+                properties:
+                    -   KIND
+                config:
+                    size-node-width-max:    440
+                    size-node-height-scale: 1.75
         -   kind: NODE
             desc: >
-                A single deployment node, named with a short (2-5 word) summary (e.g. `Web Tier`,
+                A single deployment node, named with a short (2-5 word) summary (e.g. `Web Servers`,
                 `Database Cluster`, `Edge CDN`) and described in a concise (1-3 sentence) paragraph
                 by the node, its sizing, and its place in the deployment topology, plus a 1-sentence
                 rationale ("why") for the node's placement and platform choice.
+
+                A node is a platform element the solution deploys onto and operates itself: a
+                managed third-party service the solution merely consumes is a Context View
+                `Service` entity, the software products running on the node are Technology Stack
+                components (referencing the hosted components through `USED-BY`), and the procedures
+                operating the node are Operations View concerns -- only the runtime environment
+                itself belongs to the Deployment View, with the tier and area the node belongs to
+                and the network segments it is attached to as its `TIER`, `AREA`, and `NETWORK`
+                siblings.
             diagram:
                 type: hub
                 center: self
-                nodes: "[[ARCH:DP.NODE:*]], [[ARCH:FV.COMPONENT:*]]"
+                nodes: "[[ARCH:DV.TIER:*]], [[ARCH:DV.AREA:*]], [[ARCH:DV.NODE:*]],
+                    [[ARCH:DV.NETWORK:*]], [[ARCH:FV.COMPONENT:*]], [[ARCH:CO.UNIT:*]]"
+                labeled: true
                 qualified: true
                 properties:
+                    -   LOCATION
                     -   KIND
                     -   PLATFORM
+                    -   SCOPE
                 config:
-                    size-node-width-max: 440
+                    size-node-width-max:    440
+                    size-node-height-scale: 1.75
             props:
                 -   name: KIND
                     desc: |
                         The kind of the deployment node, one of:
-
                         -   `Server`:    A physical or virtual machine.
                         -   `Container`: A containerized runtime (e.g. Docker, OCI).
-                        -   `Cluster`:   A managed group of nodes (e.g. Kubernetes cluster).
+                        -   `Cluster`:   A group of nodes managed as one (e.g. Kubernetes cluster),
+                                         containing the nodes referencing it via `PART-OF`.
                         -   `Function`:  A serverless / function-as-a-service runtime.
                         -   `Device`:    An edge or client device.
                         -   `Managed`:   A managed cloud service (e.g. managed database, queue).
                     value: enum(Server,Container,Cluster,Function,Device,Managed)
+                -   name: TIER
+                    desc: >
+                        Reference to the DEPLOYMENT-VIEW tier the node belongs to, exactly one, as a
+                        single deployment unit never spans tiers.
+                    value: "[[ARCH:DV.TIER:*]]"
+                -   name: AREA
+                    desc: >
+                        Reference to the DEPLOYMENT-VIEW area the node is dedicated to, at most one,
+                        as a single deployment unit never spans areas; omitted for a node shared by
+                        several areas or when the solution is not split vertically.
+                    value: "[[ARCH:DV.AREA:*]]"
+                    optional: true
                 -   name: PLATFORM
                     desc: >
-                        The runtime platform of the node (e.g. `Linux x86-64`, `Kubernetes 1.30`,
-                        `AWS Lambda (Node.js)`).
+                        The execution platform of the node, i.e. its operating system, runtime, or
+                        cloud service (e.g. `Linux x86-64`, `Kubernetes 1.30`, `AWS Lambda
+                        (Node.js)`), not the software products running on it, which are Technology
+                        Stack components.
+                -   name: PART-OF
+                    desc: >
+                        Reference to the DEPLOYMENT-VIEW object this node is contained in,
+                        expressing the nesting the kinds imply: a `Container` references the
+                        `Server` or `Cluster` running it, and a `Server` the `Cluster` it belongs
+                        to; omitted for a top-level node.
+                    value: "[[ARCH:DV.NODE:*]]"
+                    optional: true
+                    acyclic: true
                 -   name: HOSTS
                     desc: >
-                        Comma-separated references to the FUNCTIONALITY-VIEW objects deployed onto
-                        this node.
-                    value: list([[ARCH:FV.COMPONENT:*]])
+                        Comma-separated references to the CONCURRENCY-VIEW or FUNCTIONALITY-VIEW
+                        objects deployed onto this node: the concurrency units executing on the
+                        node (which themselves state the components they host), and the functional
+                        components not mapped by any concurrency unit directly. A containing node
+                        does not repeat what its `PART-OF` nodes host.
+                    value: list([[ARCH:CO.UNIT:*]], [[ARCH:FV.COMPONENT:*]])
+                    optional: true
+                -   name: INSTANCES
+                    desc: >
+                        How many instances of the node run (e.g. `1`, `3 per environment`, `0..n
+                        auto-scaled`).
                     optional: true
-                -   name: NETWORK
+                -   name: CONNECTS-TO
                     desc: >
-                        The network placement and connectivity of the node (e.g. `public subnet, TLS
-                        443`, `private VLAN`).
+                        Comma-separated references to the DEPLOYMENT-VIEW objects this node opens
+                        network connections to at runtime, naming the target node only, while the
+                        carried protocols are stated by the `PROTOCOLS` of the shared `NETWORK`.
+                    value: list([[ARCH:DV.NODE:*]])
+                    optional: true
+                -   name: NETWORKS
+                    desc: >
+                        Comma-separated references to the DEPLOYMENT-VIEW network segments the node
+                        is attached to (e.g. a public ingress and a private backend network); omitted
+                        when the topology models no network segments.
+                    value: list([[ARCH:DV.NETWORK:*]])
+                    optional: true
+        -   kind: NETWORK
+            desc: >
+                A single network segment the deployment nodes are attached to, named with a short
+                (2-5 word) summary (e.g. `Public Internet`, `Backend VLAN`, `Database Subnet`) and
+                described in a concise (1-3 sentence) paragraph by its reach, its isolation from the
+                other segments, and the traffic it carries, plus a 1-sentence rationale ("why") for
+                the segmentation.
+
+                A segment is the medium the nodes communicate over: the attached nodes reference it
+                via `NETWORKS`, the directed links between them are their `CONNECTS-TO` references,
+                and the contract of the carried traffic is an Interface Model interface -- only the
+                network itself belongs here. The kind is absent when the topology has no
+                segmentation worth describing.
+            optional: true
+            format:
+                type: concise
+            diagram:
+                type: hub
+                center: self
+                nodes: "[[ARCH:DV.NETWORK:*]], [[ARCH:DV.NODE:*]]"
+                labeled: true
+                qualified: true
+                properties:
+                    -   KIND
+                    -   SCOPE
+                config:
+                    size-node-width-max:    440
+                    size-node-height-scale: 1.75
+            props:
+                -   name: SCOPE
+                    desc: |
+                        The reach of the segment, one of:
+                        -   `Public`:   Reachable from the Internet.
+                        -   `Private`:  Reachable from the solution's own nodes only.
+                        -   `Isolated`: Reachable from selected nodes only (e.g. a database subnet).
+                    value: enum(Public,Private,Isolated)
+                -   name: PROTOCOLS
+                    desc: >
+                        The protocols and ports carried by the segment (e.g. `HTTPS 443, WSS 443`,
+                        `HTTP, WS, TCP 5432`).
+                -   name: ADDRESSING
+                    desc: >
+                        The address range or naming of the segment (e.g. `10.0.0.0/8`, `public IPv4
+                        and IPv6`, `*.example.com`).
+                    optional: true
 
 -   kind: ARCH
     name: Operations View
     id: OV
-    file: 29-ARCH-OV-Operations-View.md
+    file: 28-ARCH-OV-Operations-View.md
     desc: >
-        The way the solution is operated, administered, and supported in production, defining
-        installation, monitoring, and management concerns.
+        The way the solution is operated, administered, and supported in production, defining the
+        standing procedures by which the operating organization installs, configures, migrates,
+        observes, protects, upgrades, scales, and supports the running solution.
+    optional: true
     refs: >
         -   Rozanski/Woods: Software Systems Architecture, 2nd ed.: The Operational Viewpoint (2011),
             https://www.viewpoints-and-perspectives.info/home/viewpoints/operational/
@@ -2965,28 +3467,102 @@
             desc: >
                 A single operational concern, named with a short (2-5 word) summary (e.g. `Rolling
                 Deployment`, `Metrics Collection`, `Backup and Restore`) and described in a concise
-                (1-3 sentence) paragraph by how it is handled in production and which procedures or
-                tools support it, plus a 1-sentence rationale ("why") for the operational approach.
+                (1-3 sentence) paragraph by the procedure through which it is handled in production
+                and the steps and tools supporting it, plus a 1-sentence rationale ("why") for the
+                operational approach.
+
+                A concern states a standing production procedure the operating organization
+                performs on the running solution: a capability the solution offers its users (even
+                an administrating one) is a Functional Requirement or Use Case, an automatic
+                behavior of the solution is a Domain Rule, the design tactic making the solution
+                operable (e.g. replication, statelessness) is a Quality Perspectives tactic
+                referencing the concern through `OPERATED-BY`, the deployment shape acted upon
+                (instances, environments) is the Deployment View, the pipeline producing the
+                deployable artifact is a `Build` aspect of the Development Aspects, and the products
+                used are Technology Stack `Operate-Time` components referenced through `TOOLS` --
+                only the procedure itself, its trigger, and its responsible operator belong here.
+            diagram:
+                type: hub
+                center: self
+                nodes: "[[ARCH:OV.CONCERN:*]], [[REQS:NR.REQUIREMENT:*]], [[REQS:UP.PERSONA:*]],
+                    [[ARCH:QP.TACTIC:*]], [[ARCH:FV.COMPONENT:*]], [[ARCH:CO.UNIT:*]],
+                    [[ARCH:DV.NODE:*]], [[DATA:DM.ENTITY:*]], [[ARCH:TS.TIER:*.COMPONENT:*]]"
+                labeled: true
+                qualified: true
+                properties:
+                    -   CATEGORY
+                config:
+                    size-node-width-max:    440
+                    size-node-height-scale: 1.75
             props:
                 -   name: CATEGORY
+                    desc: |
+                        The category of the concern, one of:
+                        -   `Installation`:   Provisioning the environments and installing the
+                                              solution into them.
+                        -   `Configuration`:  Managing the configuration of the installed solution.
+                        -   `Migration`:      Moving data or functionality between versions or
+                                              environments.
+                        -   `Monitoring`:     Observing the health and performance of the running
+                                              solution.
+                        -   `Logging`:        Collecting, retaining, and inspecting the logs.
+                        -   `Alerting`:       Notifying the operators of conditions requiring
+                                              attention.
+                        -   `Backup`:         Preserving the data and state of the solution.
+                        -   `Recovery`:       Restoring the solution after a failure or data loss.
+                        -   `Upgrade`:        Rolling out new versions of the solution.
+                        -   `Capacity`:       Scaling the solution and planning its capacity.
+                        -   `Administration`: Routine housekeeping (e.g. user administration, data
+                                              retention, certificate rotation).
+                        -   `Incident`:       Troubleshooting and responding to incidents.
+                        -   `Support`:        Handling the requests of the users through the support
+                                              tiers and their escalation.
+                    value: enum(Installation,Configuration,Migration,Monitoring,Logging,Alerting,Backup,Recovery,Upgrade,Capacity,Administration,Incident,Support)
+                -   name: TRIGGER
+                    desc: >
+                        When the procedure is performed (e.g. `nightly`, `on release`, `on alert`,
+                        `before each event`, `on demand`), separating the routine (scheduled)
+                        concerns from the reactive (event-driven) ones.
+                -   name: OPERATOR
                     desc: >
-                        The category of the concern: `Installation`, `Configuration`,
-                        `Provisioning`, `Monitoring`, `Logging`, `Alerting`, `Backup`, `Recovery`,
-                        `Upgrade`, or `Support`.
-                    value: enum(Installation,Configuration,Provisioning,Monitoring,Logging,Alerting,Backup,Recovery,Upgrade,Support)
+                        Comma-separated references to the User Personas objects performing the
+                        procedure, usually a `Stakeholder` persona like the operations team (a
+                        procedure performed by a `User` persona through the solution is a Use Case
+                        instead); omitted when no persona of the operating organization is modeled.
+                    value: list([[REQS:UP.PERSONA:*]])
+                    optional: true
+                -   name: ADDRESSES
+                    desc: >
+                        Comma-separated references to the NON-FUNCTIONAL-REQUIREMENTS objects the
+                        procedure fulfills (e.g. a recovery objective, a retention obligation);
+                        omitted when the concern fulfills no stated requirement.
+                    value: list([[REQS:NR.*]])
+                    optional: true
                 -   name: ELEMENTS
                     desc: >
-                        Comma-separated references to the FUNCTIONALITY-VIEW or DEPLOYMENT-VIEW
-                        objects the concern applies to.
-                    value: list([[ARCH:FV.COMPONENT:*]], [[ARCH:DP.NODE:*]])
+                        Comma-separated references to the FUNCTIONALITY-VIEW, CONCURRENCY-VIEW,
+                        DEPLOYMENT-VIEW, or DATA-MODEL objects the procedure acts upon (e.g. the
+                        nodes scaled, the units restarted, the entities backed up or migrated).
+                    value: list([[ARCH:FV.COMPONENT:*]], [[ARCH:CO.UNIT:*]], [[ARCH:DV.TIER:*]],
+                        [[ARCH:DV.AREA:*]], [[ARCH:DV.NODE:*]], [[ARCH:DV.NETWORK:*]],
+                        [[DATA:DM.ENTITY:*]])
+                    optional: true
+                -   name: TOOLS
+                    desc: >
+                        Comma-separated references to the TECHNOLOGY-STACK components (usually of
+                        `PHASE` `Operate-Time`) supporting the procedure; omitted when the procedure
+                        uses no modeled product.
+                    value: list([[ARCH:TS.TIER:*.COMPONENT:*]])
                     optional: true
 
 -   kind: ARCH
     name: Quality Perspectives
     id: QP
-    file: 30-ARCH-QP-Quality-Perspectives.md
+    file: 29-ARCH-QP-Quality-Perspectives.md
     desc: >
-        How the Non-Functional Requirements (NR) are addressed.
+        How the Non-Functional Requirements (NR) are addressed by the architecture, through the
+        tactics built into the solution across the views.
+    optional: true
     refs: >
         -   Rozanski/Woods: Software Systems Architecture, 2nd ed.: The Perspectives (2011),
             https://www.viewpoints-and-perspectives.info/home/perspectives/
@@ -2996,21 +3572,41 @@
             https://www.iso.org/standard/78176.html
     diagram:
         type: grid
-        nodes: "[[ARCH:QP.PERSPECTIVE:*]]"
+        nodes: "[[ARCH:QP.TACTIC:*]]"
         properties:
             -   QUALITY
     childs:
-        -   kind: PERSPECTIVE
+        -   kind: TACTIC
             desc: >
-                A single quality perspective, named with a short (2-5 word) summary (e.g.
-                `Horizontal Scaling`, `Defense in Depth`, `Graceful Degradation`) and described in a
-                concise (1-3 sentence) paragraph by how the architecture satisfies the quality
-                attribute across the affected elements, plus a 1-sentence rationale ("why") for the
-                chosen tactic over alternatives.
+                A single quality tactic, one architectural tactic applied to one quality attribute
+                (the perspective in the sense of Rozanski/Woods, i.e. the cross-cutting quality
+                concern applied to the elements of all views, identified by `QUALITY`), named with
+                a short (2-5 word) summary (e.g. `Horizontal Scaling`, `Defense in Depth`,
+                `Graceful Degradation`) and described in a concise (1-3 sentence) paragraph by how
+                the tactic satisfies the quality attribute across the affected elements, plus a
+                1-sentence rationale ("why") for the tactic satisfying the addressed requirements
+                (not for choosing it over alternatives, which is the rationale of a Design
+                Decisions decision).
+
+                A tactic states a design mechanism built into the solution: the threshold the
+                mechanism has to meet is the `METRIC` of the addressed Non-Functional Requirement
+                and is not restated, the production procedure performed against the mechanism
+                (e.g. scaling out, restoring) is an Operations View concern referenced through
+                `OPERATED-BY`, the trade-off that chose the mechanism over alternatives is a
+                Design Decisions decision referencing the tactic through `DECIDES`, the product
+                realizing the mechanism is a Technology Stack component referenced through
+                `TOOLS`, the developer-facing rule about the source structure is an aspect of the
+                Development Aspects, and a mechanism driven solely by a `Constraint` requirement
+                (e.g. a hosting or budget mandate) protects no quality and is a Design Decisions
+                decision alone -- only the mechanism, the quality it achieves, and the elements it
+                shapes belong here.
             diagram:
                 type: hub
                 center: self
-                nodes: "[[ARCH:QP.PERSPECTIVE:*]], [[REQS:NR.REQUIREMENT:*]], [[ARCH:FV.COMPONENT:*]], [[ARCH:DP.NODE:*]]"
+                nodes: "[[ARCH:QP.TACTIC:*]], [[REQS:NR.REQUIREMENT:*]], [[ARCH:FV.COMPONENT:*]],
+                    [[ARCH:CO.UNIT:*]], [[ARCH:DA.ASPECT:*]], [[ARCH:DV.NODE:*]], [[DATA:DM.ENTITY:*]],
+                    [[ARCH:OV.CONCERN:*]], [[ARCH:DD.DECISION:*]], [[ARCH:TS.TIER:*.COMPONENT:*]]"
+                labeled: true
                 qualified: true
                 properties:
                     -   QUALITY
@@ -3019,43 +3615,75 @@
             props:
                 -   name: QUALITY
                     desc: >
-                        The quality attribute the perspective addresses, a solution-oriented
+                        The quality attribute the tactic addresses, a solution-oriented
                         refinement of the NON-FUNCTIONAL-REQUIREMENTS categories which intentionally
                         differs from them.
 
                         The NR categories follow the ISO/IEC 25010:2023 top-level characteristics
-                        (and include `Safety` and `Flexibility`) plus the non-quality categories
-                        `Compliance` and `Constraint`, whereas the perspective qualities decompose
-                        some of the characteristics into the finer-grained, architecturally
-                        actionable attributes `Scalability`, `Availability`, `Privacy`,
-                        `Accessibility`, and `Portability`, and address a `Constraint` through the
-                        quality it protects. The quality therefore need not match the category of
-                        the requirements it addresses.
-                    value: enum(Performance,Scalability,Reliability,Availability,Security,Privacy,Usability,Accessibility,Maintainability,Portability,Compatibility,Compliance)
+                        plus the non-quality categories `Compliance` and `Constraint`, whereas the
+                        tactic qualities decompose some of the characteristics into the
+                        finer-grained, architecturally actionable attributes `Scalability`,
+                        `Availability`, `Privacy`, `Accessibility`, and `Portability` (with
+                        `Flexibility` fully absorbed by `Scalability` and `Portability`), and
+                        address a `Compliance` or `Constraint` requirement through the quality it
+                        protects (e.g. a data protection obligation through `Privacy`). The
+                        quality therefore need not match the category of the requirements it
+                        addresses.
+                    value: enum(Performance,Scalability,Reliability,Availability,Safety,Security,Privacy,Usability,Accessibility,Maintainability,Portability,Compatibility)
                 -   name: ADDRESSES
                     desc: >
                         Comma-separated references to the NON-FUNCTIONAL-REQUIREMENTS objects the
-                        perspective addresses.
+                        tactic addresses.
                     value: list([[REQS:NR.*]])
-                -   name: TACTIC
+                -   name: MECHANISM
+                    desc: >
+                        The design mechanism through which the tactic is applied to achieve the
+                        quality (e.g. `stateless replication behind a load balancer`,
+                        `read-through cache`, `circuit breaker`).
+                -   name: TRADES-OFF
                     desc: >
-                        The architectural tactic or strategy applied to achieve the quality (e.g.
-                        `stateless replication behind a load balancer`, `read-through cache`,
-                        `circuit breaker`).
+                        Comma-separated quality attributes (from the same set as `QUALITY`) the
+                        tactic knowingly degrades in favor of the addressed one (e.g. a one-time
+                        token trades `Usability` for `Security`); omitted when the tactic has no
+                        notable cost on another quality.
+                    value: tags(Performance,Scalability,Reliability,Availability,Safety,Security,Privacy,Usability,Accessibility,Maintainability,Portability,Compatibility)
+                    optional: true
                 -   name: AFFECTS
                     desc: >
-                        Comma-separated references to the FUNCTIONALITY-VIEW or DEPLOYMENT-VIEW
-                        objects the tactic affects.
-                    value: list([[ARCH:FV.COMPONENT:*]], [[ARCH:DP.NODE:*]])
+                        Comma-separated references to the FUNCTIONALITY-VIEW, CONCURRENCY-VIEW,
+                        DEVELOPMENT-ASPECTS, DEPLOYMENT-VIEW, DATA-MODEL, AUTHORIZATION-MODEL, or
+                        INTERFACE-MODEL objects the tactic shapes (e.g. the components replicated,
+                        the aspects governing modifiability, the entities anonymized, the roles
+                        and interfaces secured).
+                    value: list([[ARCH:FV.COMPONENT:*]], [[ARCH:CO.UNIT:*]], [[ARCH:DA.ASPECT:*]],
+                        [[ARCH:DV.TIER:*]], [[ARCH:DV.AREA:*]], [[ARCH:DV.NODE:*]], [[ARCH:DV.NETWORK:*]],
+                        [[DATA:DM.ENTITY:*]], [[DATA:AM.ROLE:*]], [[APIS:IM.INTERFACE:*]])
+                    optional: true
+                -   name: OPERATED-BY
+                    desc: >
+                        Comma-separated references to the OPERATIONS-VIEW objects whose procedure
+                        acts upon the design mechanism of the tactic (e.g. the scaling out of the
+                        replication, the restoring of the backup); omitted when no modeled procedure
+                        operates the tactic.
+                    value: list([[ARCH:OV.CONCERN:*]])
+                    optional: true
+                -   name: TOOLS
+                    desc: >
+                        Comma-separated references to the TECHNOLOGY-STACK components realizing the
+                        tactic (e.g. the load balancer, the message broker, the CDN); omitted when
+                        the tactic uses no modeled product.
+                    value: list([[ARCH:TS.TIER:*.COMPONENT:*]])
                     optional: true
-
 -   kind: ARCH
-    name: Decision Record
-    id: DR
-    file: 31-ARCH-DR-Decision-Record.md
+    name: Design Decisions
+    id: DD
+    file: 30-ARCH-DD-Design-Decisions.md
     desc: >
-        The major decisions related to the architecture, each recording the forces at play, the
-        chosen response, and the reasoning that justifies it.
+        The major decisions related to the solution design, each recording the forces at play, the
+        chosen response, and the reasoning that justifies it. The artifact is the last one of the
+        architecture, as a decision references the requirements forcing it, the elements it
+        shapes, and the tactics and products it chose, all of which precede it.
+    optional: true
     refs: >
         -   Nygard: Documenting Architecture Decisions (2011),
             https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
@@ -3065,7 +3693,7 @@
             https://adr.github.io/
     diagram:
         type: grid
-        nodes: "[[ARCH:DR.DECISION:*]]"
+        nodes: "[[ARCH:DD.DECISION:*]]"
         properties:
             -   STATUS
         config:
@@ -3075,53 +3703,48 @@
         -   kind: DECISION
             desc: |
                 A single architecture decision, named with a short summary of the decision, not
-                longer than 80 characters, and recorded as its context (`WHEN`), the decision
-                itself (`WHAT`), its rationale (`WHY`), and optional background (`NOTES`).
+                longer than 80 characters, and recorded entirely in its properties, with no
+                description paragraph of its own: the forces driving it (`DRIVEN-BY`), the options
+                it was chosen over (`ALTERNATIVES`), its context (`WHEN`), the decision itself
+                (`WHAT`), its rationale (`WHY`), and its optional consequences (`CONSEQUENCES`) and
+                background (`NOTES`).
 
                 A decision *MUST* qualify on all of the following three tenets:
-
                 -   **Hard to Reverse**: the cost of changing it later is meaningful ("Oh my god,
                     this would result in a dramatic refactoring!"). So, if a decision is easy to
                     reverse, just skip it.
-
                 -   **Surprising without Context**: a future architect will look at the code and
                     wonder ("Why on earth did they do it this way?"). So, if a decision is not
                     surprising, nobody will wonder why.
-
                 -   **Result of a Real Trade-Off**: there were genuine alternatives and one was
                     picked for specific reasons ("We deliberately chose this, because..."). So, if
                     there was no real alternative, there's nothing to record beyond "we did the
                     obvious thing."
 
                 The following typically qualify as a decision:
-
                 -   **Architectural shape.** "We're using a monorepo." "The write model is
                     event-sourced, the read model is projected into PostgreSQL."
-
                 -   **Integration patterns between contexts.** "Ordering and Billing communicate
                     via domain events, not synchronous HTTP."
-
                 -   **Technology choices that carry lock-in.** Database, message bus, auth
                     provider, deployment target. Not every library - just the ones that would take
                     a quarter to swap out.
-
                 -   **Boundary and scope decisions.** "Customer data is owned by the Customer
                     context; other contexts reference it by ID only." The explicit no's are as
                     valuable as the yes's.
-
                 -   **Deliberate deviations from the obvious path.** "We're using manual SQL
                     instead of an ORM because X." Anything where a reasonable reader would assume
                     the opposite. These stop the next engineer from "fixing" something that was
                     deliberate.
-
-                -   **Constraints not visible in the code.** "We can't use AWS because of
-                    compliance requirements." "Response times must be under 200ms because of the
-                    partner API contract."
-
                 -   **Rejected alternatives when the rejection is non-obvious.** If you considered
                     GraphQL and picked REST for subtle reasons, record it - otherwise someone will
                     suggest GraphQL again in six months.
 
+                A constraint itself is not a decision: a compliance obligation, a hosting mandate,
+                or a partner-imposed threshold is a Non-Functional Requirement (of category
+                `Compliance`, `Constraint`, or the affected quality), and the decision is the
+                response to it, referencing it through `DRIVEN-BY`.
+
                 `WHEN`, `WHAT`, and `WHY` are each just a single paragraph of concise and brief
                 prose text, usually comprised of just 1 to 3 sentences. The value of a decision is
                 in recording *that* a decision was made and *why* - not in filling out sections of
@@ -3138,7 +3761,15 @@
             diagram:
                 type: hub
                 center: self
-                nodes: "[[ARCH:DR.DECISION:*]], [[ARCH:FV.COMPONENT:*]], [[ARCH:DP.NODE:*]]"
+                nodes: "[[ARCH:DD.DECISION:*]], [[REQS:NR.REQUIREMENT:*]], [[REQS:SP.PREMISE:*]],
+                    [[DATA:DM.ENTITY:*]], [[DATA:SM.LIFECYCLE:*]], [[DATA:AM.ROLE:*]],
+                    [[APIS:IM.INTERFACE:*]], [[APIS:ID.TYPE:*]], [[APIS:IE.ENDPOINT:*]],
+                    [[UXUI:IC.PRINCIPLE:*]], [[UXUI:LC.CONVENTION:*]], [[UXUI:DP.PATTERN:*]],
+                    [[UXUI:DS.STORYBOARD:*]], [[UXUI:VD.ELEMENT:*]],
+                    [[ARCH:CV.ENTITY:*]], [[ARCH:FV.COMPONENT:*]], [[ARCH:CO.UNIT:*]],
+                    [[ARCH:DA.ASPECT:*]], [[ARCH:DV.TIER:*]], [[ARCH:DV.AREA:*]], [[ARCH:DV.NODE:*]],
+                    [[ARCH:DV.NETWORK:*]], [[ARCH:QP.TACTIC:*]], [[ARCH:TS.TIER:*.COMPONENT:*]]"
+                labeled: true
                 qualified: true
                 properties:
                     -   STATUS
@@ -3146,22 +3777,65 @@
                     size-node-width-max: 440
             props:
                 -   name: STATUS
+                    desc: |
+                        The status of the decision, one of:
+                        -   `Proposed`:   Under consideration, not yet binding.
+                        -   `Accepted`:   Binding for the solution.
+                        -   `Rejected`:   Considered and deliberately turned down, recorded so
+                                          that it is not proposed again unknowingly.
+                        -   `Deprecated`: No longer binding, without a replacing decision.
+                        -   `Superseded`: Replaced by the decision referenced in `SUPERSEDED-BY`.
+                    value: enum(Proposed,Accepted,Rejected,Deprecated,Superseded)
+                -   name: SUPERSEDED-BY
                     desc: >
-                        The status of the decision: `proposed`, `accepted`, `deprecated`, or
-                        `superseded`.
-                    value: enum(proposed,accepted,deprecated,superseded)
-                -   name: AFFECTS
-                    desc: >
-                        Comma-separated references to the FUNCTIONALITY-VIEW or DEPLOYMENT-VIEW
-                        objects the decision affects.
-                    value: list([[ARCH:FV.COMPONENT:*]], [[ARCH:DP.NODE:*]])
+                        Reference to the DESIGN-DECISIONS object that supersedes this decision,
+                        present if and only if `STATUS` is `Superseded` (which the schema cannot
+                        enforce itself).
+                    value: "[[ARCH:DD.DECISION:*]]"
                     optional: true
-                -   name: SUPERSEDED-BY
+                    acyclic: true
+                -   name: DRIVEN-BY
                     desc: >
-                        Reference to the DECISION-RECORD object that supersedes this decision.
-                        Should be present if and only if `STATUS` is `superseded`.
-                    value: "[[ARCH:DR.DECISION:*]]"
+                        Comma-separated references to the NON-FUNCTIONAL-REQUIREMENTS or
+                        SOLUTION-PREMISES objects forcing the decision (e.g. the compliance
+                        obligation, the budget constraint, the dependency taken as given), anchoring
+                        the forces `WHEN` describes in prose; omitted when no modeled requirement or
+                        premise drives the decision.
+                    value: list([[REQS:NR.*]], [[REQS:SP.PREMISE:*]])
                     optional: true
+                -   name: AFFECTS
+                    desc: >
+                        Comma-separated references to the objects of the DATA, APIS, UXUI, or ARCH
+                        artifacts the decision shapes, i.e. the entities, lifecycles, and roles, the
+                        interfaces, datatypes, and endpoints, the interaction principles, language
+                        conventions, dialog patterns, storyboards, and visual elements, and the
+                        elements of the architecture views (e.g. the entity owned by a single
+                        context, the interface styled REST instead of GraphQL, the dialog pattern
+                        chosen over a native one, the components split, the external system
+                        integrated); omitted for a decision shaping no modeled element.
+                    value: list([[DATA:DM.ENTITY:*]], [[DATA:SM.LIFECYCLE:*]], [[DATA:AM.ROLE:*]],
+                        [[APIS:IM.INTERFACE:*]], [[APIS:ID.TYPE:*]], [[APIS:IE.ENDPOINT:*]],
+                        [[UXUI:IC.PRINCIPLE:*]], [[UXUI:LC.CONVENTION:*]], [[UXUI:DP.PATTERN:*]],
+                        [[UXUI:DS.STORYBOARD:*]], [[UXUI:VD.ELEMENT:*]],
+                        [[ARCH:CV.ENTITY:*]], [[ARCH:FV.COMPONENT:*]], [[ARCH:CO.UNIT:*]],
+                        [[ARCH:DA.ASPECT:*]], [[ARCH:DV.TIER:*]], [[ARCH:DV.AREA:*]], [[ARCH:DV.NODE:*]],
+                        [[ARCH:DV.NETWORK:*]])
+                    optional: true
+                -   name: DECIDES
+                    desc: >
+                        Comma-separated references to the QUALITY-PERSPECTIVES tactics or
+                        TECHNOLOGY-STACK components the decision chose over their alternatives,
+                        i.e. the mechanism or product which exists because of this decision; omitted
+                        when the decision chose no modeled tactic or product.
+                    value: list([[ARCH:QP.TACTIC:*]], [[ARCH:TS.TIER:*.COMPONENT:*]])
+                    optional: true
+                -   name: ALTERNATIVES
+                    desc: >
+                        Comma-separated names of the options considered but not chosen (e.g.
+                        `REST polling, bespoke WebSocket protocol`): the rationale `WHY` states *why*
+                        the decision won, this property states *against what*, and as a decision
+                        qualifies only as the result of a real trade-off, there is always at least
+                        one.
                 -   name: WHEN
                     desc: |
                         The **Context** of the decision: it captures the situation that forces the
@@ -3203,7 +3877,7 @@
                         The **Rationale** of the decision: it is the reasoning that justifies the
                         decision - the bridge that explains why this choice, given those forces. It
                         answers "Of all the things we could have done, why was this the right
-                        one?". Where the context states the forces and the decision states the
+                        one?" Where the context states the forces and the decision states the
                         choice, the rationale is the logical connective tissue between them - it
                         shows that the decision actually follows from the context. The following
                         usually goes into it:
@@ -3216,6 +3890,19 @@
                             on X, option C cost too much on Y"); and
                         -   assumptions and evidence (benchmarks, prior experience, constraints, or
                             principles the reasoning rests on).
+                -   name: CONSEQUENCES
+                    desc: |
+                        The **Consequences** of the decision: what follows from it once made, in
+                        contrast to the trade-off reasoning of `WHY`, which precedes it. It is
+                        *OPTIONAL* and omitted when nothing non-obvious follows. The following
+                        usually goes into it:
+
+                        -   what becomes easier and what becomes harder (the negative consequences
+                            are the valuable ones, as they are the price knowingly paid);
+                        -   the obligations the decision imposes on the elements it affects (e.g.
+                            a convention to follow, a migration to perform); and
+                        -   the follow-up decisions it makes necessary.
+                    optional: true
                 -   name: NOTES
                     desc: |
                         The **Background** of the decision: it is *OPTIONAL* and can be omitted
@@ -3223,254 +3910,154 @@
                         following usually goes into it:
 
                         -   information about the decision *process* (e.g. a weighted decision
-                            matrix of considered alternatives);
-                        -   consequences of the decision (but only when non-obvious downstream
-                            effects need to be called out); and
+                            matrix of considered alternatives); and
                         -   links to strongly related decisions.
                     optional: true
-
--   kind: ARCH
-    name: Technology Stack
-    id: TS
-    file: 32-ARCH-TS-Technology-Stack.md
+-   kind: TEST
+    name: Test Cases
+    id: TC
+    file: 31-TEST-TC-Test-Cases.md
     desc: >
-        The concrete technology products the solution is built upon, organized by tier and lifecycle
-        phase, recording for each component its chosen product, its purpose, and the alternatives
-        that were considered but not chosen.
+        The verifiable conditions and steps used to confirm that requirements, domain rules, use
+        case scenarios, state transitions, and the mechanisms, procedures, and decisions of the
+        architecture are correctly implemented, with mandatory defined inputs, mandatory expected
+        outcomes, and optional pre- and post-conditions. The artifact is the last one, as a test
+        case verifies objects of every preceding kind.
+
+        Test cases are not derived from use cases alone: a use case scenario describes an intent-level
+        flow, while a test case fixes the concrete data and the observable assertions that decide pass
+        or fail, and many test cases (e.g. of Non-Functional Requirements or of cross-session rules)
+        have no use case counterpart at all.
+    optional: true
     refs: >
-        -   ThoughtWorks: Technology Radar (2010),
-            https://www.thoughtworks.com/radar
-        -   Ford: Build Your Own Technology Radar (2013),
-            https://nealford.com/memeagora/2013/05/28/build_your_own_technology_radar.html
-        -   Fowler: Patterns of Enterprise Application Architecture (2002),
-            https://martinfowler.com/books/eaa.html
+        -   ISO/IEC/IEEE 29119-3:2021: Software and systems engineering -- Software testing -- Part 3: Test documentation (2021),
+            https://www.iso.org/standard/79429.html
+        -   ISO/IEC/IEEE 29119-4:2021: Software and systems engineering -- Software testing -- Part 4: Test techniques (2021),
+            https://www.iso.org/standard/79430.html
+        -   ISTQB CTFL 4.0: Certified Tester Foundation Level Syllabus (2023),
+            https://istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/
     diagram:
         type: grid
-        nodes: "[[ARCH:TS.TIER:*]]"
+        nodes: "[[TEST:TC.TEST-CASE:*]]"
+        config:
+            size-node-width-max: 440
+            size-node-height-scale: 2
+            grid-columns-max: 4
     childs:
-        -   kind: TIER
-            name: (?:Client|Server|Middleware|Database)
-            desc: |
-                The architectural tier grouping the technology components belonging to it, one of:
+        -   kind: TEST-CASE
+            desc: >
+                A single verifiable test case, named with a short (3-8 word) summary and defined by
+                its mandatory input and expected outcome plus its optional pre- and post-conditions.
 
-                -   `Client`:     Runs on the client side (e.g. browser, desktop, mobile).
-                -   `Server`:     Runs on the server side (e.g. backend, application, API).
-                -   `Middleware`: Runs between client and server (e.g. message broker, gateway).
-                -   `Database`:   Runs as the data store (e.g. relational or document database).
+                The test case is at verification level: it pins down what the objects it verifies
+                leave open, namely concrete data (e.g. `the correct six-digit token`), a boundary
+                or equivalence class (e.g. `one more question within the same minute`), and an
+                observable assertion, including the negative one (e.g. `the rejected question is
+                not stored and the earlier questions remain unchanged`).
+
+                A test case which merely rephrases a scenario in different words, adding none of these,
+                is redundant and should be sharpened or dropped. Conversely, one scenario can require
+                several test cases (one per boundary or equivalence class), and one test case can
+                verify a requirement, a rule, and a scenario at once.
+
+                A test case whose stimulus is a sequence rather than a single action carries the
+                procedure in its body as sequentially numbered, imperative steps, mirroring the
+                steps of a use case scenario (e.g. `1. The user logs in on device A. 2. The same
+                user logs in on device B.`), with `INPUT` naming the decisive stimulus among them.
+
+                A test case verifying an architecture element asserts the element itself, not the
+                threshold behind it: a threshold is the `METRIC` of a Non-Functional Requirement and
+                verified by referencing the requirement, while a Quality Perspectives tactic is
+                referenced only when its mechanism is the assertion (e.g. that the failover switch
+                happens, not how fast), an Operations View concern when its procedure is rehearsed
+                (e.g. a restore drill), a Deployment View node or network when its topology is
+                inspected (e.g. a port scan proving an `Isolated` segment), a component or
+                concurrency unit when its collaboration or contention is exercised, an aspect of
+                the Development Aspects or a Design Decisions decision when its rule is checked by
+                an architectural fitness function (e.g. no dependency edge against the layering).
             diagram:
                 type: hub
                 center: self
-                hierarchy: true
-                properties:
-                    -   PRODUCT
+                nodes: "[[TEST:TC.TEST-CASE:*]], [[REQS:FR.REQUIREMENT:*]], [[REQS:NR.REQUIREMENT:*]],
+                    [[REQS:DR.RULE:*]], [[REQS:UC.USE-CASE:*.SCENARIO:*]], [[REQS:DW.WORKFLOW:*]],
+                    [[DATA:SM.LIFECYCLE:*.TRANSITION:*]], [[DATA:DM.ENTITY:*.ATTRIBUTE:*]],
+                    [[DATA:AM.ROLE:*.PERMISSION:*]], [[APIS:IE.ENDPOINT:*]],
+                    [[UXUI:DS.STORYBOARD:*.FRAME:*]], [[ARCH:FV.COMPONENT:*]], [[ARCH:CO.UNIT:*]],
+                    [[ARCH:DA.ASPECT:*]], [[ARCH:DV.NODE:*]], [[ARCH:DV.NETWORK:*]],
+                    [[ARCH:OV.CONCERN:*]], [[ARCH:QP.TACTIC:*]], [[ARCH:DD.DECISION:*]]"
+                labeled: true
+                qualified: true
                 config:
                     size-node-width-max: 440
                     size-node-height-scale: 1.75
-            childs:
-                -   kind: COMPONENT
+            props:
+                -   name: VERIFIES
                     desc: >
-                        A single technology component, named with a short (2-5 word) summary (e.g.
-                        `UI Framework`, `Web Server`, `Relational Database`) and described in a
-                        concise (1-3 sentence) paragraph by how the product is used within the
-                        solution and how it fits into the overall technology stack, plus a
-                        1-sentence rationale ("why") for choosing this product over the
-                        alternatives.
-                    props:
-                        -   name: PRODUCT
-                            desc: >
-                                The concrete product, library, or framework chosen for this
-                                component (e.g. `VueJS`, `Node.js`, `PostgreSQL`).
-                        -   name: ALTERNATIVES
-                            desc: >
-                                Comma-separated names of products which would also fit this
-                                component but were not chosen (e.g. `React, Svelte`).
-                            optional: true
-                        -   name: COVERAGE
-                            desc: |
-                                A comma-separated list of either one or more of the *Client
-                                Aspects* or one or more of the *Server Aspects* (or their
-                                sub-aspects) defined below. The general goal is to achieve a
-                                maximum coverage of all aspects per `TIER` with the minimum
-                                total number of `PRODUCT`s.
-
-                                The known *Client Aspects* which usually have to be covered (at
-                                least for clients in a Rich-Client architecture):
-
-                                -   **Interface Theme**:
-                                    Style Reset, Shape, Color, Gradient, Shadow, Font, Icon.
-
-                                -   **Interface Widgets**:
-                                    Icon, Label, Text Paragraph, Image, Form, Text-Field,
-                                    Text-Area, Date Picker, Toggle, Radio Button, Checkbox,
-                                    Select List, Slider, Progress Bar, Hyperlink, Popup Menu,
-                                    Dropdown Menu, Toolbar, Tooltip, Tab, Pill, Breadcrumb,
-                                    Pagination, Badge, Alert, Panel, Modal, Table, Scrollbar,
-                                    Carousel.
-
-                                -   **Interface Layouting**:
-                                    Responsive Design, Media Query, Frame, Grid, Padding, Border,
-                                    Margin, Alignment, Force, Magnetism.
-
-                                -   **Interface Effects**:
-                                    Transition, Transformation, Keyframes, Easing Function, Sound
-                                    Effect, Physics.
-
-                                -   **Interface Interactions**:
-                                    Mouse, Keyboard, Touchscreen, Gesture, Clipboard, Drag & Drop.
-
-                                -   **Interface States**:
-                                    Rendered, Enabled, Visible, Focused, Warning, Error, Floating.
-
-                                -   **Interface Mask**:
-                                    Markup Loading, Markup Generation, Virtual DOM, Text, Bitmaps,
-                                    Vectors, 2D/3D Canvas, Accessibility.
-
-                                -   **Interface Internationalization**:
-                                    Text Internationalization (I18N).
-
-                                -   **Data Conversion**:
-                                    Value Formatting, Value Parsing, Localization (L10N).
-
-                                -   **Data Binding**:
-                                    Reactive, Observer, Unidirectional, Bidirectional, Incremental.
-
-                                -   **Presentation Model**:
-                                    Parameter Value, Command Value, State Value, Data Value, Event
-                                    Value, Value Validation, Presentation Logic.
-
-                                -   **Dialog Navigation**:
-                                    Deep Linking, Routing, Dialog Flow.
-
-                                -   **Dialog Automation**:
-                                    Dialog Macros, Click-Through, Smoke Testing.
-
-                                -   **Dialog Communication**:
-                                    Service, Event, Model, Socket, Hooks.
-
-                                -   **Dialog Life-Cycle**:
-                                    Component States, Component State Transitions.
-
-                                -   **Dialog Structure**:
-                                    Component, Model/View/Controller Roles, Hierarchical
-                                    Composition.
-
-                                -   **State Persistence**:
-                                    Local Storage, Cookies, Caching.
-
-                                -   **Business Model**:
-                                    Entity, Field, Relationship, Universally Unique Identifiers
-                                    (UUID).
-
-                                -   **Use-Case Authorization**:
-                                    User Experience, Dialog Restriction, User, Group, Role,
-                                    Use-Case, Data, Access.
-
-                                -   **Client Networking**:
-                                    Request/Response, Synchronization, Push, Pull, Pulled-Push,
-                                    REST, GraphQL, Authentication, Session.
-
-                                -   **Environment Detection**:
-                                    Runtime Detection, Feature Detection.
-
-                                The known *Server Aspects* which usually have to be covered (at
-                                least for servers, sometimes called Thin-Servers, in a Rich-Client
-                                architecture):
-
-                                -   **Environment Detection**:
-                                    Detect the run-time environment, like underlying operating
-                                    system, execution platform, network topology, feature toggles,
-                                    etc.
-
-                                -   **Argument Parsing**:
-                                    Parse options and arguments of the Command-Line Interface
-                                    (CLI) to bootstrap application parameters.
-
-                                -   **Configuration Parsing**:
-                                    Load and parse directives from a configuration file to
-                                    bootstrap application parameters.
-
-                                -   **Process Daemonizing**:
-                                    Detach from the startup terminal and host process in order to
-                                    run fully independently.
-
-                                -   **Process Management**:
-                                    (Pre-)fork child processes and/or threads of execution and
-                                    monitor and control them during the life-cycle of the
-                                    application.
-
-                                -   **Component Management**:
-                                    Structure the code into components, instantiate them at
-                                    run-time and manage them in a stateful component life-cycle.
-
-                                -   **Component Communication**:
-                                    Provide inter-component communication mechanisms like events,
-                                    hooks, registry, etc.
-
-                                -   **Server Networking**:
-                                    Listen to network sockets, accept connections and manage
-                                    request/response and message communication.
-
-                                -   **Peer Information**:
-                                    Determine unique identification and add-on information about
-                                    the client peer.
-
-                                -   **Session Handling**:
-                                    Manage secured per-connection sessions to keep state between
-                                    communication requests and/or client sessions.
-
-                                -   **User Authentication**:
-                                    Determine and validate the unique identity of the user
-                                    communicating over the current network connection.
-
-                                -   **Request Validation**:
-                                    Validate the syntactical and semantical compliance of the
-                                    requests and sanitize the requests.
-
-                                -   **Request Processing**:
-                                    Process the request by dispatching execution according to the
-                                    provided request and determined context information.
-
-                                -   **Role Authorization**:
-                                    Determine whether the role of the current user is allowed to
-                                    execute the current request.
-
-                                -   **Client Networking**:
-                                    Provide mechanisms to connect to peers over the network and
-                                    perform request/response and/or publish/subscribe
-                                    communication.
-
-                                -   **Task Scheduling**:
-                                    Schedule and execute recurring tasks independent of regular
-                                    I/O operations.
-
-                                -   **Execution Tracing**:
-                                    Provide mechanisms for tracing the execution by logging event
-                                    and measurement information at certain points of interest.
-
-                                -   **Database Access**:
-                                    Map in-memory domain entities onto a data-store-dependent
-                                    persistent data structure.
-
-                                -   **Database Connectivity**:
-                                    Locally or remotely connect the database access layer to the
-                                    underlying data store.
-
-                                -   **Database Schema**:
-                                    Create, update or downgrade the data schema inside the
-                                    underlying data store.
-
-                                -   **Database Bootstrapping**:
-                                    Create, update or downgrade both mandatory bootstrapping and
-                                    optional domain-specific data inside the underlying data
-                                    store.
-                            optional: true
-                        -   name: WHEN
-                            desc: |
-                                The lifecycle phase in which the component is relevant, one of:
-
-                                -   `Build-Time`: Used during development, compilation, or
-                                                  packaging.
-                                -   `Run-Time`:   Used while the solution executes in production.
-                            value: enum(Build-Time,Run-Time)
-                            optional: true
+                        Comma-separated references to the FUNCTIONAL-REQUIREMENTS or
+                        NON-FUNCTIONAL-REQUIREMENTS objects, the DOMAIN-RULES objects, the
+                        USE-CASES scenario objects, the STATE-MODEL transition objects, the
+                        DATA-MODEL attribute objects, the AUTHORIZATION-MODEL permission objects,
+                        the INTERFACE-ENDPOINTS objects, the DIALOG-STORYBOARD frame objects, the
+                        FUNCTIONALITY-VIEW, CONCURRENCY-VIEW, DEVELOPMENT-ASPECTS, DEPLOYMENT-VIEW
+                        (node and network), OPERATIONS-VIEW, and QUALITY-PERSPECTIVES objects,
+                        and/or the DESIGN-DECISIONS objects the test case verifies, so that a
+                        scenario (in particular an `Exceptional` one, judged by its `OUTCOME`) is
+                        covered by an acceptance test beside the requirements it exercises, a rule
+                        (judged by the condition it states) is proven to hold, not just to be
+                        documented, a transition (judged by its `GUARD` and the resulting state) is
+                        proven to be permitted exactly as modeled, an attribute (judged by its
+                        `TYPE` and `CONSTRAINT`) is proven to reject the values outside its range,
+                        pattern, or invariant, a permission (judged by the operations it grants
+                        and, the model being closed, by the ones it denies) is proven to be
+                        enforced, an endpoint (judged by its arguments, options, and results) is
+                        proven to honor its contract, a frame (judged by the dialog step it
+                        storyboards) is proven to be reachable and to behave as storyboarded, a
+                        component or unit (judged by its responsibility and dependencies) is proven
+                        to collaborate and to withstand contention as modeled, an aspect (judged by
+                        the rule it states) is proven to be obeyed by the source structure, a node
+                        or network (judged by its `INSTANCES`, `PART-OF`, and `SCOPE`) is proven to
+                        be deployed and isolated as modeled, a concern (judged by its procedure) is
+                        proven to be performable, a tactic (judged by its `MECHANISM`) is proven to
+                        take effect, and a decision (judged by its `WHAT`) is proven to be complied
+                        with.
+                    value: list([[REQS:*.REQUIREMENT:*]], [[REQS:DR.RULE:*]], [[REQS:UC.USE-CASE:*.SCENARIO:*]],
+                        [[DATA:SM.LIFECYCLE:*.TRANSITION:*]], [[DATA:DM.ENTITY:*.ATTRIBUTE:*]],
+                        [[DATA:AM.ROLE:*.PERMISSION:*]], [[APIS:IE.ENDPOINT:*]],
+                        [[UXUI:DS.STORYBOARD:*.FRAME:*]], [[ARCH:FV.COMPONENT:*]], [[ARCH:CO.UNIT:*]],
+                        [[ARCH:DA.ASPECT:*]], [[ARCH:DV.NODE:*]], [[ARCH:DV.NETWORK:*]],
+                        [[ARCH:OV.CONCERN:*]], [[ARCH:QP.TACTIC:*]], [[ARCH:DD.DECISION:*]])
+                -   name: WORKFLOWS
+                    desc: >
+                        Comma-separated references to the DOMAIN-WORKFLOWS objects the test case
+                        walks through end to end, i.e. whose activities and handoffs its procedure
+                        steps cross in order, so that the collaboration across actors and sittings
+                        (not just the use cases of each single sitting) is proven to work as
+                        modeled; omitted for a test case confined to a single sitting.
+                    value: list([[REQS:DW.WORKFLOW:*]])
+                    optional: true
+                -   name: PRE-CONDITION
+                    desc: >
+                        The state or setup that must hold before the test is executed.
+                    optional: true
+                -   name: INPUT
+                    desc: >
+                        The mandatory, concrete input data or action applied during the test, i.e.
+                        the stimulus whose response the `EXPECTED` judges.
+                -   name: EXPECTED
+                    desc: >
+                        The mandatory, concrete, observable response of the solution to the `INPUT`
+                        (a message shown, a session issued, a submission rejected) that defines a
+                        passing test, as opposed to the `POST-CONDITION` which is the state left
+                        behind. When the test case verifies a NON-FUNCTIONAL-REQUIREMENTS object,
+                        the expected response restates the `METRIC` threshold of that requirement
+                        as the pass criterion (e.g. `p95 latency < 200 ms`) rather than a
+                        qualitative phrase (e.g. `remains responsive`).
+                -   name: POST-CONDITION
+                    desc: >
+                        The persisted state that must hold after the test completes (e.g. `the
+                        authorization token is in state used`), including the state that must not
+                        have changed (e.g. `no session token exists`), as opposed to the `EXPECTED`
+                        which is the immediate response, and omitted for a test whose input leaves
+                        no state behind.
+                    optional: true