A model release is a security decision.

The exact release

Bind the model artifact, preprocessing and configuration to a reviewed version. A release that cannot be named exactly cannot be approved exactly.

The right authority

Tie approval to the exact release and destination, independently of the workload that proposes the change.

The receiving runtime

Check compatibility, and distinguish the desired release from the version the managed service reports loading. Approval and successful loading are separate events.

The acceptance record

Retain accepted, failed or uncertain activation, and the evidence available during recovery. A missing report is a result to keep, not a gap to fill in.

A permit is only part of the control

A policy engine can return a decision. The component holding access to the resource must enforce it against the exact request, the current authority and any required approval.

Questions for each team

• Release teams: how models are packaged, reviewed, promoted and rolled back.
• Platform teams: where a release can be checked, and where existing deployment tooling must enforce that decision.
• Security teams: who could alter a model release, which controls already exist, and what evidence would show a useful improvement.

Start at the release boundary

Vraelis Contour starts here. In the experiment it connects signed release and approval bindings, runtime policy enforcement for ONNX Runtime 1.23.2 on CPU, real CPU inference, and desired against reported loaded observations, in a small synthetic ONNX workload.

Loaded state evidence is a worker self-report. The experiment does not establish protection against a compromised host or show how a model behaves.

Vraelis Contour is in private development. There is no public application or available deployment.