Field note
Record the Model Artefact You Actually Run
Track the exact files and transformations between the publisher's release and your running service.
“We run an open model locally” leaves several practical questions unanswered. Which publisher supplied it? Which revision is installed? Who converted the weights? Which tokenizer and chat template are in use? Where is the licence text that accompanied that release?
Create a release record for each deployed model bundle. It should let another person identify the files, understand their origin and rebuild the same deployment without guessing from a friendly name in a user interface.
Follow the artefact chain
Begin with the original publisher's repository and a specific revision. Then record any fine-tuning, adapter, merge, conversion or quantisation that sits between that source and the installed files. A community conversion is a separate step in the chain even when it uses the same model family name.
Hugging Face's model card documentation supports base-model relationships for fine-tunes, adapters, quantised models and merges. It also supports licence metadata and links to custom terms. These fields are useful evidence to collect, but the record should retain the underlying licence file and relevant documentation as well.
For each transformation, identify who produced it, the source revision, the method and the output digest. Where the information is unavailable, mark the gap. Do not turn an unknown conversion process into a confident claim that the result is identical to the publisher's release.
Record more than the weights
A useful deployment record contains the following information:
| Component | Evidence to retain |
|---|---|
| Weights | Publisher, repository, revision, filenames and digests |
| Tokenizer | Source revision and installed files |
| Chat template | Exact template or its versioned source |
| Adaptation | Adapter, fine-tune or merge lineage where used |
| Quantisation | Method, producer, source and output identity |
| Runtime | Version, backend and relevant load configuration |
| Terms | Licence files, linked terms and the review decision |
| Validation | Task set, configuration and acceptance results |
Keep secrets outside this record. The aim is reproducibility and review, not a convenient collection of credentials. Include references to approved secret locations where deployment instructions require them.
A tokenizer or template change can alter the input the model receives even when the weight files stay constant. Treat changes to the bundle as release changes and run the relevant task checks again.
Be precise about the licence claim
The Open Source Initiative's Open Source AI Definition 1.0 considers permissions and access to data information, code and parameters. A downloadable weight file alone does not establish that the whole system meets that definition.
Use the publisher's actual terms in the inventory rather than relying on a broad label such as “open”, “free” or “commercial”. Distinguish the model's terms from the runtime's licence and from any additional components you distribute.
For a concrete example, Microsoft's Phi-4-mini-instruct model card identifies an MIT licence and separately describes intended uses and limitations. That is a reason to preserve both documents in the release evidence. It is not a licence determination for a different model, a third-party conversion or an entire application built around it.
If the intended use is unclear under the available terms, record the question and resolve it with the appropriate owner before that use begins. The inventory supplies evidence for the decision; it does not replace a review of the actual terms.
Make updates reviewable
Avoid an unattended production process that always downloads whatever a mutable tag points to. Resolve the selected release to a specific revision and record the resulting digests. During an update, compare the complete bundle and its terms with the previous approved version.
Ask what changed beyond model capability. A new runtime may need another hardware backend. A conversion may use a different template. A licence file may have changed location or content. A previously documented source relationship may be missing.
Keep the old bundle available where its retention is appropriate. A rollback should restore the model, tokenizer, template and runtime combination that was validated together. Replacing only one component can create a configuration that neither release actually tested.
Check that the record is usable
In a separate test environment, rebuild from the recorded sources and revisions. Verify the file identities and run a small representative acceptance set. Have someone other than the original installer follow the record and note any assumptions they had to supply.
Keep the results tied to the exact artefact and runtime versions tested, including unresolved failures and any conditions on acceptance. The local AI privacy guide covers processing location; this release record establishes exactly what software and model artefacts operate there.
References
- Hugging Face, Model cards. Accessed 17 October 2026.
- Open Source Initiative, Open Source AI Definition 1.0. Accessed 17 October 2026.
- Microsoft, Phi-4-mini-instruct model card. Accessed 17 October 2026.