diff --git a/server/vissv2server/signaldimension.json b/server/vissv2server/signaldimension.json
new file mode 100644
index 00000000..01cd2b76
--- /dev/null
+++ b/server/vissv2server/signaldimension.json
@@ -0,0 +1 @@
+{"dim2":[{"path1":"Vehicle.CurrentLocation.Latitude", "path2":"Vehicle.CurrentLocation.Longitude"}], "dim3":[{"path1":"Vehicle.Acceleration.Lateral", "path2":"Vehicle.Acceleration.Longitudinal", "path3":"Vehicle.Acceleration.Vertical"}]}
diff --git a/tutorial/content/client/_index.md b/tutorial/content/client/_index.md
index 7be20528..e9c4d607 100644
--- a/tutorial/content/client/_index.md
+++ b/tutorial/content/client/_index.md
@@ -1,5 +1,5 @@
 ---
-title: "VISSv2 Clients"
+title: "VISSR Clients"
 ---
 
 ## Client deployment options
diff --git a/tutorial/content/datastore/_index.md b/tutorial/content/datastore/_index.md
index a3a5029a..a10607a4 100644
--- a/tutorial/content/datastore/_index.md
+++ b/tutorial/content/datastore/_index.md
@@ -4,10 +4,15 @@ title: "VISSR Data Storage"
 
 The VISSR tech stack architecture contains a data storage component located between the server and the feeder(s).
 This data store provides a decoupling between the server data access operations and the data access operations of a feeder.
+
 Feeders are expected to keep the data store updated with the latest available value of the signals defined in the VSS tree,
 and for client read/subscribe requests the server reads from what is available in the data store.
 This leads to that for all client read/subscribe requests the underlying vehicle system does not get involved by instantaneously
 having to provide a signal value when asked for by a client.
+
+For subscriptions it also enables that a more versatile menu of event trigger conditions can be available to the client
+than what the underlying vehicle system actually is supporting.
+
 Client write requests are not passed through the data store (except for the soon to be deprecated version 1 client template type),
 but are instead communicated over an Unix Domain Socket IPC channel directly to the feeder by the server.
 
diff --git a/tutorial/content/docker-step-by-step/_index.md b/tutorial/content/docker-step-by-step/_index.md
index f661171f..4d30ce1c 100644
--- a/tutorial/content/docker-step-by-step/_index.md
+++ b/tutorial/content/docker-step-by-step/_index.md
@@ -1,5 +1,5 @@
 ---
-title: "VISSv2 Docker"
+title: "VISSR Docker"
 ---
 
 ## Intro
diff --git a/tutorial/content/peripheral-components/_index.md b/tutorial/content/peripheral-components/_index.md
index 011d1bd8..9be825e9 100644
--- a/tutorial/content/peripheral-components/_index.md
+++ b/tutorial/content/peripheral-components/_index.md
@@ -1,5 +1,5 @@
 ---
-title: "VISSv2 peripheral components"
+title: "VISSR peripheral components"
 ---
 
 A few other software components that can be useful when setting up a VISSv2 communication tech stack exists:
diff --git a/tutorial/content/server/_index.md b/tutorial/content/server/_index.md
index c8ea0ad6..12e5c2fe 100644
--- a/tutorial/content/server/_index.md
+++ b/tutorial/content/server/_index.md
@@ -1,5 +1,5 @@
 ---
-title: "VISSv2 Server"
+title: "VISSR Server"
 ---
 
 The VISSv2 server is the Sw component that implements the interface that is exposed to the clients, and that must conform to the COVESA VISSv2 specification.
diff --git a/tutorial/static/images/vissv2.png b/tutorial/static/images/vissv2.png
index 137c177a..051e4ec6 100644
Binary files a/tutorial/static/images/vissv2.png and b/tutorial/static/images/vissv2.png differ