diff --git a/docs/changelog.md b/docs/changelog.md
index cfb2ad7c974892aa16b435865d54f36979e27044..96c8658170b4e30a9489a669538838d562c2bec4 100644
--- a/docs/changelog.md
+++ b/docs/changelog.md
@@ -84,7 +84,7 @@ Das Format dieser Datei basiert auf [Keep a Changelog](https://keepachangelog.co
   ([Bug](https://git.fitko.de/fit-connect/planning/-/issues/303))
 
 ### Zustelldienst 1.3.1
-- Die Reihenfolge der Ereignise im Ereignis-Log für einen Einreichungsvorgang wurde von "Aufsteigend basiert auf der
+- Die Reihenfolge der Ereignisse im Ereignis-Log für einen Einreichungsvorgang wurde von "Aufsteigend basiert auf der
   Ereignis Id und gruppiert basierend auf der Einreichungsid" zu "Aufsteigend basiert auf der Ereignis Id" geändert
   ([Bug](https://git.fitko.de/fit-connect/planning/-/issues/279))
 - Security Feature: Der Zustelldienst wird über einen Docker Container ausgeliefert. Dieser Docker Container nutzt
diff --git a/docs/getting-started/event-log/set-creation.mdx b/docs/getting-started/event-log/set-creation.mdx
index 1c278293c4baf71a39bcb0cf35a1836c527a235d..f9df723becf00e064458d1e404ae00e725e64c43 100644
--- a/docs/getting-started/event-log/set-creation.mdx
+++ b/docs/getting-started/event-log/set-creation.mdx
@@ -7,14 +7,16 @@ import TabItem from '@theme/TabItem'
 
 # SET Erzeugung
 
-## Ereignis Payload
+## Ereignis Payload {#ereignis-payload}
 
 Je nach SET ist ein Ereignis-Payload für das darin vorkommendes Ereignis vorgesehen.
 Auf der Seite [Ereignisse](./events.mdx) finden Sie eine Liste der Ereignisse und deren Struktur.
 
-Derzeit ist es weiterhin möglich, Ereignise auch ohne Ereignis-Payload zu senden.
+:::caution Warnung
+Derzeit ist es möglich, Ereignisse auch ohne Ereignis-Payload zu senden.
 In diesem Fall darf kein SET-Payload-Schema (unter `$schema`) angegeben werden.
 Denn sollte ein SET-Payload-Schema verwendet werden, das ein Ereignis-Payload vorschreibt, wird das SET ohne diese Ereignis-Payload vom Zustelldienst mit einem Fehler zurückgewiesen.
+:::
 
 ### Authentication Tags Ereignis Payload
 
@@ -171,18 +173,25 @@ values={[
 Die SET Payload ist wie folgt aufgebaut.
 Die Elemente der obersten Ebene sind bei allen SETs vorhanden (Ausnahme `$schema`).
 Der Claim `events` enthält als Schlüssel das eigentliche Ereignis, das ggf. einen eigenen Ereignis Payload (hier: `authenticationTags`) enthält.
+Mehr zu der Ereignis spezifischen Payload finden Sie auf dieser Seite under [Ereignis Payload](#ereignis-payload) und auf der [Ereignisse](./events.mdx) Seite
 
+:::caution Warnung
 Für die SET Payload wird unter `$schema` ein Schema zur Validierung definiert.
-Entspricht ein SET Payload nicht dem definierten Schema wird es z.B. vom Zustelldienst zurückgeweisen.
-Es ist aktuell noch möglich kein `$schema` zu setzten. Dadurch findet keine Validation statt.
-Dies wird in unspezifizierter Zukunft `deprecated` und alle SETs müssen ein valides Schema verwenden.
+Entspricht ein SET Payload nicht dem definierten Schema wird es z.B. vom Zustelldienst und vom Empfänger zurückgewiesen.
+Es ist aktuell noch möglich kein `$schema` an zu geben. Dadurch findet keine Validation auf Seiten des Zustelldienst und des Empfänger statt.
+Dies wird in unspezifizierter Zukunft `deprecated` und alle SETs müssen dann ein valides Schema verwenden und angeben.
+
+Derzeit ist es auch noch möglich, Ereignisse auch ohne [Ereignis Payload](#ereignis-payload) zu senden.
+In diesem Fall darf kein SET-Payload-Schema (unter `$schema`) angegeben werden.
+Denn sollte ein SET-Payload-Schema verwendet werden, das ein Ereignis-Payload vorschreibt, wird das SET ohne diese Ereignis-Payload vom Zustelldienst mit einem Fehler zurückgewiesen.
+:::
 
 :::info
 Derzeit ist die Version [1.0.0](https://schema.fitko.de/fit-connect/set-payload/1.0.0/set-payload.schema.json) des SET-Payload-Schemas aktuell.
 Mit diesem Schema `1.0.0` stellt auch der Zustelldienst seine SETs aus.
 Bis auf weiteres kann auch noch die Version [0.1.0](https://schema.fitko.de/fit-connect/set-payload/1.0.0/set-payload.schema.json) verwendet werden.
 Inhaltlich ist sie deckungsgleich mit der Version `1.0.0`.
-Diese Version `0.1.0` wird deswegen in noch unspezifizierter Zukunft mit Ankündigung `deprecated` und sollte dann nicht mehr verwendet werden.
+Diese Version `0.1.0` wird deswegen in noch unspezifizierter Zukunft mit Ankündigung `deprecated` und sollte nicht mehr verwendet werden.
 :::
 
 ```json
diff --git a/docs/getting-started/event-log/set-validation.mdx b/docs/getting-started/event-log/set-validation.mdx
index 2c26b4bc6e0b4edc6720019d65ee98d620cfcffe..b8d4e4b221580631cde20ee1cd4fcf42f294f027 100644
--- a/docs/getting-started/event-log/set-validation.mdx
+++ b/docs/getting-started/event-log/set-validation.mdx
@@ -17,7 +17,7 @@ Dies wird z.B. auch schon vom zuständigen Zustelldienst gemacht.
 Aktuell ist die Angabe eines SET-Payload-Schemas aber noch optional und kann nicht existieren.
 Dies wird in unspezifizierter Zukunft `deprecated` und alle SETs müssen ein valides SET-Payload-Schema verwenden und angeben.
 In dem Fall, dass das SET-Payload-Schema nicht angegeben ist, müssen trotzdem die kryptografischen Vorgaben bzw. die kryptografische Signatur validiert werden.
-:::caution
+:::caution Warnung
 Sowohl die Prüfung der kryptografischen Vorgaben, als auch die Prüfung der kryptografischen Signatur darf KEINESFALLS ausgelassen werden.
 :::