Ship models with a dependable release path.

A model file is part of a release

Delivering weights is not the same as deploying a working inference feature. A release may also require a tokenizer, external tensor data, preprocessing logic, a runtime binary, and version-specific application code. Identify those relationships before assigning cache policies.

For a browser workload, describe the supported environment and the expected behavior when the runtime cannot initialize. For a server workload, record the runtime and hardware assumptions. In both cases, verify the exact artifacts together before promoting the release.

Keep release assets immutable

Give each approved artifact a versioned or content-addressed path. Publish a new path when its bytes change. Reusing a long-cached URL for new weights can create an inconsistent deployment when a client has the old runtime and the new model, or the reverse.

A small release manifest can tell the application which asset set to use. Its freshness policy should reflect how quickly a release change or rollback must become visible. Immutable assets and mutable release pointers need different treatment.

release: classifier-2026-08
model: /models/classifier-2026-08/model.onnx
preprocessing: /models/classifier-2026-08/preprocess.json
runtime: pinned and compatibility-tested
integrity: expected digest from a trusted manifest

This is an illustrative release record. Adapt its fields to the actual runtime and distribution process; it does not define a CDNML API.

Verify the runtime’s delivery requirements

ONNX Runtime Web’s deployment guidance explains runtime asset locations and deployment considerations. Use the documentation for the pinned runtime version when choosing asset paths and browser policies.

Test with the same response headers, origin relationships, and asset URLs that users will receive. A model can work locally while a production content-security policy, cross-origin rule, or missing auxiliary file prevents it from loading.

Separate integrity from trust

A digest can detect a mismatch with expected bytes. It cannot establish trust if an attacker can replace both the model and the expected digest. Protect the manifest, release permissions, and distribution channel as a connected system.

Budget for the first load

Measure transfer size, download time, initialization, and inference under representative connectivity and device conditions. A cached model may improve repeat visits while the first load still feels slow. Consider whether the feature should load on demand, progressively prepare, or offer an eligible remote path.

Do not assume that a smaller file guarantees lower memory use or better results. Quantization and format choices need model-specific accuracy and runtime tests. Keep a known-good artifact available while assessing a new optimization.

Make rollback a release operation

• Preserve the prior approved artifact set and compatibility record.
• Change the trusted release pointer through an authorized process.
• Check how long cached manifests can keep clients on the affected version.
• Verify that access policy and retention rules permit continued distribution of the rollback target.

Follow the ONNX model delivery guide for a fuller deployment checklist. The edge architecture page helps decide where inference should run, while the edge AI security checklist covers release authority and model supply-chain boundaries.