Approval binding
An approval names the exact release and where it may run, under a runtime policy with an age limit. Approving a model in general is not enough.
What an approval binds
| Part | In the captured run | What it means |
|---|---|---|
| Release | cpu-2, generation 2, by its identity digests | The exact bytes being approved. |
| Destination | non-actuating-lab and onnx-cpu | The environment and the resource the release may run on. |
| Policy | cpu-lab, version 1 | The runtime requirements the destination must meet. |
| Age limit | 60 seconds (maxAgeMs 60000) | How old an approval may be when it is used. |
| Runtime | ONNX Runtime 1.23.2, CPUExecutionProvider | The one runtime the experiment supports. |
Signed bindings in the experiment
In the experiment, release and approval bindings are signed, and the runtime policy is enforced before the worker serves.
The recorded trace keeps a receipt digest for each release. It does not hold the approval signature or the approver's identity, and the evidence app does not check signatures.
Roles
The runtime policy names three roles: publishers, deployers and approvers. In the captured run they are the placeholder principals publisher, deployer and approver.
The design keeps approval separate from the workload that proposes a change, so a deployment job cannot approve its own release. This is the machine trust principle applied to releases.
Supplier and recipient responsibilities
The supplier identifies and delivers the release. The recipient owns destination authorization and acceptance. The runtime operator controls installation and recovery. These can be different organizations, and a supplier signature does not grant permission to change a customer's system.
Approval and successful loading are separate events. An approved release that the runtime has not loaded is still only approved, and Vraelis Contour records it that way.
Last updated: October 10, 2026