Approval and reported runtime identity
A release can be approved while the runtime still reports an earlier release. Preserve both facts.
Research note · November 13, 2026Research question
What evidence distinguishes approval, a pending reload, and a subsequent report of the approved release?
Method
- Identify the approved model and configuration by digest, and bind the approval to its intended destination.
- Record the worker's reported loaded release independently of the approval record. Compare release identity and runtime policy without treating approval as deployment.
- Preserve observations before and after an explicit reload, including unavailable evidence. Re-evaluate the reported identity after the reload rather than inferring success from the reload request.
- Keep the runtime and execution-provider versions with the record. The documented reference uses ONNX Runtime 1.23.2 and CPUExecutionProvider in a non-actuating lab.
Records to retain
- Approved release and destination binding
- Reported loaded release and observation time
- Runtime policy and reported provider
- Ordered observations around the explicit reload
Current evidence
The published reference describes an approved cpu-2 release while cpu-1 remained loaded, followed by an explicit reload and a matching report. The documentation also reports 133 internal tests at the runtime rejection-diagnostics revision; that count is historical and scoped to that revision.
Interpretation & limits
Runtime identity is a worker self-report, not hardware attestation. Internal test counts are not field reliability, attack-detection accuracy or a latency benchmark. The experiment is not a customer deployment.
Next experiments
- Run the specified fault cases and publish their conditions and observed outcomes.
- Define evidence freshness and outage behavior before presenting a report as current.