Skip to content

Architecture and data flow

View as Markdown

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

Roles

RoleWhat it does
PublisherPublishes a release: the model and configuration, named by digest.
ApproverSigns the approval that binds one release to one destination, policy and age limit.
DeployerDelivers the approved release to the destination's runtime.
ReviewerReads 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.
  1. 01Identify the release
  2. 02Bind approval to the release and destination
  3. 03Integrate with a supported runtime
  4. 04Compare approved and reported
  5. 05Preserve discrepancies, missing evidence and recovery
Diagram of the five-step workflow. Each step is described below.

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.

Last updated: October 12, 2026