A model intake policy says that no third party model reaches production until someone has checked the source, file format, license, lineage and behaviour, recorded the exact revision, and approved it. Keep it to one page, name an owner, and enforce what you can in CI rather than relying on memory.
Why a policy and not good intentions
Models arrive by many paths: a notebook, a README snippet, a colleague's laptop. Without a rule, each one is a one off decision made under time pressure. A policy makes the checks boring and repeatable, which is the point.
It also answers a question buyers and auditors increasingly ask: how do you decide which models you use?
The checks
Each item below ties to something the Hub or the framework documentation says is worth checking.
- Source. Is the publisher known? Do recent commits show Verified status? See what verified commits prove.
- Format. Prefer safetensors. For pickle based files, require restricted loading and a sandbox, or reject. See torch.load weights_only.
- Code. Does it need custom repository code? If so, a named reviewer reads it. See trust_remote_code.
- Scans. What do the Hub's scans show, and are any pending? See scan badges.
- License and lineage. Read the model card, record base models. See model card fields.
- Behaviour. Run your own evaluations on your own tasks, including misuse cases.
- Pin. Record the full commit hash. See pinning a revision.
What to record
One entry per model: name, revision, source URL, file hashes, format, license, base models, reviewer, date, evaluation summary and a review date. Store it in the repository that deploys the model. The ML-BOM field list gives a fuller version.
Roles
Keep it light. One requester, one reviewer who is not the requester, and one owner of the policy who keeps the list of approved publishers. For small teams, the reviewer may be a rotating engineer.
Enforcement
Policies that depend on remembering fail. Put what you can in the pipeline: a check that fails the build if a model reference has no pinned revision, or if a load call disables restricted loading, or if an unapproved model name appears in config. Pull request review then covers the human judgement.
Click through it at your own pace, or open it full screen.
Safeguard offers policies, gates and guardrails for CI checks like these, along with SBOM and dependency scanning for the libraries around your models. A free scan is at https://gold.safeguard.sh/scan.
Start small
You do not need all seven checks on day one. Begin with pinning and recording, since they cost almost nothing and give you an inventory. Add the format and code rules next, because they close the most direct execution paths. Add behaviour testing as your tooling matures. Review the policy every quarter and note which exceptions were granted, so repeated exceptions turn into rule changes rather than quiet drift.
Quick check
How long should the policy be?
One page. If people will not read it before a release, it will not be followed.
Do internal models need the same process?
Models you trained yourself still need a record and a review, but the source check is easier. Apply the same revision pinning and inventory steps.
Last reviewed: 19 October 2026.
