diff --git a/docs/architecture.md b/docs/architecture.md
index b1f148a..2f58a86 100644
--- a/docs/architecture.md
+++ b/docs/architecture.md
@@ -1,51 +1,44 @@
 # General Architecture
 
-The validator itself is just an engine which executes validation according to a certain configuration (see [configuration documentation](configuration.md))
-
+The validator itself is just an engine which executes validation according to a certain configuration (see [configuration documentation](docs/configurations.md)).
+
+The validator takes a sceanrio.xml and the configured directory with all artifacts necessary for validation (scenario repository). Then it performs 
+the validation and generates a report in XML format. This report is then the input to an XSLT provided by the configuration.
+
+## Separation of concerns
+
+* The purpose of the validator is to only report if an XML instance is valid or not
+* A configuration can provide an XSLT which takes the validator report and generates an own report
+  * This report may choose to conclude acceptance of the XML instance or not
+
+The validator reports valid/invalid, a configuration reports acceptance/rejection!
 
 
+## General process
+The general process is like this: 
 
 ```mermaid
 
 sequenceDiagram
-    participant e as Validator
-    participant c as Configuration
-    e ->> c: Read scenario.xml
-    e ->> c: Pick validation artifacts
+  participant e as Validator
+  participant c as Configuration
+  e->>+c: create ScenarioRepository
+  c->>-e: is available
+  e->>e: parse XML
+  e->>e: select scenario
+  e->>e: validate XSD
+  e->>e: validate Schematron
+  e->>e: create Validator Report
+  e->>+c: execute configuration report generator
+  e->>-c: return XPATH of acceptance message
   
-  
-  
-
 ```
+ 
+1. *XML-Parsing*: Is the XML instance valid in the basic sense. If not, validation is stopped and the validator report is returned with status *invalid*.
+2. *Identifikation of applicable scenario*: The configuration must have a defined scenario which matches the XML instance (it is an XPATH expression). If no scenario matches, validation is stopped and the validator report is returned with status *invalid*.
+3. *XML-Schema validation*: The XML instance must be valid according to the configured XSD. If not, validation is stopped and the validator report is returned with status *invalid*.
+4. *Schematron validation*
+5. *Aggregation of validation results*: All results are aggregated into the validation report:
+    * In case there is a single *error* or *warning* the report will have status erhält*invalid*, otherwise the status will be *valid*.
 
 
-Eine zu prüfende Datei durchläuft die folgenden Schritte
-
-
-Eine zu prüfende Datei durchläuft die folgenden Schritte   
-
-1. *Grundsätzliche XML-Prüfung*: Es muss sich bei der zu prüfenden Datei um wohlgeformtes XML handeln, andernfalls
-   werden keine weiteren Prüfungen durchgeführt und ein [Prüfbericht] mit Status *invalid* und Empfehlung 
-    *reject* generiert.
-2. *Identifikation des anzuwendenden Prüfszenarios*: Für den Dokumenttyp der zu prüfenden XML-Datei muss in der
-    [Konfigurationsdatei](#konfiguration-des-prüftools) ein Prüfszenario definiert sein (die Identifikation des
-    Dokumenttyps erfolgt durch einen XPath-Test), andernfalls werden keine weiteren Prüfungen durchgeführt und ein
-    [Prüfbericht] mit Status *invalid* und Empfehlung *reject* generiert.
-3. *Prüfung gegen das XML-Schema des identifizierten Dokumenttyps*: Das zu prüfende Dokument muss valide bzgl. des
-    Schemas sein, andernfalls werden keine weiteren Prüfungen durchgeführt und ein [Prüfbericht] mit Status *invalid*
-    und Empfehlung *reject* generiert.
-4. *Prüfung gegen die Schematron-Regeln des identifizierten Dokumenttyps*
-5. *Aggregation und Bewertung der einzelnen Prüfungen* zu einem [Prüfbericht]: Die Ergebnisse der
-    vorherigen Schritte werden in einem einheitlichen Berichtsformat zusammengefasst und bewertet:
-    * Sofern mindestens einer der zuvor durchgeführten Prüfschritte einen Fehler (*error*) oder eine Warnung (*warning*)
-      geliefert hat, erhält der Prüfbericht den Status *invalid*, andernfalls erhält er den Status *valid*.
-    * Sofern einer der Prüfschritte einen Fehler geliefert hat, erhält der Prüfbericht grundsätzlich die Empfehlung
-      *reject*, andernfalls erhält er die Empfehlung *accept*. 
-    * In der [Konfigurationsdatei](#konfiguration-des-prüftools) kann für einzelne Prüfregeln festgelegt werden, dass
-      sie für die Bewertung einer [anderen Meldungsart](#anpassung-der-fehlergrade-für-die-bewertung) zuzuordnen sind
-      (z. B. *warning* anstelle von *error*).  
-    * Der Prüfbericht ist ein für die maschinelle Auswertung geeignetes XML-Dokument. Darin eingebettet ist auch eine 
-      für menschliche Leser bestimmte HTML-Aufbereitung des Prüfergebnisses. Die Details dieser HTML-Aufbereitung können
-      bei Bedarf [angepasst](#anpassung-der-html-ausgabe) werden.
-    
-