Replace SVG figures with Mermaid diagrams embedded in Markdown

01_Semantic-Interaction-Architecture-sdv.md

@@ -49,7 +49,27 @@ Significant abstraction work exists below and around the interaction layer, but
 
 Figure 1 positions the proposed layer in the SDV stack.
 
-![Figure 1: Position in the SDV stack](./figures/fig1-stack-position.svg)
+```mermaid
+graph TB
+    OCC["Occupant — Driver · Front passenger · Rear passenger"]
+    HMI["Renderers and Input Devices\nHUD · Cluster · IVI · Voice · Haptic · AR · Steering wheel · Gesture · Eye tracking"]
+    SIA["★ Semantic Interaction Architecture\nOntology · Translation · Runtime · Context · Trust"]
+    SVC["Services and Orchestration\nKuksa Databroker · uProtocol · Zenoh · Chariott · Ankaios · Symphony"]
+    DAT["Data Model — COVESA VSS"]
+    MW["Middleware — AUTOSAR Classic · Adaptive · S-CORE"]
+    HW["Hardware — HPC · ECUs · Sensors · Actuators · CAN · Ethernet · SOME/IP"]
+
+    OCC --- HMI
+    HMI --- SIA
+    SIA --- SVC
+    SVC --- DAT
+    DAT --- MW
+    MW --- HW
+
+    style SIA fill:#f0fdfa,stroke:#0f766e,stroke-width:2px,color:#0f766e
+```
+
+*Figure 1. Position of the proposed Semantic Interaction Architecture relative to existing SDV layers.*
 
 The proposed Semantic Interaction Architecture (SIA) sits **above** existing service and data abstractions and **below** concrete renderers. It is not a replacement for any current SDV project or HMI stack; it is a mediation boundary between them and occupant-facing interaction.
 
@@ -67,13 +87,36 @@ We propose four functional components and two cross-cutting policy functions, il
 
 **Interaction Coordination Runtime.** A coordination function for focus, in-flight task flows, acknowledgement timers, and consistency across distributed renderers. It does not replace a GUI framework; it coordinates semantic state that multiple renderers need to handle consistently.
 
-**Renderer Layer.** A heterogeneous set of consumers — HUD, cluster, IVI, voice, haptic, AR — each declaring its capabilities and consuming the semantic stream filtered by Translation. Renderers remain implementation-specific; the schema defines the meaning they receive.
-
-**Context Policy.** A continuously updated vector of contextual axes (driving state, autonomy level, road type, occupant state, market or regulatory jurisdiction) that modulates priority, modality preference, and suppression policy. Context is not a tree; it is a set of composable predicates.
-
-**Trust and Provenance Policy.** A cross-cutting verification function that validates message origin, freshness, and authority before semantic propagation. It applies policy to which actor classes may emit which node classes at which trust levels.
+```mermaid
+graph TB
+    EXT1(["Occupant input · output"])
+
+    subgraph STACK [" "]
+        R["Renderer Layer\nHUD · Cluster · IVI · Voice · Haptic · AR"]
+        RT["Interaction Runtime\nFocus · task-flow state · acknowledgement · cross-renderer consistency"]
+        T["Translation Layer\nnode × capabilities × context → modality decision"]
+        O["Ontology Layer\nTyped node taxonomy · metadata contracts · versioning\n— single source of meaning —"]
+    end
+
+    CE["Context Engine\nSAE level · Road type\nDriver state · Regulatory regime"]
+    TL["Trust Layer\nReq. vs attestation\nactor_class · freshness\nreplay · provenance"]
+    EXT2(["SDV transport — Kuksa · uProtocol"])
+
+    EXT1 --> R
+    R --> RT
+    RT --> T
+    T --> O
+    O --> EXT2
+    CE -->|"modulates"| T
+    TL -->|"validates"| R
+    TL -->|"validates"| RT
+    TL -->|"validates"| T
+    TL -->|"validates"| O
+
+    style O fill:#f0fdfa,stroke:#0f766e,stroke-width:2px,color:#0f766e
+```
 
----
+*Figure 2. Six-layer architecture. Trust validates all layers; Context Engine modulates Translation; Ontology is the canonical source of meaning.*
 
 ## 3.1 Human-Ergonomic Language Design
 
@@ -101,7 +144,42 @@ This is an ergonomics requirement on the language itself. A schema that is techn
 
 A common failure mode in interaction schemas is conflating semantically different node types into a single generic message model. We separate four primary semantic primitives, each with its own metadata contract.
 
-![Figure 3: Node taxonomy](./figures/fig3-node-taxonomy.svg)
+```mermaid
+graph TB
+    I(["Interaction"])
+
+    A["Action\nuser → system\nattention_metrics · temporal_type · recommended_modality"]
+    E["Event\nsystem → user"]
+    S["State\nruntime-internal\nscope · target_role · consistency_class"]
+    T["Task\ncomposed flow\nstep_count · interruptible_at · resumable_across_contexts"]
+
+    AL["Alert\ntrust_requirements · priority · requires_ack"]
+    N["Notification\nsuppression_class · priority · merges_with"]
+
+    AL1["Alert.Collision.Warning"]
+    AL2["Alert.Lane.Departure"]
+    N1["Notification.Message.Incoming"]
+    N2["Notification.Media.TrackChange"]
+    A1["Navigate.Back"]
+    A2["Media.Volume.Increase"]
+    A3["Map.Zoom"]
+    S1["State.Focus.Domain"]
+    S2["State.Mode.AutonomyEngaged"]
+    T1["Task.Media.Browse"]
+    T2["Task.Route.PlanWithStops"]
+
+    I --> A & E & S & T
+    E --> AL & N
+    AL --> AL1 & AL2
+    N --> N1 & N2
+    A --> A1 & A2 & A3
+    S --> S1 & S2
+    T --> T1 & T2
+
+    style I fill:#f0fdfa,stroke:#0f766e,stroke-width:2px,color:#0f766e
+```
+
+*Figure 3. Node taxonomy. Four primary types with distinct metadata contracts; Event splits into Alert and Notification. Naming follows reverse-DNS hierarchy; subclasses may strengthen but not weaken contracts.*
 
 **Action.** Occupant-initiated. May be discrete (`Navigate.Back`), sustained (`Media.Volume.Increase`), or continuous (`Map.Zoom`). Carries `recommended_modality`, `attention_metrics`, `temporal_type`.
 

02_Appendix-a-worked-example.md

@@ -87,7 +87,28 @@ The trust and provenance policy checks: signature validity, `actor_class ∈ per
 
 ## A.3 Trust verification flow
 
-![Figure A.1: Alert flow end-to-end](./figures/figA1-alert-flow.svg)
+```mermaid
+sequenceDiagram
+    participant ADAS as ADAS (emitter)
+    participant Trust as Trust Layer (verifier)
+    participant Trans as Translation + Context
+    participant Runtime as Runtime (state · focus · ack)
+    participant Renderers as Renderers (HUD · Cluster · Voice · Haptic)
+
+    ADAS->>Trust: emit instance + attestation
+
+    alt trust verification fails
+        Trust-->>ADAS: reject + log State.SecurityEvent.UnauthorisedEmission
+    else trust verification passes
+        Trust->>Trans: verified node propagates
+        Trans->>Runtime: allocate focus slot · arm ack timer
+        Runtime->>Renderers: dispatch (multicast)
+        Renderers->>Runtime: ack (explicit input | gaze | timeout)
+        Runtime->>Trust: close interaction · log outcome
+    end
+```
+
+*Figure A.1. Sequence flow for Alert.Collision.Warning. Trust verification is a chokepoint before Translation. Renderer dispatch is multicast; acknowledgement is tracked by Runtime.*
 
 Trust and provenance policy is the chokepoint at which interaction integrity is enforced. Importantly, verification operates *before* Translation — a node that fails verification never reaches a renderer, regardless of its declared priority.
 

README.md

@@ -40,14 +40,14 @@
 - [**Position paper**](./01_Semantic-Interaction-Architecture-sdv.md) — six-layer architecture, node taxonomy, metadata contracts, trust model, attention model, context as a multi-axis vector, versioning, relations to existing standards, and a path toward Eclipse SDV standardisation.
 - [**Appendix A: Worked example**](./02_Appendix-a-worked-example.md) — a single `Alert.Collision.Warning` traced end-to-end: ontology declaration, trust verification, translation under three contexts (highway/manual, parked, L4/autonomous), and four adversarial scenarios (spoofed actor class, expired freshness, AI agent attempting a critical alert, priority injection).
 
-## Key figures
+## Key diagrams
 
-| | |
-|---|---|
-| ![Stack position](./figures/fig1-stack-position.svg) | ![Six-layer architecture](./figures/fig2-six-layer-architecture.svg) |
-| *Fig 1 — Where SIA sits in the SDV stack* | *Fig 2 — The six layers and how they interact* |
-| ![Node taxonomy](./figures/fig3-node-taxonomy.svg) | ![Alert flow](./figures/figA1-alert-flow.svg) |
-| *Fig 3 — Four node types and their metadata contracts* | *Fig A.1 — Sequence flow for a collision warning* |
+The diagrams are embedded directly in the paper as Mermaid and render automatically on GitHub:
+
+- **Fig 1** — [Where SIA sits in the SDV stack](./01_Semantic-Interaction-Architecture-sdv.md#2-related-work-and-position-in-the-ecosystem)
+- **Fig 2** — [Six-layer architecture](./01_Semantic-Interaction-Architecture-sdv.md#3-architecture-overview)
+- **Fig 3** — [Node taxonomy](./01_Semantic-Interaction-Architecture-sdv.md#4-node-taxonomy)
+- **Fig A.1** — [Alert flow sequence diagram](./02_Appendix-a-worked-example.md#a3-trust-verification-flow)
 
 ## Status and how to engage
 
@@ -55,7 +55,7 @@
 
 Open questions the paper flags: schema language (JSON Schema vs. OWL/SHACL), cryptographic substrate for the Trust Layer, empirical validation of the attention metric composition formula, conflict resolution between renderers, and a prototype on top of Eclipse Kuksa.
 
 Feedback, counter-positions, and collaboration offers are welcome: **dizencz@gmail.com**
 
 ---