diff --git a/OMDSServiceDefinition/doc/ON_3 Vertragsbestand/ON_3.04 Vertragsänderungen/ON_3.04 Vertragsänderungen.pdf b/OMDSServiceDefinition/doc/ON_3 Vertragsbestand/ON_3.04 Vertragsänderungen/ON_3.04 Vertragsänderungen.pdf
index cf4459f1..af7696eb 100644
Binary files a/OMDSServiceDefinition/doc/ON_3 Vertragsbestand/ON_3.04 Vertragsänderungen/ON_3.04 Vertragsänderungen.pdf and b/OMDSServiceDefinition/doc/ON_3 Vertragsbestand/ON_3.04 Vertragsänderungen/ON_3.04 Vertragsänderungen.pdf differ
diff --git a/OMDSServiceDefinition/doc/ON_3 Vertragsbestand/ON_3.04 Vertragsänderungen/ON_3.04 Vertragsänderungen.tex b/OMDSServiceDefinition/doc/ON_3 Vertragsbestand/ON_3.04 Vertragsänderungen/ON_3.04 Vertragsänderungen.tex
index 007baf31..b60c83bb 100644
--- a/OMDSServiceDefinition/doc/ON_3 Vertragsbestand/ON_3.04 Vertragsänderungen/ON_3.04 Vertragsänderungen.tex	
+++ b/OMDSServiceDefinition/doc/ON_3 Vertragsbestand/ON_3.04 Vertragsänderungen/ON_3.04 Vertragsänderungen.tex	
@@ -183,6 +183,17 @@
     \end{itemize}
 
     \subsubsection{Normierungsgrad des Laufzeitverhaltens}
+
+    Die Daten für eine Änderung können in verschiedenen Formen angegeben werden. Heckel nennt dies \textit{Szenario} und
+    die Repräsentation im Graph nennt er \textit{instance graph}.
+    Die Form, die die Daten für die Übertragung annehmen können werden bei uns über das XSD vorgegeben,
+    das XSD definiert den \textit{Type-Graph}. Die Typen im XSD (\texttt{ComplexType} und \texttt{SimpleType})
+    sind die \textit{Concepts} bei Heckel.
+
+    Der instance graph kann Schrittweise verändert werden, sein \textit{state} wird transformiert. Die möglichen oder
+    zulässigen Änderungen des Zustands, folgen dabei bestimmten Regeln, bei Heckel werden diese als \textit{rules} bezeichnet.
+
+
     \begin{itemize}
         \item Datenobjekte mit individuellem Laufzeitverhalten: Bei diesen Objekten wird zwar die Struktur des
         Objekts in der Norm oder durch den Serviceprovider mittels Xml-Schema-Definition (XSD) festgelegt, die
@@ -215,8 +226,8 @@
     \end{itemize}
 
     \subsubsection{Modell am Server?}
-    Bei Änderungen mit zwei Services stellt sich die Frage, ob diese beiden Services stateless umgesetzt werden sollen
-    oder ob das Modell der Änderung am Server verwaltet werden soll (stateful).
+    Bei Änderungen mit zwei Services stellt sich die Frage, ob diese beiden Services voneinander vollkommen
+    unabhängig sein sollen (stateless) oder ob das Modell der Änderung am Server verwaltet werden soll (stateful).
     \paragraph{Vorteile stateful}
     \begin{itemize}
         \item Bei einem invaliden Request vom Client, kann das letzte gültige Modell am Server erhalten bleiben.