# Key concepts

Ten words carry the whole product. Each gets one sentence, then the example shows them working together.

## The objects

| Concept | What it is | Where it is defined |
| --- | --- | --- |
| Release | One version of a model and its configuration, published for approval. The example has two: `cpu-1` and `cpu-2`. | [Release identity](https://docs.vraelis.com/release-identity) |
| Release identity | The digests that name a release exactly: model, configuration, release and receipt. Preprocessing identity is proposed, not recorded. | [Release identity](https://docs.vraelis.com/release-identity) |
| Approval | A signed decision that one release may run in one destination, under one policy, within an age limit. | [Approval binding](https://docs.vraelis.com/approval-binding) |
| Policy | The runtime a destination requires: the exact ONNX Runtime version and execution providers, and who may publish, deploy and approve. | [Runtime integration](https://docs.vraelis.com/runtime-integration) |
| Destination | Where an approved release may run: an environment and a resource. In the experiment, `non-actuating-lab` and `onnx-cpu`. | [Approval binding](https://docs.vraelis.com/approval-binding) |
| Runtime | The process that loads and serves the model. In the experiment, a managed ONNX Runtime session on CPU. | [Runtime integration](https://docs.vraelis.com/runtime-integration) |
| Desired | The approved release the runtime should be running. | [Observation record](https://docs.vraelis.com/observation-record) |
| Loaded | What the runtime reports it is actually running. A worker self-report, not attestation. | [Observation record](https://docs.vraelis.com/observation-record) |
| Observation | One comparison of desired with loaded, with a status: matched, pending or unknown. | [States and codes](https://docs.vraelis.com/states-and-codes) |
| Trace | The ordered file of observations a run produces. The evidence app reads it; it never changes it. | [Evidence and observations](https://docs.vraelis.com/evidence-and-observations) |

## How they relate

- A release has exactly one identity. Change any byte of the model or configuration and the identity changes.
- An approval names one release, one destination and one policy. It does not approve a model in general.
- A runtime loads a release only if its own version and execution providers satisfy the policy the approval names.
- Every observation pairs one desired release with one loaded report, or with a reason why there is no report.
- A trace holds observations in the order they were recorded. Nothing is dropped, including the ones that confirm nothing.

## The example, all the way through

1. `cpu-1` is published and approved for `non-actuating-lab / onnx-cpu`. The runtime loads it and reports it. Observation 01: matched.
2. `cpu-2` is published and approved. The runtime is in baseline mode, so it keeps serving `cpu-1`. Observation 02: pending (Reload pending).
3. An explicit reload loads `cpu-2`, and the runtime reports it. Observation 03: matched.
4. The worker stops. `cpu-2` stays approved, but nothing reports what is loaded. Observation 04: unknown, reason `RUNTIME_UNAVAILABLE`.

> **Read this first.** Everything here comes from one captured run of a synthetic ONNX CPU experiment. The loaded side is what the worker says about itself; Vraelis does not claim hardware attestation.

- [Architecture](https://docs.vraelis.com/architecture): Who does what, and where each piece of evidence comes from.
- [Walkthrough](https://docs.vraelis.com/walkthrough): The same four observations, screen by screen.

---

Vraelis documentation, Vraelis. https://docs.vraelis.com/key-concepts
