Runtime integration and policy

The receiving runtime checks the policy before it serves. In the experiment there is one supported runtime: ONNX Runtime 1.23.2 with exactly one execution provider, CPUExecutionProvider.

The runtime policy

This is the runtime policy from the recorded trace, unchanged.

policy cpu-lab, version 1JSON

{
  "schemaVersion": 1,
  "policyId": "cpu-lab",
  "version": "1",
  "environmentId": "non-actuating-lab",
  "resourceId": "onnx-cpu",
  "publishers": ["publisher"],
  "deployers": ["deployer"],
  "approvers": ["approver"],
  "maxAgeMs": 60000,
  "runtime": {
    "ortVersion": "1.23.2",
    "executionProviders": ["CPUExecutionProvider"]
  }
}

Field	What it holds
`policyId`, `version`	The policy's name and version: `cpu-lab`, version 1.
`environmentId`, `resourceId`	The destination: `non-actuating-lab` and `onnx-cpu`.
`publishers`, `deployers`, `approvers`	Who may publish, deploy and approve.
`maxAgeMs`	The approval age limit: 60000 milliseconds.
`runtime.ortVersion`	The required ONNX Runtime version, exactly `1.23.2`.
`runtime.executionProviders`	The required execution providers, exactly `CPUExecutionProvider`.

What the policy binds, and what it does not

The ONNX Runtime version and the execution provider list are part of the signed policy. A reported runtime satisfies the policy only when its version is the same and its execution provider list is the same, in the same order.

Python is different. The worker reports its Python version, 3.12.14 in the captured run, and the test harness pins it, but Python is not part of the signed policy. The evidence app labels it as recorded only.

Component	Version	Bound by the signed policy
ONNX Runtime	`1.23.2`	Yes
Execution provider	`CPUExecutionProvider`	Yes
Python	`3.12.14`	No. Reported by the worker and pinned by the harness.
Node.js	`v24.19.0`	No. Pinned by the harness.

Runtime policy satisfied: ONNX Runtime 1.23.2 required and reported, CPUExecutionProvider. — Read-only evidence app, inside the controlled ONNX reference experiment.

Real inference on a synthetic model

The experiment runs real CPU inference on the approved bytes. The model is synthetic: it exists to exercise the release path, and it is not a robotics integration or a customer model.

Baseline and reconcile modes

The experiment runs in two modes. In baseline mode the runtime keeps serving the release it loaded until an explicit reload, which is why an approved update first shows as Reload pending. The experiment also has a reconcile mode. The captured run in these docs is a baseline run.

Not built yet

ProposedAdapters for customer runtimes. Today the experiment supports one runtime, on CPU.
ProposedA Kubernetes collector, in specification v1.3. The proposal has not been applied.
Not built yetA latency study. There are no latency measurements to report.

Last updated: October 10, 2026