---
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.
