Model family, checkpoint, and version: keep the record precise
The useful unit of a model fact is a specific artifact or documented endpoint at a specific point in time. A family name alone is too broad for a performance or compatibility statement.
Use a compact identity record
For a local checkpoint, save the repository, revision, weight variant, tokenizer or processor, runtime version, and configuration. For a hosted endpoint, save the provider, model identifier, documented version if available, request settings, and test date. Mark a provider-controlled version as unspecified when you cannot pin it.
Avoid accidental transfers
A claim about one checkpoint does not automatically apply to a smaller variant, quantized copy, fine-tune, API endpoint, or later release. A shared name also does not establish that two organizations have identical responsibilities.
When sources disagree, retain both statements with their URLs and dates. Look for a release note or explicit owner clarification. Until that resolves the difference, label it as an open question rather than silently choosing the more favorable description.
A useful change log
| Changed item | Follow-up |
|---|---|
| Weights or revision | Recheck task results and compatibility |
| Runtime or processor | Recheck output format and reproducibility |
| API alias | Record the date and check version documentation |
| Model card or license | Preserve the updated source and review affected claims |
Read the model-card guide for the fields behind this record. This is a documentation method, not a claim about any particular model.