A model intake record is a one page form filled in before a model enters your product. It captures where the model came from, the exact revision and file formats, the license, the datasets, the tests you ran and who approved it. It turns a casual download into a decision you can defend.
Why a form helps
Models arrive informally: a developer finds one, tries it, and it quietly ends up in production. A short intake step costs little and leaves a trail. The form below is built from the controls covered across the model supply chain: pinned revisions, file format checks, license review, dataset review and sandboxed loading.
The record
| Section | Questions to answer |
|---|---|
| Identity | Name, publisher, repository URL, full commit hash |
| Purpose | What product feature uses it, and who owns it |
| Files | List of files, formats, SHA256 of each, any custom code files |
| Format risk | Pickle based, TensorFlow graph, Keras, ONNX with external data, safetensors |
| License | Declared license, license text saved, base model license |
| Data | Datasets named on the card, their licenses, known bias notes |
| Provenance | Is it a fine tune, adapter, merge or quantized copy, and of what |
| Loading | Sandbox used, loader and settings, trust_remote_code needed or not |
| Tests | Evaluation set results, abuse tests, output checks |
| Dependencies | Libraries and versions required, locked with hashes |
| Decision | Approved, approved with limits, rejected; name and date |
| Review date | When to look again |
How to fill it in
- Start from the pinned revision. Everything else refers to it.
- Hash the files. The Hub download guide supports filtering by pattern, so fetch only what you intend to use.
- Read the model card and dataset card. The Hub documentation says cards describe intended uses, limitations, training information and datasets, so use them as a starting checklist, and note what is missing.
- Open the repo for code files. The Transformers docs advise extra precaution with custom models and loading from a specific revision.
- Load in a sandbox first. For pickle based files, note the Python documentation warning that unpickling can execute arbitrary code.
- Run your tests and write the results into the record.
- Get a second person to sign off for anything customer facing.
Keeping it light
A form nobody fills in is worse than none. Keep it to one page, prefill from a script where possible, and store it next to the code in version control. For low risk uses such as internal experiments, accept a short version with identity, license and decision.
A good rule for scope: if a model touches customer data, runs with credentials, or ships to customers, use the full record. Otherwise use the short one.
After approval
Add the model to your inventory and your AI bill of materials, using the record as the source. Set a reminder for the review date. When the publisher releases a new revision, treat it as a new intake, since weights, files and licenses can all change.
Quick check
Who should approve a model?
The owner of the feature plus someone who owns security or risk. Two people reduce the chance of an unreviewed model slipping through.
Do open source models need the same record as vendor models?
The fields differ, but the habit is the same. For hosted vendor models, shift the record toward contract, data flow and version control.
Safeguard scans repository dependencies and generates SBOMs, and policies and gates can block risky changes in pull requests. Try a free scan at gold.safeguard.sh/scan.
Sources
- Hugging Face Hub model cards
- Hugging Face Hub dataset cards
- Transformers loading models guide
- Hugging Face Hub download guide
- pickle, Python object serialization
Last reviewed: 19 October 2026.
