@rse/specbook 1.0.3 → 1.0.4

package/dst/specbook-format.yaml

@@ -4,13 +4,100 @@
 ##  Licensed under Apache 2.0 <https://spdx.org/licenses/Apache-2.0>
 ##
 
+#   This is the "Standard" SpecBook schema.
+#
+#   Modeling Purpose
+#   ----------------
+#
+#   This schema allows to specify a large variety 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  |
+#
+#   Legend:
+#   -   PRD:  Product Requirements Document                      (Cagan 2005)
+#   -   StRS: Stakeholder Requirements Specification             (ISO/IEC/IEEE 29148 StRS)
+#   -   SyRS: System Requirements Specification                  (ISO/IEC/IEEE 29148 SyRS)
+#   -   SRS:  Software Requirements Specification                (ISO/IEC/IEEE 29148 SRS)
+#   -   UIS:  Human-Centred Design: User Interface Specification (ISO 9241-210:2019)
+#   -   UISG: User Interface Style Guide                         (ISO 9241-110/-112/-125/-161)
+#   -   TCS:  Test Case Specification                            (ISO/IEC/IEEE 29119-3:2021)
+#   -   AD:   Architecture Description                           (ISO/IEC/IEEE 42010)
+#
+#   Design Decisions
+#   ----------------
+#
+#   -   All object references are strictly back-references, i.e., later
+#       objects reference earlier ones.
+#
+#   -   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.
+#
+#   -   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
+#       those documents separately) the AI should see one coherent
+#       specification document, too.
+#
+
 -   kind: META
     name: Title
     id:   TI
-    file: META-01-TI-Title.md
+    file: 00-META-TI-Title.md
     desc: >
         The top-level specification meta information.
         Some of the information is rendered onto the title page.
+    diagram:
+        type: graph
+        nodes: "[[REQS:*]], [[DATA:*]], [[APIS:*]], [[UXUI:*]], [[TEST:*]], [[ARCH:*]]"
+        deep: true
+        qualified: true
     props:
         -   name: LOGO
             desc: The logo of the specification.
@@ -47,33 +134,263 @@
             value: /^#[0-9a-fA-F]{6}$/
             optional: true
 
--   kind: SPEC
+-   kind: REQS
     name: Solution Vision
     id: SV
-    file: SPEC-01-SV-Solution-Vision.md
+    file: 01-REQS-SV-Solution-Vision.md
     desc: >
-        The high-level, aspirational description of the solution, capturing its purpose, value
-        proposition, and the desired future state it aims to achieve.
+        The high-level, aspirational description of the solution,
+        capturing why it exists, whom it serves, what it is, which
+        benefit it offers, how it differs from the alternatives, where
+        its boundary runs, how its achievement is measured, and the
+        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.
+    refs: >
+        -   ISO/IEC/IEEE 29148:2018: Systems and software engineering -- Life cycle processes -- Requirements engineering (2018),
+            https://www.iso.org/standard/72089.html
+        -   Moore: Crossing the Chasm, 3rd ed. (2014),
+            https://www.harperbusiness.com/book/9780062293008/Crossing-the-Chasm-3rd-Edition-Geoffrey-A.-Moore/
+        -   Pichler: The Product Vision Board (2011),
+            https://www.romanpichler.com/tools/product-vision-board/
+    props:
+        -   name: PURPOSE
+            desc: >
+                Why the solution exists.
+        -   name: TARGET-AUDIENCE
+            desc: >
+                Who the solution serves.
+        -   name: SOLUTION
+            desc: >
+                What the solution is, in a single sentence naming its kind or
+                category (e.g. a self-hosted, browser-based streaming platform).
+        -   name: VALUE-PROPOSITION
+            desc: >
+                The benefit the solution offers its target audience, stated in
+                absolute terms without reference to alternatives.
+        -   name: DIFFERENTIATORS
+            desc: >
+                How the solution stands apart from the alternatives, naming the
+                alternatives it is compared against (including the status quo).
+            optional: true
+        -   name: SCOPE
+            desc: >
+                The boundary of the solution, stating what it deliberately does
+                *not* cover and which adjacent concerns are left to others.
+            optional: true
+        -   name: SUCCESS-CRITERIA
+            desc: >
+                The measurable business outcomes by which the achievement of the
+                vision is judged (e.g. adoption, cost, or time-to-value targets).
+            optional: true
+        -   name: FUTURE-STATE
+            desc: >
+                The desired outcome once the solution is adopted, describing what
+                is true then that is not true today.
+            optional: true
+
+-   kind: REQS
+    name: Solution Premises
+    id: SP
+    file: 02-REQS-SP-Solution-Premises.md
+    desc: >
+        The premises the specification rests on but cannot guarantee itself: the assumptions
+        held true without proof, the dependencies on parties and systems outside the solution,
+        and the risks whose occurrence would endanger it, each rated by the likelihood and
+        the impact of its failure and stating what follows then, so that the requirements
+        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.
+    refs: >
+        -   ISO/IEC/IEEE 29148:2018: Systems and software engineering -- Life cycle processes -- Requirements engineering (2018),
+            https://www.iso.org/standard/72089.html
+        -   Robertson/Robertson: Volere Requirements Specification Template, 18th ed. (2018),
+            https://www.volere.org/templates/volere-requirements-specification-template/
+        -   ISO 31000:2018: Risk management -- Guidelines (2018),
+            https://www.iso.org/standard/65694.html
+        -   Boehm: Software Risk Management: Principles and Practices, IEEE Software 8(1) (1991),
+            https://doi.org/10.1109/52.62930
+    diagram:
+        type: grid
+        nodes: "[[REQS:SP.PREMISE:*]]"
+        properties:
+            -   TYPE
+            -   LIKELIHOOD
+            -   IMPACT
+        config:
+            size-node-width-max: 440
+            size-node-height-scale: 1.75
+            grid-columns-max: 5
     childs:
-        -   kind: ASPECT
+        -   kind: PREMISE
             desc: >
-                A single vision aspect, named with a short (2-5 word) summary and described in a
-                concise (1-3 sentence) paragraph in an aspirational but unambiguous tone.
+                A single premise, named with a short (3-8 word) summary phrased as the fact taken
+                as given or the event feared (e.g. `Streaming Providers Deliver the Video`, `Access
+                URLs Forwarded Beyond the Audience`) and described in a concise (1-3 sentence)
+                paragraph as a declarative statement of what is held true (an `Assumption` or
+                `Dependency`) or what may happen (a `Risk`), plus a 1-sentence rationale ("why")
+                stating the evidence or agreement the premise rests on or the cause the risk stems
+                from.
+
+                A premise is outside the control of the solution (a condition the solution
+                enforces itself is a Domain Rule or a Non-Functional Requirement instead) and
+                states a fact or event, not a decision (a deliberate exclusion is the `SCOPE` of
+                the Solution Vision or a `WONT` requirement instead).
+            format:
+                maxTableColumns: 5
+            props:
+                -   name: TYPE
+                    desc: >
+                        The kind of premise: `Assumption` (a fact about the domain, the users,
+                        or the environment held true without proof, whose falsity changes the
+                        requirements), `Dependency` (a reliance on a party, system, or
+                        deliverable outside the solution, which has to be available and to
+                        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
+                        to be false, the dependency is not honored, or the risk occurs: `Low`,
+                        `Medium`, or `High`.
+                    value: enum(Low,Medium,High)
+                -   name: IMPACT
+                    desc: >
+                        The severity of the `CONSEQUENCE` for the solution once the premise fails:
+                        `Low`, `Medium`, or `High`, so that the product of likelihood and impact
+                        ranks the premises by the attention they need.
+                    value: enum(Low,Medium,High)
+                -   name: CONSEQUENCE
+                    desc: >
+                        What concretely follows for the solution if the premise fails, stated
+                        as a 1-2 sentence description of the harm (e.g. `attendees cannot enter
+                        the event`), justifying the `IMPACT` rating.
+                -   name: MITIGATION
+                    desc: >
+                        What is done to lower the likelihood or the impact of the failure or to
+                        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
 
-                Recommended aspects are `Purpose` (why the solution exists), `Target Audience` (who
-                it serves), `Value Proposition` (the unique benefit offered), `Differentiators` (how
-                it stands apart from alternatives), and `Future State` (the desired outcome once
-                adopted).
+-   kind: REQS
+    name: Domain Glossary
+    id: GL
+    file: 03-REQS-GL-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.
+    refs: >
+        -   ISO 704:2022: Terminology work -- Principles and methods (2022),
+            https://www.iso.org/standard/79077.html
+        -   ISO 1087:2019: Terminology work and terminology science -- Vocabulary (2019),
+            https://www.iso.org/standard/62330.html
+        -   Evans: Domain-Driven Design: Tackling Complexity in the Heart of Software (2003),
+            https://www.domainlanguage.com/ddd/
+    diagram:
+        type: grid
+        nodes: "[[REQS:GL.TERM:*]]"
+        properties:
+            -   TYPE
+        config:
+            size-node-width-max: 440
+            grid-columns-max: 4
+    childs:
+        -   kind: TERM
+            name: "[A-Z][A-Za-z0-9-]*( [A-Z][A-Za-z0-9-]*)*"
+            desc: >
+                A single domain term, named with its canonical, preferred form (each word
+                capitalized, as it should appear in all artifacts) and defined in a concise (1-3
+                sentence) paragraph in business language, independent of any implementation,
+                referencing other terms by their name where helpful.
+
+                The definition is intensional (ISO 704): it opens with the superordinate concept
+                (the `BROADER` term where one exists) and adds the characteristics delimiting the
+                term from its siblings (e.g. `A Message submitted by an Attendee as ...`), so that
+                the hierarchy and the definitions cross-check each other.
+            format:
+                maxTableColumns: 5
+            referenced:
+                -   "[[*]]"
+            diagram:
+                type: hub
+                center: self
+                nodes: "[[REQS:GL.TERM:*]], [[REQS:DR.RULE:*]], [[DATA:DM.ENTITY:*]], [[REQS:UP.PERSONA:*]]"
+                labeled: true
+                qualified: true
+                config:
+                    size-node-width-max: 440
+                    size-node-height-scale: 1.75
+            props:
+                -   name: TYPE
+                    desc: >
+                        The kind of concept the term denotes: `Entity` (a thing of the domain,
+                        usually materialized by a DATA-MODEL entity), `Actor` (a party acting in
+                        the domain, be it a human role usually embodied by a PERSONA or an external
+                        system), or `Activity` (a process or procedure of the domain).
+                    value: enum(Entity,Actor,Activity)
+                -   name: SYNONYMS
+                    desc: >
+                        Comma-separated list of alternative names or abbreviations that refer to the
+                        same term but are *not* the preferred form; a synonym is unambiguous within
+                        the Domain Glossary, so a shorthand shared by several terms (the ambiguity a
+                        `DISTINCT-FROM` marks) is not a synonym of any of them.
+                    optional: true
+                -   name: BROADER
+                    desc: >
+                        Reference to the GLOSSARY term this term is a kind of (or a part of), so
+                        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:*]]"
+                    optional: true
+                    acyclic: true
+                -   name: DISTINCT-FROM
+                    desc: >
+                        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:*]])
+                    optional: true
+                    symmetric: true
 
--   kind: SPEC
+-   kind: REQS
     name: User Personas
     id: UP
-    file: SPEC-02-UP-User-Personas.md
+    file: 04-REQS-UP-User-Personas.md
     desc: >
         The *archetypal* user profiles representing distinct user groups, capturing their goals,
-        needs, behaviors, and context.
-    format:
-        maxTableColumns: 5
+        needs, behaviors, and context, complemented by the non-user stakeholders whose interests
+        the solution has to serve.
+    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
+        -   Cooper et al.: About Face: The Essentials of Interaction Design, 4th ed. (2014),
+            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
     childs:
         -   kind: PERSONA
             desc: >
@@ -81,41 +398,92 @@
                 fictional person and carrying a short, bold first-person quote -- written in the
                 persona's own voice, like a "tagline", "mantra", or "defining statement" -- that
                 captures their core attitude, motivation, frustration, or need in a single memorable
-                line.
+                line. Non-user stakeholders are modeled as personas of type `Stakeholder`.
+            format:
+                maxTableColumns: 5
+            referenced:
+                -   "[[DATA:AM.ROLE:*]]"
             props:
+                -   name: TYPE
+                    desc: >
+                        Whether the persona is a `User` of the solution, i.e. an archetype of the
+                        people directly interacting with it, or a `Stakeholder`, i.e. a party
+                        with a legitimate interest in the solution but without (or beyond) its
+                        direct use -- like a sponsor, regulator, auditor, or operations team --
+                        whose goals and frustrations shape the requirements and constraints, but
+                        whose "quote" reflects an institutional rather than a personal voice;
+                        defaults to `User`.
+                    value: enum(User,Stakeholder)
+                    optional: true
                 -   name: GENDER
                     desc: >
                         The gender of the persona: `male`, `female`, or `diverse`.
                     value: enum(male,female,diverse)
+                    optional: true
                 -   name: AGE
-                    desc: The age in years of the persona.
+                    desc: >
+                        The age in years of the persona.
                     value: /^[0-9]+$/
+                    optional: true
                 -   name: ROLE
-                    desc: The role of the persona.
+                    desc: >
+                        The role of the persona.
+                -   name: TERMS
+                    desc: >
+                        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:*]])
+                    optional: true
+                -   name: PROFICIENCY
+                    desc: >
+                        The technical and domain skill level of the persona: `novice`,
+                        `intermediate`, or `expert`.
+                    value: enum(novice,intermediate,expert)
+                    optional: true
+                -   name: GOAL
+                    desc: >
+                        What the persona wants to achieve with the solution overall, stated as one
+                        or more concise goals.
+                -   name: FRUSTRATION
+                    desc: >
+                        The status-quo pains and unmet needs motivating the persona, stated
+                        independently of the per-step pain points of the User Journey, which
+                        record the friction within the target journey instead.
+                    optional: true
 
--   kind: SPEC
+-   kind: REQS
     name: User Journey
     id: UJ
-    file: SPEC-03-UJ-User-Journey.md
+    file: 05-REQS-UJ-User-Journey.md
     desc: >
         The end-to-end experience a user has while discovering, adopting, and using the solution,
-        mapping their steps, touchpoints, and emotions over time.
+        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.
+    refs: >
+        -   NN/g: Journey Mapping 101 (2018),
+            https://www.nngroup.com/articles/journey-mapping-101/
+        -   Kalbach: Mapping Experiences, 2nd ed. (2020),
+            https://www.oreilly.com/library/view/mapping-experiences-2nd/9781492076629/
+        -   Stickdorn et al.: This Is Service Design Doing (2018),
+            https://www.thisisservicedesigndoing.com/
     diagram:
         type: grid
-        nodes: "[[SPEC:UJ.JOURNEY:*]]"
+        nodes: "[[REQS:UJ.JOURNEY:*]]"
         properties:
-            -   ACTOR
+            -   ACTORS
     childs:
         -   kind: JOURNEY
             desc: >
                 The end-to-end journey of a single persona (or of multiple personas sharing the same
                 experience as role variants), named with a 2-5 word summary of the pursued scenario.
             props:
-                -   name: ACTOR
+                -   name: ACTORS
                     desc: >
                         Comma-separated references to the User Personas objects experiencing the
                         journey.
-                    value: list([[SPEC:UP.PERSONA:*]])
+                    value: list([[REQS:UP.PERSONA:*]])
             childs:
                 -   kind: STEP
                     desc: >
@@ -128,10 +496,11 @@
                                 aware of the solution, but has a need), `Consideration` (the actor
                                 is aware of the solution and considers its use), `Decision` (the
                                 actor wants to pick the solution), `Onboarding` (the actor starts
-                                using the solution), `Retention` (the actor stays a user in the long
-                                term), or `Advocacy` (the actor is a fan of the solution and tells
-                                others).
-                            value: enum(Awareness,Consideration,Decision,Onboarding,Retention,Advocacy)
+                                using the solution for the first time), `Usage` (the actor performs
+                                the recurring core activity the solution is for), `Retention` (the
+                                actor returns, renews, or extends use over the long term), or
+                                `Advocacy` (the actor is a fan of the solution and tells others).
+                            value: enum(Awareness,Consideration,Decision,Onboarding,Usage,Retention,Advocacy)
                         -   name: GOAL
                             desc: What the actor wants to achieve at this step.
                         -   name: TOUCHPOINT
@@ -142,25 +511,41 @@
                             desc: What the actor actually does at this step.
                         -   name: EMOTION
                             desc: >
-                                The **AS IS** felt state at this step, given as a word plus an
-                                intensity on a 1-5 Likert scale (e.g. `Curious (4)`).
-                            value: /^.+ \([1-5]\)$/
+                                The felt state of the actor at this step, given as a word plus its
+                                valence on a signed 5-point Likert scale from `-2` (very negative)
+                                over `0` (neutral) to `+2` (very positive), so that the emotion
+                                curve of the journey can be derived (e.g. `Curious (+1)`).
+                            value: /^.+ \((-[12]|0|\+[12])\)$/
                         -   name: PAIN-POINT
                             desc: >
-                                The **AS IS** friction or frustration the actor encounters at this
-                                step.
+                                The friction or frustration the actor encounters at this step,
+                                i.e. what the solution has to mitigate here.
+                            optional: true
+                        -   name: OPPORTUNITY
+                            desc: >
+                                The improvement the solution delivers (or should deliver) at this
+                                step, mitigating the pain point or reinforcing the positive emotion,
+                                and serving as the seed of Functional Requirements.
                             optional: true
 
--   kind: SPEC
+-   kind: REQS
     name: Functional Requirements
     id: FR
-    file: SPEC-04-FR-Functional-Requirements.md
+    file: 06-REQS-FR-Functional-Requirements.md
     desc: >
         The concrete behaviors and capabilities the solution must provide, describing *what* the
-        system does in terms of functions, features, and operations.
+        system does in terms of functions, features, and operations, while the quality bounds and
+        constraints on them belong to the Non-Functional Requirements.
+    refs: >
+        -   Mavin et al.: Easy Approach to Requirements Syntax (EARS) (2009),
+            https://ieeexplore.ieee.org/document/5328509
+        -   ISO/IEC/IEEE 29148:2018: Systems and software engineering -- Life cycle processes -- Requirements engineering (2018),
+            https://www.iso.org/standard/72089.html
+        -   DSDM: MoSCoW Prioritisation, DSDM Agile Project Framework (2014),
+            https://www.agilebusiness.org/dsdm-project-framework/moscow-prioritisation.html
     diagram:
         type: grid
-        nodes: "[[SPEC:FR.REQUIREMENT:*]]"
+        nodes: "[[REQS:FR.REQUIREMENT:*]]"
         properties:
             -   PRIORITY
         config:
@@ -170,28 +555,47 @@
         -   kind: REQUIREMENT
             desc: >
                 A single functional requirement, named with a short (3-8 word) summary and described
-                in a concise (1-3 sentence) paragraph as *what* the solution must do, written with
-                the keyword `MUST`, `SHOULD`, `COULD`, or `WONT` to indicate the obligation level,
-                plus a 1-sentence rationale ("why").
+                in a concise (1-3 sentence) paragraph as *what* the solution must do, stating
+                exactly one obligation (split into several requirements otherwise) as an observable
+                behavior a test case can verify, written with exactly one keyword `MUST`, `SHOULD`,
+                or `COULD` matching its `PRIORITY`, plus a 1-sentence rationale ("why").
+
+                The statement follows one of the EARS patterns: ubiquitous (`The system MUST ...`),
+                event-driven (`When <trigger>, the system MUST ...`), state-driven (`While <state>,
+                the system MUST ...`), optional-feature (`Where <feature>, the system MUST ...`), or
+                unwanted-behavior (`If <condition>, then the system MUST ...`).
+            format:
+                maxTableColumns: 6
+            referenced:
+                -   "[[REQS:UC.USE-CASE:*]]"
             props:
                 -   name: PRIORITY
                     desc: >
                         The MoSCoW priority of the requirement: `MUST`, `SHOULD`, `COULD`, or
-                        `WONT`. The `WONT` priority records a requirement deliberately excluded from
-                        the current scope ("won't have this time"), preserving the conscious
-                        decision rather than silently dropping it.
+                        `WONT`, matching the keyword of the statement. The `WONT` priority records
+                        a requirement deliberately excluded from the current scope ("won't have this
+                        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)
 
--   kind: SPEC
+-   kind: REQS
     name: Non-Functional Requirements
     id: NR
-    file: SPEC-05-NR-Non-Functional-Requirements.md
+    file: 07-REQS-NR-Non-Functional-Requirements.md
     desc: >
         The quality attributes and constraints the solution must satisfy, such as performance,
         security, scalability, reliability, and usability.
+    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
+        -   ISO/IEC/IEEE 29148:2018: Systems and software engineering -- Life cycle processes -- Requirements engineering (2018),
+            https://www.iso.org/standard/72089.html
+        -   DSDM: MoSCoW Prioritisation, DSDM Agile Project Framework (2014),
+            https://www.agilebusiness.org/dsdm-project-framework/moscow-prioritisation.html
+        -   Doran: There's a S.M.A.R.T. Way to Write Management's Goals and Objectives, Management Review 70(11) (1981)
     diagram:
         type: grid
-        nodes: "[[SPEC:NR.REQUIREMENT:*]]"
+        nodes: "[[REQS:NR.REQUIREMENT:*]]"
         properties:
             -   PRIORITY
             -   CATEGORY
@@ -203,78 +607,487 @@
             desc: >
                 A single non-functional requirement, named with a short (3-8 word) summary and
                 described in a concise (1-3 sentence) paragraph as the quality attribute or
-                constraint the solution must satisfy, plus a 1-sentence rationale ("why").
-
-                The description especially *MUST* contain a *METRIC* within the `CATEGORY`, which
-                (according to the SMART principle) is the *specific*, *measurable*, *achievable*,
-                *relevant*, and *time-bound* threshold or target by which the requirement is judged
-                satisfied (e.g. `p95 latency < 200ms`, `99.9% uptime`).
+                constraint the solution must satisfy, stating exactly one obligation (split into
+                several requirements otherwise) which is verifiable against its `METRIC`, written
+                with exactly one keyword `MUST`, `SHOULD`, or `COULD` matching its `PRIORITY`, plus
+                a 1-sentence rationale ("why").
             props:
                 -   name: PRIORITY
                     desc: >
                         The MoSCoW priority of the requirement: `MUST`, `SHOULD`, `COULD`, or
-                        `WONT`. The `WONT` priority records a requirement deliberately excluded from
-                        the current scope ("won't have this time"), preserving the conscious
-                        decision rather than silently dropping it.
+                        `WONT`, matching the keyword of the statement. The `WONT` priority records
+                        a requirement deliberately excluded from the current scope ("won't have this
+                        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: CATEGORY
                     desc: >
-                        The quality attribute category the requirement addresses, according to the
-                        top-level characteristics of the ISO/IEC 25010:2023 Software-Quality Model
-                        (except for `Functional Suitability`, which is covered by the Functional
-                        Requirements instead).
-                    value: enum(Performance,Compatibility,Usability,Reliability,Security,Safety,Maintainability,Flexibility,Compliance)
+                        The category of the requirement: the quality attribute it addresses,
+                        according to the top-level characteristics of the ISO/IEC 25010:2023
+                        Software-Quality Model (except for `Functional Suitability`, which is
+                        covered by the Functional Requirements instead, and with `Usability` kept
+                        as the name of `Interaction Capability`), plus the two non-quality
+                        categories `Compliance` (a legal or regulatory obligation) and `Constraint`
+                        (a technical, business, or environmental constraint on the *solution*,
+                        e.g. a hosting, budget, or technology mandate, as opposed to a constraint
+                        on the domain, which is a Domain Rule).
+                    value: enum(Performance,Compatibility,Usability,Reliability,Security,Safety,Maintainability,Flexibility,Compliance,Constraint)
+                -   name: QUALIFIES
+                    desc: >
+                        Comma-separated references to the FUNCTIONAL-REQUIREMENTS objects whose
+                        capability the requirement bounds or constrains.
+                    value: list([[REQS:FR.*]])
+                    optional: true
+                -   name: METRIC
+                    desc: >
+                        The threshold or target by which the requirement is judged satisfied,
+                        stated as a scale plus a target value according to the SMART principle
+                        (*specific*, *measurable*, *achievable*, *relevant*, and *time-bound*),
+                        e.g. `p95 latency < 200 ms` or `uptime >= 99.9 % per month`.
 
--   kind: SPEC
-    name: Business Rules
-    id: BR
-    file: SPEC-06-BR-Business-Rules.md
+-   kind: REQS
+    name: Domain Rules
+    id: DR
+    file: 08-REQS-DR-Domain-Rules.md
     desc: >
         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.
+    refs: >
+        -   Hay/Healy: Defining Business Rules ~ What Are They Really? (2000),
+            https://www.businessrulesgroup.org/first_paper/br01c0.htm
+        -   BRG: Business Rules Manifesto (2003),
+            https://www.businessrulesgroup.org/brmanifesto.htm
+        -   OMG DMN 1.5: Decision Model and Notation (2024),
+            https://www.omg.org/spec/DMN/
     diagram:
         type: grid
-        nodes: "[[SPEC:BR.RULE:*]]"
+        nodes: "[[REQS:DR.RULE:*]]"
         properties:
             -   CATEGORY
+            -   SOURCE
         config:
             size-node-width-max: 440
             grid-columns-max: 5
     childs:
         -   kind: RULE
             desc: >
-                A single business rule, named with a short (3-8 word) summary and described in a
+                A single domain rule, named with a short (3-8 word) summary and described in a
                 concise (1-3 sentence) paragraph stating the rule declaratively as a condition that
-                must hold, written with the keyword `MUST`, `SHOULD`, or `MUST NOT` to indicate the
-                obligation level and naming the domain terms it governs (as defined in the
-                Glossary), plus a 1-sentence rationale ("why").
+                must hold, written with the keyword `MUST` or `MUST NOT` (`SHOULD` or `SHOULD NOT`
+                for a `Policy` only, as a `SHOULD` on any other kind contradicts its "must always
+                hold" nature) to indicate the obligation level and naming the domain terms it
+                governs (as defined in the Domain Glossary and listed in `GOVERNS`), plus a 1-sentence
+                rationale ("why"). A permission (`MAY`) is not a rule: state the obligation which
+                bounds the permitted choice instead (e.g. `MUST use only ...` rather than
+                `MAY use ...`).
+
+                The subject of the statement is a domain term, never the system: a rule holds in
+                the problem domain even if the solution were replaced, so if the sentence needs
+                `The system` as its subject, it is a Functional Requirement, not a rule.
+
+                A rule whose outcome depends on more than two conditions is stated as a decision
+                list instead of prose, in the manner of a DMN decision table: a lead sentence
+                naming the governed term and the obligation, an ordered list with one `<condition>:
+                <outcome>` item per case, applied in order with the first matching case winning,
+                and a closing sentence stating the outcome of the remaining cases ("otherwise")
+                and carrying the rationale.
+            format:
+                maxTableColumns: 5
+            referenced:
+                -   "[[TEST:TC.TEST-CASE:*]]"
             props:
                 -   name: CATEGORY
                     desc: >
-                        The kind of rule: `Invariant` (a condition that must always hold),
-                        `Constraint` (a limit on allowed values or actions), `Derivation` (a value
-                        computed from others), or `Policy` (a deliberate business decision or
-                        guideline).
-                    value: enum(Invariant,Constraint,Derivation,Policy)
+                        The kind of rule: `Constraint` (a structural condition that must always
+                        hold, limiting the allowed *domain* states, values, or actions, as opposed
+                        to a constraint on the solution, which is a Non-Functional Requirement),
+                        `Derivation` (a value computed or a fact inferred from others), `Action`
+                        (an obligation triggered by a domain event, stated as `When <trigger>,
+                        <term> MUST ...` and told apart from an event-driven Functional Requirement
+                        by its domain subject alone), or `Policy` (a deliberate business guideline
+                        stated with `SHOULD`/`SHOULD NOT`, which may be deviated from with
+                        justification, whereas the other kinds are stated with `MUST`/`MUST NOT`
+                        and cannot).
+                    value: enum(Constraint,Derivation,Action,Policy)
+                -   name: SOURCE
+                    desc: >
+                        The authority the rule originates from, determining who can change it:
+                        `Law` (a statutory or regulatory obligation, changeable by the legislator
+                        only), `Contract` (an agreement with a customer, partner, or supplier,
+                        changeable by renegotiation only), `Standard` (an industry norm or
+                        standard, deviated from with justification only), `Business` (a deliberate
+                        decision of the organization, changeable by its owner), or `Domain` (an
+                        inherent truth of the problem domain, not changeable without redefining
+                        the domain). The concrete authority (e.g. `GDPR Art. 17`) is named in the
+                        rationale of the rule.
+                    value: enum(Law,Contract,Standard,Business,Domain)
+                    optional: true
+                -   name: GOVERNS
+                    desc: >
+                        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:*]])
+                    optional: true
                 -   name: CONSTRAINS
                     desc: >
                         Comma-separated references to the FUNCTIONAL-REQUIREMENTS or
                         NON-FUNCTIONAL-REQUIREMENTS objects the rule constrains.
-                    value: list([[SPEC:FR.*]], [[SPEC:NR.*]])
+                    value: list([[REQS:FR.*]], [[REQS:NR.*]])
                     optional: true
 
--   kind: SPEC
+-   kind: REQS
+    name: Domain Workflows
+    id: DW
+    file: 09-REQS-DW-Domain-Workflows.md
+    desc: >
+        The cross-actor, multi-sitting workflows of the domain (also known as business
+        processes) the solution takes part in, each an ordered set of activities connected by
+        handoffs between the acting parties, making the collaboration across roles and over time
+        explicit, which neither the User Journey (the experience of a single persona) nor the
+        Use Cases (the goal of a single actor in one sitting) capture. The artifact is absent for
+        a tool-like solution without any workflow spanning several actors or sittings.
+    optional: true
+    refs: >
+        -   OMG: Business Process Model and Notation (BPMN) 2.0.2 (2013),
+            https://www.omg.org/spec/BPMN/2.0.2
+        -   Dumas/La Rosa/Mendling/Reijers: Fundamentals of Business Process Management, 2nd ed. (2018),
+            https://link.springer.com/book/10.1007/978-3-662-56509-4
+        -   van der Aalst: Process Mining: Data Science in Action, 2nd ed. (2016),
+            https://link.springer.com/book/10.1007/978-3-662-49851-4
+    diagram:
+        type: grid
+        nodes: "[[REQS:DW.WORKFLOW:*]]"
+        properties:
+            -   ACTORS
+        config:
+            size-node-width-max: 440
+            size-node-height-scale: 2
+            grid-columns-max: 4
+    childs:
+        -   kind: WORKFLOW
+            desc: >
+                A single workflow, named with a short (2-5 word) summary phrased as the outcome
+                pursued (e.g. `Run Broadcast Event`) and described in a concise (1-3 sentence)
+                paragraph at a glance, plus a 1-sentence rationale ("why") stating the value the
+                organization gains. A workflow is a flat control flow of `ACTIVITY`
+                objects (the work done by one party at a time) connected by `HANDOFF` objects (the
+                passing of control from one activity to the next): exactly one initial activity,
+                at least one final activity, every activity reachable from the initial one, and
+                some final activity reachable from every activity, while a handoff back to an
+                earlier activity (a rework loop) is permitted.
+
+                The workflow is at summary level, above the user-goal level of the Use Cases: it
+                spans several actors and several sittings, and its activities leave the
+                step-by-step interaction with the solution to the use cases referencing them.
+            automaton:
+                nodes: ACTIVITY
+                edges: HANDOFF
+                source: FROM
+                target: TO
+                initial: INITIAL
+                final: FINAL
+            diagram:
+                type: graph
+                edges: "[[REQS:DW.WORKFLOW:*.HANDOFF:*]]"
+                edgeSource: FROM
+                edgeTarget: TO
+                onlyConnected: true
+                properties:
+                    -   ACTOR
+                config:
+                    size-node-width-max: 440
+            props:
+                -   name: ACTORS
+                    desc: >
+                        Comma-separated references to the User Personas objects taking part in the
+                        workflow, in the order of their first appearance, so that every `ACTOR` of
+                        an activity is listed here.
+                    value: list([[REQS:UP.PERSONA:*]])
+                -   name: OWNER
+                    desc: >
+                        Reference to the User Personas object (usually a `Stakeholder`) accountable
+                        for the workflow as a whole, i.e. for its outcome and its rules, as opposed
+                        to the actors performing its activities.
+                    value: "[[REQS:UP.PERSONA:*]]"
+                    optional: true
+                -   name: TRIGGER
+                    desc: >
+                        The event that starts the workflow, stated as a 1-sentence
+                        occurrence (e.g. `A manager decides to hold a broadcast event.`).
+                -   name: OUTCOME
+                    desc: >
+                        The result that holds once the workflow has reached a final
+                        activity (e.g. `The event took place and its results are archived.`).
+                -   name: JOURNEYS
+                    desc: >
+                        Comma-separated references to the User Journey objects the workflow spans,
+                        i.e. the per-persona experiences of which the workflow is the cross-persona
+                        counterpart.
+                    value: list([[REQS:UJ.JOURNEY:*]])
+                    optional: true
+                -   name: TERMS
+                    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:*]])
+                    optional: true
+                -   name: RULES
+                    desc: >
+                        Comma-separated references to the DOMAIN-RULES objects governing the
+                        workflow as a whole (e.g. a deadline or an approval policy), while a rule
+                        checked at a single handoff is referenced from the handoff instead.
+                    value: list([[REQS:DR.RULE:*]])
+                    optional: true
+            childs:
+                -   kind: ACTIVITY
+                    desc: >
+                        A single unit of work within the workflow, performed by one party without a
+                        handoff in between, named with a short (2-5 word) verb phrase (e.g. `Invite
+                        Attendees`) and described by a 1-2 sentence description of what is done and
+                        what it yields. Every activity used in a handoff *MUST* be declared, every
+                        activity *MUST* be reachable from the initial one, and every activity with
+                        no outgoing handoff *MUST* be final.
+                    format:
+                        maxTableColumns: 5
+                    props:
+                        -   name: ACTOR
+                            desc: >
+                                Reference to the User Personas object performing the activity, or
+                                `System` for an activity the solution performs on its own (e.g.
+                                sending the invitations) or `Time` for a waiting period ending with
+                                a deadline; several parties are given only for an activity they
+                                perform jointly, as a change of the acting party is a handoff.
+                            value: list([[REQS:UP.PERSONA:*]], enum(System,Time))
+                        -   name: INITIAL
+                            desc: >
+                                Whether the activity is the initial one, i.e. the single activity
+                                the `TRIGGER` of the workflow starts (exactly one per workflow).
+                            value: /^(?:true|false)$/
+                            unique: enum(true)
+                            present: enum(true)
+                            optional: true
+                        -   name: FINAL
+                            desc: >
+                                Whether the activity is a final one, i.e. one in which the workflow
+                                may legally end with its `OUTCOME` (at least one per workflow).
+                            value: /^(?:true|false)$/
+                            present: enum(true)
+                            optional: true
+                -   kind: HANDOFF
+                    name: "[a-z][a-z-]*"
+                    desc: >
+                        A single passing of control from one activity to the next, named with a
+                        short, lower-cased verb of the completing event (e.g. `approve`, `publish`)
+                        and described by a 1-sentence description of what is passed on
+                        (information, artifact, or notification) and how the receiving party learns
+                        about it. Several handoffs departing from the same activity form a decision
+                        (told apart by their `CONDITION`) or a parallel split, several arriving at
+                        the same activity a merge, and a handoff back to an earlier activity a
+                        rework loop.
+                    format:
+                        maxTableColumns: 6
+                    props:
+                        -   name: FROM
+                            desc: The activity (of the same workflow) the handoff departs from.
+                            value: "[[REQS:DW.WORKFLOW:*.ACTIVITY:*]]"
+                            local: true
+                        -   name: TO
+                            desc: The activity (of the same workflow) the handoff arrives at.
+                            value: "[[REQS:DW.WORKFLOW:*.ACTIVITY:*]]"
+                            local: true
+                        -   name: CONDITION
+                            desc: >
+                                The condition under which the handoff is taken when several
+                                handoffs depart from the same activity, stated as a 1-sentence
+                                statement of what has to hold (e.g. `The rehearsal revealed
+                                defects.`); omitted for an unconditional handoff.
+                            optional: true
+                        -   name: RULES
+                            desc: >
+                                Comma-separated references to the DOMAIN-RULES objects the
+                                handoff enforces, usually through its `CONDITION`.
+                            value: list([[REQS:DR.RULE:*]])
+                            optional: true
+
+-   kind: REQS
+    name: Use Cases
+    id: UC
+    file: 10-REQS-UC-Use-Cases.md
+    desc: >
+        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.
+    refs: >
+        -   Cockburn: Writing Effective Use Cases (2001),
+            https://www.informit.com/store/writing-effective-use-cases-9780201702255
+        -   Jacobson et al.: Object-Oriented Software Engineering: A Use Case Driven Approach (1992),
+            https://www.informit.com/store/object-oriented-software-engineering-a-use-case-driven-9780201544350
+        -   Jacobson/Spence/Bittner: Use-Case 2.0: The Guide to Succeeding with Use Cases (2011),
+            https://www.ivarjacobson.com/publications/white-papers/use-case-20-e-book
+    diagram:
+        type: grid
+        nodes: "[[REQS:UC.USE-CASE:*]]"
+        config:
+            size-node-height-scale: 4
+            grid-columns-max: 4
+    childs:
+        -   kind: USE-CASE
+            desc: >
+                A discrete goal a user pursues with the solution, named with a short (3-8 word)
+                summary phrased as an actor goal (e.g. `Reset Forgotten Password`) and described in
+                a concise (1-3 sentence) paragraph at a glance, plus a 1-sentence rationale ("why")
+                stating the value the actor gains, without prescribing the step-by-step flow, which
+                belongs to its `SCENARIO` objects: exactly one `Main` scenario, listed first,
+                followed by any number of `Alternative` and `Exceptional` scenarios.
+
+                The use case is at user-goal level: a goal the actor completes in one sitting,
+                neither a summary of many sittings and actors (which belongs to a Domain Workflow
+                as a whole, or to a User Journey when seen by a single persona) nor a single
+                interaction (which belongs to a scenario as one of its steps).
+            diagram:
+                type: hub
+                center: self
+                nodes: "[[REQS:UC.USE-CASE:*]], [[REQS:UP.PERSONA:*]], [[REQS:UJ.JOURNEY:*.STEP:*]],
+                    [[REQS:DW.WORKFLOW:*.ACTIVITY:*]], [[REQS:FR.REQUIREMENT:*]], [[REQS:DR.RULE:*]],
+                    [[DATA:SM.LIFECYCLE:*.TRANSITION:*]]"
+                labeled: true
+                qualified: true
+                config:
+                    size-node-width-max: 440
+                    size-node-height-scale: 1.75
+            props:
+                -   name: ACTOR
+                    desc: >
+                        Reference to the PERSONAS object denoting the primary actor pursuing the
+                        goal.
+                    value: "[[REQS:UP.PERSONA:*]]"
+                -   name: JOURNEYS
+                    desc: >
+                        Comma-separated references to the User Journey STEP objects the use case
+                        covers, tracing the journey into the use cases.
+                    value: list([[REQS:UJ.JOURNEY:*.STEP:*]])
+                    optional: true
+                -   name: ACTIVITIES
+                    desc: >
+                        Comma-separated references to the Domain Workflow ACTIVITY objects within
+                        which the actor performs the use case, tracing the workflow into the use
+                        cases; omitted for a use case outside any workflow.
+                    value: list([[REQS:DW.WORKFLOW:*.ACTIVITY:*]])
+                    optional: true
+                -   name: REQUIREMENTS
+                    desc: >
+                        Comma-separated references to the FUNCTIONAL-REQUIREMENTS objects the use
+                        case exercises, i.e. whose behavior its scenarios walk through, so that every
+                        Functional Requirement is exercised by at least one use case.
+                    value: list([[REQS:FR.*]])
+                    optional: true
+                -   name: RULES
+                    desc: >
+                        Comma-separated references to the DOMAIN-RULES objects the scenarios of
+                        the use case apply, i.e. whose condition a scenario step checks or enforces
+                        (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
+                        includes as sub-flows, i.e. whose entire flow one of its scenario steps
+                        invokes (e.g. `The attendee authenticates ([[USE-CASE:authenticate]]).`),
+                        factoring a flow shared by several use cases out into a use case of its own
+                        instead of restating its steps.
+                    value: list([[REQS:UC.USE-CASE:*]])
+                    optional: true
+                    acyclic: true
+                -   name: PRE-CONDITION
+                    desc: >
+                        The condition that must hold before the use case can begin.
+                    optional: true
+                -   name: TRIGGER
+                    desc: >
+                        The event that starts the use case, stated as a 1-sentence occurrence (e.g.
+                        `The attendee opens the event URL.`), as opposed to the `PRE-CONDITION`
+                        which is a state that has to hold, and matching the `When <trigger>` of the
+                        event-driven Functional Requirements the use case exercises.
+                    optional: true
+                -   name: POST-CONDITION
+                    desc: >
+                        The condition that holds after the use case completes successfully.
+                    optional: true
+            childs:
+                -   kind: SCENARIO
+                    desc: >
+                        A concrete step-by-step flow of the use case, named with a short (3-8 word)
+                        summary and comprised of sequentially numbered, imperative steps, each
+                        naming the acting party (actor or system) and the action taken (e.g. `The
+                        user submits their credentials.`). The steps describe the intent and the
+                        information exchanged between actor and system, not the user interface
+                        (dialogs, screens, buttons, and the like), which belongs to the Dialog
+                        Patterns and the Dialog Storyboard instead.
+                    props:
+                        -   name: TYPE
+                            desc: >
+                                The path the scenario represents: `Main` (the primary, happy-path
+                                flow, exactly one per use case), `Alternative` (a valid but
+                                secondary flow), or `Exceptional` (an error or failure-handling
+                                flow).
+                            value: enum(Main,Alternative,Exceptional)
+                            unique: enum(Main)
+                            present: enum(Main)
+                        -   name: RESULT
+                            desc: >
+                                How an `Alternative` or `Exceptional` scenario ends: `Success` (the
+                                goal is reached, possibly in an end state differing from the `Main`
+                                scenario), `Failure` (the goal is abandoned), or `Resume` (the flow
+                                returns to the `Main` scenario at the step named in the `OUTCOME`),
+                                omitted on the `Main` scenario, which ends in the `POST-CONDITION`
+                                of the use case.
+                            value: enum(Success,Failure,Resume)
+                            optional: true
+                        -   name: AT-MAIN-STEP
+                            desc: >
+                                The number of the step of the `Main` scenario at which an
+                                `Alternative` or `Exceptional` scenario branches off: the scenario
+                                shares the preceding steps of the `Main` scenario instead of
+                                restating them, and its own steps, numbered from this number on,
+                                replace the remaining ones (not applicable to the `Main` scenario
+                                itself).
+                            value: /^[1-9][0-9]*$/
+                            optional: true
+                        -   name: OUTCOME
+                            desc: >
+                                The condition that holds when an `Alternative` or `Exceptional`
+                                scenario ends, stated like a post-condition and replacing the
+                                `POST-CONDITION` of the use case for this scenario (naming the
+                                `Main` step at which the flow continues in case of `Resume`),
+                                omitted on the `Main` scenario.
+                            optional: true
+
+-   kind: DATA
     name: Data Model
     id: DM
-    file: SPEC-07-DM-Data-Model.md
+    file: 11-DATA-DM-Data-Model.md
     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.
+    refs: >
+        -   Chen: The Entity-Relationship Model -- Toward a Unified View of Data (1976),
+            https://dl.acm.org/doi/10.1145/320434.320440
+        -   OMG UML 2.5.1: Unified Modeling Language (2017),
+            https://www.omg.org/spec/UML/2.5.1
     diagram:
         type: graph
-        nodes: "[[SPEC:DM.ENTITY:*]]"
-        edges: "[[SPEC:DM.ENTITY:*.RELATION:*]]"
+        nodes: "[[DATA:DM.ENTITY:*]]"
+        edges: "[[DATA:DM.ENTITY:*.RELATION:*]]"
     childs:
         -   kind: ENTITY
             name: "[A-Z][a-zA-Z0-9]*"
@@ -285,10 +1098,25 @@
             diagram:
                 type: hub
                 center: self
-                nodes: "[[SPEC:DM.ENTITY:*]]"
-                edges: "[[SPEC:DM.ENTITY:*.RELATION:*]]"
+                nodes: "[[DATA:DM.ENTITY:*]]"
+                edges: "[[DATA:DM.ENTITY:*.RELATION:*]]"
                 config:
                     size-node-width-max: 440
+            props:
+                -   name: REQUIREMENTS
+                    desc: >
+                        Comma-separated references to the FUNCTIONAL-REQUIREMENTS objects the
+                        entity supports, i.e. whose behavior needs the information it carries,
+                        tracing the requirements into the data model.
+                    value: list([[REQS:FR.*]])
+                    optional: true
+                -   name: TERMS
+                    desc: >
+                        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:*]])
+                    optional: true
             childs:
                 -   kind: ATTRIBUTE
                     name: "[a-z][a-zA-Z0-9]*"
@@ -296,65 +1124,129 @@
                         A named attribute of the entity, carrying a camel-cased, 1-3 word long,
                         per-entity unique identifier, and described by a 1-sentence description
                         ("what") plus a 1-sentence rationale ("why").
+                    format:
+                        maxTableColumns: 6
                     props:
                         -   name: TYPE
                             desc: >
-                                The type of the entity attribute, one of `boolean`, `string`,
-                                `integer`, `float`, `uuid`, `bytes`, `date`, `time`, `datetime`, or
-                                `enum(XXX,YYY[,...])`, optionally prefixed with the qualifier
-                                `unique` to indicate inclusion into the primary key of the entity,
-                                and optionally suffixed with `?` to indicate an optional (nullable)
-                                value.
-                            value: /^(?:unique\s+)?(?:boolean|string|integer|float|uuid|bytes|date|time|datetime|enum\((?:[A-Za-z0-9_]+)(?:,\s*[A-Za-z0-9_]+)*\))(?:\?)?$/
+                                The type of the entity attribute, one of `boolean`, `string`
+                                (short single-line text), `text` (long free-form text), `integer`,
+                                `float` (approximate), `decimal` (exact, e.g. for money), `uuid`,
+                                `bytes`, `date`, `time`, `datetime`, `duration` (time span), or
+                                `enum(XXX,YYY[,...])`, optionally prefixed with the qualifier `key`
+                                to indicate inclusion into the primary key of the entity or `unique`
+                                to indicate an alternate uniqueness constraint, or optionally
+                                suffixed with `?` to indicate an optional (nullable) value, where a
+                                `key` or `unique` attribute cannot be optional.
+                            value: /^(?!(?:key|unique)\s.*\?$)(?:(?:key|unique)\s+)?(?:boolean|string|text|integer|float|decimal|uuid|bytes|date|time|datetime|duration|enum\((?:[A-Za-z0-9_]+)(?:,\s*[A-Za-z0-9_]+)*\))(?:\?)?$/
                         -   name: DEFAULT
                             desc: The default value of the entity attribute.
                             value: /.*/
                             optional: true
+                        -   name: CONSTRAINT
+                            desc: >
+                                The constraint on the value of the entity attribute beyond its type,
+                                as a short phrase stating a range, unit, pattern, or invariant (e.g.
+                                `1..60 seconds`, `RFC 5322 address`, `not before begin`).
+                            value: /.+/
+                            optional: true
+                        -   name: CLASSIFICATION
+                            desc: >
+                                The sensitivity classification of the entity attribute value:
+                                `Public` for a value disclosable to anyone, `Internal` for a value
+                                disclosable within the operating organization only, `Confidential`
+                                for a value disclosable to explicitly authorized persons only (e.g. a
+                                secret or credential), or `Personal` for a value identifying or
+                                relating to a natural person and hence subject to data protection
+                                law (e.g. GDPR); defaults to `Internal`.
+                            value: enum(Public,Internal,Confidential,Personal)
+                            optional: true
+                        -   name: RETENTION
+                            desc: >
+                                The retention of the entity attribute value, as a short phrase
+                                stating the duration or the triggering event beyond which the value
+                                is deleted or anonymized (e.g. `30 days after creation`, `until
+                                event finish`, `until account deletion`); expected on every
+                                `Personal` classified attribute (GDPR Art. 5(1)(e), storage
+                                limitation) and on every `Confidential` classified one, while an
+                                absent retention means the value is kept as long as the entity
+                                exists.
+                            value: /.+/
+                            optional: true
                 -   kind: RELATION
                     name: "[a-z][a-zA-Z0-9]*"
                     desc: >
                         A named directed relation of the entity, carrying a camel-cased, 1-3 word
                         long, per-entity unique identifier and targeting another entity, and
                         described by a 1-sentence description ("what") plus a 1-sentence rationale
-                        ("why").
+                        ("why"). A relation carries no attributes of its own: a relation needing
+                        attributes (an "association class") is reified as an entity of its own,
+                        related from both sides.
                     optional: true
                     props:
-                        -   name: TYPE
+                        -   name: TARGET
                             desc: Reference to the DATA-MODEL entity the directed relation targets.
-                            value: "[[SPEC:DM.ENTITY:*]]"
+                            value: "[[DATA:DM.ENTITY:*]]"
+                        -   name: KIND
+                            desc: >
+                                The kind of the directed relation: `association` for a plain
+                                reference to an independent target entity, `aggregation` for a
+                                shared part-of relation whose target outlives the entity, or
+                                `composition` for an exclusive part-of relation whose target is
+                                owned by and deleted with the entity; defaults to `association`.
+                            value: enum(association,aggregation,composition)
+                            optional: true
                         -   name: ARITY
                             desc: >
                                 The arity (cardinality) of the relation at the target entity: `0..1`
                                 or `?` for zero or one ("optional"), `1` for exactly one
                                 ("mandatory"), `0..n` or `*` for zero or more, `1..n` or `+` for one
-                                or more, or `{n}`/`{n,m}` for an exact number or range.
-                            value: /^(?:\?|\*|\+|\{\d+(?:,\d+)?\}|1|0\.\.1|0\.\.n|1\.\.n)$/
+                                or more, or `{n}`/`{n,m}` for an exact number or range; defaults to
+                                `1`.
+                            value: /^(?:\?|\*|\+|\{\d+(?:,\d+)?\}|1|0\.\.1|0\.\.n|1\.\.n|\d+\.\.\d+)$/
                             optional: true
 
--   kind: SPEC
+-   kind: DATA
     name: State Model
     id: SM
-    file: SPEC-08-SM-State-Model.md
+    file: 12-DATA-SM-State-Model.md
     desc: >
         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.
+    refs: >
+        -   Shlaer/Mellor: Object Lifecycles: Modeling the World in States (1992)
+        -   Harel: Statecharts: A Visual Formalism for Complex Systems (1987),
+            https://doi.org/10.1016/0167-6423(87)90035-9
+        -   OMG UML 2.5.1: Unified Modeling Language (2017),
+            https://www.omg.org/spec/UML/2.5.1
     diagram:
         type: grid
-        nodes: "[[SPEC:SM.LIFECYCLE:*]]"
+        nodes: "[[DATA:SM.LIFECYCLE:*]]"
         properties:
             -   ENTITY
         config:
             size-node-width-max: 440
+            size-node-height-scale: 2
             grid-columns-max: 5
     childs:
         -   kind: LIFECYCLE
             desc: >
                 The lifecycle of a single entity, named with the short (1-3 word) name of the
-                lifecycle, normally the name of the entity it governs.
+                lifecycle, normally the name of the entity it governs. A lifecycle is a flat finite
+                state machine: exactly one initial state, at least one final state, every state
+                reachable from the initial state, and some final state reachable from every state
+                (a state from which no final state can be reached anymore is a livelock).
+            automaton:
+                nodes: STATE
+                edges: TRANSITION
+                source: FROM
+                target: TO
+                initial: INITIAL
+                final: FINAL
             diagram:
                 type: graph
-                edges: "[[SPEC:SM.LIFECYCLE:*.TRANSITION:*]]"
+                edges: "[[DATA:SM.LIFECYCLE:*.TRANSITION:*]]"
                 edgeSource: FROM
                 edgeTarget: TO
                 onlyConnected: true
@@ -366,8 +1258,10 @@
             props:
                 -   name: ENTITY
                     desc: >
-                        Reference to the DATA-MODEL entity whose lifecycle this models.
-                    value: "[[SPEC:DM.ENTITY:*]]"
+                        Reference to the DATA-MODEL entity whose lifecycle this models, at most one
+                        lifecycle per entity (an entity without a lifecycle has a trivial one).
+                    value: "[[DATA:DM.ENTITY:*]]"
+                    unique: true
             childs:
                 -   kind: STATE
                     name: "[A-Z][a-zA-Z0-9]*"
@@ -376,228 +1270,870 @@
                         per-lifecycle unique name (e.g. `Draft`, `Shipped`) and described by a
                         1-sentence description of what holds true in it.
 
-                        Every state used in a transition *MUST* be declared, and every state with no
-                        outgoing transition *MUST* be final (a non-final state with no outgoing
-                        transition would be a stuck dead-end). The converse does *not* hold: a final
-                        state *MAY* still have outgoing transitions, modeling a resting state that
-                        can later be left again (e.g. a `Closed` state with a `reopen` transition
-                        back to `Active`). Thus the final states are a superset of, but not
-                        necessarily equal to, the states without outgoing transitions.
+                        Every state used in a transition *MUST* be declared, every state *MUST* be
+                        reachable from the initial state, and every state with no outgoing
+                        transition *MUST* be final (a non-final state with no outgoing transition
+                        would be a stuck dead-end). The converse does *not* hold: a final state
+                        *MAY* still have outgoing transitions, modeling a resting state that can
+                        later be left again (e.g. a `Closed` state with a `reopen` transition back
+                        to `Active`). Thus the final states are the "accepting" states of the
+                        automaton, a superset of, but not necessarily equal to, the states without
+                        outgoing transitions.
                     props:
                         -   name: INITIAL
                             desc: >
                                 Whether the state is the initial one, i.e. the single state every
-                                instance of the entity enters upon creation.
+                                instance of the entity enters upon creation (exactly one per
+                                lifecycle).
                             value: /^(?:true|false)$/
+                            unique: enum(true)
+                            present: enum(true)
                             optional: true
                         -   name: FINAL
                             desc: >
                                 Whether the state is a final one, i.e. a terminal state in which the
-                                entity may legally come to rest permanently.
+                                entity may legally come to rest permanently (at least one per
+                                lifecycle).
                             value: /^(?:true|false)$/
+                            present: enum(true)
                             optional: true
                 -   kind: TRANSITION
-                    name: "[a-z]+"
+                    name: "[a-z][a-z-]*"
                     desc: >
                         A single permitted transition between two states, named with the short,
                         lower-cased verb of the triggering event or action (e.g. `submit`, `ship`,
                         `cancel`) and described by a 1-sentence description of its side effect
-                        ("what happens"), followed by a ", **WHEN** `<guard>`" clause stating the
-                        condition that must hold for the transition to be permitted. Any move not
-                        listed as a transition is implicitly forbidden.
+                        ("what happens"). The same verb *MAY* name several transitions departing
+                        from different states (told apart by their anchors), and a transition *MAY*
+                        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 the transition departs from.
-                            value: "[[SPEC:SM.LIFECYCLE:*.STATE:*]]"
+                            desc: The state (of the same lifecycle) the transition departs from.
+                            value: "[[DATA:SM.LIFECYCLE:*.STATE:*]]"
+                            local: true
                         -   name: TO
-                            desc: The state the transition arrives at.
-                            value: "[[SPEC:SM.LIFECYCLE:*.STATE:*]]"
+                            desc: The state (of the same lifecycle) the transition arrives at.
+                            value: "[[DATA:SM.LIFECYCLE:*.STATE:*]]"
+                            local: true
+                        -   name: ACTOR
+                            desc: >
+                                Comma-separated references to the PERSONAS objects able to trigger
+                                the transition, and/or `System` for a transition the solution
+                                triggers on its own or `Time` for one triggered by the passing of
+                                time (e.g. an expiry); omitted when the trigger is irrelevant.
+                            value: list([[REQS:UP.PERSONA:*]], enum(System,Time))
+                            optional: true
+                        -   name: GUARD
+                            desc: >
+                                The condition which, beyond being in the `FROM` state, has to be
+                                satisfied for the transition to be permitted, stated as a
+                                1-sentence statement of what has to hold (e.g. `The order has at
+                                least one item.`); omitted when the `FROM` state alone permits it.
+                            optional: true
+                        -   name: RULES
+                            desc: >
+                                Comma-separated references to the DOMAIN-RULES objects the
+                                transition enforces, usually through its `GUARD`.
+                            value: list([[REQS:DR.RULE:*]])
+                            optional: true
 
--   kind: SPEC
-    name: Glossary
-    id: GL
-    file: SPEC-09-GL-Glossary.md
+-   kind: DATA
+    name: Authorization Model
+    id: AM
+    file: 13-DATA-AM-Authorization-Model.md
     desc: >
-        The ubiquitous language of the domain, defining the meaning of each domain term in business
-        language, together with its synonyms and the ambiguities to avoid, shared consistently
-        across all Artifacts.
+        The access rights of the solution, bundled into the roles a person acts in and stating for
+        each role the operations it may perform on each entity, confined to the lifecycle states
+        of the entity and to a further condition where necessary, so that "who may do what on
+        which entity in which state" is answered in one place instead of being scattered over the
+        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.
+    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
+        -   Sandhu/Coyne/Feinstein/Youman: Role-Based Access Control Models, IEEE Computer 29(2) (1996),
+            https://doi.org/10.1109/2.485845
+        -   ANSI INCITS 359-2012: Information Technology -- Role Based Access Control (2012),
+            https://csrc.nist.gov/projects/role-based-access-control
+        -   OASIS: eXtensible Access Control Markup Language (XACML) Version 3.0 (2013),
+            https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html
     diagram:
-        type: grid
-        nodes: "[[SPEC:GL.TERM:*]]"
+        type: graph
+        nodes: "[[DATA:AM.ROLE:*]], [[DATA:DM.ENTITY:*]]"
+        edges: "[[DATA:AM.ROLE:*.PERMISSION:*]]"
+        edgeTarget: ENTITY
+        onlyConnected: true
+        qualified: true
         config:
             size-node-width-max: 440
-            grid-columns-max: 5
     childs:
-        -   kind: TERM
+        -   kind: ROLE
             desc: >
-                A single domain term, named with its canonical, preferred form (capitalized as it
-                should appear in all artifacts) and defined in a concise (1-3 sentence) paragraph in
-                business language, independent of any implementation, referencing other terms by
-                their name where helpful.
+                A single role, named with the canonical name of the domain role it grants (e.g.
+                `Moderator`, matching its GLOSSARY term of type `Actor`) and described in a concise
+                (1-2 sentence) paragraph by the responsibility the role carries, plus a 1-sentence
+                rationale ("why") stating why the rights are bundled this way. A role is the unit
+                in which rights are granted to a person: the personas embodying it hold exactly
+                its `PERMISSION` objects (plus those of the roles it `INHERITS`), while a persona
+                holding several roles holds the union of their permissions.
+            diagram:
+                type: hub
+                center: self
+                deep: true
+                nodes: "[[DATA:AM.ROLE:*]], [[REQS:UP.PERSONA:*]], [[REQS:GL.TERM:*]], [[DATA:DM.ENTITY:*]],
+                    [[REQS:DR.RULE:*]]"
+                labeled: true
+                qualified: true
+                config:
+                    size-node-width-max: 440
+                    size-node-height-scale: 1.75
             props:
-                -   name: SYNONYMS
+                -   name: ACTORS
+                    desc: >
+                        Comma-separated references to the User Personas objects embodying the
+                        role, i.e. the personas acting with exactly its rights, so that every
+                        persona holds at least one role and its rights are stated here rather than
+                        implied by its `ROLE` description, and/or to the GLOSSARY terms of type
+                        `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:*]])
+                -   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:*]]"
+                    optional: true
+                -   name: INHERITS
+                    desc: >
+                        Comma-separated references to the other ROLE objects whose permissions
+                        this role holds in addition to its own (a role hierarchy, e.g. a manager
+                        inheriting the rights of a moderator), where an inherited permission is
+                        not restated.
+                    value: list([[DATA:AM.ROLE:*]])
+                    optional: true
+                    acyclic: true
+            childs:
+                -   kind: PERMISSION
+                    desc: >
+                        A single right of the role on a single entity, named with a short (2-5
+                        word) verb phrase of what the role may do (e.g. `Decide Pending Messages`)
+                        and described by a 1-sentence description of the right, in particular of
+                        the reach of its `CONDITION`. One permission covers one entity: the
+                        operations it grants, the states of the entity in which they are granted,
+                        and the condition under which they are granted, so that the permissions
+                        of all roles form the access matrix of roles against entities. Any
+                        operation, state, or condition not covered by a permission of the role (or
+                        of an inherited one) is forbidden.
+                    format:
+                        maxTableColumns: 7
+                    props:
+                        -   name: ENTITY
+                            desc: Reference to the DATA-MODEL entity the permission is granted on.
+                            value: "[[DATA:DM.ENTITY:*]]"
+                        -   name: OPERATIONS
+                            desc: >
+                                Comma-separated operations the role may perform on the entity: the
+                                generic `Create`, `Read`, `Update`, and `Delete`, and/or references
+                                to the STATE-MODEL transitions of the entity the role may trigger
+                                (a state change is not an `Update`: it is granted by its transition
+                                only), where every persona named as `ACTOR` of a transition holds
+                                a role granting it.
+                            value: list(enum(Create,Read,Update,Delete), [[DATA:SM.LIFECYCLE:*.TRANSITION:*]])
+                        -   name: STATES
+                            desc: >
+                                Comma-separated references to the STATE-MODEL states of the entity
+                                in which the operations are granted (`Create` needs none, as a
+                                creation enters the initial state); omitted when granted in every
+                                state or when the entity has no lifecycle.
+                            value: list([[DATA:SM.LIFECYCLE:*.STATE:*]])
+                            optional: true
+                        -   name: CONDITION
+                            desc: >
+                                The condition which, beyond the role and the `STATES`, has to hold
+                                for the operations to be granted, stated as a 1-sentence statement
+                                of what has to hold, typically the ownership of the instance (e.g.
+                                `The attendee is the sender of the message.`), a confinement to
+                                certain attributes (e.g. `The update is confined to the presenter
+                                alert.`), or a configuration of the surrounding entity; omitted
+                                when the role and the states alone grant the operations.
+                            optional: true
+                        -   name: RULES
+                            desc: >
+                                Comma-separated references to the DOMAIN-RULES objects justifying
+                                or bounding the permission, i.e. the rules whose statement grants
+                                or limits the right.
+                            value: list([[REQS:DR.RULE:*]])
+                            optional: true
+
+-   kind: APIS
+    name: Interface Model
+    id: IM
+    file: 14-APIS-IM-Interface-Model.md
+    desc: >
+        The machine-facing interfaces the solution provides to, or requires from, other programs
+        (REST, GraphQL, gRPC, WebSocket, MQTT, AMQP, MCP, CLI, library, or custom ones), each
+        described by its kind, direction, location, and consumers, while the named types,
+        constants, and endpoints of all interfaces are modeled generically in the
+        INTERFACE-DATATYPES and INTERFACE-ENDPOINTS artifacts, whose objects reference the
+        interfaces they belong to. The artifact is absent when the solution neither provides nor
+        requires any machine-facing interface.
+    optional: true
+    refs: >
+        -   OpenAPI Initiative: OpenAPI Specification 3.1 (2021),
+            https://spec.openapis.org/oas/v3.1.0
+        -   GraphQL Foundation: GraphQL Specification (2021),
+            https://spec.graphql.org/October2021/
+        -   OASIS: MQTT Version 5.0 (2019),
+            https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html
+        -   Anthropic: Model Context Protocol Specification (2025),
+            https://modelcontextprotocol.io/specification/
+        -   IEEE/The Open Group: POSIX.1-2024, Utility Conventions (2024),
+            https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap12.html
+    diagram:
+        type: grid
+        nodes: "[[APIS:IM.INTERFACE:*]]"
+        properties:
+            -   KIND
+            -   DIRECTION
+    childs:
+        -   kind: INTERFACE
+            desc: >
+                A single interface, named with a short (2-5 word) summary (e.g. `Public REST API`,
+                `Event Topics`, `Command Line`) and described in a concise (1-3 sentence) paragraph
+                by its purpose and its consumers, plus a 1-sentence rationale ("why") for the
+                interface's existence and boundary. All kinds of interfaces share the same model:
+                the INTERFACE-DATATYPES `TYPE` objects are the data shapes exchanged (carrying the
+                fixed values agreed upon as their `CONSTANT` objects) and the INTERFACE-ENDPOINTS
+                `ENDPOINT` objects the operations offered, each referencing the interfaces it
+                belongs to, where the kind-specific parts (HTTP method, GraphQL operation, topic
+                direction, command) are carried by the `OPERATION` and `LOCATOR` properties of the
+                endpoints only.
+            diagram:
+                type: hub
+                center: self
+                nodes: "[[APIS:IM.INTERFACE:*]], [[APIS:ID.TYPE:*]], [[APIS:IE.ENDPOINT:*]]"
+                labeled: true
+                qualified: true
+                config:
+                    size-node-width-max: 440
+            props:
+                -   name: KIND
+                    desc: |
+                        The kind of the interface, one of:
+                        -   `REST`:      HTTP resources addressed by URL paths and HTTP methods.
+                        -   `GraphQL`:   A GraphQL schema of queries, mutations, and subscriptions.
+                        -   `gRPC`:      Protocol Buffers based remote procedure calls.
+                        -   `WebSocket`: Messages exchanged over a WebSocket connection.
+                        -   `MQTT`:      Messages published to and subscribed from MQTT topics.
+                        -   `MCP`:       Tools, resources, and prompts of a Model Context Protocol server.
+                        -   `CLI`:       Commands, options, and arguments of a command-line program.
+                        -   `Library`:   Functions, methods, and classes of a programming language library.
+                        -   `Custom`:    Any other kind of interface, explained in the description.
+                    value: enum(REST,GraphQL,gRPC,WebSocket,MQTT,MCP,CLI,Library,Custom)
+                -   name: DIRECTION
+                    desc: >
+                        Whether the interface is `Provided` by the solution to its consumers or
+                        `Required` by the solution from an external system; defaults to `Provided`.
+                    value: enum(Provided,Required)
+                    optional: true
+                -   name: LOCATION
                     desc: >
-                        Comma-separated list of alternative names or abbreviations that refer to the
-                        same term but are *not* the preferred form.
+                        Where the interface is reached, depending on its `KIND`: the base URL
+                        (e.g. `https://api.example.com/v1`), the broker URL or topic prefix (e.g.
+                        `wss://broker.example.com/mqtt`, `event/`), the server name (MCP), the
+                        executable name (e.g. `specbook`), or the package or module name (e.g.
+                        `@rse/specbook`).
+                -   name: VERSION
+                    desc: The version of the interface contract (e.g. `1.2`, `2026-08`).
+                    optional: true
+                -   name: CONSUMERS
+                    desc: >
+                        Comma-separated references to the PERSONAS objects which use the interface
+                        (the external systems using it reference the interface from the
+                        CONTEXT-VIEW instead).
+                    value: list([[REQS:UP.PERSONA:*]])
                     optional: true
 
--   kind: SPEC
-    name: Use Cases
-    id: UC
-    file: SPEC-10-UC-Use-Cases.md
+-   kind: APIS
+    name: Interface Datatypes
+    id: ID
+    file: 15-APIS-ID-Interface-Datatypes.md
     desc: >
-        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.
+        The named data types exchanged through the machine-facing interfaces of the INTERFACES
+        artifact, modeled generically for all kinds of interfaces: a type is either an object
+        type composed of fields or a scalar, enumeration, alias, or union type, carries the fixed
+        values agreed upon as its constants, and references the interfaces it is exchanged
+        through, so that one type serves several interfaces. The artifact is absent when the
+        solution neither provides nor requires any machine-facing interface.
+    optional: true
+    refs: >
+        -   OpenAPI Initiative: OpenAPI Specification 3.1 (2021),
+            https://spec.openapis.org/oas/v3.1.0
+        -   GraphQL Foundation: GraphQL Specification (2021),
+            https://spec.graphql.org/October2021/
     diagram:
-        type: grid
-        nodes: "[[SPEC:UC.USE-CASE:*]]"
+        type: graph
+        nodes: "[[APIS:ID.TYPE:*]]"
+        deep: true
+        onlyConnected: true
+        qualified: true
+        config:
+            size-node-width-max: 440
     childs:
-        -   kind: USE-CASE
+        -   kind: TYPE
+            name: "[A-Z][A-Za-z0-9_]*"
             desc: >
-                A discrete goal a user pursues with the solution, named with a short (3-8 word)
-                summary phrased as an actor goal (e.g. `Reset Forgotten Password`) and described in
-                a concise (1-3 sentence) paragraph at a glance, without prescribing the step-by-step
-                flow (which belongs to its `SCENARIO` objects).
+                A named data type exchanged through one or more interfaces, carrying a
+                Pascal-cased, unique name (e.g. `Event`, `ChatMessage`, `Diagnostic`) and
+                described by a 1-sentence description ("what") plus a 1-sentence rationale
+                ("why"). A type without a `BASE` is an object type composed of its `FIELD`
+                objects (plus the fields of the object types it `EXTENDS`); a type with a
+                `BASE` is a scalar, enumeration, alias, or union type without fields. Either
+                kind of type additionally carries the named fixed values agreed upon through
+                its interfaces as its `CONSTANT` objects.
+            optional: true
             diagram:
                 type: hub
                 center: self
-                nodes: "[[SPEC:UC.USE-CASE:*]], [[SPEC:UP.PERSONA:*]], [[SPEC:FR.REQUIREMENT:*]]"
+                nodes: "[[APIS:ID.TYPE:*]], [[APIS:IM.INTERFACE:*]]"
+                deep: true
+                labeled: true
                 qualified: true
                 config:
-                    size-node-width-max: 440
+                    size-node-width-max: 600
+                    size-node-height-scale: 1.75
             props:
-                -   name: ACTOR
+                -   name: INTERFACES
                     desc: >
-                        Reference to the PERSONAS object denoting the primary actor pursuing the
-                        goal.
-                    value: "[[SPEC:UP.PERSONA:*]]"
-                -   name: REQUIREMENTS
+                        Comma-separated references to the INTERFACE-MODEL objects the type is
+                        exchanged through, i.e. the interfaces whose endpoints consume or return it,
+                        directly or through the fields of another type.
+                    value: list([[APIS:IM.INTERFACE:*]])
+                -   name: BASE
                     desc: >
-                        Comma-separated references to the FUNCTIONAL-REQUIREMENTS objects the use
-                        case realizes.
-                    value: list([[SPEC:FR.*]])
+                        The underlying type of a non-object (value) type: one of the primitives
+                        `boolean`, `string` (short single-line text), `text` (long
+                        free-form text), `integer`, `float` (approximate), `decimal`
+                        (exact, e.g. for money), `uuid`, `bytes`, `date`, `time`,
+                        `datetime`, `duration` (time span), or `any` (a named scalar), an
+                        enumeration `enum(XXX,YYY[,...])`, or a reference to another `TYPE`
+                        object (an alias), where several
+                        comma-separated alternatives form a named union type; omitted for
+                        an object type composed of fields.
+                    value: list([[APIS:ID.TYPE:*]], /^(?:boolean|string|text|integer|float|decimal|uuid|bytes|date|time|datetime|duration|any|enum\((?:[A-Za-z0-9_-]+)(?:,\s*[A-Za-z0-9_-]+)*\))$/)
                     optional: true
-                -   name: GOAL
-                    desc: >
-                        The 1-sentence statement of what the actor wants to achieve through this use
-                        case.
-                -   name: PRE-CONDITION
+                -   name: EXTENDS
                     desc: >
-                        The condition that must hold before the use case can begin.
+                        Comma-separated references to the object types whose fields this
+                        object type inherits in addition to its own, so its instances carry
+                        the fields of all of them (e.g. a message type extending a common
+                        envelope type, or a GraphQL type implementing interfaces), where an
+                        inherited field is not redeclared; omitted for a type carrying a
+                        `BASE`.
+                    value: list([[APIS:ID.TYPE:*]])
+                    acyclic: true
                     optional: true
-                -   name: POST-CONDITION
+                -   name: MATERIALIZES
                     desc: >
-                        The condition that holds after the use case completes successfully.
+                        Comma-separated references to the DATA-MODEL entities the type
+                        materializes (e.g. as a data transfer object carrying the
+                        attributes of one entity, or as a view flattening several
+                        entities), tracing the interface into the data model.
+                    value: list([[DATA:DM.ENTITY:*]])
                     optional: true
             childs:
-                -   kind: SCENARIO
+                -   kind: FIELD
+                    name: "[A-Za-z_][A-Za-z0-9_-]*"
                     desc: >
-                        A concrete step-by-step flow of the use case, named with a short (3-8 word)
-                        summary and comprised of sequentially numbered, imperative steps, each
-                        naming the acting party (actor or system) and the action taken (e.g. `The
-                        user submits the login form.`).
+                        A named field of an object type, carrying a per-type unique
+                        identifier in the naming convention of the interface (e.g.
+                        `eventId`, `event_id`, `event-id`) and described by a 1-sentence
+                        description ("what") plus a 1-sentence rationale ("why").
+                    optional: true
+                    format:
+                        maxTableColumns: 5
                     props:
                         -   name: TYPE
                             desc: >
-                                The path the scenario represents: `Main` (the primary, happy-path
-                                flow), `Alternative` (a valid but secondary flow), or `Exceptional`
-                                (an error or failure-handling flow).
-                            value: enum(Main,Alternative,Exceptional)
-
--   kind: SPEC
-    name: Test Cases
-    id: TC
-    file: SPEC-11-TC-Test-Cases.md
+                                The type of the field: a reference to a `TYPE` object of
+                                the interface, one of the primitives `boolean`, `string`,
+                                `text`, `integer`, `float`, `decimal`, `uuid`, `bytes`,
+                                `date`, `time`, `datetime`, `duration`, or `any`, or an inline
+                                enumeration `enum(XXX,YYY[,...])` (a reusable one is a `TYPE`
+                                object with an `enum(...)` base), where several comma-separated
+                                alternatives form a union type.
+                            value: list([[APIS:ID.TYPE:*]], /^(?:boolean|string|text|integer|float|decimal|uuid|bytes|date|time|datetime|duration|any|enum\((?:[A-Za-z0-9_-]+)(?:,\s*[A-Za-z0-9_-]+)*\))$/)
+                        -   name: ARITY
+                            desc: >
+                                The arity (cardinality) of the field value: `0..1` or `?`
+                                for zero or one ("optional"), `1` for exactly one
+                                ("mandatory"), `0..n` or `*` for zero or more, `1..n` or
+                                `+` for one or more, or `{n}`/`{n,m}` for an exact number
+                                or range; defaults to `1`.
+                            value: /^(?:\?|\*|\+|\{\d+(?:,\d+)?\}|1|0\.\.1|0\.\.n|1\.\.n|\d+\.\.\d+)$/
+                            optional: true
+                        -   name: DEFAULT
+                            desc: The default value of the field.
+                            value: /.*/
+                            optional: true
+                        -   name: CONSTRAINT
+                            desc: >
+                                The constraint on the value of the field beyond its type,
+                                as a short phrase stating a range, unit, pattern, or
+                                invariant (e.g. `1..100`, `RFC 5322 address`).
+                            value: /.+/
+                            optional: true
+                -   kind: CONSTANT
+                    name: "[A-Za-z_][A-Za-z0-9_-]*"
+                    desc: >
+                        A named fixed value of the type, agreed upon through the interfaces of
+                        the type, carrying a per-type unique identifier in the naming convention
+                        of the interfaces (e.g. `MAX_PAGE_SIZE`, `defaultPort`, `topic-prefix`)
+                        and described by a 1-sentence description ("what") plus a 1-sentence
+                        rationale ("why").
+                    optional: true
+                    format:
+                        maxTableColumns: 5
+                    props:
+                        -   name: TYPE
+                            desc: >
+                                The value type of the constant, i.e. the type its literal `VALUE`
+                                is of: one of the primitives `boolean`, `string`, `text`,
+                                `integer`, `float`, `decimal`, `uuid`, `bytes`, `date`, `time`,
+                                `datetime`, `duration`, or `any`, an inline enumeration
+                                `enum(XXX,YYY[,...])`, or a reference to a non-object `TYPE`
+                                object (a scalar, enumeration, alias, or union
+                                type carrying a `BASE`); an object type composed of fields is no
+                                value type and hence not admitted, as a literal cannot express it.
+                            value: list([[APIS:ID.TYPE:*]], /^(?:boolean|string|text|integer|float|decimal|uuid|bytes|date|time|datetime|duration|any|enum\((?:[A-Za-z0-9_-]+)(?:,\s*[A-Za-z0-9_-]+)*\))$/)
+                        -   name: VALUE
+                            desc: >
+                                The literal value of the constant (e.g. `100`, `event/`), matching
+                                its `TYPE`.
+                            value: /.+/
+-   kind: APIS
+    name: Interface Endpoints
+    id: IE
+    file: 16-APIS-IE-Interface-Endpoints.md
     desc: >
-        The verifiable conditions and steps used to confirm that requirements are correctly
-        implemented, with mandatory defined inputs, mandatory expected outcomes, and optional pre-
-        and post-conditions.
+        The operations offered by the machine-facing interfaces of the INTERFACE-MODEL artifact,
+        modeled generically for all kinds of interfaces: an endpoint references the interface it
+        belongs to and consumes the INTERFACE-DATATYPES types and constants through its positional
+        arguments and named options and returns them through its results. The artifact is absent
+        when the solution neither provides nor requires any machine-facing interface.
+    optional: true
+    refs: >
+        -   OpenAPI Initiative: OpenAPI Specification 3.1 (2021),
+            https://spec.openapis.org/oas/v3.1.0
+        -   GraphQL Foundation: GraphQL Specification (2021),
+            https://spec.graphql.org/October2021/
+        -   OASIS: MQTT Version 5.0 (2019),
+            https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html
+        -   Anthropic: Model Context Protocol Specification (2025),
+            https://modelcontextprotocol.io/specification/
+        -   IEEE/The Open Group: POSIX.1-2024, Utility Conventions (2024),
+            https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap12.html
     diagram:
-        type: grid
-        nodes: "[[SPEC:TC.TEST-CASE:*]]"
+        type: graph
+        nodes: "[[APIS:IE.ENDPOINT:*]], [[APIS:ID.TYPE:*]]"
+        deep: true
+        onlyConnected: true
+        qualified: true
+        config:
+            size-node-width-max: 440
     childs:
-        -   kind: TEST-CASE
+        -   kind: ENDPOINT
+            name: "[A-Za-z_][A-Za-z0-9_-]*"
             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.
+                A single operation of an interface, carrying a technical, unique name in the
+                naming convention of its interface (e.g. `createEvent`, `chat_message`, `lint`)
+                and described by a 1-sentence description ("what") plus a 1-sentence rationale
+                ("why").
+
+                An endpoint consumes its input through its positional `ARGUMENT` objects
+                (in document order, e.g. the URL path placeholders, a request body, a message
+                payload, or the operands of a command) and its named `OPTION` objects (e.g. the
+                query parameters, the arguments of a GraphQL field or MCP tool, or the
+                options of a command), and returns its output through its `RESULT`
+                objects (e.g. a response body, a subscription message, or the output and
+                exit code of a command).
+
+                Endpoints form a flat list: a hierarchy of sub-commands or sub-resources
+                is expressed by a path-style `LOCATOR` (e.g. `remote add`,
+                `/events/{eventId}/chat`) only.
             diagram:
                 type: hub
                 center: self
-                nodes: "[[SPEC:TC.TEST-CASE:*]], [[SPEC:FR.REQUIREMENT:*]], [[SPEC:NR.REQUIREMENT:*]]"
+                nodes: "[[APIS:IE.ENDPOINT:*]], [[APIS:ID.TYPE:*]], [[APIS:ID.TYPE:*.CONSTANT:*]], [[APIS:IM.INTERFACE:*]],
+                    [[DATA:AM.ROLE:*.PERMISSION:*]]"
+                deep: true
+                labeled: true
                 qualified: true
                 config:
-                    size-node-width-max: 440
+                    size-node-width-max: 600
+                    size-node-height-scale: 1.75
             props:
-                -   name: VERIFIES
+                -   name: INTERFACE
+                    desc: The INTERFACES object the endpoint belongs to and is addressed within.
+                    value: "[[APIS:IM.INTERFACE:*]]"
+                -   name: PERMISSIONS
                     desc: >
-                        Reference to the FUNCTIONAL-REQUIREMENTS or NON-FUNCTIONAL-REQUIREMENTS
-                        object the test case verifies.
-                    value: "[[SPEC:*.REQUIREMENT:*]]"
-                -   name: PRE-CONDITION
+                        Comma-separated references to the AUTHORIZATION-MODEL permission objects
+                        the endpoint enforces, i.e. the rights (of a persona or an external system,
+                        through one of their roles) a caller has to hold for the endpoint to serve
+                        the operation, so that the authorization of every endpoint is stated
+                        rather than left to the implementation; omitted for an endpoint open to
+                        every caller.
+                    value: list([[DATA:AM.ROLE:*.PERMISSION:*]])
+                    optional: true
+                -   name: OPERATION
+                    desc: |
+                        The kind-specific operation the endpoint performs, one of:
+                        -   `GET`, `POST`, `PUT`, `PATCH`, `DELETE`, `HEAD`, `OPTIONS`:
+                            the HTTP method (`REST`).
+                        -   `query`, `mutation`, `subscription`: the GraphQL operation
+                            type (`GraphQL`).
+                        -   `call`, `stream`: a unary or streaming remote procedure call
+                            (`gRPC`).
+                        -   `publish`, `subscribe`: the message direction from the
+                            perspective of the interface consumer (`WebSocket`, `MQTT`,
+                            `AMQP`).
+                        -   `tool`, `resource`, `prompt`: the MCP primitive (`MCP`).
+                        -   `command`: a command or sub-command (`CLI`).
+                        -   `function`, `method`, `constructor`, `event`: the callable or
+                            emitted member (`Library`).
+                        -   `custom`: any other operation, explained in the description.
+                    value: enum(GET,POST,PUT,PATCH,DELETE,HEAD,OPTIONS,query,mutation,subscription,call,stream,publish,subscribe,tool,resource,prompt,command,function,method,constructor,event,custom)
+                -   name: LOCATOR
                     desc: >
-                        The state or setup that must hold before the test is executed.
+                        How the endpoint is addressed within its interface, depending on
+                        the `KIND` of the interface: the URL path with `{xxx}` placeholders (e.g.
+                        `/events/{eventId}/chat`), the GraphQL field name, the topic
+                        pattern (e.g. `event/{eventId}/chat`), the tool, resource, or
+                        prompt name, the command path of words (e.g. `specbook lint`),
+                        or the symbol (e.g. `SpecBook.lint`); defaults to the
+                        endpoint name.
+                    value: /.+/
                     optional: true
-                -   name: INPUT
+                -   name: USE-CASES
                     desc: >
-                        The mandatory, concrete input data or actions applied during the test.
-                -   name: EXPECTED
+                        Comma-separated references to the USE-CASES objects the endpoint
+                        realizes, tracing the requirements into the interface.
+                    value: list([[REQS:UC.USE-CASE:*]])
+                    optional: true
+            childs:
+                -   kind: OPTION
+                    name: "-{0,2}[A-Za-z_][A-Za-z0-9_-]*"
                     desc: >
-                        The mandatory, concrete expected outcome or observable result that defines a
-                        passing test.
-                -   name: POST-CONDITION
+                        A named input of the endpoint, carrying a per-endpoint unique
+                        identifier in the syntax of the interface (e.g. `--output`,
+                        `first`, `file_path`) and described by a 1-sentence description
+                        ("what") plus a 1-sentence rationale ("why").
+                    optional: true
+                    format:
+                        maxTableColumns: 6
+                    props:
+                        -   name: TYPE
+                            desc: >
+                                The type of the option: a reference to a `TYPE` object of
+                                the interface, one of the primitives `boolean`, `string`,
+                                `text`, `integer`, `float`, `decimal`, `uuid`, `bytes`,
+                                `date`, `time`, `datetime`, `duration`, or `any`, or an inline
+                                enumeration `enum(XXX,YYY[,...])` (a reusable one is a `TYPE`
+                                object with an `enum(...)` base), where several comma-separated
+                                alternatives form a union type.
+                            value: list([[APIS:ID.TYPE:*]], /^(?:boolean|string|text|integer|float|decimal|uuid|bytes|date|time|datetime|duration|any|enum\((?:[A-Za-z0-9_-]+)(?:,\s*[A-Za-z0-9_-]+)*\))$/)
+                        -   name: ALIAS
+                            desc: >
+                                Comma-separated alternative names of the option in the
+                                syntax of the interface (e.g. `-o` for `--output`).
+                            value: /^-{0,2}[A-Za-z_][A-Za-z0-9_-]*(?:,\s*-{0,2}[A-Za-z_][A-Za-z0-9_-]*)*$/
+                            optional: true
+                        -   name: ARITY
+                            desc: >
+                                The arity (cardinality) of the option:
+                                -   `0..1` or `?` for zero or one ("optional", the default)
+                                -   `1` for exactly one ("mandatory")
+                                -   `0..n` or `*` for zero or more
+                                -   `1..n` or `+` for one or more
+                                -   `{X}` or `X` for an exact number X
+                                -   `{X,Y}` or `X...Y` for a range from X to Y
+                            value: /^(?:\?|\*|\+|\{\d+(?:,\d+)?\}|1|0\.\.1|0\.\.n|1\.\.n|\d+|\d+\.\.\d+)$/
+                            optional: true
+                        -   name: DEFAULT
+                            desc: The default value of the option (matching its type).
+                            value: /.*/
+                            optional: true
+                        -   name: CONSTRAINT
+                            desc: >
+                                The constraint on the value of the option beyond its type,
+                                as a short phrase stating a range, unit, pattern, or
+                                invariant (e.g. `1..65535`, `readable directory`).
+                            value: /.+/
+                            optional: true
+                -   kind: ARGUMENT
+                    name: "[A-Za-z_][A-Za-z0-9_-]*"
+                    desc: >
+                        A positional input of the endpoint, in document order, carrying a
+                        per-endpoint unique identifier (e.g. `eventId`, `body`, `file`)
+                        and described by a 1-sentence description ("what") plus a
+                        1-sentence rationale ("why").
+                    optional: true
+                    format:
+                        maxTableColumns: 6
+                    props:
+                        -   name: TYPE
+                            desc: >
+                                The type of the argument: a reference to a `TYPE` object
+                                of the interface, one of the primitives `boolean`,
+                                `string`, `text`, `integer`, `float`, `decimal`, `uuid`,
+                                `bytes`, `date`, `time`, `datetime`, `duration`, or `any`, or an
+                                inline enumeration `enum(XXX,YYY[,...])` (a reusable one is a
+                                `TYPE` object with an `enum(...)` base), where several comma-separated
+                                alternatives form a union type.
+                            value: list([[APIS:ID.TYPE:*]], /^(?:boolean|string|text|integer|float|decimal|uuid|bytes|date|time|datetime|duration|any|enum\((?:[A-Za-z0-9_-]+)(?:,\s*[A-Za-z0-9_-]+)*\))$/)
+                        -   name: ARITY
+                            desc: >
+                                The arity (cardinality) of the argument:
+                                -   `0..1` or `?` for zero or one ("optional", the default)
+                                -   `1` for exactly one ("mandatory")
+                                -   `0..n` or `*` for zero or more
+                                -   `1..n` or `+` for one or more
+                                -   `{X}` or `X` for an exact number X
+                                -   `{X,Y}` or `X...Y` for a range from X to Y
+                            value: /^(?:\?|\*|\+|\{\d+(?:,\d+)?\}|1|0\.\.1|0\.\.n|1\.\.n|\d+|\d+\.\.\d+)$/
+                            optional: true
+                        -   name: DEFAULT
+                            desc: The default value of the argument (matching its type).
+                            value: /.*/
+                            optional: true
+                        -   name: CONSTRAINT
+                            desc: >
+                                The constraint on the value of the argument beyond its
+                                type, as a short phrase stating a range, unit, pattern, or
+                                invariant (e.g. `existing file`, `1..100`).
+                            value: /.+/
+                            optional: true
+                -   kind: RESULT
+                    name: "[A-Za-z_][A-Za-z0-9_-]*"
                     desc: >
-                        The state that must hold after the test completes.
+                        A named output of the endpoint, carrying a per-endpoint unique
+                        identifier (e.g. `body`, `message`, `stdout`, `exit-code`) and
+                        described by a 1-sentence description ("what") plus a 1-sentence
+                        rationale ("why"). An error outcome is a result of its own (e.g.
+                        `error` with an HTTP status in its `CONSTRAINT`).
                     optional: true
+                    format:
+                        maxTableColumns: 5
+                    props:
+                        -   name: TYPE
+                            desc: >
+                                The type of the result: a reference to a `TYPE` object of
+                                the interface, one of the primitives `boolean`, `string`,
+                                `text`, `integer`, `float`, `decimal`, `uuid`, `bytes`,
+                                `date`, `time`, `datetime`, `duration`, or `any`, or an inline
+                                enumeration `enum(XXX,YYY[,...])` (a reusable one is a `TYPE`
+                                object with an `enum(...)` base), where several comma-separated
+                                alternatives form a union type.
+                            value: list([[APIS:ID.TYPE:*]], /^(?:boolean|string|text|integer|float|decimal|uuid|bytes|date|time|datetime|duration|any|enum\((?:[A-Za-z0-9_-]+)(?:,\s*[A-Za-z0-9_-]+)*\))$/)
+                        -   name: ARITY
+                            desc: >
+                                The arity (cardinality) of the result:
+                                -   `0..1` or `?` for zero or one ("optional", the default)
+                                -   `1` for exactly one ("mandatory")
+                                -   `0..n` or `*` for zero or more
+                                -   `1..n` or `+` for one or more
+                                -   `{X}` or `X` for an exact number X
+                                -   `{X,Y}` or `X...Y` for a range from X to Y
+                            value: /^(?:\?|\*|\+|\{\d+(?:,\d+)?\}|1|0\.\.1|0\.\.n|1\.\.n|\d+|\d+\.\.\d+)$/
+                            optional: true
+                        -   name: CONSTRAINT
+                            desc: >
+                                The constraint on the value of the result beyond its type,
+                                as a short phrase stating a range, unit, pattern, or
+                                invariant (e.g. `HTTP 201`, `0 iff no diagnostics`).
+                            value: /.+/
+                            optional: true
 
--   kind: SPEC
+-   kind: UXUI
     name: Interaction Concept
     id: IC
-    file: SPEC-12-IC-Interaction-Concept.md
+    file: 17-UXUI-IC-Interaction-Concept.md
     desc: >
-        The overarching idea of how users interact with the solution, describing the intended
-        workflows and interaction philosophy (e.g. auto-save behavior).
+        The interaction philosophy of the solution, stated as the set of cross-cutting principles
+        (e.g. auto-save instead of explicit saving) which govern how users interact with the
+        solution and which the Dialog Patterns, Dialog Storyboard, and Visual Design have to obey,
+        while the concrete workflows belong to the User Journey, Use Cases, and Dialog Storyboard.
+        The principles are listed in decreasing precedence, so that whenever two principles
+        conflict in a particular design decision, the earlier one wins.
+    refs: >
+        -   ISO 9241-110:2020: Ergonomics of human-system interaction -- Part 110: Interaction principles (2020),
+            https://www.iso.org/standard/75258.html
+        -   Nielsen: 10 Usability Heuristics for User Interface Design (1994),
+            https://www.nngroup.com/articles/ten-usability-heuristics/
+        -   Shneiderman: The Eight Golden Rules of Interface Design (1987),
+            https://www.cs.umd.edu/users/ben/goldenrules.html
+    optional: true
+    diagram:
+        type: grid
+        nodes: "[[UXUI:IC.PRINCIPLE:*]]"
+        properties:
+            -   CATEGORY
+        config:
+            size-node-width-max: 440
+            size-node-height-scale: 2
+            grid-columns-max: 4
     childs:
         -   kind: PRINCIPLE
             desc: >
                 A single interaction principle, named with a short (2-5 word) summary (e.g.
                 `Auto-Save`, `Optimistic Updates`, `Undo over Confirm`) and described in a concise
                 (1-3 sentence) paragraph by how it governs the user's experience across the
-                solution, plus a 1-sentence rationale ("why").
+                solution, plus a 1-sentence rationale ("why"). A principle is solution-wide and
+                independent of any particular screen or flow (a structure recurring within one flow
+                is a Dialog Pattern instead), decides between design alternatives (the alternative
+                it rejects is its `TRADE-OFF`), and is not verifiable by a metric (a measurable
+                quality bound is a Non-Functional Requirement instead).
+            referenced:
+                -   "[[UXUI:DP.PATTERN:*]]"
             props:
                 -   name: CATEGORY
-                    desc: The aspect of interaction the principle governs.
-                    value: enum(Onboarding,Navigation,Input,Feedback,Workflow,Personalization,Awareness,Resilience,Privacy)
+                    desc: >
+                        The interaction principle of ISO 9241-110:2020 the principle primarily
+                        promotes: `Task-Suitability` (suitability for the user's tasks),
+                        `Self-Descriptiveness`, `Expectation-Conformity` (conformity with user
+                        expectations), `Learnability`, `Controllability`, `Error-Robustness` (use
+                        error robustness), or `Engagement` (user engagement).
+                    value: enum(Task-Suitability,Self-Descriptiveness,Expectation-Conformity,Learnability,Controllability,Error-Robustness,Engagement)
+                -   name: ACTORS
+                    desc: >
+                        Comma-separated references to the User Personas objects whose experience
+                        the principle governs, omitted for a principle governing the experience of
+                        all users alike.
+                    value: list([[REQS:UP.PERSONA:*]])
+                    optional: true
+                -   name: MOTIVATED-BY
+                    desc: >
+                        Comma-separated references to the User Journey step objects whose
+                        `PAIN-POINT` or `OPPORTUNITY` the principle answers, so that a principle is
+                        grounded in the observed experience rather than in taste alone.
+                    value: list([[REQS:UJ.JOURNEY:*.STEP:*]])
+                    optional: true
+                -   name: TRADE-OFF
+                    desc: >
+                        The competing concern the principle deliberately subordinates, stated so
+                        that the opposite of the principle is a defensible choice, too (e.g.
+                        `explicit confirmation before every destructive action` for `Undo over
+                        Confirm`), as opposed to the rationale which states why this side wins.
 
--   kind: SPEC
+-   kind: UXUI
     name: Language Conventions
     id: LC
-    file: SPEC-13-LC-Language-Conventions.md
+    file: 18-UXUI-LC-Language-Conventions.md
     desc: >
-        The terminology, naming, tone, and wording standards used consistently across the solution
-        and its content.
+        The voice, tone, and wording of the user-facing text of the solution (labels, messages,
+        notifications, help), governing how the solution speaks to its users, so that the Interaction
+        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).
+    refs: >
+        -   Podmajersky: Strategic Writing for UX (2019),
+            https://www.oreilly.com/library/view/strategic-writing-for/9781492049388/
+        -   Metts/Welfle: Writing Is Designing: Words and the User Experience (2020),
+            https://rosenfeldmedia.com/books/writing-is-designing/
+        -   Mailchimp: Content Style Guide -- Voice and Tone (2015),
+            https://styleguide.mailchimp.com/
+        -   Microsoft: Microsoft Writing Style Guide (2018),
+            https://learn.microsoft.com/en-us/style-guide/welcome/
+    optional: true
+    diagram:
+        type: grid
+        nodes: "[[UXUI:LC.CONVENTION:*]]"
+        properties:
+            -   CATEGORY
+        config:
+            size-node-width-max: 440
+            size-node-height-scale: 2
+            grid-columns-max: 4
     childs:
         -   kind: CONVENTION
             desc: >
-                A single language convention, named with a short (2-5 word) summary and described in
-                a concise (1-3 sentence) paragraph as the convention to be applied consistently
-                across the solution, optionally illustrated by a short, concrete example of the
-                convention in practice.
+                A single language convention, named with a short (2-5 word) summary (e.g. `Neutral
+                Error Tone`, `Second-Person Address`) and described in a concise (1-3 sentence)
+                paragraph as the rule the user-facing text of the solution has to follow
+                consistently, plus a 1-sentence rationale ("why"). A convention governs how the
+                solution phrases what it says, not what it does (a behavior is an Interaction
+                Concept principle instead) and not what a term means (a definition is a Domain
+                Glossary term instead).
             props:
                 -   name: CATEGORY
                     desc: >
-                        The aspect of language the convention governs: `Terminology` (preferred and
-                        forbidden terms), `Naming` (naming patterns), `Tone` (voice and register),
-                        `Capitalization`, `Punctuation`, or `Formatting`.
-                    value: enum(Terminology,Naming,Tone,Capitalization,Punctuation,Formatting)
+                        The aspect of language the convention governs: `Voice` (the stable persona
+                        the solution speaks with), `Tone` (the register varying with the situation,
+                        e.g. on errors), `Vocabulary` (preferred and forbidden words and phrasings),
+                        `Grammar` (person, tense, mood, sentence structure), `Capitalization`,
+                        `Punctuation`, `Formatting` (numbers, dates, units, quotations), or
+                        `Localization` (languages, translations, locale-dependent wording).
+                    value: enum(Voice,Tone,Vocabulary,Grammar,Capitalization,Punctuation,Formatting,Localization)
+                -   name: ACTORS
+                    desc: >
+                        Comma-separated references to the User Personas objects the convention
+                        addresses, omitted for a convention governing the text shown to all users
+                        alike.
+                    value: list([[REQS:UP.PERSONA:*]])
+                    optional: true
+                -   name: PRINCIPLES
+                    desc: >
+                        Comma-separated references to the INTERACTION-CONCEPT objects the convention
+                        supports in wording, so that a convention is grounded in the interaction
+                        philosophy rather than in taste alone.
+                    value: list([[UXUI:IC.PRINCIPLE:*]])
+                    optional: true
+                -   name: TERMS
+                    desc: >
+                        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:*]])
+                    optional: true
+                -   name: EXAMPLE
+                    desc: >
+                        A short, concrete "do, not don't" pair illustrating the convention in
+                        practice, quoting the text as the user sees it (e.g. `"You are not
+                        authorized for this event.", not "Access forbidden!"`).
 
--   kind: SPEC
+-   kind: UXUI
     name: Dialog Patterns
     id: DP
-    file: SPEC-14-DP-Dialog-Patterns.md
+    file: 19-UXUI-DP-Dialog-Patterns.md
     desc: >
         The reusable interaction structures governing how the system and user exchange information
-        across recurring conversational or UI flows (e.g. master-detail dialog).
+        across recurring UI flows (e.g. master-detail dialog).
+    refs: >
+        -   Alexander et al.: A Pattern Language: Towns, Buildings, Construction (1977),
+            https://global.oup.com/academic/product/a-pattern-language-9780195019193
+        -   Borchers: A Pattern Approach to Interaction Design (2001),
+            https://www.wiley.com/en-us/A+Pattern+Approach+to+Interaction+Design-p-9780471498285
+        -   Tidwell et al.: Designing Interfaces: Patterns for Effective Interaction Design, 3rd ed. (2020),
+            https://www.oreilly.com/library/view/designing-interfaces-3rd/9781492051954/
+    optional: true
+    diagram:
+        type: grid
+        nodes: "[[UXUI:DP.PATTERN:*]]"
+        properties:
+            -   CATEGORY
+        config:
+            size-node-width-max: 440
+            size-node-height-scale: 2
+            grid-columns-max: 4
     childs:
         -   kind: PATTERN
             desc: >
@@ -606,8 +2142,35 @@
                 paragraph by the interaction structure and how the system and user exchange
                 information within it, plus a 1-sentence rationale ("why") stating why this
                 particular structure is worth adopting -- the benefit it secures or the trade-off it
-                wins.
+                wins. A pattern is a structure recurring in at least two flows (a structure
+                occurring in a single flow is a Dialog Storyboard frame instead) and is bound to a
+                particular kind of screen or flow (a solution-wide rule independent of any screen
+                is an Interaction Concept principle instead).
+            diagram:
+                type: hub
+                center: self
+                nodes: "[[UXUI:DP.PATTERN:*]], [[UXUI:IC.PRINCIPLE:*]], [[UXUI:DS.STORYBOARD:*]]"
+                deep: true
+                qualified: true
+                config:
+                    size-node-width-max: 440
             props:
+                -   name: CATEGORY
+                    desc: >
+                        The aspect of the interaction the pattern structures: `Navigation` (moving
+                        between the screens and places of the solution), `Layout` (arranging the
+                        regions of a screen), `List` (browsing, filtering, and selecting among many
+                        items), `Data` (presenting complex data and information graphics), `Form`
+                        (entering and editing data), `Action` (issuing commands and handling their
+                        effects), or `Feedback` (conveying status, progress, and notifications).
+                    value: enum(Navigation,Layout,List,Data,Form,Action,Feedback)
+                -   name: ACTORS
+                    desc: >
+                        Comma-separated references to the User Personas objects whose interaction
+                        the pattern structures, omitted for a pattern applied to the interaction of
+                        all users alike.
+                    value: list([[REQS:UP.PERSONA:*]])
+                    optional: true
                 -   name: CONTEXT
                     desc: >
                         The recurring situation or flow in which the pattern is applied.
@@ -617,86 +2180,406 @@
                         pattern needed"), stated independently of its solution (which belongs to the
                         description) and of its rationale (which states why this particular solution
                         is worth adopting).
+                -   name: PRINCIPLES
+                    desc: >
+                        Comma-separated references to the INTERACTION-CONCEPT objects the pattern
+                        embodies, so that every principle is shown to be honored by at least one
+                        pattern rather than merely declared.
+                    value: list([[UXUI:IC.PRINCIPLE:*]])
+                    optional: true
+                -   name: USES
+                    desc: >
+                        Comma-separated references to the smaller DIALOG-PATTERNS objects the
+                        pattern is composed of (e.g. a `Master-Detail` using an `Inline Edit` in
+                        its detail), so that the patterns form a language of related structures
+                        rather than a flat catalogue.
+                    value: list([[UXUI:DP.PATTERN:*]])
+                    optional: true
+                -   name: TRADE-OFF
+                    desc: >
+                        The liability the pattern accepts in exchange for its benefit, stated so
+                        that not applying the pattern is a defensible choice, too (e.g. `the
+                        horizontal space of two panes, cramped on small screens` for
+                        `Master-Detail`), as opposed to the rationale which states why the benefit
+                        wins.
 
--   kind: SPEC
+-   kind: UXUI
     name: Dialog Storyboard
     id: DS
-    file: SPEC-15-DS-Dialog-Storyboard.md
+    file: 20-UXUI-DS-Dialog-Storyboard.md
     desc: >
         The sequenced visual or textual depiction of a specific dialog flow, illustrating how an
         interaction unfolds screen by screen or turn by turn.
+    refs: >
+        -   Truong et al.: Storyboarding: An Empirical Determination of Best Practices and Effective Guidelines (2006),
+            https://dl.acm.org/doi/10.1145/1142405.1142410
+        -   Buxton: Sketching User Experiences: Getting the Design Right and the Right Design (2007),
+            https://shop.elsevier.com/books/sketching-user-experiences-getting-the-design-right-and-the-right-design/buxton/978-0-12-374037-3
+        -   NN/g: Storyboards Help Visualize UX Ideas (2018),
+            https://www.nngroup.com/articles/storyboards-visualize-ideas/
+    optional: true
     diagram:
         type: grid
-        nodes: "[[SPEC:DS.STORYBOARD:*]]"
+        nodes: "[[UXUI:DS.STORYBOARD:*]]"
+        properties:
+            -   ACTORS
+        config:
+            size-node-width-max: 440
+            size-node-height-scale: 2
+            grid-columns-max: 4
     childs:
         -   kind: STORYBOARD
             desc: >
                 A single depicted dialog flow, named with a short (3-8 word) summary of the flow and
-                comprised of sequentially numbered frames.
+                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
+                Cases scenario instead, and a structure recurring across flows is a Dialog Pattern
+                instead).
             diagram:
                 type: hub
                 center: self
-                nodes: "[[SPEC:DS.STORYBOARD:*]], [[SPEC:UC.USE-CASE:*]],
-                    [[SPEC:UC.USE-CASE:*.SCENARIO:*]], [[SPEC:DP.PATTERN:*]]"
+                nodes: "[[UXUI:DS.STORYBOARD:*]], [[REQS:UP.PERSONA:*]],
+                    [[REQS:UC.USE-CASE:*.SCENARIO:*]], [[UXUI:DP.PATTERN:*]]"
+                deep: true
                 qualified: true
                 config:
                     size-node-width-max: 440
+                    size-node-height-scale: 1.75
             props:
-                -   name: USE-CASE
+                -   name: ACTORS
                     desc: >
-                        Reference to the USE-CASES object the storyboard visualizes.
-                    value: "[[SPEC:UC.USE-CASE:*]]"
-                    optional: true
+                        Comma-separated references to the User Personas objects whose story the
+                        storyboard tells, in the order of their appearance, so that a storyboard
+                        switching its viewpoint between actors (e.g. from a moderator to a
+                        presenter) names all of them.
+                    value: list([[REQS:UP.PERSONA:*]])
                 -   name: SCENARIO
                     desc: >
-                        Reference to the USE-CASES scenario object the storyboard visualizes.
-                    value: "[[SPEC:UC.USE-CASE:*.SCENARIO:*]]"
-                    optional: true
-                -   name: PATTERN
-                    desc: >
-                        Reference to the DIALOG-PATTERNS object the storyboard instantiates.
-                    value: "[[SPEC:DP.PATTERN:*]]"
+                        Reference to the USE-CASES scenario object the storyboard renders as user
+                        interface, omitted for a storyboard of a flow no scenario covers.
+                    value: "[[REQS:UC.USE-CASE:*.SCENARIO:*]]"
                     optional: true
             childs:
                 -   kind: FRAME
                     desc: >
                         A single frame of the storyboard, named with a short (2-5 word) label for
-                        the screen, turn, or state depicted and described in a concise (1-2
-                        sentence) paragraph by what the user sees and does at this frame of the
-                        interaction.
+                        the screen, turn, or state depicted, shown by its `SKETCH`, and described in
+                        a concise (1-2 sentence) paragraph by what the actor sees and does at this
+                        frame of the interaction.
+                    format:
+                        type: concise
+                        maxTableColumns: 5
+                    props:
+                        -   name: SCENARIO-STEP
+                            desc: >
+                                The number of the step of the referenced USE-CASES scenario the
+                                frame renders, so that a frame traces back to the intent it gives a
+                                user interface to, omitted for a frame setting the scene before or
+                                between the steps.
+                            value: /^[1-9][0-9]*$/
+                            optional: true
+                        -   name: ACTOR
+                            desc: >
+                                Reference to the User Personas object from whose viewpoint the frame
+                                is depicted, given whenever the storyboard names several `ACTORS`
+                                and omitted for a storyboard of a single actor.
+                            value: "[[REQS:UP.PERSONA:*]]"
+                            optional: true
+                        -   name: PATTERNS
+                            desc: >
+                                Comma-separated references to the DIALOG-PATTERNS objects the frame
+                                instantiates, so that a pattern is shown to recur across the
+                                concrete flows rather than merely being catalogued.
+                            value: list([[UXUI:DP.PATTERN:*]])
+                            optional: true
+                        -   name: SKETCH
+                            desc: >
+                                An image (`![...](...)`) of the frame, preferably a low-fidelity
+                                sketch or wireframe which invites critique, or a screenshot for an
+                                already existing user interface, so that the frame is seen rather
+                                than only read, omitted for a frame whose depiction differs from
+                                the preceding one only in a detail the description names.
+                            optional: true
 
--   kind: SPEC
+-   kind: UXUI
     name: Visual Design
     id: VD
-    file: SPEC-16-VD-Visual-Design.md
+    file: 21-UXUI-VD-Visual-Design.md
     desc: >
-        The aesthetic and layout aspects of the solution, defining colors, typography, spacing,
-        imagery, and overall look and feel.
+        The visual design decisions of the solution (brand, color, typography, spacing, shape,
+        iconography, imagery, and motion), each stated as a rule with its rationale, plus the
+        high-fidelity mockups showing the decisions applied to concrete screens, so that the
+        Interaction Concept states how the solution behaves, the Language Conventions how it
+        talks, and the Visual Design how it looks. The concrete token values live in the design
+        system (token file, design tool library) and are referenced rather than restated, the
+        arrangement of the regions of a screen is a Dialog Pattern, the screen of a particular
+        flow step is a Dialog Storyboard frame, and a measurable visual bound (e.g. a contrast
+        ratio) is a Non-Functional Requirement.
+    refs: >
+        -   DTCG: Design Tokens Format Module (2025),
+            https://www.designtokens.org/tr/format/
+        -   Google: Material Design 3 -- Styles: Color, Typography, Shape, Motion, Icons, Elevation (2021),
+            https://m3.material.io/styles
+        -   Kholmatova: Design Systems: A practical guide for creating design languages for digital products (2017),
+            https://www.smashingmagazine.com/printed-books/design-systems/
+    optional: true
+    diagram:
+        type: grid
+        nodes: "[[UXUI:VD.ELEMENT:*]]"
+        properties:
+            -   CATEGORY
+        config:
+            size-node-width-max: 440
+            size-node-height-scale: 2
+            grid-columns-max: 4
     childs:
         -   kind: ELEMENT
             desc: >
-                A single visual design element, named with a short (2-5 word) summary and described
-                in a concise (1-3 sentence) paragraph specifying the concrete values, tokens, or
-                rules that define it (e.g. palette, font family, scale), plus a 1-sentence rationale
-                ("why").
+                A single visual design element, named with a short (2-5 word) summary (e.g. `Brand
+                Color Palette`, `Self-Hosted Typography`) and described in a concise (1-3 sentence)
+                paragraph as the rule the appearance of the solution has to follow consistently,
+                naming its stable concrete values (e.g. the primary color, the font family, the
+                type scale) and deferring the remaining ones to its `SOURCE`, plus a 1-sentence
+                rationale ("why"). An element decides how the solution looks (a behavior is an
+                Interaction Concept principle instead, a wording is a Language Conventions
+                convention instead), solution-wide rather than for one screen (a screen is a
+                `MOCKUP` or a Dialog Storyboard frame instead), and is a decision rather than a
+                list of token values (the values are in the design system) or a measurable bound
+                (a bound is a Non-Functional Requirement instead).
+            format:
+                maxTableColumns: 5
+            diagram:
+                type: hub
+                center: self
+                nodes: "[[UXUI:VD.ELEMENT:*]], [[REQS:UP.PERSONA:*]], [[UXUI:IC.PRINCIPLE:*]], [[UXUI:VD.MOCKUP:*]]"
+                qualified: true
+                config:
+                    size-node-width-max: 440
             props:
                 -   name: CATEGORY
-                    desc: The aspects of visual design the element governs.
-                    value: tags(Color,Typography,Iconography,Imagery,Layout,Animation)
+                    desc: >
+                        The aspect of visual design the element governs: `Brand` (logo, wordmark,
+                        and identity marks), `Color` (palettes, themes, and semantic color roles),
+                        `Typography` (font families, type scale, and text styles), `Spacing`
+                        (spacing scale, grid, and breakpoints, i.e. the metrics of the arrangements
+                        the Dialog Patterns structure), `Shape` (corner radii, borders, and
+                        elevation), `Iconography` (icon set and its usage), `Imagery`
+                        (photography, illustration, and video treatment), or `Motion`
+                        (transitions, animations, and their timing).
+                    value: enum(Brand,Color,Typography,Spacing,Shape,Iconography,Imagery,Motion)
+                -   name: ACTORS
+                    desc: >
+                        Comma-separated references to the User Personas objects for whom the
+                        element governs the appearance, omitted for an element governing the
+                        appearance for all users alike.
+                    value: list([[REQS:UP.PERSONA:*]])
+                    optional: true
+                -   name: PRINCIPLES
+                    desc: >
+                        Comma-separated references to the INTERACTION-CONCEPT objects the element
+                        supports in appearance, so that an element is grounded in the interaction
+                        philosophy rather than in taste alone.
+                    value: list([[UXUI:IC.PRINCIPLE:*]])
+                    optional: true
+                -   name: SOURCE
+                    desc: >
+                        The authoritative external artifact holding the concrete values of the
+                        element (e.g. a design token file, a design tool library, a stylesheet),
+                        so that the values are maintained there and only referenced here, omitted
+                        for an element whose values are fully named in its description.
+                    optional: true
+                -   name: TRADE-OFF
+                    desc: >
+                        The liability the element accepts in exchange for its benefit, stated so
+                        that the opposite decision is a defensible choice, too (e.g. `a larger
+                        initial download` for `Self-Hosted Typography`), as opposed to the
+                        rationale which states why the benefit wins.
+        -   kind: MOCKUP
+            desc: >
+                A single high-fidelity mockup, named with a short (2-5 word) label for the screen
+                depicted, shown by its `IMAGE`, and described in a concise (1-2 sentence) paragraph
+                by which visual design elements it shows applied and where on the screen. A mockup
+                is a reference rendering of the final look of one screen (a low-fidelity sketch of
+                a screen within its flow is a Dialog Storyboard frame instead) and shows rules
+                applied rather than stating them (a rule is an `ELEMENT` instead).
+            format:
+                type: complex
+            props:
+                -   name: ACTORS
+                    desc: >
+                        Comma-separated references to the User Personas objects who see the
+                        depicted screen.
+                    value: list([[REQS:UP.PERSONA:*]])
+                -   name: STORYBOARD
+                    desc: >
+                        Reference to the DIALOG-STORYBOARD object whose flow the depicted screen
+                        belongs to, so that the high-fidelity look traces back to the sketched
+                        flow, omitted for a mockup of a screen no storyboard covers.
+                    value: "[[UXUI:DS.STORYBOARD:*]]"
+                    optional: true
+                -   name: ELEMENTS
+                    desc: >
+                        Comma-separated references to the `ELEMENT` objects the mockup shows
+                        applied, so that an element is shown to be realized rather than merely
+                        declared.
+                    value: list([[UXUI:VD.ELEMENT:*]])
+                -   name: IMAGE
+                    desc: >
+                        An image (`![...](...)`) of the mockup, a high-fidelity rendering from
+                        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: ARCH-01-CV-Context-View.md
+    file: 23-ARCH-CV-Context-View.md
     desc: >
         The relationships, dependencies, and interactions between the solution and its environment,
-        defining the system's scope, external entities, and boundaries.
+        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.
+    refs: >
+        -   Rozanski/Woods: Software Systems Architecture, 2nd ed.: The Context Viewpoint (2011),
+            https://www.viewpoints-and-perspectives.info/home/viewpoints/context/
+        -   Brown: The C4 Model: System Context Diagram (2018),
+            https://c4model.com/diagrams/system-context
+        -   ISO/IEC/IEEE 42010:2022: Software, systems and enterprise -- Architecture description (2022),
+            https://www.iso.org/standard/74393.html
     diagram:
-        type: grid
+        type: hub
         nodes: "[[ARCH:CV.ENTITY:*]]"
+        center:
+            source: "[[META:TI]]"
+            property: TITLE
+            kind: Solution
+        centerEdges:
+            property: DIRECTION
+            inbound:  Inbound
+            outbound: Outbound
+            both:     Bidirectional
+        qualified: true
         properties:
             -   KIND
-            -   DIRECTION
     childs:
         -   kind: ENTITY
             desc: >
@@ -705,30 +2588,71 @@
                 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.
+
+                An entity is outside the solution and exchanges information with it across the
+                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.
+            format:
+                maxTableColumns: 5
             props:
                 -   name: KIND
                     desc: |
                         The kind of the external entity, one of:
                         -   `Person`:       A human actor interacting with the solution.
-                        -   `System`:       An external software system the solution integrates
-                                            with.
+                        -   `System`:       An external software system the solution integrates with.
                         -   `Service`:      A third-party or managed service the solution consumes.
-                        -   `Datastore`:    An external data repository the solution reads from or
-                                            writes to.
-                        -   `Device`:       A physical device or sensor the solution communicates
-                                            with.
+                        -   `Datastore`:    An external data repository the solution reads from or writes to.
+                        -   `Device`:       A physical device or sensor the solution communicates with.
                         -   `Organization`: An external organizational party.
                     value: enum(Person,System,Service,Datastore,Device,Organization)
                 -   name: DIRECTION
                     desc: >
-                        The flow of interaction relative to the solution: `Inbound` (the entity
-                        drives the solution), `Outbound` (the solution drives the entity), or
-                        `Bidirectional` (both directions).
+                        Who initiates the interaction: `Inbound` (the entity drives the solution),
+                        `Outbound` (the solution drives the entity), or `Bidirectional` (both
+                        sides initiate), independent of the direction the exchanged information
+                        flows in, which the `DATA` property describes (e.g. a datastore the
+                        solution reads from is `Outbound`, as the solution initiates, while the
+                        data flows in).
                     value: enum(Inbound,Outbound,Bidirectional)
+                -   name: TERMS
+                    desc: >
+                        Comma-separated references to the GLOSSARY terms the entity appears as in
+                        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:*]])
+                    optional: true
                 -   name: INTERFACE
                     desc: >
-                        How the interaction happens (e.g. REST API, message queue, file exchange,
-                        web UI).
+                        Comma-separated references to the INTERFACE-MODEL objects through which
+                        the interaction happens, i.e. the interfaces the entity consumes (for a
+                        `Provided` one) or offers (for a `Required` one); omitted when the
+                        interaction happens through the user interface or outside any modeled
+                        interface (e.g. a file exchange).
+                    value: list([[APIS:IM.INTERFACE:*]])
+                    optional: true
+                -   name: ACTORS
+                    desc: >
+                        Comma-separated references to the User Personas objects acting behind the
+                        entity: a `Person` entity is the boundary-level role class and the referenced
+                        personas are its archetypes, while an `Organization` entity may reference
+                        the `Stakeholder` personas representing it, so the entity aggregates the
+                        personas instead of re-stating them; omitted when no persona stands behind
+                        the entity.
+                    value: list([[REQS:UP.PERSONA:*]])
+                    optional: true
+                -   name: PREMISES
+                    desc: >
+                        Comma-separated references to the SOLUTION-PREMISES objects (usually of
+                        type `Dependency`) resting on this entity: the entity describes the
+                        structural interaction with the external party, the premise the reliance
+                        on it and the consequence of its failure, so the risky context entities
+                        are found by traversal.
+                    value: list([[REQS:SP.PREMISE:*]])
+                    optional: true
                 -   name: DATA
                     desc: >
                         The principal information exchanged across the boundary with this entity.
@@ -736,10 +2660,17 @@
 -   kind: ARCH
     name: Functionality View
     id: FV
-    file: ARCH-02-FV-Functionality-View.md
+    file: 24-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.
+    refs: >
+        -   Rozanski/Woods: Software Systems Architecture, 2nd ed.: The Functional Viewpoint (2011),
+            https://www.viewpoints-and-perspectives.info/home/viewpoints/functional/
+        -   Kruchten: Architectural Blueprints -- The "4+1" View Model of Software Architecture (1995),
+            https://ieeexplore.ieee.org/document/469759
+        -   Brown: The C4 Model (2018),
+            https://c4model.com/
     diagram:
         type: graph
         nodes: "[[ARCH:FV.COMPONENT:*]]"
@@ -753,6 +2684,8 @@
                 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.
+            format:
+                maxTableColumns: 5
             diagram:
                 type: hub
                 center: self
@@ -777,10 +2710,14 @@
                     desc: >
                         The 1-sentence statement of the single, primary responsibility the component
                         owns.
-                -   name: INTERFACE
+                -   name: PROVIDES
                     desc: >
-                        How other components interact with this component (e.g. REST API, library
-                        API, message topic, CLI).
+                        Comma-separated references to the INTERFACE-MODEL objects the component
+                        provides, i.e. through which other components and external entities
+                        interact with it; omitted when the component provides no modeled interface
+                        (e.g. a user interface or an internal module).
+                    value: list([[APIS:IM.INTERFACE:*]])
+                    optional: true
                 -   name: DEPENDS-ON
                     desc: >
                         Comma-separated references to the FUNCTIONALITY-VIEW objects this component
@@ -791,10 +2728,15 @@
 -   kind: ARCH
     name: Information View
     id: IV
-    file: ARCH-03-IV-Information-View.md
+    file: 25-ARCH-IV-Information-View.md
     desc: >
         The way the solution stores, manages, manipulates, and distributes information, defining the
         static data structure and dynamic information flow.
+    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/
     diagram:
         type: grid
         nodes: "[[ARCH:IV.ASPECT:*]]"
@@ -811,7 +2753,7 @@
             diagram:
                 type: hub
                 center: self
-                nodes: "[[ARCH:IV.ASPECT:*]], [[SPEC:DM.ENTITY:*]], [[ARCH:FV.COMPONENT:*]]"
+                nodes: "[[ARCH:IV.ASPECT:*]], [[DATA:DM.ENTITY:*]], [[ARCH:FV.COMPONENT:*]]"
                 qualified: true
                 properties:
                     -   CONCERN
@@ -827,7 +2769,7 @@
                 -   name: ENTITIES
                     desc: >
                         Comma-separated references to the DATA-MODEL entities the aspect governs.
-                    value: list([[SPEC:DM.ENTITY:*]])
+                    value: list([[DATA:DM.ENTITY:*]])
                     optional: true
                 -   name: OWNER
                     desc: >
@@ -842,10 +2784,17 @@
 -   kind: ARCH
     name: Concurrency View
     id: CO
-    file: ARCH-04-CO-Concurrency-View.md
+    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:*]]"
@@ -897,10 +2846,17 @@
 -   kind: ARCH
     name: Development View
     id: DV
-    file: ARCH-05-DV-Development-View.md
+    file: 27-ARCH-DV-Development-View.md
     desc: >
         The architecture supporting the software development process, defining the module
         organization, build approach, and codeline conventions.
+    refs: >
+        -   Rozanski/Woods: Software Systems Architecture, 2nd ed.: The Development Viewpoint (2011),
+            https://www.viewpoints-and-perspectives.info/home/viewpoints/development/
+        -   Kruchten: Architectural Blueprints -- The "4+1" View Model of Software Architecture (1995),
+            https://ieeexplore.ieee.org/document/469759
+        -   Clements et al.: Documenting Software Architectures: Views and Beyond, 2nd ed. (2010),
+            https://www.informit.com/store/documenting-software-architectures-views-and-beyond-9780321552686
     diagram:
         type: grid
         nodes: "[[ARCH:DV.ASPECT:*]]"
@@ -924,10 +2880,17 @@
 -   kind: ARCH
     name: Deployment View
     id: DP
-    file: ARCH-06-DP-Deployment-View.md
+    file: 28-ARCH-DP-Deployment-View.md
     desc: >
         The environment into which the solution is deployed, mapping software elements to the
         runtime platform, hardware, and network topology.
+    refs: >
+        -   Rozanski/Woods: Software Systems Architecture, 2nd ed.: The Deployment Viewpoint (2011),
+            https://www.viewpoints-and-perspectives.info/home/viewpoints/deployment/
+        -   Kruchten: Architectural Blueprints -- The "4+1" View Model of Software Architecture (1995),
+            https://ieeexplore.ieee.org/document/469759
+        -   Brown: The C4 Model: Deployment Diagram (2018),
+            https://c4model.com/diagrams/deployment
     diagram:
         type: grid
         nodes: "[[ARCH:DP.NODE:*]]"
@@ -981,10 +2944,17 @@
 -   kind: ARCH
     name: Operations View
     id: OV
-    file: ARCH-07-OV-Operations-View.md
+    file: 29-ARCH-OV-Operations-View.md
     desc: >
         The way the solution is operated, administered, and supported in production, defining
         installation, monitoring, and management concerns.
+    refs: >
+        -   Rozanski/Woods: Software Systems Architecture, 2nd ed.: The Operational Viewpoint (2011),
+            https://www.viewpoints-and-perspectives.info/home/viewpoints/operational/
+        -   Beyer et al.: Site Reliability Engineering: How Google Runs Production Systems (2016),
+            https://sre.google/sre-book/table-of-contents/
+        -   ISO/IEC 20000-1:2018: Information technology -- Service management -- Part 1: Service management system requirements (2018),
+            https://www.iso.org/standard/70636.html
     diagram:
         type: grid
         nodes: "[[ARCH:OV.CONCERN:*]]"
@@ -1004,7 +2974,7 @@
                         `Provisioning`, `Monitoring`, `Logging`, `Alerting`, `Backup`, `Recovery`,
                         `Upgrade`, or `Support`.
                     value: enum(Installation,Configuration,Provisioning,Monitoring,Logging,Alerting,Backup,Recovery,Upgrade,Support)
-                -   name: ELEMENT
+                -   name: ELEMENTS
                     desc: >
                         Comma-separated references to the FUNCTIONALITY-VIEW or DEPLOYMENT-VIEW
                         objects the concern applies to.
@@ -1014,9 +2984,16 @@
 -   kind: ARCH
     name: Quality Perspectives
     id: QP
-    file: ARCH-08-QP-Quality-Perspectives.md
+    file: 30-ARCH-QP-Quality-Perspectives.md
     desc: >
         How the Non-Functional Requirements (NR) are addressed.
+    refs: >
+        -   Rozanski/Woods: Software Systems Architecture, 2nd ed.: The Perspectives (2011),
+            https://www.viewpoints-and-perspectives.info/home/perspectives/
+        -   Bass/Clements/Kazman: Software Architecture in Practice, 4th ed. (2021),
+            https://www.informit.com/store/software-architecture-in-practice-9780136886099
+        -   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
     diagram:
         type: grid
         nodes: "[[ARCH:QP.PERSPECTIVE:*]]"
@@ -1033,7 +3010,7 @@
             diagram:
                 type: hub
                 center: self
-                nodes: "[[ARCH:QP.PERSPECTIVE:*]], [[SPEC:NR.REQUIREMENT:*]], [[ARCH:FV.COMPONENT:*]], [[ARCH:DP.NODE:*]]"
+                nodes: "[[ARCH:QP.PERSPECTIVE:*]], [[REQS:NR.REQUIREMENT:*]], [[ARCH:FV.COMPONENT:*]], [[ARCH:DP.NODE:*]]"
                 qualified: true
                 properties:
                     -   QUALITY
@@ -1047,17 +3024,19 @@
                         differs from them.
 
                         The NR categories follow the ISO/IEC 25010:2023 top-level characteristics
-                        (and include `Safety` and `Flexibility`), whereas the perspective qualities
-                        decompose some of these into the finer-grained, architecturally actionable
-                        attributes `Scalability`, `Availability`, `Privacy`, `Accessibility`, and
-                        `Portability`. The quality therefore need not match the category of the
-                        requirements it addresses.
+                        (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)
                 -   name: ADDRESSES
                     desc: >
                         Comma-separated references to the NON-FUNCTIONAL-REQUIREMENTS objects the
                         perspective addresses.
-                    value: list([[SPEC:NR.*]])
+                    value: list([[REQS:NR.*]])
                 -   name: TACTIC
                     desc: >
                         The architectural tactic or strategy applied to achieve the quality (e.g.
@@ -1073,10 +3052,17 @@
 -   kind: ARCH
     name: Decision Record
     id: DR
-    file: ARCH-09-DR-Decision-Record.md
+    file: 31-ARCH-DR-Decision-Record.md
     desc: >
         The major decisions related to the architecture, each recording the forces at play, the
         chosen response, and the reasoning that justifies it.
+    refs: >
+        -   Nygard: Documenting Architecture Decisions (2011),
+            https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
+        -   Tyree/Akerman: Architecture Decisions: Demystifying Architecture (2005),
+            https://ieeexplore.ieee.org/document/1407822
+        -   ADR: Architectural Decision Records (2017),
+            https://adr.github.io/
     diagram:
         type: grid
         nodes: "[[ARCH:DR.DECISION:*]]"
@@ -1246,11 +3232,18 @@
 -   kind: ARCH
     name: Technology Stack
     id: TS
-    file: ARCH-10-TS-Technology-Stack.md
+    file: 32-ARCH-TS-Technology-Stack.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.
+    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
     diagram:
         type: grid
         nodes: "[[ARCH:TS.TIER:*]]"
@@ -1264,8 +3257,6 @@
                 -   `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).
-            format:
-                maxTableColumns: 5
             diagram:
                 type: hub
                 center: self
@@ -1274,6 +3265,7 @@
                     -   PRODUCT
                 config:
                     size-node-width-max: 440
+                    size-node-height-scale: 1.75
             childs:
                 -   kind: COMPONENT
                     desc: >