#30 Simplify name ofphase three as sugested

Signed-off-by: Sven Strittmatter <sven.strittmatter@iteratec.com>

Author: Weltraumschaf

docs/adr/adr_0001.adoc

@@ -181,17 +181,16 @@ Analog to kubernetes webhooks: HTTP server receiving findings and returning resu
 
 == Decision
 
-Regarding question 1 it seems that both solution approaches are resulting in the same execution model. We decided to implement solution approach 1 and unify both concepts into a more general concept with the name _hook concept_. Therefore we exchange the existing name _PersistenceProvider_ for phase 3 in the execution model with a more general term _DataProcessing_:
+Regarding question 1 it seems that both solution approaches are resulting in the same execution model. We decided to implement solution approach 1 and unify both concepts into a more general concept with the name _hook concept_. Therefore we exchange the existing name _PersistenceProvider_ for phase 3 in the execution model with a more general term _processing_:
 
-// #30 I suggest the term "processing" instead of data processing/
 ....
 ┌──────────────────┐          ┌──────────────────┐          ┌──────────────────┐
-│     scanning     ├─────────▶│     parsing      ├─────────▶│  data processing │
+│     scanning     ├─────────▶│     parsing      ├─────────▶│    processing    │
 │    (Phase 1)     │          │    (Phase 2)     │          │    (Phase 3)     │
 └──────────────────┘          └──────────────────┘          └──────────────────┘
 ....
 
-Regarding question 2 we decided to implement the solution approach 1 with a job-based approach (no active service component needed). Therefore the phase 3 _data processing_ will be split into two separate phases named _ReadAndWriteHooks_ (3.1) and _ReadOnlyHooks_ (3.2)
+Regarding question 2 we decided to implement the solution approach 1 with a job-based approach (no active service component needed). Therefore the phase 3 _processing_ will be split into two separate phases named _ReadAndWriteHooks_ (3.1) and _ReadOnlyHooks_ (3.2)
 // #30 to what refers 3.1 and 3.2?
 
 ....
@@ -207,9 +206,9 @@ Regarding question 2 we decided to implement the solution approach 1 with a job-
 
 == Consequences
 
-With the new _hook concept_ we open the _phase 3 data processing_ to a more intuitive and flexible architecture. It is easier to understand because _WebHooks_ are already a well known concept. It is possible to keep the existing implementation of the _PersistenceProvider_ and integrate them with a lot of other possible data processing components in a more general fashion. In the end, this step will result in a lot of additional feature possibilities, which go far beyond the existing ones proposed here. Therefore we only need to implement this concept once in the _secureCodeBox operator_ and new ideas for extending the _DataProcessing_ will not enforce conceptual or architectural changes.
+With the new _hook concept_ we open the _phase 3 processing_ to a more intuitive and flexible architecture. It is easier to understand because _WebHooks_ are already a well known concept. It is possible to keep the existing implementation of the _PersistenceProvider_ and integrate them with a lot of other possible processing components in a more general fashion. In the end, this step will result in a lot of additional feature possibilities, which go far beyond the existing ones proposed here. Therefore we only need to implement this concept once in the _secureCodeBox operator_ and new ideas for extending the _DataProcessing_ will not enforce conceptual or architectural changes.
 
-Ideas for additional data processing hooks:
+Ideas for additional processing hooks:
 
 * Notifier hooks (_ReadOnlyHook_) e.g., for chat (slack, teams etc.), metric, alerting systems
 * MetaData enrichment hooks (_ReadAndWriteHook_)