2-Guides/review-guide.md

 # Scope
-This guide describes the review/assessment-workflow as part of the community based assessment by the OSEGeV Conformity Assessment Body.
+This guide describes the review/assessment workflow as part of the community based assessment by the OSEGeV Conformity Assessment Body.
 
+The guide is directed at reviewers that support the assessment through verifying the hardware's reproducability.
 
 ----
 
@@ -8,21 +9,14 @@ in rework
 
 ---
 
-**Welcome to community-based assessment of open source hardware!**
+# The assessment workflow
 
-**You, the reviewer**, are part of this pilot of decentralised, transparent and community-driven quality control of documentation for open source hardware (OSH). We believe that this procedure (standardised by [DIN SPEC 3105-2](https://din.one/pages/viewpage.action?pageId=36603167)) contributes to the overall trustworthiness and applicability of open source hardware. As a side effect we hope this helps OSH projects to interconnect to each other.
-
-Thanks for donating your time and brain capacity for this. Highly appreciated.
-
-# The Scope
-
-By your review you'll assess whether a certain piece of hardware qualifies as open source hardware according to [DIN SPEC 3105-1](https://din.one/pages/viewpage.action?pageId=36603169). See [CAB overview](3-Further-Information/CAB) or [DIN SPEC 3105-1](https://din.one/pages/viewpage.action?pageId=36603169) for more general information.
-
-# The Procedure
+The assessment workflow is the center of the community based assessment, which will check and - if applicable - approve that a piece of hardware can be studied, modified, produced and sold according to the definition by the [DIN SPEC 3105](/cab/docs/-/wikis/3-Further-Information/DIN-SPEC-3105-Open-Source-Hardware). In short this means, the technology is reproducable without requirement of reverse engineering.
 
 ## Overview
 
 Review happens in corresponding issues on the CAB's GitLab instance. They should be self-explanatory and may differ based on the projects structure. Usually we divide projects in different subgroups so you can go through the project step by step. 
+
 Two Issues will always be there:
 
 * `[Review][main] <project-name>`