@rse/ase 1.0.6 → 2.0.0

package/plugin/meta/ase-format-specbook.yaml

@@ -5,23 +5,13 @@
   desc: >
     The top-level specification meta information. Some of the information is rendered onto the title page.
   optional: true
-  diagram:
-    type: graph
-    nodes: "[[REQS:*]], [[DATA:*]], [[APIS:*]], [[UXUI:*]], [[ARCH:*]], [[TEST:*]]"
-    deep: true
-    qualified: true
-    ordered: true
-    nest:
-      kind: true
-      crossing: target
-    config:
-      graph-columns-max: 2
   props:
     - name: LOGO
       desc: The logo of the specification.
       optional: true
     - name: TITLE
       desc: The title of the specification.
+      optional: true
     - name: SUBTITLE
       desc: The subtitle of the specification.
       optional: true
@@ -48,8 +38,8 @@
       value: enum(Dark,Light)
       optional: true
     - name: THEME-TONE
-      desc: The theme color tone.
-      value: /^#[0-9a-fA-F]{6}$/
+      desc: The theme color tone, optionally followed by the complement color tone (else derived).
+      value: /^#[0-9a-fA-F]{6}(\s+#[0-9a-fA-F]{6})?$/
       optional: true
 
 - kind: REQS
@@ -59,26 +49,23 @@
   desc: >
     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.
   optional: true
-  refs: >
-    -   ISO/IEC/IEEE 29148:2018: Systems and software engineering -- Life cycle processes -- Requirements engineering (2018),
-        https://www.iso.org/standard/72089.html
-    -   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.
+      optional: true
     - name: TARGET-AUDIENCE
       desc: >
         Whom the solution serves.
+      optional: true
     - 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).
+      optional: true
     - name: VALUE-PROPOSITION
       desc: >
         The benefit the solution offers its target audience, stated in absolute terms without reference to alternatives.
+      optional: true
     - name: DIFFERENTIATORS
       desc: >
         How the solution stands apart from the alternatives, naming the alternatives it is compared against (including the status quo).
@@ -105,34 +92,13 @@
 
     The premises are not constraints: a constraint is imposed on the solution and belongs to the Non-Functional Requirements or the Domain Rules, whereas a premise lies outside the control of the solution.
   optional: true
-  refs: >
-    -   ISO/IEC/IEEE 29148:2018: Systems and software engineering -- Life cycle processes -- Requirements engineering (2018),
-        https://www.iso.org/standard/72089.html
-    -   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: "[[PREMISE:*]]"
-    properties:
-      - TYPE
-      - FAILURE-LIKELIHOOD
-      - FAILURE-IMPACT
-    config:
-      size-node-width-max: 440
-      size-node-height-scale: 1.75
-      grid-columns-max: 5
   children:
     - kind: PREMISE
       desc: >
         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
+      optional: true
       props:
         - name: TYPE
           desc: >
@@ -161,21 +127,6 @@
   desc: >
     The ubiquitous language of the domain, defining the meaning of each domain term in business language, together with its synonyms, its place in the hierarchy of terms, and the terms it has to be kept apart from, shared consistently across all Artifacts.
   optional: true
-  refs: >
-    -   ISO 704:2022: Terminology work -- Principles and methods (2022),
-        https://www.iso.org/standard/79077.html
-    -   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: "[[TERM:*]]"
-    properties:
-      - TYPE
-    config:
-      size-node-width-max: 440
-      grid-columns-max: 4
   children:
     - kind: TERM
       name: "[A-Z][A-Za-z0-9-]*( [A-Z][A-Za-z0-9-]*)*"
@@ -183,19 +134,9 @@
         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
+      optional: true
       referenced:
         - "[[*]]"
-      diagram:
-        type: hub
-        center: self
-        nodes: "[[TERM:*]], [[PREMISE:*]], [[RULE:*]], [[DM.ENTITY:*]], [[ROLE:*]], [[PERSONA:*]], [[WORKFLOW:*]], [[CONVENTION:*]], [[CV.ENTITY:*]]"
-        labeled: true
-        qualified: true
-        config:
-          size-node-width-max: 440
-          size-node-height-scale: 1.75
       props:
         - name: TYPE
           desc: >
@@ -230,39 +171,13 @@
   desc: >
     The roles the parties play towards the solution and the *archetypal* user profiles embodying them: a role names the part played (by a human or by an external system) and is the actor of the Use Cases and the Domain Workflows and the unit in which the Authorization Model grants rights, while a persona represents a distinct user group holding one or more roles, capturing its goals, needs, behaviors, and context, complemented by the non-user stakeholders whose interests the solution has to serve.
   optional: true
-  refs: >
-    -   Cockburn: Writing Effective Use Cases (2001),
-        https://www.informit.com/store/writing-effective-use-cases-9780201702255
-    -   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
-  diagram:
-    type: graph
-    nodes: "[[ROLE:*]], [[PERSONA:*]]"
-    labeled: true
-    qualified: true
-    config:
-      size-node-width-max: 440
   children:
     - kind: ROLE
       desc: >
         A single role, named with the canonical name of the part a party plays towards the solution (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 part is cut this way. A role is the name of a part and not of a person: the personas embodying it act in exactly this part and hold exactly the rights the Authorization Model grants to it (plus those of the roles it `INHERITS`), while a persona holding several roles holds the union of them.
-      format:
-        maxTableColumns: 5
+      optional: true
       referenced:
         - "[[*]]"
-      diagram:
-        type: hub
-        center: self
-        nodes: "[[ROLE:*]], [[TERM:*]], [[PERSONA:*]], [[WORKFLOW:*]], [[ACTIVITY:*]], [[USE-CASE:*]], [[TRANSITION:*]], [[CV.ENTITY:*]]"
-        labeled: true
-        qualified: true
-        config:
-          size-node-width-max: 440
-          size-node-height-scale: 1.75
       props:
         - name: TYPE
           desc: >
@@ -282,8 +197,7 @@
     - kind: PERSONA
       desc: >
         An archetypal user profile, named with a per-artifact unique first name of the 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. Non-user stakeholders are modeled as personas of type `Stakeholder`.
-      format:
-        maxTableColumns: 5
+      optional: true
       props:
         - name: TYPE
           desc: >
@@ -335,22 +249,11 @@
   desc: >
     The end-to-end experience a user has while discovering, adopting, and using the solution, mapping their steps, touchpoints, and emotions over time. The journey is the *target* journey with the solution in place, so the friction it records is what the solution has to mitigate, not the status quo it replaces.
   optional: true
-  refs: >
-    -   NN/g: Journey Mapping 101 (2018),
-        https://www.nngroup.com/articles/journey-mapping-101/
-    -   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: "[[JOURNEY:*]]"
-    properties:
-      - ACTORS
   children:
     - 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.
+      optional: true
       props:
         - name: ACTORS
           desc: >
@@ -390,31 +293,21 @@
   id: FR
   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, while the quality bounds and constraints on them belong to the Non-Functional Requirements.
+    The concrete behaviors and capabilities the solution must provide, describing *what* the system does in terms of functions, features, and operations, while the quality bounds and constraints on them belong to the Non-Functional Requirements. The requirements are optionally grouped into the coherent capabilities they add up to (the epics of agile planning, the features of product management), which the overview diagram draws as boxes around their requirements.
   optional: true
-  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: "[[FR.REQUIREMENT:*]]"
-    properties:
-      - PRIORITY
-    config:
-      size-node-width-max: 440
-      grid-columns-max: 5
   children:
+    - kind: GROUP
+      desc: >
+        A named group of strongly related requirements, carrying a short (1-3 word), per-artifact unique name distinct from the names of its requirements (e.g. `Moderation` for the moderating, forwarding, and answering of attendee inputs, `Event Access` for the access URLs), and described by a 1-sentence description ("what") of the capability the requirements add up to plus a 1-sentence rationale ("why") of the cohesion. A group is an epic in the agile sense and a feature in the product sense, but carries no obligation of its own: it has no priority, states no behavior, and is verified through its requirements alone, so it affects the overview diagram only, where its requirements are drawn next to each other inside a box. The groups are listed before the requirements, and every requirement belongs to at most one group.
+      optional: true
+      referenced:
+        - "[[FR.REQUIREMENT:*]]"
     - 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, 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
+      optional: true
       referenced:
         - "[[USE-CASE:*]]"
       props:
@@ -422,6 +315,17 @@
           desc: >
             The MoSCoW priority of the requirement: `MUST`, `SHOULD`, `COULD`, or `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: GROUP
+          desc: >
+            Reference to the FUNCTIONAL-REQUIREMENTS group the requirement belongs to, placing it next to the other requirements of the group in the overview diagram; omitted for a requirement standing on its own.
+          value: "[[FR.GROUP:*]]"
+          optional: true
+        - name: DEPENDS-ON
+          desc: >
+            Comma-separated references to the FUNCTIONAL-REQUIREMENTS objects the requirement presupposes, i.e. whose behavior has to exist before its own makes sense (e.g. replying to chat messages presupposes chat messages), so that dropping or deferring a requirement reveals what falls with it; omitted for a requirement presupposing no other one.
+          value: list([[FR.REQUIREMENT:*]])
+          optional: true
+          acyclic: true
         - name: PREMISES
           desc: >
             Comma-separated references to the SOLUTION-PREMISES objects the requirement rests on, i.e. the assumptions, dependencies, and risks whose failure calls for revisiting it.
@@ -433,44 +337,25 @@
   id: NR
   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.
+    The quality attributes and constraints the solution must satisfy, such as performance, security, scalability, reliability, and usability. The requirements are optionally grouped into the project-specific quality goals they refine (the upper levels of a quality attribute utility tree), which the overview diagram draws as boxes around their requirements.
   optional: true
-  refs: >
-    -   ISO/IEC 25010:2023: Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- Product quality model (2023),
-        https://www.iso.org/standard/78176.html
-    -   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: "[[NR.REQUIREMENT:*]]"
-    properties:
-      - PRIORITY
-      - CATEGORY
-    config:
-      size-node-width-max: 440
-      grid-columns-max: 5
   children:
+    - kind: GROUP
+      desc: >
+        A named group of requirements jointly refining one project-specific quality goal, carrying a short (1-3 word), per-artifact unique name distinct from the names of its requirements (e.g. `Observability` for the completeness, causality, integrity, and availability of the recorded traces, `Data Protection` for the lawful, minimal, and guarded processing of personal data), and described by a 1-sentence description ("what") of the quality goal the requirements add up to plus a 1-sentence rationale ("why") of the cohesion. A group is a quality goal in the sense of a quality attribute utility tree: unlike the fixed `CATEGORY` of a requirement, which classifies it for comparability, it names the quality the project itself strives for and may span requirements of several categories. It is distinct from a Functional Requirements group, which bundles the functions and mechanisms realizing such a quality. A group carries no obligation of its own: it has no priority, no metric, and is verified through its requirements alone, so it affects the overview diagram only, where its requirements are drawn next to each other inside a box. The groups are listed before the requirements, and every requirement belongs to at most one group.
+      optional: true
+      referenced:
+        - "[[NR.REQUIREMENT:*]]"
     - kind: REQUIREMENT
       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, 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").
 
         The requirement is answered by the architecture, never the other way round: a Quality Perspectives tactic addresses it through its mechanism, a Design Decisions decision is driven by it as a force, and an Operations View concern fulfills it through its procedure, so every requirement is referenced from at least one of them (a `WONT` requirement, which the architecture rightly ignores, is the tolerated exception the lint warning cannot tell apart) and its hub diagram shows what answers it.
+      optional: true
       referenced:
         - "[[TACTIC:*]]"
         - "[[DECISION:*]]"
         - "[[CONCERN:*]]"
-      diagram:
-        type: hub
-        center: self
-        nodes: "[[NR.REQUIREMENT:*]], [[FR.REQUIREMENT:*]], [[PREMISE:*]], [[RULE:*]], [[TACTIC:*]], [[DECISION:*]], [[CONCERN:*]], [[TEST-CASE:*]]"
-        labeled: true
-        qualified: true
-        config:
-          size-node-width-max: 440
-          size-node-height-scale: 1.75
       props:
         - name: PRIORITY
           desc: >
@@ -480,6 +365,11 @@
           desc: >
             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: GROUP
+          desc: >
+            Reference to the NON-FUNCTIONAL-REQUIREMENTS group (the quality goal) the requirement belongs to, placing it next to the other requirements of the group in the overview diagram, independent of its `CATEGORY`; omitted for a requirement standing on its own.
+          value: "[[NR.GROUP:*]]"
+          optional: true
         - name: QUALIFIES
           desc: >
             Comma-separated references to the FUNCTIONAL-REQUIREMENTS objects whose capability the requirement bounds or constrains.
@@ -501,22 +391,6 @@
   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.
   optional: true
-  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: "[[RULE:*]]"
-    properties:
-      - CATEGORY
-      - SOURCE
-    config:
-      size-node-width-max: 440
-      grid-columns-max: 5
   children:
     - kind: RULE
       desc: >
@@ -525,8 +399,7 @@
         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
+      optional: true
       referenced:
         - "[[TEST-CASE:*]]"
       props:
@@ -562,28 +435,13 @@
   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: "[[WORKFLOW:*]]"
-    properties:
-      - ACTORS
-    config:
-      size-node-width-max: 440
-      size-node-height-scale: 2
-      grid-columns-max: 4
   children:
     - 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. An activity and a use case relate n:m -- an activity is covered by several use cases, a use case spans several activities, and an activity performed outside the solution is covered by none at all -- so the workflow is no mere sequence of use cases and cannot be assembled from them.
+      optional: true
       automaton:
         nodes: ACTIVITY
         edges: HANDOFF
@@ -591,18 +449,6 @@
         target: TO
         initial: INITIAL
         final: FINAL
-      diagram:
-        type: graph
-        edges: "[[HANDOFF:*]]"
-        edgeSource: FROM
-        edgeTarget: TO
-        onlyConnected: true
-        qualified: true
-        nest:
-          properties:
-            - ACTOR
-        config:
-          size-node-width-max: 440
       props:
         - name: ACTORS
           desc: >
@@ -638,8 +484,6 @@
         - 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: >
@@ -662,8 +506,6 @@
           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.
@@ -690,36 +532,13 @@
   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.
   optional: true
-  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: graph
-    nodes: "[[USE-CASE:*]], [[ROLE:*]]"
-    labeled: true
-    qualified: true
-    onlyConnected: true
-    config:
-      size-node-width-max: 440
   children:
     - 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). Its `ACTIVITIES` relate it n:m to the Domain Workflow activities -- a use case spans several activities and an activity is covered by several use cases -- so the two decompose the same domain independently instead of nesting into each other.
-      diagram:
-        type: hub
-        center: self
-        nodes: "[[USE-CASE:*]], [[ROLE:*]], [[PERSONA:*]], [[STEP:*]], [[ACTIVITY:*]], [[FR.REQUIREMENT:*]], [[RULE:*]], [[DM.ENTITY:*]], [[TRANSITION:*]], [[PERMISSION:*]], [[PRINCIPLE:*]], [[STORYBOARD:*]], [[CV.ENTITY:*]], [[TEST-CASE:*]]"
-        labeled: true
-        qualified: true
-        config:
-          size-node-width-max: 440
-          size-node-height-scale: 1.75
+      optional: true
       props:
         - name: ACTOR
           desc: >
@@ -801,20 +620,6 @@
   desc: >
     The structure of named entities, with named attributes and directed relationships, of the data the solution manages, defining how information is organized and connected.
   optional: true
-  refs: >
-    -   Chen: The Entity-Relationship Model -- Toward a Unified View of Data (1976),
-        https://dl.acm.org/doi/10.1145/320434.320440
-    -   OMG UML 2.5.1: Unified Modeling Language (2017),
-        https://www.omg.org/spec/UML/2.5.1
-  diagram:
-    type: graph
-    nodes: "[[DM.ENTITY:*]]"
-    edges: "[[RELATION:*]]"
-    nest:
-      properties:
-        - GROUP
-    config:
-      graph-columns-max: 2
   children:
     - kind: GROUP
       name: "[A-Z][a-zA-Z0-9]*"
@@ -827,16 +632,7 @@
       name: "[A-Z][a-zA-Z0-9]*"
       desc: >
         A named entity of the data model, carrying a Pascal-cased, 1-3 word long, per-artifact unique name, and described by a 1-sentence description ("what") plus a 1-sentence rationale ("why").
-      diagram:
-        type: hub
-        center: self
-        nodes: "[[DM.ENTITY:*]], [[FR.REQUIREMENT:*]], [[USE-CASE:*]], [[LIFECYCLE:*]], [[FV.COMPONENT:*]], [[CONCERN:*]], [[TACTIC:*]], [[DECISION:*]], [[TEST-CASE:*]]"
-        edges: "[[RELATION:*]]"
-        labeled: true
-        qualified: true
-        config:
-          size-node-width-max: 440
-          size-node-height-scale: 1.75
+      optional: true
       props:
         - name: REQUIREMENTS
           desc: >
@@ -863,8 +659,6 @@
           name: "[a-z][a-zA-Z0-9]*"
           desc: >
             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: >
@@ -894,8 +688,6 @@
           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"). 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
-          format:
-            maxTableColumns: 5
           props:
             - name: TARGET
               desc: Reference to the DATA-MODEL entity the directed relation targets.
@@ -918,24 +710,11 @@
   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.
   optional: true
-  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: "[[LIFECYCLE:*]]"
-    properties:
-      - ENTITY
-    config:
-      size-node-width-max: 440
-      size-node-height-scale: 2
-      grid-columns-max: 5
   children:
     - 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. 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).
+      optional: true
       automaton:
         nodes: STATE
         edges: TRANSITION
@@ -943,18 +722,6 @@
         target: TO
         initial: INITIAL
         final: FINAL
-      diagram:
-        type: graph
-        edges: "[[TRANSITION:*]]"
-        edgeSource: FROM
-        edgeTarget: TO
-        onlyConnected: true
-        properties:
-          - INITIAL
-          - FINAL
-        config:
-          size-node-width-max: 440
-          size-node-height-scale: 1.75
       props:
         - name: ENTITY
           desc: >
@@ -1022,32 +789,11 @@
   desc: >
     The access rights of the solution, granted to the roles of the User Personas 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.
   optional: true
-  refs: >
-    -   Ferraiolo/Kuhn: Role-Based Access Controls, 15th National Computer Security Conference (1992),
-        https://csrc.nist.gov/publications/detail/conference-paper/1992/10/13/role-based-access-controls
-    -   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: graph
-    nodes: "[[ROLE:*]], [[DM.ENTITY:*]]"
-    edges: "[[PERMISSION:*]]"
-    edgeSource: ROLE
-    edgeTarget: ENTITY
-    onlyConnected: true
-    qualified: true
-    config:
-      size-node-width-max: 440
-      graph-channel-width-max: 340
   children:
     - kind: PERMISSION
       desc: >
         A single right of a 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 a role it `INHERITS`) is forbidden.
-      format:
-        maxTableColumns: 8
+      optional: true
       props:
         - name: ROLE
           desc: >
@@ -1087,35 +833,11 @@
   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: "[[INTERFACE:*]]"
-    properties:
-      - KIND
-      - DIRECTION
   children:
     - 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: "[[INTERFACE:*]], [[TYPE:*]], [[ENDPOINT:*]], [[FV.COMPONENT:*]]"
-        labeled: true
-        qualified: true
-        config:
-          size-node-width-max: 440
+      optional: true
       props:
         - name: KIND
           desc: |
@@ -1154,36 +876,12 @@
   desc: >
     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: graph
-    nodes: "[[TYPE:*]]"
-    deep: true
-    onlyConnected: true
-    labeled: true
-    qualified: true
-    config:
-      size-node-width-max: 440
   children:
     - kind: TYPE
       name: "[A-Z][A-Za-z0-9_]*"
       desc: >
         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: "[[TYPE:*]], [[INTERFACE:*]], [[ENDPOINT:*]]"
-        deep: true
-        labeled: true
-        qualified: true
-        config:
-          size-node-width-max: 600
-          size-node-height-scale: 1.75
       props:
         - name: INTERFACES
           desc: >
@@ -1211,8 +909,6 @@
           desc: >
             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: >
@@ -1237,8 +933,6 @@
           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: >
@@ -1255,26 +949,6 @@
   desc: >
     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: graph
-    nodes: "[[ENDPOINT:*]], [[TYPE:*]]"
-    deep: true
-    onlyConnected: true
-    labeled: true
-    qualified: true
-    config:
-      size-node-width-max: 440
   children:
     - kind: ENDPOINT
       name: "[A-Za-z_][A-Za-z0-9_-]*"
@@ -1284,16 +958,7 @@
         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: "[[ENDPOINT:*]], [[TYPE:*]], [[CONSTANT:*]], [[INTERFACE:*]], [[PERMISSION:*]]"
-        deep: true
-        labeled: true
-        qualified: true
-        config:
-          size-node-width-max: 600
-          size-node-height-scale: 1.75
+      optional: true
       props:
         - name: INTERFACE
           desc: The INTERFACES object the endpoint belongs to and is addressed within.
@@ -1337,8 +1002,6 @@
           desc: >
             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: >
@@ -1368,8 +1031,6 @@
           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: >
@@ -1394,8 +1055,6 @@
           desc: >
             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: >
@@ -1418,37 +1077,14 @@
   file: 17-UXUI-IC-Interaction-Concept.md
   desc: >
     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: "[[PRINCIPLE:*]]"
-    properties:
-      - CATEGORY
-    config:
-      size-node-width-max: 440
-      size-node-height-scale: 2
-      grid-columns-max: 4
   children:
     - 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"). 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).
+        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"). 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`), is not verifiable by a metric (a measurable quality bound is a Non-Functional Requirement instead), and governs the user's experience (a principle governing the architecture is an Architecture Tenets principle instead).
+      optional: true
       referenced:
-        - "[[PATTERN:*]]"
-      diagram:
-        type: hub
-        center: self
-        nodes: "[[PRINCIPLE:*]], [[PERSONA:*]], [[STEP:*]], [[USE-CASE:*]], [[CONVENTION:*]], [[PATTERN:*]], [[ELEMENT:*]], [[DECISION:*]]"
-        labeled: true
-        qualified: true
-        config:
-          size-node-width-max: 440
+        - "[[DIALOG-PATTERN:*]]"
       props:
         - name: CATEGORY
           desc: >
@@ -1479,29 +1115,12 @@
   file: 18-UXUI-LC-Language-Conventions.md
   desc: >
     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 Aspects).
-  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: "[[CONVENTION:*]]"
-    properties:
-      - CATEGORY
-    config:
-      size-node-width-max: 440
-      size-node-height-scale: 2
-      grid-columns-max: 4
   children:
     - kind: CONVENTION
       desc: >
         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).
+      optional: true
       props:
         - name: CATEGORY
           desc: >
@@ -1515,7 +1134,7 @@
         - 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([[PRINCIPLE:*]])
+          value: list([[IC.PRINCIPLE:*]])
           optional: true
         - name: TERMS
           desc: >
@@ -1532,36 +1151,12 @@
   file: 19-UXUI-DP-Dialog-Patterns.md
   desc: >
     The reusable interaction structures governing how the system and user exchange information 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: "[[PATTERN:*]]"
-    properties:
-      - CATEGORY
-    config:
-      size-node-width-max: 440
-      size-node-height-scale: 2
-      grid-columns-max: 4
   children:
-    - kind: PATTERN
+    - kind: DIALOG-PATTERN
       desc: >
         A single reusable dialog pattern, named with a short (2-5 word) summary (e.g. `Master-Detail`, `Wizard`, `Inline Edit`) and described in a concise (1-3 sentence) 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. 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: "[[PATTERN:*]], [[PRINCIPLE:*]], [[STORYBOARD:*]], [[DECISION:*]]"
-        deep: true
-        labeled: true
-        qualified: true
-        config:
-          size-node-width-max: 440
+      optional: true
       props:
         - name: CATEGORY
           desc: >
@@ -1581,12 +1176,12 @@
         - 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([[PRINCIPLE:*]])
+          value: list([[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([[PATTERN:*]])
+          value: list([[DIALOG-PATTERN:*]])
           optional: true
         - name: TRADE-OFF
           desc: >
@@ -1598,37 +1193,12 @@
   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: "[[STORYBOARD:*]]"
-    properties:
-      - ACTORS
-    config:
-      size-node-width-max: 440
-      size-node-height-scale: 2
-      grid-columns-max: 4
   children:
     - kind: STORYBOARD
       desc: >
         A single depicted dialog flow, named with a short (3-8 word) summary of the flow and comprised of frames in sequence. A storyboard shows the concrete user interface of one flow, as seen by its actors (the intent and the information exchanged are a Use Cases scenario instead, and a structure recurring across flows is a Dialog Pattern instead).
-      diagram:
-        type: hub
-        center: self
-        nodes: "[[STORYBOARD:*]], [[PERSONA:*]], [[SCENARIO:*]], [[PATTERN:*]], [[MOCKUP:*]]"
-        deep: true
-        labeled: true
-        qualified: true
-        config:
-          size-node-width-max: 440
-          size-node-height-scale: 1.75
+      optional: true
       props:
         - name: ACTORS
           desc: >
@@ -1643,9 +1213,6 @@
         - kind: FRAME
           desc: >
             A single frame of the storyboard, named with a short (2-5 word) label for 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: >
@@ -1660,7 +1227,7 @@
             - 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([[PATTERN:*]])
+              value: list([[DIALOG-PATTERN:*]])
               optional: true
             - name: SKETCH
               desc: >
@@ -1673,37 +1240,12 @@
   file: 21-UXUI-VD-Visual-Design.md
   desc: >
     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: "[[ELEMENT:*]]"
-    properties:
-      - CATEGORY
-    config:
-      size-node-width-max: 440
-      size-node-height-scale: 2
-      grid-columns-max: 4
   children:
     - kind: ELEMENT
       desc: >
         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: "[[ELEMENT:*]], [[PERSONA:*]], [[PRINCIPLE:*]], [[MOCKUP:*]]"
-        labeled: true
-        qualified: true
-        config:
-          size-node-width-max: 440
+      optional: true
       props:
         - name: CATEGORY
           desc: >
@@ -1717,7 +1259,7 @@
         - 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([[PRINCIPLE:*]])
+          value: list([[IC.PRINCIPLE:*]])
           optional: true
         - name: SOURCE
           desc: >
@@ -1729,8 +1271,7 @@
     - 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
+      optional: true
       props:
         - name: ACTORS
           desc: >
@@ -1749,44 +1290,92 @@
           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: ARCH
+  name: Architecture Tenets
+  id: AT
+  file: 22-ARCH-AT-Architecture-Tenets.md
+  desc: >
+    The architecture philosophy of the solution, stated as the few overarching maxims and the standing principles derived from them, which every pattern, view, tactic, decision, and aspect of the architecture has to obey, while the reusable structures belong to the Architecture Patterns and the concrete ones to the views following them. The maxims are listed in decreasing precedence, so that whenever two maxims conflict in a particular design decision, the earlier one wins, and a principle conflict is settled by the precedence of the maxims the principles derive from.
+
+    The tenets are prescriptive and reusable, not verifiable and not decided once: a quality bound verifiable by a metric is a Non-Functional Requirement, the mechanism achieving a quality is a Quality Perspectives tactic, the rule about the source structure and process is a Development Aspects aspect, the one-off trade-off between genuine alternatives is a Design Decisions decision (which applies the tenets through `GUIDED-BY`), and the principle governing the user's experience is an Interaction Concept principle.
+  optional: true
+  children:
+    - kind: MAXIM
+      desc: >
+        A single architecture maxim, named with a short (2-5 word) preference or imperative (e.g. `Simplicity over Flexibility`, `Buy before Build`, `Own the Data`) and described in a concise (1-3 sentence) paragraph by how it guides the architecture of the solution as a whole, plus a 1-sentence rationale ("why"). A solution has only a few (3-7) maxims: a maxim is solution-wide and independent of any particular view or element (a rule bound to a structure is a principle instead), decides between design alternatives (the subordinated side usually named by its `X over Y` form), and is not verifiable by a metric (a measurable quality bound is a Non-Functional Requirement instead).
+      optional: true
+      props:
+        - name: DRIVEN-BY
+          desc: >
+            Comma-separated references to the NON-FUNCTIONAL-REQUIREMENTS or SOLUTION-PREMISES objects the maxim answers (e.g. the maintainability requirement, the small-team premise), so that a maxim is grounded in the forces on the solution rather than in taste alone; omitted for a maxim rooted in the Solution Vision alone.
+          value: list([[NR.*]], [[PREMISE:*]])
+          optional: true
+    - kind: PRINCIPLE
+      desc: >
+        A single architecture principle, named with a short (2-5 word) summary (e.g. `Stateless Services`, `One Owner per Entity`, `Async between Contexts`) and described in a concise (1-3 sentence) paragraph as the standing rule the architecture follows whenever its concern arises, stated with `MUST`/`MUST NOT` or `SHOULD`/`SHOULD NOT`, plus a 1-sentence rationale ("why"). A principle is bound to a particular structure of the architecture (a rule independent of any structure is a maxim instead), reusable across many decisions (a trade-off made once between genuine alternatives is a Design Decisions decision instead), names no mechanism and no product (the mechanism is a Quality Perspectives tactic, the product a Technology Stack component), and governs the architecture, not the source process (a Development Aspects aspect), the code (a Code Patterns pattern), or the user's experience (an Interaction Concept principle).
+      optional: true
+      props:
+        - name: MAXIMS
+          desc: >
+            Comma-separated references to the MAXIM objects the principle concretizes (e.g. a `Stateless Services` principle concretizing a `Scale Out over Scale Up` maxim), so that the principles form a hierarchy below the maxims rather than a flat catalogue; omitted for a principle standing on its own forces alone.
+          value: list([[MAXIM:*]])
+          optional: true
+        - name: DRIVEN-BY
+          desc: >
+            Comma-separated references to the NON-FUNCTIONAL-REQUIREMENTS or SOLUTION-PREMISES objects the principle answers beyond the maxims it concretizes (e.g. the availability requirement, the hosting constraint); omitted for a principle grounded in its maxims alone.
+          value: list([[NR.*]], [[PREMISE:*]])
+          optional: true
+        - name: IMPLICATIONS
+          desc: >
+            What following the principle obliges the architecture to, stated as a 1-2 sentence description of the consequences for the elements it governs (e.g. `session state lives in the shared store, so every component instance is replaceable at any time`), as opposed to the rationale which states why the principle is worth these consequences; omitted when nothing non-obvious follows from the principle.
+          optional: true
+
+- kind: ARCH
+  name: Architecture Patterns
+  id: AP
+  file: 23-ARCH-AP-Architecture-Patterns.md
+  desc: >
+    The reusable structural solutions the architecture of the solution follows, each a named pattern of the literature or of the organization (e.g. hexagonal architecture, transactional outbox, backend for frontend) applied to the solution as a whole, which the views following them realize, the tactics build upon, the decisions choose, and the code patterns code. The artifact completes the guidance of the architecture: the Architecture Tenets state what the architecture values and obeys, the patterns state the structures it takes to do so.
+
+    A pattern names a structure, nothing else: the mechanism achieving one quality attribute is a Quality Perspectives tactic (which may be built from patterns), the one-off trade-off choosing a pattern over its alternatives is a Design Decisions decision, the coded form of a pattern is a Code Patterns pattern shown as a listing, and a structure of the user interface is a Dialog Patterns pattern.
+  optional: true
+  children:
+    - kind: PATTERN
+      desc: >
+        A single architecture pattern, named with its established short (2-5 word) name (e.g. `Hexagonal Architecture`, `Transactional Outbox`, `Backend for Frontend`) and described in a concise (1-3 sentence) paragraph by the structure the pattern prescribes and the problem it solves in the solution, plus a 1-sentence rationale ("why") for adopting it. A pattern is a structure reusable beyond one quality attribute (a mechanism for one quality is a Quality Perspectives tactic instead) and beyond one decision (a trade-off made once is a Design Decisions decision instead), applies the Architecture Tenets rather than restating them, and is realized by the elements of the views following it, which reference it, so its hub diagram shows where it took effect.
+      optional: true
+      props:
+        - name: PRINCIPLES
+          desc: >
+            Comma-separated references to the ARCHITECTURE-TENETS principles the pattern applies (e.g. a `Transactional Outbox` applying an `Async between Contexts` principle), so that a pattern is adopted for a stated stance of the architecture rather than for its popularity; omitted for a pattern applying no modeled principle.
+          value: list([[AT.PRINCIPLE:*]])
+          optional: true
+        - name: DRIVEN-BY
+          desc: >
+            Comma-separated references to the NON-FUNCTIONAL-REQUIREMENTS or SOLUTION-PREMISES objects the pattern answers beyond the principles it applies (e.g. the scalability requirement, the hosting constraint); omitted for a pattern grounded in its principles alone.
+          value: list([[NR.*]], [[PREMISE:*]])
+          optional: true
+        - name: USES
+          desc: >
+            Comma-separated references to the smaller ARCHITECTURE-PATTERNS objects the pattern is composed of (e.g. a `Saga` using a `Transactional Outbox` for its steps), so that the patterns form a language of related structures rather than a flat catalogue.
+          value: list([[PATTERN:*]])
+          optional: true
+          acyclic: true
+
 - kind: ARCH
   name: Context View
   id: CV
-  file: 22-ARCH-CV-Context-View.md
+  file: 24-ARCH-CV-Context-View.md
   desc: >
     The relationships, dependencies, and interactions between the solution and its environment, defining the system's boundary by enumerating the external entities sitting at it. The artifact complements the Solution Vision: its `SCOPE` states what is deliberately *out* of the solution, the Context View enumerates what the solution touches *at* the boundary.
   optional: true
-  refs: >
-    -   Rozanski/Woods: Software Systems Architecture, 2nd ed.: The Context Viewpoint (2011),
-        https://www.viewpoints-and-perspectives.info/home/viewpoints/context/
-    -   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: hub
-    nodes: "[[CV.ENTITY:*]]"
-    center:
-      source: "[[TI]]"
-      property: TITLE
-      kind: Solution
-    centerEdges:
-      property: DIRECTION
-      inbound: Inbound
-      outbound: Outbound
-      both: Bidirectional
-      via: VIA
-    qualified: true
-    properties:
-      - KIND
   children:
     - kind: ENTITY
       desc: >
         A single external entity the solution interacts with, named with a short (2-5 word) summary (e.g. `Payment Gateway`, `Identity Provider`, `End User`) and described in a concise (1-3 sentence) paragraph by the relationship and dependency between the 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
+      optional: true
       props:
         - name: KIND
           desc: |
@@ -1840,43 +1429,15 @@
 - kind: ARCH
   name: Functionality View
   id: FV
-  file: 23-ARCH-FV-Functionality-View.md
+  file: 25-ARCH-FV-Functionality-View.md
   desc: >
     The functional components of the solution, their responsibilities, interfaces, and primary interactions, describing *how* the solution's runtime elements are structured and which responsibility each owns, delivering the behaviors the Functional Requirements state.
   optional: true
-  refs: >
-    -   Rozanski/Woods: Software Systems Architecture, 2nd ed.: The Functional Viewpoint (2011),
-        https://www.viewpoints-and-perspectives.info/home/viewpoints/functional/
-    -   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: "[[FV.COMPONENT:*]]"
-    labeled: true
-    nest:
-      properties:
-        - PART-OF
-    properties:
-      - KIND
   children:
     - kind: COMPONENT
       desc: >
         A single functional component, named with a short (2-5 word) summary (e.g. `Authentication Service`, `Order Processor`, `Notification Dispatcher`) and described in a concise (1-3 sentence) paragraph whose first sentence names the single, primary responsibility the component owns (split into several components otherwise) and which elaborates how the component fulfills it and collaborates with the components it depends on, plus a 1-sentence rationale ("why") for the component's existence and boundary.
-      format:
-        maxTableColumns: 5
-      diagram:
-        type: hub
-        center: self
-        nodes: "[[FV.COMPONENT:*]], [[FR.REQUIREMENT:*]], [[INTERFACE:*]], [[DM.ENTITY:*]], [[UNIT:*]], [[NODE:*]], [[CONCERN:*]], [[TACTIC:*]], [[DECISION:*]]"
-        labeled: true
-        qualified: true
-        properties:
-          - KIND
-        config:
-          size-node-width-max: 440
-          size-node-height-scale: 1.75
+      optional: true
       props:
         - name: KIND
           desc: |
@@ -1900,6 +1461,11 @@
             Comma-separated references to the FUNCTIONAL-REQUIREMENTS objects the component realizes, i.e. whose capability its functionality delivers, so that every Functional Requirement is owned by at least one component.
           value: list([[FR.*]])
           optional: true
+        - name: PATTERNS
+          desc: >
+            Comma-separated references to the ARCHITECTURE-PATTERNS objects the structure of the component follows (e.g. the service shaped by a `Hexagonal Architecture`, the publisher keeping a `Transactional Outbox`); omitted for a component following no modeled pattern.
+          value: list([[PATTERN:*]])
+          optional: true
         - name: OWNS
           desc: >
             Comma-separated references to the DATA-MODEL entities the component owns, i.e. for which it is the single authoritative source of truth (other components access an owned entity through the owner's interfaces or hold derived copies only), so that every entity is owned by at most one component; omitted when the component owns no entity.
@@ -1924,26 +1490,10 @@
 - kind: ARCH
   name: Technology Stack
   id: TS
-  file: 24-ARCH-TS-Technology-Stack.md
+  file: 26-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.
   optional: true
-  refs: >
-    -   Starke/Hruschka: arc42 Template: Solution Strategy and Crosscutting Concepts (2005),
-        https://arc42.org/overview
-    -   Brown: The C4 Model: Container Diagram (2018),
-        https://c4model.com/diagrams/container
-  diagram:
-    type: grid
-    nodes: "[[TS.TIER:*]], [[TS.TIER:*.COMPONENT:*]]"
-    nest:
-      parent: true
-      layout: grid
-    properties:
-      - PRODUCT
-    config:
-      size-node-width-max: 440
-      grid-columns-max: 2
   children:
     - kind: TIER
       desc: |
@@ -1959,34 +1509,13 @@
                           or a shared module used by client and server), so a product
                           used on several tiers is a single component here instead of
                           one per tier; referenced by no Deployment View tier.
-      diagram:
-        type: hub
-        center: self
-        nodes: "[[TS.TIER:*]], [[TS.TIER:*.COMPONENT:*]], [[DV.TIER:*]]"
-        hierarchy: true
-        properties:
-          - PRODUCT
-        config:
-          size-node-width-max: 440
-          size-node-height-scale: 1.75
+      optional: true
       children:
         - kind: COMPONENT
           desc: >
             A single technology component, named with a short (2-5 word) summary (e.g. `UI Framework`, `Web Server`, `Relational Database`) and described in a concise (1-3 sentence) paragraph by how the product is used within the solution and how it fits into the overall technology stack, plus a 1-sentence rationale ("why") for choosing this product over the alternatives.
 
             A component states one product in one role on one tier: the product used by several tiers alike belongs to the `Common` tier once, the lock-in carrying trade-off behind the choice is a Design Decisions decision referencing the component through `DECIDES`, and the functional components depending on the product reference it through `USED-BY`.
-          diagram:
-            type: hub
-            center: self
-            nodes: "[[TS.TIER:*.COMPONENT:*]], [[FV.COMPONENT:*]], [[CONCERN:*]], [[TACTIC:*]], [[DECISION:*]]"
-            labeled: true
-            qualified: true
-            properties:
-              - PRODUCT
-              - PHASE
-            config:
-              size-node-width-max: 440
-              size-node-height-scale: 1.75
           props:
             - name: PRODUCT
               desc: >
@@ -2235,82 +1764,42 @@
 - kind: ARCH
   name: Development Aspects
   id: DA
-  file: 25-ARCH-DA-Development-Aspects.md
+  file: 27-ARCH-DA-Development-Aspects.md
   desc: >
     The architecture supporting the software development process, defining the module organization, build approach, and codeline conventions. The artifact is absent when the development conventions are governed outside the specification (e.g. by repository-level contributor instructions).
   optional: true
-  refs: >
-    -   Rozanski/Woods: Software Systems Architecture, 2nd ed.: The Development Viewpoint (2011),
-        https://www.viewpoints-and-perspectives.info/home/viewpoints/development/
-    -   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: "[[ASPECT:*]]"
-    properties:
-      - CATEGORY
   children:
     - kind: ASPECT
       desc: >
         A single development aspect, named with a short (2-5 word) summary (e.g. `Module Layering`, `Build Pipeline`, `Branching Model`) and described in a concise (1-3 sentence) paragraph by the development convention or structure and the rule developers must follow, plus a 1-sentence rationale ("why").
 
-        An aspect states a standing developer-facing rule about the source structure and process: it names no concrete products (a Technology Stack `Build-Time` component states the product choice), does not restate the runtime structure (a Functionality View `Module` or `Subsystem` groups the logic), does not cover production procedures (an Operations View concern does), and the trade-off that produced a rule is a Design Decisions decision referencing the aspect through `AFFECTS`, while the quality the rule protects (usually a `Maintainability` requirement) is addressed by a Quality Perspectives tactic referencing the aspect through `AFFECTS`, too, so the hub diagram of an aspect shows the decision and the tactic behind it.
-      diagram:
-        type: hub
-        center: self
-        nodes: "[[ASPECT:*]], [[TACTIC:*]], [[DECISION:*]]"
-        labeled: true
-        qualified: true
-        properties:
-          - CATEGORY
-        config:
-          size-node-width-max: 440
-          size-node-height-scale: 1.75
+        An aspect states a standing developer-facing rule about the source structure and process: it names no concrete products (a Technology Stack `Build-Time` component states the product choice), does not restate the runtime structure (a Functionality View `Module` or `Subsystem` groups the logic), does not cover production procedures (an Operations View concern does), does not prescribe how a concern is coded (a Code Patterns pattern shows that as a listing), the tenet the rule concretizes is an Architecture Tenets maxim or principle referenced through `GUIDED-BY`, and the trade-off that produced a rule is a Design Decisions decision referencing the aspect through `AFFECTS`, while the quality the rule protects (usually a `Maintainability` requirement) is addressed by a Quality Perspectives tactic referencing the aspect through `AFFECTS`, too, so the hub diagram of an aspect shows the tenet, the decision, and the tactic behind it.
+      optional: true
       props:
         - name: CATEGORY
           desc: >
             The development concern the aspect governs: `Structure` (the physical source module/package layout), `Build` (compilation and packaging), `Dependency` (the allowed dependency edges between the structures), `Codeline` (branching, merging, versioning), `Standardization` (coding standards and conventions), `Testing` (test conventions, layout, and coverage rules), or `Tooling` (development tools and automation).
           value: enum(Structure,Build,Dependency,Codeline,Standardization,Testing,Tooling)
+        - name: GUIDED-BY
+          desc: >
+            Comma-separated references to the ARCHITECTURE-TENETS objects the aspect concretizes for the source structure and process (e.g. the module layering following a `Dependencies Point Inward` principle); omitted for an aspect concretizing no modeled tenet.
+          value: list([[MAXIM:*]], [[AT.PRINCIPLE:*]])
+          optional: true
 
 - kind: ARCH
   name: Concurrency View
   id: CO
-  file: 26-ARCH-CO-Concurrency-View.md
+  file: 28-ARCH-CO-Concurrency-View.md
   desc: >
     The concurrency structure of the solution, mapping functional components to processes and threads, and defining how they coordinate and communicate. The artifact is absent when the solution runs as a single sequential unit of execution and has no concurrency structure worth describing.
   optional: true
-  refs: >
-    -   Rozanski/Woods: Software Systems Architecture, 2nd ed.: The Concurrency Viewpoint (2011),
-        https://www.viewpoints-and-perspectives.info/home/viewpoints/concurrency/
-    -   Kruchten: Architectural Blueprints -- The "4+1" View Model of Software Architecture (1995),
-        https://ieeexplore.ieee.org/document/469759
-    -   Schmidt et al.: Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects (2000),
-        https://www.wiley.com/en-us/Pattern+Oriented+Software+Architecture,+Volume+2,+Patterns+for+Concurrent+and+Networked+Objects-p-9781118725177
-  diagram:
-    type: graph
-    nodes: "[[UNIT:*]]"
-    labeled: true
-    properties:
-      - KIND
   children:
     - kind: UNIT
       desc: >
         A single concurrency unit, named with a short (2-5 word) summary (e.g. `Web Worker Pool`, `Background Scheduler`, `Ingest Queue Consumer`) and described in a concise (1-3 sentence) paragraph by how it executes and how it avoids or manages contention, races, and deadlocks (including its start order and failure/restart behavior where non-obvious), plus a 1-sentence rationale ("why") for the chosen concurrency structure.
 
         A unit executes work at runtime: a queue or channel between units is not a unit but the coordination mechanism stated in `COORDINATION`, its contract an Interface Model interface (e.g. of kind `MQTT` or `WebSocket`), and the platform element hosting a managed broker a Deployment View `Managed` node -- only the executing structure itself belongs to the Concurrency View.
-      diagram:
-        type: hub
-        center: self
-        nodes: "[[UNIT:*]], [[FV.COMPONENT:*]], [[NODE:*]], [[TACTIC:*]], [[DECISION:*]]"
-        labeled: true
-        qualified: true
-        properties:
-          - KIND
-        config:
-          size-node-width-max: 440
-          size-node-height-scale: 1.75
+      optional: true
       props:
         - name: KIND
           desc: |
@@ -2348,52 +1837,17 @@
 - kind: ARCH
   name: Deployment View
   id: DV
-  file: 27-ARCH-DV-Deployment-View.md
+  file: 29-ARCH-DV-Deployment-View.md
   desc: >
     The environment into which the solution is deployed, partitioning it into tiers and mapping software elements to the runtime platform, hardware, and network topology.
   optional: true
-  refs: >
-    -   Rozanski/Woods: Software Systems Architecture, 2nd ed.: The Deployment Viewpoint (2011),
-        https://www.viewpoints-and-perspectives.info/home/viewpoints/deployment/
-    -   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: graph
-    nodes: "[[NODE:*]]"
-    labeled: true
-    qualified: true
-    nest:
-      properties:
-        - PART-OF
-        - TIER
-    properties:
-      - AREA
-      - KIND
-      - PLATFORM
-    config:
-      size-node-width-max: 350
   children:
     - kind: TIER
       desc: >
         A single deployment tier, named with a short (1-3 word) summary (e.g. `Client`, `Server`, `Database`, `Data Center`) and described in a concise (1-3 sentence) paragraph by the code or data it hosts and its spatial and network separation from the other tiers, plus a 1-sentence rationale ("why") for the partitioning.
 
         A tier is a logically and spatially distinct, network-connected, technology-induced partition of the solution, the *horizontal* split when drawn (an `AREA` is the *vertical*, domain-induced one): every node belongs to exactly one tier via its `TIER`, a location-level tier (e.g. a data center) groups the tiers referencing it via `PART-OF`, and a single deployment unit within a tier is a `NODE` -- only the partition itself belongs here.
-      format:
-        type: concise
-      diagram:
-        type: hub
-        center: self
-        nodes: "[[DV.TIER:*]], [[NODE:*]], [[TACTIC:*]], [[DECISION:*]]"
-        labeled: true
-        qualified: true
-        properties:
-          - LOCATION
-          - KIND
-        config:
-          size-node-width-max: 440
-          size-node-height-scale: 1.75
+      optional: true
       props:
         - name: PART-OF
           desc: >
@@ -2416,38 +1870,12 @@
 
         An area is a logically distinct, domain-induced partition of the solution deployed as physical units of its own, the *vertical* split when drawn (a `TIER` is the *horizontal*, technology-induced one): a node dedicated to the area references it via its `AREA`, a node shared by several areas references none, and a domain grouping without deployment units of its own is a Functionality View `Subsystem` instead. The kind is absent when the solution is not split vertically.
       optional: true
-      format:
-        type: concise
-      diagram:
-        type: hub
-        center: self
-        nodes: "[[AREA:*]], [[NODE:*]], [[TACTIC:*]], [[DECISION:*]]"
-        labeled: true
-        qualified: true
-        properties:
-          - KIND
-        config:
-          size-node-width-max: 440
-          size-node-height-scale: 1.75
     - kind: NODE
       desc: >
         A single deployment node, named with a short (2-5 word) summary (e.g. `Web Servers`, `Database Cluster`, `Edge CDN`) and described in a concise (1-3 sentence) paragraph by the node, its sizing, and its place in the deployment topology, plus a 1-sentence rationale ("why") for the node's placement and platform choice.
 
         A node is a platform element the solution deploys onto and operates itself: a managed third-party service the solution merely consumes is a Context View `Service` entity, the software products running on the node are Technology Stack components (referencing the hosted components through `USED-BY`), and the procedures operating the node are Operations View concerns -- only the runtime environment itself belongs to the Deployment View, with the tier and area the node belongs to and the network segments it is attached to as its `TIER`, `AREA`, and `NETWORK` siblings.
-      diagram:
-        type: hub
-        center: self
-        nodes: "[[DV.TIER:*]], [[AREA:*]], [[NODE:*]], [[NETWORK:*]], [[FV.COMPONENT:*]], [[UNIT:*]], [[CONCERN:*]], [[TACTIC:*]], [[DECISION:*]]"
-        labeled: true
-        qualified: true
-        properties:
-          - LOCATION
-          - KIND
-          - PLATFORM
-          - SCOPE
-        config:
-          size-node-width-max: 440
-          size-node-height-scale: 1.75
+      optional: true
       props:
         - name: KIND
           desc: |
@@ -2503,20 +1931,6 @@
 
         A segment is the medium the nodes communicate over: the attached nodes reference it via `NETWORKS`, the directed links between them are their `CONNECTS-TO` references, and the contract of the carried traffic is an Interface Model interface -- only the network itself belongs here. The kind is absent when the topology has no segmentation worth describing.
       optional: true
-      format:
-        type: concise
-      diagram:
-        type: hub
-        center: self
-        nodes: "[[NETWORK:*]], [[NODE:*]], [[TACTIC:*]], [[DECISION:*]]"
-        labeled: true
-        qualified: true
-        properties:
-          - KIND
-          - SCOPE
-        config:
-          size-node-width-max: 440
-          size-node-height-scale: 1.75
       props:
         - name: SCOPE
           desc: |
@@ -2536,39 +1950,17 @@
 - kind: ARCH
   name: Operations View
   id: OV
-  file: 28-ARCH-OV-Operations-View.md
+  file: 30-ARCH-OV-Operations-View.md
   desc: >
     The way the solution is operated, administered, and supported in production, defining the standing procedures by which the operating organization installs, configures, migrates, observes, protects, upgrades, scales, and supports the running solution.
   optional: true
-  refs: >
-    -   Rozanski/Woods: Software Systems Architecture, 2nd ed.: The Operational Viewpoint (2011),
-        https://www.viewpoints-and-perspectives.info/home/viewpoints/operational/
-    -   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: "[[CONCERN:*]]"
-    properties:
-      - CATEGORY
   children:
     - kind: CONCERN
       desc: >
         A single operational concern, named with a short (2-5 word) summary (e.g. `Rolling Deployment`, `Metrics Collection`, `Backup and Restore`) and described in a concise (1-3 sentence) paragraph by the procedure through which it is handled in production and the steps and tools supporting it, plus a 1-sentence rationale ("why") for the operational approach.
 
         A concern states a standing production procedure the operating organization performs on the running solution: a capability the solution offers its users (even an administrating one) is a Functional Requirement or Use Case, an automatic behavior of the solution is a Domain Rule, the design tactic making the solution operable (e.g. replication, statelessness) is a Quality Perspectives tactic referencing the concern through `OPERATED-BY`, the deployment shape acted upon (instances, environments) is the Deployment View, the pipeline producing the deployable artifact is a `Build` aspect of the Development Aspects, and the products used are Technology Stack `Operate-Time` components referenced through `TOOLS` -- only the procedure itself, its trigger, and its responsible operator belong here.
-      diagram:
-        type: hub
-        center: self
-        nodes: "[[CONCERN:*]], [[NR.REQUIREMENT:*]], [[PERSONA:*]], [[TACTIC:*]], [[FV.COMPONENT:*]], [[UNIT:*]], [[NODE:*]], [[DM.ENTITY:*]], [[TS.TIER:*.COMPONENT:*]]"
-        labeled: true
-        qualified: true
-        properties:
-          - CATEGORY
-        config:
-          size-node-width-max: 440
-          size-node-height-scale: 1.75
+      optional: true
       props:
         - name: CATEGORY
           desc: |
@@ -2620,38 +2012,17 @@
 - kind: ARCH
   name: Quality Perspectives
   id: QP
-  file: 29-ARCH-QP-Quality-Perspectives.md
+  file: 31-ARCH-QP-Quality-Perspectives.md
   desc: >
     How the Non-Functional Requirements (NR) are addressed by the architecture, through the tactics built into the solution across the views.
   optional: true
-  refs: >
-    -   Rozanski/Woods: Software Systems Architecture, 2nd ed.: The Perspectives (2011),
-        https://www.viewpoints-and-perspectives.info/home/perspectives/
-    -   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: "[[TACTIC:*]]"
-    properties:
-      - QUALITY
   children:
     - kind: TACTIC
       desc: >
         A single quality tactic, one architectural tactic applied to one quality attribute (the perspective in the sense of Rozanski/Woods, i.e. the cross-cutting quality concern applied to the elements of all views, identified by `QUALITY`), named with a short (2-5 word) summary (e.g. `Horizontal Scaling`, `Defense in Depth`, `Graceful Degradation`) and described in a concise (1-3 sentence) paragraph by how the tactic satisfies the quality attribute across the affected elements, plus a 1-sentence rationale ("why") for the tactic satisfying the addressed requirements (not for choosing it over alternatives, which is the rationale of a Design Decisions decision).
 
-        A tactic states a design mechanism built into the solution: the threshold the mechanism has to meet is the `METRIC` of the addressed Non-Functional Requirement and is not restated, the production procedure performed against the mechanism (e.g. scaling out, restoring) is an Operations View concern referenced through `OPERATED-BY`, the trade-off that chose the mechanism over alternatives is a Design Decisions decision referencing the tactic through `DECIDES`, the product realizing the mechanism is a Technology Stack component referenced through `TOOLS`, the developer-facing rule about the source structure is an aspect of the Development Aspects, and a mechanism driven solely by a `Constraint` requirement (e.g. a hosting or budget mandate) protects no quality and is a Design Decisions decision alone -- only the mechanism, the quality it achieves, and the elements it shapes belong here.
-      diagram:
-        type: hub
-        center: self
-        nodes: "[[TACTIC:*]], [[NR.REQUIREMENT:*]], [[FV.COMPONENT:*]], [[UNIT:*]], [[ASPECT:*]], [[NODE:*]], [[DM.ENTITY:*]], [[CONCERN:*]], [[DECISION:*]], [[TS.TIER:*.COMPONENT:*]], [[TEST-CASE:*]]"
-        labeled: true
-        qualified: true
-        properties:
-          - QUALITY
-        config:
-          size-node-width-max: 440
+        A tactic states a design mechanism built into the solution: the threshold the mechanism has to meet is the `METRIC` of the addressed Non-Functional Requirement and is not restated, the production procedure performed against the mechanism (e.g. scaling out, restoring) is an Operations View concern referenced through `OPERATED-BY`, the tenet the mechanism follows is an Architecture Tenets maxim or principle referenced through `GUIDED-BY`, the structure it is built from is an Architecture Patterns pattern referenced through `PATTERNS`, the trade-off that chose the mechanism over alternatives is a Design Decisions decision referencing the tactic through `DECIDES`, the product realizing the mechanism is a Technology Stack component referenced through `TOOLS`, the developer-facing rule about the source structure is an aspect of the Development Aspects, the coded form of the mechanism is a Code Patterns pattern referencing the tactic through `REALIZES`, and a mechanism driven solely by a `Constraint` requirement (e.g. a hosting or budget mandate) protects no quality and is a Design Decisions decision alone -- only the mechanism, the quality it achieves, and the elements it shapes belong here.
+      optional: true
       props:
         - name: QUALITY
           desc: >
@@ -2663,6 +2034,16 @@
           desc: >
             Comma-separated references to the NON-FUNCTIONAL-REQUIREMENTS objects the tactic addresses.
           value: list([[NR.*]])
+        - name: GUIDED-BY
+          desc: >
+            Comma-separated references to the ARCHITECTURE-TENETS objects the mechanism of the tactic follows (e.g. the stateless replication following a `Stateless Services` principle); omitted for a tactic following no modeled tenet.
+          value: list([[MAXIM:*]], [[AT.PRINCIPLE:*]])
+          optional: true
+        - name: PATTERNS
+          desc: >
+            Comma-separated references to the ARCHITECTURE-PATTERNS objects the mechanism of the tactic is built from (e.g. the failover built on a `Circuit Breaker`), while `MECHANISM` states the mechanism itself; omitted for a tactic built from no modeled pattern.
+          value: list([[PATTERN:*]])
+          optional: true
         - name: MECHANISM
           desc: >
             The design mechanism through which the tactic is applied to achieve the quality (e.g. `stateless replication behind a load balancer`, `read-through cache`, `circuit breaker`).
@@ -2689,25 +2070,10 @@
 - kind: ARCH
   name: Design Decisions
   id: DD
-  file: 30-ARCH-DD-Design-Decisions.md
+  file: 32-ARCH-DD-Design-Decisions.md
   desc: >
-    The major decisions related to the solution design, each recording the forces at play, the chosen response, and the reasoning that justifies it. The artifact is the last one of the architecture, as a decision references the requirements forcing it, the elements it shapes, and the tactics and products it chose, all of which precede it.
+    The major decisions related to the solution design, each recording the forces at play, the chosen response, and the reasoning that justifies it. The artifact is the last decision-level one of the architecture, as a decision references the requirements forcing it, the elements it shapes, and the tactics and products it chose, all of which precede it, while the Code Patterns following it reference the decisions they implement.
   optional: true
-  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: "[[DECISION:*]]"
-    properties:
-      - STATUS
-    config:
-      size-node-width-max: 440
-      grid-columns-max: 5
   children:
     - kind: DECISION
       desc: |
@@ -2752,7 +2118,10 @@
         A constraint itself is not a decision: a compliance obligation, a hosting mandate,
         or a partner-imposed threshold is a Non-Functional Requirement (of category
         `Compliance`, `Constraint`, or the affected quality), and the decision is the
-        response to it, referencing it through `DRIVEN-BY`.
+        response to it, referencing it through `DRIVEN-BY`. A standing rule is not a
+        decision either: a maxim or principle reusable across many decisions is an
+        Architecture Tenets object, and the decision applies it, referencing it through
+        `GUIDED-BY`.
 
         `WHEN`, `WHAT`, and `WHY` are each just a single paragraph of concise and brief
         prose text, usually comprised of just 1 to 3 sentences. The value of a decision is
@@ -2767,16 +2136,7 @@
         decision is under-justified. The rationale should make the decision feel earned,
         not asserted - if you delete the rationale and the decision suddenly looks
         arbitrary, the rationale was doing its job.
-      diagram:
-        type: hub
-        center: self
-        nodes: "[[DECISION:*]], [[NR.REQUIREMENT:*]], [[PREMISE:*]], [[DM.ENTITY:*]], [[LIFECYCLE:*]], [[ROLE:*]], [[INTERFACE:*]], [[TYPE:*]], [[ENDPOINT:*]], [[PRINCIPLE:*]], [[CONVENTION:*]], [[PATTERN:*]], [[STORYBOARD:*]], [[ELEMENT:*]], [[CV.ENTITY:*]], [[FV.COMPONENT:*]], [[UNIT:*]], [[ASPECT:*]], [[DV.TIER:*]], [[AREA:*]], [[NODE:*]], [[NETWORK:*]], [[TACTIC:*]], [[TS.TIER:*.COMPONENT:*]]"
-        labeled: true
-        qualified: true
-        properties:
-          - STATUS
-        config:
-          size-node-width-max: 440
+      optional: true
       props:
         - name: STATUS
           desc: |
@@ -2798,15 +2158,20 @@
           desc: >
             Comma-separated references to the NON-FUNCTIONAL-REQUIREMENTS or SOLUTION-PREMISES objects forcing the decision (e.g. the compliance obligation, the budget constraint, the dependency taken as given), anchoring the forces `WHEN` describes in prose: as a decision is the response to forces, at least one is always named, usually a Non-Functional Requirement and only exceptionally a premise alone, and a decision finding no requirement to name reveals a missing one rather than a needless reference.
           value: list([[NR.*]], [[PREMISE:*]])
+        - name: GUIDED-BY
+          desc: >
+            Comma-separated references to the ARCHITECTURE-TENETS objects the decision applies (e.g. the `Buy before Build` maxim settling the choice of a managed service, the `Async between Contexts` principle settling the integration style), anchoring the principles the rationale `WHY` rests on; omitted for a decision applying no modeled tenet.
+          value: list([[MAXIM:*]], [[AT.PRINCIPLE:*]])
+          optional: true
         - name: AFFECTS
           desc: >
             Comma-separated references to the objects of the DATA, APIS, UXUI, or ARCH artifacts the decision shapes, i.e. the entities, lifecycles, and roles, the interfaces, datatypes, and endpoints, the interaction principles, language conventions, dialog patterns, storyboards, and visual elements, and the elements of the architecture views (e.g. the entity owned by a single context, the interface styled REST instead of GraphQL, the dialog pattern chosen over a native one, the components split, the external system integrated); omitted for a decision shaping no modeled element.
-          value: list([[DM.ENTITY:*]], [[LIFECYCLE:*]], [[ROLE:*]], [[INTERFACE:*]], [[TYPE:*]], [[ENDPOINT:*]], [[PRINCIPLE:*]], [[CONVENTION:*]], [[PATTERN:*]], [[STORYBOARD:*]], [[ELEMENT:*]], [[CV.ENTITY:*]], [[FV.COMPONENT:*]], [[UNIT:*]], [[ASPECT:*]], [[DV.TIER:*]], [[AREA:*]], [[NODE:*]], [[NETWORK:*]])
+          value: list([[DM.ENTITY:*]], [[LIFECYCLE:*]], [[ROLE:*]], [[INTERFACE:*]], [[TYPE:*]], [[ENDPOINT:*]], [[IC.PRINCIPLE:*]], [[CONVENTION:*]], [[DIALOG-PATTERN:*]], [[STORYBOARD:*]], [[ELEMENT:*]], [[CV.ENTITY:*]], [[FV.COMPONENT:*]], [[UNIT:*]], [[ASPECT:*]], [[DV.TIER:*]], [[AREA:*]], [[NODE:*]], [[NETWORK:*]])
           optional: true
         - name: DECIDES
           desc: >
-            Comma-separated references to the QUALITY-PERSPECTIVES tactics or TECHNOLOGY-STACK components the decision chose over their alternatives, i.e. the mechanism or product which exists because of this decision; omitted when the decision chose no modeled tactic or product.
-          value: list([[TACTIC:*]], [[TS.TIER:*.COMPONENT:*]])
+            Comma-separated references to the ARCHITECTURE-PATTERNS objects, QUALITY-PERSPECTIVES tactics, or TECHNOLOGY-STACK components the decision chose over their alternatives, i.e. the pattern, mechanism, or product which exists because of this decision; omitted when the decision chose no modeled pattern, tactic, or product.
+          value: list([[PATTERN:*]], [[TACTIC:*]], [[TS.TIER:*.COMPONENT:*]])
           optional: true
         - name: ALTERNATIVES
           desc: >
@@ -2888,10 +2253,58 @@
                 matrix of considered alternatives); and
             -   links to strongly related decisions.
           optional: true
+
+- kind: ARCH
+  name: Code Patterns
+  id: CP
+  file: 33-ARCH-CP-Code-Patterns.md
+  desc: >
+    The implementation patterns the source code of the solution follows, each prescribing how one recurring concern (e.g. authorization enforcement, entity persistence, error propagation) is coded and showing it as a code listing. The artifact follows the Design Decisions, as a pattern is the coded form of the tactics and decisions preceding it, and is absent when the coding conventions are governed outside the specification (e.g. by repository-level contributor instructions).
+  optional: true
+  children:
+    - kind: CODE-PATTERN
+      desc: >
+        A single code pattern, named with a short (2-5 word) summary of the concern it codes (e.g. `Endpoint Authorization`, `Entity Persistence`, `Error Propagation`) and described in a concise (1-3 sentence) paragraph by the rule the code follows whenever the concern arises, plus a 1-sentence rationale ("why") for the rule.
+
+        The listing showing the pattern follows the description and its rationale as the elaboration of the pattern: either a fenced code block in the language of the pattern (e.g. ` ```ts start=10 mark=3-5 `, the parameters numbering the lines from `start` and marking the essential ones) or an embedded excerpt of an existing source file (e.g. `![Entity Persistence](src/persistence.ts#lines=10-30&mark=3-5)`, the fragment selecting and marking the lines), the latter preferred once the code exists, as the specification then never drifts from it. The listing is the canonical, idealized form of the pattern, not an exhaustive example, so it is kept short (typically 10-30 lines) and the prose names what the listing cannot: the places the pattern applies and the deviation it rules out (`AVOID`).
+
+        A pattern states how a concern is coded, and nothing else: the structure or the quality mechanism it implements is an Architecture Patterns pattern or a Quality Perspectives tactic referenced through `REALIZES`, the trade-off that chose its approach over alternatives is a Design Decisions decision referenced through `DECIDED-BY` (a pattern weighs no alternatives itself), the product it codes against is a Technology Stack component referenced through `TOOLS`, and the rule about the source layout, build, or process it lives in is a Development Aspects aspect -- only the recurring code shape, the elements written that way, and the deviation ruled out belong here.
+      optional: true
+      props:
+        - name: APPLIES-TO
+          desc: >
+            Comma-separated references to the FUNCTIONALITY-VIEW, CONCURRENCY-VIEW, DATA-MODEL, AUTHORIZATION-MODEL, INTERFACE-MODEL, or INTERFACE-ENDPOINTS objects whose code follows the pattern (e.g. the components persisting their entities this way, the roles and endpoints guarded by the check); omitted for a pattern applied throughout the code base.
+          value: list([[FV.COMPONENT:*]], [[UNIT:*]], [[DM.ENTITY:*]], [[ROLE:*]], [[INTERFACE:*]], [[ENDPOINT:*]])
+          optional: true
+        - name: REALIZES
+          desc: >
+            Comma-separated references to the ARCHITECTURE-PATTERNS objects or QUALITY-PERSPECTIVES tactics the pattern is the coded form of (e.g. the port interface coding the hexagonal architecture, the token check implementing the access security tactic); omitted for a pattern serving no modeled architecture pattern or tactic.
+          value: list([[PATTERN:*]], [[TACTIC:*]])
+          optional: true
+        - name: DECIDED-BY
+          desc: >
+            Comma-separated references to the DESIGN-DECISIONS objects the pattern implements (e.g. the query builder usage following the decision against an ORM); omitted for a pattern behind which no recorded decision stands.
+          value: list([[DECISION:*]])
+          optional: true
+        - name: TOOLS
+          desc: >
+            Comma-separated references to the TECHNOLOGY-STACK components the pattern codes against (e.g. the query builder, the logging library); omitted for a pattern using the language alone.
+          value: list([[TS.TIER:*.COMPONENT:*]])
+          optional: true
+        - name: USES
+          desc: >
+            Comma-separated references to the smaller CODE-PATTERNS objects the pattern is composed of (e.g. an `Endpoint Authorization` using the `Error Propagation` for its rejections), so that the patterns form a language of related shapes rather than a flat catalogue.
+          value: list([[CODE-PATTERN:*]])
+          optional: true
+          acyclic: true
+        - name: AVOID
+          desc: >
+            The deviation the pattern rules out, stated as the concrete shape a developer would otherwise reach for (e.g. `SQL strings assembled in the request handlers`, `role checks in the client alone`); omitted when the rule has no tempting alternative.
+          optional: true
 - kind: TEST
   name: Test Cases
   id: TC
-  file: 31-TEST-TC-Test-Cases.md
+  file: 34-TEST-TC-Test-Cases.md
   desc: >
     The verifiable conditions and steps used to confirm that requirements, domain rules, use case scenarios, state transitions, and the mechanisms, procedures, and decisions of the architecture are correctly implemented, with mandatory defined inputs, mandatory expected outcomes, and optional pre- and post-conditions. The artifact is the last one, as a test case verifies objects of every preceding kind.
 
@@ -2902,20 +2315,6 @@
     - "[[SCENARIO:*]]"
     - "[[REQUIREMENT:*]]"
     - "[[RULE:*]]"
-  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-CASE:*]]"
-    config:
-      size-node-width-max: 440
-      size-node-height-scale: 2
-      grid-columns-max: 4
   children:
     - kind: TEST-CASE
       desc: >
@@ -2928,15 +2327,7 @@
         A test case whose stimulus is a sequence rather than a single action carries the procedure in its body as sequentially numbered, imperative steps, mirroring the steps of a use case scenario (e.g. `1. The user logs in on device A. 2. The same user logs in on device B.`), with `INPUT` naming the decisive stimulus among them.
 
         A test case verifying an architecture element asserts the element itself, not the threshold behind it: a threshold is the `METRIC` of a Non-Functional Requirement and verified by referencing the requirement, while a Quality Perspectives tactic is referenced only when its mechanism is the assertion (e.g. that the failover switch happens, not how fast), an Operations View concern when its procedure is rehearsed (e.g. a restore drill), a Deployment View node or network when its topology is inspected (e.g. a port scan proving an `Isolated` segment), a component or concurrency unit when its collaboration or contention is exercised, an aspect of the Development Aspects or a Design Decisions decision when its rule is checked by an architectural fitness function (e.g. no dependency edge against the layering).
-      diagram:
-        type: hub
-        center: self
-        nodes: "[[TEST-CASE:*]], [[FR.REQUIREMENT:*]], [[NR.REQUIREMENT:*]], [[RULE:*]], [[SCENARIO:*]], [[WORKFLOW:*]], [[TRANSITION:*]], [[ATTRIBUTE:*]], [[PERMISSION:*]], [[ENDPOINT:*]], [[FRAME:*]], [[FV.COMPONENT:*]], [[UNIT:*]], [[ASPECT:*]], [[NODE:*]], [[NETWORK:*]], [[CONCERN:*]], [[TACTIC:*]], [[DECISION:*]]"
-        labeled: true
-        qualified: true
-        config:
-          size-node-width-max: 440
-          size-node-height-scale: 1.75
+      optional: true
       props:
         - name: VERIFIES
           desc: >