Model packaging, approval, and registry

The package is the approval unit

Model weights alone do not define served behavior. Create a package that binds model and tokenizer identities to configuration, prompt or interface contract, runtime compatibility, evaluation, license, provenance, policy, limitations, and approval.

Registry record

An approved model registry should expose:

• Immutable model, tokenizer, and package identities.
• Intended and prohibited uses, owners, and approved environments.
• License review and attribution obligations.
• Evaluation datasets, conditions, results, and unresolved failures.
• Runtime and hardware compatibility claims with tested versions.
• Serving defaults, security constraints, and required controls.
• Approval, exceptions, expiry, supersession, revocation, and rollback target.

Promotion should copy the evaluated package without substituting files or rebuilding transformations. Re-verify identities after transfer.

Access and lifecycle state

Separate who may submit, evaluate, approve, promote, deploy, revoke, and administer the registry. Consumers should select only approved versions within their scope. A revoked model must become unavailable to new deployments and visible in existing-deployment response plans.

The registry is a decision system and authoritative metadata source, not merely a file browser.