# Architecture and data flow

Four roles, one policy, one runtime and one read-only app. This is how the pieces of the reference experiment fit together.

## Roles

| Role | What it does |
| --- | --- |
| Publisher | Publishes a release: the model and configuration, named by digest. |
| Approver | Signs the approval that binds one release to one destination, policy and age limit. |
| Deployer | Delivers the approved release to the destination's runtime. |
| Reviewer | Reads the evidence afterwards in the read-only evidence app. Not a role in the policy; anyone with the trace. |

The policy names who may publish, deploy and approve (`publishers`, `deployers`, `approvers`). In the captured run they are the placeholder principals `publisher`, `deployer` and `approver`.

## The data flow

1. Publish. The release is written to the experiment's local release store, whose signatures the experiment checks.
2. Approve. The approval names the release, the destination (`non-actuating-lab / onnx-cpu`), the policy (`cpu-lab`, version 1) and an age limit of 60 seconds.
3. Load. Before it serves, the runtime checks the policy: ONNX Runtime exactly 1.23.2, execution providers exactly `CPUExecutionProvider`. A mismatch is refused.
4. Report. The worker reports what its session loaded: the release's identity and its own runtime (ONNX Runtime version, execution providers, Python version).
5. Record. Each report is compared with the approved release and recorded as an observation in the trace, in order.
6. Review. The evidence app opens the trace read-only, checks its structure and consistency, and shows each observation with its source JSON. It does not check signatures.

*Diagram of the five-step workflow: 01 Identify the release, then 02 Bind approval to the release and destination, then 03 Integrate with a supported runtime, then 04 Compare approved and reported, then 05 Preserve discrepancies, missing evidence and recovery.*

## What the architecture is not

- Not a deployment tool. It does not decide what runs where; it records what was approved and what is reported.
- The evidence app is read-only and never changes a runtime. The private runtime adapter can prepare and activate sessions: approved-session mode waits for an explicit reload, while reconcile mode synchronizes the desired release before inference.
- Not attestation. The loaded identity is the worker's own report. The host and worker are trusted in the experiment.
- Not live. The evidence app reads a recorded trace; it does not watch a running system.

> **Where Python sits.** The worker reports its Python version (3.12.14 in the captured run), but Python is not part of the signed policy. The app labels it recorded only.

- [Runtime integration and policy](https://docs.vraelis.com/runtime-integration): The policy fields, and how a runtime is checked.
- [Observation record](https://docs.vraelis.com/observation-record): Every field of an observation, from the real trace.

---

Vraelis documentation, Products. https://docs.vraelis.com/architecture