Search your repositories for the calls that load models and the identifiers they pass, then check configs, notebooks, container files and scripts. A first pass with plain text search finds most of them. Record each hit with its source, revision and owner, and mark the ones you could not resolve.
Why start with discovery
You cannot write an AI bill of materials for models you do not know you use. Models enter through many doors: a data scientist's notebook, a default inside a library, an environment variable in a deploy file. An inventory built from memory misses these.
Where models hide
| Place | What to look for |
|---|---|
| Source code | Calls such as from_pretrained, torch.load, load_model, pickle.load, joblib.load |
| Config files | Model names in YAML, JSON or environment files |
| Notebooks | The same calls, often with a hard coded repo id |
| Dockerfiles and scripts | Downloads with the hub CLI, curl or wget of weight files |
| CI and deploy files | Cache keys and mount paths that mention model folders |
| Requirements files | ML libraries, and libraries that download models on first use |
The Transformers docs show that from_pretrained takes a hub identifier or a local directory, so a string argument is your clue. Local paths need one more step: find where the folder is filled.
Steps
- Run a text search across all repos for the call names above.
grep -rnE "from_pretrained|torch\.load|load_model|pickle\.load|joblib\.load|snapshot_download|hf_hub_download" --include="*.py" --include="*.ipynb" .
- Search config and deploy files for known hub identifiers and for the words model, checkpoint and weights.
- List files with weight extensions that are checked in or mounted: .safetensors, .bin, .pt, .pth, .h5, .onnx.
- Check library defaults. Some libraries download a default model on first run, so read their docs for your version.
- Ask each team: what do you run in production, what do you use in notebooks, what does the pipeline pull?
- Write one row per model: identifier, revision or digest, format, license, owner, where it runs, and how you found it.
- Mark unknowns. A row that says "revision unknown" is a task, not a failure.
What this will miss
Text search cannot see models chosen at run time from user input, loaded through a remote service, or pulled by a vendor tool you do not control. For hosted models called by API, record the provider, the model name and the version you pin if one exists. That is a different kind of entry, but it belongs in the same list.
Keep the search script in version control and run it on a schedule, so new models show up as changes instead of surprises.
Try it yourself
Click through it at your own pace, or open it full screen.
Open the inventory and see how libraries are listed with versions. Your model list should read the same way.
Quick check
Do I need to inventory models I only call through an API?
Yes, as a separate kind of entry: provider, model name, pinned version where offered, and the terms you accepted. You cannot inspect the weights, but you can record what you depend on.
How often should I rerun the search?
On every pull request if you can, or at least weekly. Models are added casually, so catch them early.
Safeguard scans repositories for dependencies and generates SBOMs, which covers the libraries that load models. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
