Minor changes to the adr_0001.adoc

Author: jorgestiga

docs/adr/adr_0001.adoc

@@ -23,7 +23,7 @@
 
 === Status Quo
 
-One major challange implementing the _secureCodeBox_ is to provide an flexible and modular architecture which enables the open source community to easily understand the concepts and especially to extend the _secureCodeBox_ with individual features. Therefore we decided to seperate the process stages of an single security scan (instance of scanType CRD) in 3 major phases:
+One major challenge implementing the _secureCodeBox_ is to provide a flexible and modular architecture, which enables the open source community to easily understand the concepts and especially to extend the _secureCodeBox_ with individual features. Therefore we decided to seperate the process stages of a single security scan (instance of scanType CRD) in 3 major phases:
 ```
 	┌──────────────────┐          ┌──────────────────┐          ┌──────────────────┐
 	│     Scanning     ├─────────▶│     Parsing      ├─────────▶│    Persisting    │
@@ -34,18 +34,18 @@ By now the "Persisting Phase 3" was implemented by so called _persistenceProvide
 
 === Problem and Question
 
-We identified different additional UseCases with a are more _data proccessing oriented_ pattern than the implemented _persisting phase3_ indicates. For example we implemented a so called "MetaDataProvider" feature which is responsible for enhancing each security finding with additional metadata. But the MetaDataProvider must be executed after the _parsing phase 2_ and before the _persisting phase 3_ because it depends on the parsed finding results (which will be enhanced) and the update findings should be persisted also. 
+We identified different additional UseCases with a more _data proccessing oriented_ pattern than the implemented _persisting phase3_ indicates. For example, we implemented a so called "MetaDataProvider" feature, which is responsible for enhancing each security finding with additional metadata. But the MetaDataProvider must be executed after the _parsing phase 2_ and before the _persisting phase 3_ because it depends on the parsed finding results (which will be enhanced) and the update findings should be also persisted. 
 
 
-To find a proper solution we splitted the topic into the follwong two questions:
+To find a proper solution, we splitted the topic into the follwong two questions:
 
 * Question 1: Should we unify the concepts MetaDataProvider and PersistenceProvider?
-* Question 2: How should the execution model look like for each?
+* Question 2: How should the execution model look like for each concept?
 
 ==== Question 1: Should we unify the concepts MetaDataProvider and PersistenceProvider?
 ==== Solution approach 1: Unify
 
-Both "modules" are "processing" the security findings which are generated in the parsing phase.
+Both "modules" are "processing" the security findings, which are generated in the parsing phase.
 But there is one larger difference between them:
 
 * `PersistenceProvider` is proccesing the findings with a *ReadOnly* pattern
@@ -58,13 +58,13 @@ The are two variants:
 * `ValidatingWebhookConfiguration` (ReadOnly) *Executed Last*
 * `MutatingWebhookConfiguration` (ReadAndWrite) *Executed First*
 
-We could do a similar thing and introduce CRD which allows to execute "custom code" (generally speaking, depends on the second question) after a scan has completed (meaning scan and parser phase are done). Some name ideas:
+We could do a similar thing and introduce CRD which allows to execute "custom code" (generally speaking, depends on the second question) after a scan has completed (meaning both scan and parser phases are done). Some name ideas:
 
 - `ScanHooks`
 - `ScanCompletionHooks`
 - `FindingProcessors`
 
-These could than have a `type` attribute which declares if they are `ReadOnly` or `ReadAndWrite`.
+These could be implemented with a `type` attribute, which declares if they are `ReadOnly` or `ReadAndWrite`.
 
 The operator would process all these resources in the namespace and execute the `ReadAndWrite` ones first (in serial: one at a time to avoid write conflicts) and then the `ReadOnly` ones (in parallel).
 
@@ -99,9 +99,9 @@ The Execution Flow would then look something like this:
 
 **Cons:**
 
-- Possible "over abstraction"?
+- Possible "over-abstraction"?
 - Need to refactor the ElasticSearch PersistenceProvider
-- The "General Implementation" will be harder than the individual ones - 
+- The "General Implementation" will be harder than the individual ones
 
 ==== Solution approach 1: Keep Split between Persistence Provider and MetaData Provider
 
@@ -187,7 +187,7 @@ Regarding the Question 1 it seems that both solution approaches are resulting in
 	└──────────────────┘          └──────────────────┘          └──────────────────┘
 ```
 
-Regarding the question 2 we descided to implement the solution approach 1 with a job based approach (no active service componend needed).
+Regarding the Question 2 we decided to implement the solution approach 1 with a job-based approach (no active service componend needed).
 The Phase 3 `DataProcessing` will be therefore splitt into to seperate phases named `ReadAndWriteHooks (3.1)` and `ReadOnlyHooks (3.2)`
 
 ```
@@ -203,11 +203,11 @@ The Phase 3 `DataProcessing` will be therefore splitt into to seperate phases na
 
 == Consequences
 
-With the new `Hook Concept` we open the `DataProcessing` Phase 3 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 `persistenceProviders` and to 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 fare beyond the existing ones. 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 `DataProcessing` Phase 3 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 `persistenceProviders` and to 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 fare beyond the existing ones. 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:
 * Notifier-Hooks (ReadOnlyHook) e.g. for chat systems (slack, teams...) or metric / alerting systems
 * MetaData Enrichment Hooks (ReadAndWriteHook)
 * FilterData Hooks (e.g. false/positive Handling) (ReadAndWriteHook)
 * SystemIntegration Hooks (ReadOnlyHook) e.g. for ticketing systems like JIRA
-* CascadingScans Hooks (ReadOnlyHook) e.g. for starting new security scans based on findings
+* CascadingScans Hooks (ReadOnlyHook) e.g. for starting new security scans based on findings