content/en/docs/concepts/4_digital-platforms/platform-components/cicd-pipeline/review-stl.md

@@ -0,0 +1,11 @@
+
+
+# Gitops changes the definition of 'Delivery' or 'Deployment'
+
+We have Gitops these days .... so there is a desired state of an environment in a repo and a reconciling mechanism done by Gitops to enforce this state on the environemnt.
+
+There is no continuous whatever step inbetween ... Gitops is just 'overwriting' (to avoid saying 'delivering' or 'deploying') the environment with the new state.
+
+This means whatever quality ensuring steps have to take part before 'overwriting' have to be defined as state changer in the repos, not in the environments.
+
+Conclusio: I think we only have three contexts, or let's say we don't have the contect 'continuous delivery'

content/en/docs/solution/tools/Backstage/_index.md

@@ -1,9 +1,5 @@
-+++
-title = "Backstage"
-weight = 2
-[params]
-    author = 'evgenii.dominov@telekom.de'
-    date = '2024-09-36'
-+++
-
-Here you will find information about Backstage, it's plugins and usage tutorials
+---
+title: Backstage
+weight: 2
+description: Here you will find information about Backstage, it's plugins and usage tutorials
+---

content/en/docs/solution/tools/CNOE/CNOE-competitors/_index.md

@@ -1,7 +1,8 @@
-+++
-title = "Analysis of the CNOE competitors"
-weight = 1
-+++
+---
+title: Analysis of CNOE competitors
+weight: 1
+description: We compare CNOW - which we see as an orchestrator - with other platform orchestring tools like Kratix and Humanitc
+---
 
 ## Kratix
 

content/en/docs/solution/tools/CNOE/_index.md

@@ -0,0 +1,4 @@
+---
+title: CNOE
+description: CNOE is a platform building orchestrator, which we choosed at least to start in 2024 with to build the EDF
+---

content/en/docs/solution/tools/CNOE/idpbuilder/_index.md

@@ -0,0 +1,6 @@
+---
+title: idpbuilder
+weight: 3
+description: Here you will find information about idpbuilder installation and usage
+---
+

content/en/docs/solution/tools/CNOE/verification.md

@@ -0,0 +1,69 @@
+---
+title: Validation and Verification
+weigth: 100
+description: How does CNOE ensure equality between actual and desired state
+---
+
+## Definition
+
+The CNOE docs do somewhat interchange validation and verification but for the
+most part they adhere to the general definition:
+
+> Validation is used when you check your approach before actually executing an
+> action.
+
+Examples:
+
+- Form validation before processing the data
+- Compiler checking syntax
+- Rust's borrow checker
+
+> Verification describes testing if your 'thing' complies with your spec
+
+Examples:
+
+- Unit tests
+- Testing availability (ping, curl health check)
+- Checking a ZKP of some computation
+
+---
+
+## In CNOE
+
+It seems that both validation and verification within the CNOE framework are
+not actually handled by some explicit component but should be addressed
+throughout the system and workflows.
+
+As stated in the [docs](https://cnoe.io/docs/intro/capabilities/validation),
+validation takes place in all parts of the stack by enforcing strict API usage
+and policies (signing, mitigations, security scans etc, see usage of kyverno
+for example), and using code generation (proven code), linting, formatting,
+LSP. Consequently, validation of source code, templates, etc is more a best
+practice rather than a hard fact or feature and it is up to the user
+to incorporate them into their workflows and pipelines. This is probably
+due to the complexity of the entire stack and the individual properties of
+each component and applications.
+
+Verification of artifacts and deployments actually exists in a somewhat similar
+state. The current CNOE reference-implementation does not provide sufficient
+verification tooling.
+
+However, as stated in the [docs](https://cnoe.io/docs/reference-implementation/integrations/verification)
+within the framework `cnoe-cli` is capable of extremely limited verification of
+artifacts within kubernetes. The same verification is also available as a step
+within a backstage
+[plugin](https://github.com/cnoe-io/plugin-scaffolder-actions). This is pretty
+much just a wrapper of the cli tool. The tool consumes CRD-like structures
+defining the state of pods and CRDs and checks for their existence within a
+live cluster ([example](https://github.com/cnoe-io/cnoe-cli/blob/main/pkg/cmd/prereq/ack-s3-prerequisites.yaml)).
+
+Depending on the aspiration of 'verification' this check is rather superficial
+and might only suffice as an initial smoke test. Furthermore, it seems like the
+feature is not actually used within the CNOE stacks repo.
+
+For a live product more in depth verification tools and schemes are necessary
+to verify the correct configuration and authenticity of workloads, which is, in
+the context of traditional cloud systems, only achievable to a limited degree.
+
+Existing tools within the stack, e.g. Argo, provide some verification
+capabilities. But further investigation into the general topic is necessary.

content/en/docs/solution/tools/idpbuilder/_index.md

@@ -1,6 +0,0 @@
-+++
-title = "idpbuilder"
-weight = 3
-+++
-
-Here you will find information about idpbuilder installation and usage