yaneczech · yaneczech · May 13, 2026 · May 13, 2026 · May 13, 2026 · May 13, 2026
diff --git a/.DS_Store b/.DS_Store
diff --git a/01_Semantic-Interaction-Architecture-sdv.md b/01_Semantic-Interaction-Architecture-sdv.md
@@ -5,7 +5,7 @@
 ---
 
 **Author:** Jan Janeček
-**Affiliation:** Independent researcher
+**Affiliation:** Cars Making Sense
 **Version:** 0.1 — Draft for circulation
 **Date:** May 2026
 
@@ -103,7 +103,7 @@ A common failure mode in interaction schemas is conflating semantically differen
 
 ![Figure 3: Node taxonomy](./figures/fig3-node-taxonomy.svg)
 
-**Action.** An intended command or operation. Many actions are occupant-initiated (`Navigate.Back`), but some are gesture-neutral commands or system-mediated intents. Actions may be discrete (`Navigate.Back`), sustained (`Media.Volume.Increase`), or continuous (`Map.Zoom`). Carries `recommended_modality`, `attention_cost`, `temporal_type`.
+**Action.** Occupant-initiated. May be discrete (`Navigate.Back`), sustained (`Media.Volume.Increase`), or continuous (`Map.Zoom`). Carries `recommended_modality`, `attention_metrics`, `temporal_type`.
 
 **Event.** System-initiated. Splits into **Alert** (safety-relevant, may require acknowledgement) and **Notification** (informational, suppressible). Carries `priority`, `interruptibility`, `requires_ack`, `trust_requirements`.
 

diff --git a/README.md b/README.md
@@ -1,72 +1,68 @@
 # Semantic Interaction Architecture (SIA)
 
-**A Cars Making Sense initiative · v0.1 draft · May 2026**
+**A [Cars Making Sense](#about-cars-making-sense) initiative · v0.1 draft · May 2026**
 
-> What if a collision warning could declare, in machine-readable terms, that it cannot be suppressed, must reach the driver within 200 ms, requires a signed origin, and degrades to voice if the HUD is unavailable, without any of that logic living inside a renderer?
+> **What if a collision warning could declare, in machine-readable terms, that it cannot be suppressed, must reach the driver within 200 ms, requires a signed origin, and degrades to voice if the HUD is unavailable — without any of that logic living inside a renderer?**
 
-This repository contains a draft position paper proposing a semantic mediation layer for high-value interactions in software-defined vehicles. SIA decouples the meaning, trust requirements, attention demand, and context fitness of in-vehicle interactions from concrete screens, widgets, input devices, and renderers.
-
-## The Problem
+This repository contains a position paper proposing exactly that: a semantic interaction layer for Software-Defined Vehicles that separates *what an interaction means* from *how it is rendered*.
 
-Modern vehicle HMI is screen-first and tightly coupled. The same intent, such as acknowledging an alert, increasing volume, or navigating back, is implemented separately for each screen size, input device, voice assistant, and OEM. When a new surface arrives, or an AI agent needs to emit an interaction, the logic is often rewritten in renderer-specific code.
+This repository contains a draft position paper proposing a semantic mediation layer for high-value interactions in software-defined vehicles. SIA decouples the meaning, trust requirements, attention demand, and context fitness of in-vehicle interactions from concrete screens, widgets, input devices, and renderers.
 
-This costs engineering time, produces inconsistent experiences, and creates a security gap: there is currently no common semantic layer that constrains whether a third-party app or cloud AI agent may emit, suppress, or spoof a safety-critical interaction.
+## The problem
 
-## The Proposal
+Modern vehicle HMI is screen-first and tightly coupled. The same intent — *acknowledge an alert*, *increase volume*, *navigate back* — is implemented separately for each screen size, each input device, each voice assistant, and each OEM. When a new surface arrives, or an AI agent needs to emit an interaction, the logic has to be rewritten from scratch.
 
-SIA is framed as a scalable ontology language exposed initially through a small typed event/command schema profile plus policy mediation, not as a replacement HMI platform. The ontology is the long-term language of meaning; the schema profile is the first implementable compatibility target. The first version focuses on three cores:
+This costs engineering time. It produces inconsistent experiences. And it creates a security gap: there is currently no standard way to prevent a third-party app or a cloud AI agent from spoofing the priority or origin of a safety-critical alert.
 
-- **Intent/action abstraction**: common primitives for high-value commands and interaction events.
-- **Attention policy**: predictive attention-demand proxies, priority, interruptibility, and driving context.
-- **Trust provenance**: who may emit which interaction type, with what authority and freshness.
+## The proposal
 
-The proposal uses Actions, Events, States, and Tasks as semantic primitives and treats backward compatibility as a first-order requirement. Broader cross-domain generalisation and full vehicle-wide runtime behavior remain future specification work.
+SIA defines a **typed node ontology** — Actions, Events, States, Tasks — where every node carries machine-readable metadata for:
 
-The language is also intended to be ergonomic for humans without becoming free-form natural language. Its primitives mirror the structure of natural communication: what is being requested or asserted, who is speaking, who the target is, how urgent it is, whether acknowledgement is required, what context changes its meaning, and how the system should repair or degrade the interaction when the preferred channel is unavailable. Those primitives must remain deterministic, typed, parsable, testable, and safe to validate at runtime.
+- **Attention** — predicted glance time, task steps, cognitive load; auditable against NHTSA/JAMA/ISO thresholds
+- **Trust** — required actor class, signed origin, freshness window, replay protection
+- **Context** — a multi-axis vector (SAE level, road type, driver state, regulatory regime) that modulates rendering policy
+- **Capability negotiation** — renderers declare measurable capabilities; the Translation Layer picks the right surface mechanically
 
-A mediation architecture sits above existing SDV data and service abstractions such as COVESA VSS, Eclipse Kuksa, and uProtocol, and below concrete renderers. It is intended as connective tissue, not a replacement for existing SDV infrastructure.
+A six-layer architecture (Ontology → Translation → Runtime → Renderer, with Trust and Context Engine spanning the stack) sits above existing SDV data and service abstractions (COVESA VSS, Eclipse Kuksa, uProtocol) and below concrete renderers. Nothing in the current SDV stack needs to be replaced — SIA is the missing connective tissue.
 
-## Who This Is For
+## Who this is for
 
-| You are... | The relevant question |
-| --- | --- |
-| An HMI or UX engineer at an OEM or Tier-1 | Could my renderer consume a semantic stream instead of hard-coded widget logic? |
+| You are… | The relevant question |
+|---|---|
+| An HMI or UX engineer at an OEM or Tier-1 | Could my renderer consume a semantic stream instead of being hard-coded to a widget set? |
 | An SDV platform architect | Where does the interaction layer live relative to Kuksa, uProtocol, and S-CORE? |
 | A cybersecurity engineer | How do we prevent AI agents or third-party apps from spoofing safety-critical alerts? |
 | An academic in AutomotiveUI, CHI, or escar | Is there a tractable formalisation of in-vehicle interaction semantics? |
-| An Eclipse SDV contributor | How does this relate to AI agents, trustable software, and ongoing SDV projects? |
+| An Eclipse SDV contributor | How does this relate to the 2026 AI SIG and ongoing work in Ankaios, Symphony, and LMOS? |
 
-## Read The Paper
+## Read the paper
 
-- [Position paper](./01_Semantic-Interaction-Architecture-sdv.md) — mediation architecture, semantic primitives, metadata contracts, trust provenance, attention policy, context model, versioning, relations to existing standards, and a path toward Eclipse SDV standardisation.
-- [Appendix A: Worked example](./02_Appendix-a-worked-example.md) — `Alert.Collision.Warning` traced end-to-end through trust verification, translation, renderer dispatch, and adversarial scenarios.
-- [Schema draft](./schema/interaction-node.schema.json) — minimal JSON Schema sketch for the metadata contract.
+- [**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 figures
 
 | | |
-| --- | --- |
-| ![Stack position](./figures/fig1-stack-position.svg) | ![Mediation architecture](./figures/fig2-six-layer-architecture.svg) |
-| Figure 1: Where SIA sits in the SDV stack | Figure 2: Components and policy functions |
+|---|---|
+| ![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) |
-| Figure 3: Four node types and their metadata contracts | Figure A.1: Sequence flow for a collision warning |
+| *Fig 3 — Four node types and their metadata contracts* | *Fig A.1 — Sequence flow for a collision warning* |
 
-## Status
+## Status and how to engage
 
-Version 0.1 is a draft for circulation and critique. The proposal is not a standard, implementation, or safety-certified architecture. Open questions include ontology/schema formalism, compatibility rules, cryptographic substrate, attention metric validation, renderer conflict resolution, and a reference prototype integrated with existing SDV middleware.
+This is **v0.1 — a draft for circulation and critique**. The goal is to gather feedback before committing to a schema formalism, a cryptographic substrate, or a reference implementation.
 
-## Citation
+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.
 
-Citation metadata is available in [CITATION.cff](./CITATION.cff).
+Feedback, counter-positions, and collaboration offers are welcome: **dizencz@gmail.com**
 
-## License
+---
 
-This work is released under [CC0 1.0 Universal](./LICENSE).
-
-## Contact
+## About Cars Making Sense
 
-Feedback, counter-positions, and collaboration offers are welcome: <dizencz@gmail.com>.
+Cars Making Sense is a research initiative focused on usability and UX in the automotive industry. We analyse existing and historical HMI solutions, identify where they fall short, and propose better design paths — grounded in how people actually use vehicles, not in how dashboards happen to be built.
 
-## About Cars Making Sense
+SIA is our first concrete technical proposal: a formal answer to a problem we kept running into while studying current in-vehicle interaction design.
 
-Cars Making Sense is a research initiative focused on usability and UX in the automotive industry. It analyses existing and historical HMI solutions, identifies where they fall short, and proposes better design paths grounded in how people use vehicles rather than in how dashboards happen to be built.
+*Cars Making Sense — May 2026*