Internal repositories and model stores

Internal repositories become authoritative

Disconnected builds must not search uncontrolled sources at build or run time. Define internal repositories for each artifact class: container images, operating-system packages, language packages, models and tokenizers, datasets, charts or manifests, policies, and configuration. A repository is authoritative when it is the only source a build or deployment is permitted to resolve from — not merely a convenient mirror alongside the public internet.

Repository design

Document:

• Namespace and naming rules, immutable identity, metadata, and lifecycle state.
• Which sources may publish, promote, consume, deprecate, or delete, and under whose authority.
• How dependencies are closed over, and how a missing dependency fails — silently substituting an external source is not an acceptable failure mode.
• Isolation between quarantine, staging, and approved channels, so an unreviewed artifact cannot be resolved by a production build.
• Retention, replication, backup, restore, capacity, and integrity verification.
• Revocation, and how consumers are prevented from selecting revoked content once it is marked unsafe.
• Export and portability needed for recovery or a future platform change — see Portability, reversibility, and exit.

Prefer immutable versions and digest pinning over mutable tags. A mutable tag may still be useful as a discovery aid, but it must resolve to the identity recorded by the release, and that resolution must be logged.

Models need more than object storage

A model store should connect weights and tokenizer to license, provenance, evaluation, runtime compatibility, serving configuration, approval scope, and known limitations. Storing a model file without this decision context turns later use into guesswork — a future consumer has no way to know whether the file in front of them was ever actually approved for the purpose they intend.

Test repository unavailability, corruption, restore, expiry, and revocation directly, not only in design review. A local mirror is not authoritative until its governance and operational ownership are explicit and its failure behavior has been exercised.