The container is the runtime map
A conventional checkpoint is optimized for interchange or training frameworks. A Minirun container adds the structure a storage-native runtime needs: a complete inventory, stable model metadata, and addressable regions organized around how the model is consumed.
The container does not make every architecture identical. Dense layers, routed experts, recurrent components, and multimodal modules can require different physical layouts. Their adapters interpret model-specific structure while the storage core continues to enforce exact ranges and bounded transfer semantics.
This page explains what the runtime needs from a container. The format itself — the repository layout, the index document and its three shapes, the MNRNTIL1 tile container, its quantization modes and feature flags, and which authority decides completeness — is specified in full on its own page.
Addressability
Addressability means the runtime can identify the stored bytes for a logical model region before it reads them. Offsets, lengths, element layout, and container metadata are checked before the region enters a compute path. Invalid or overlapping ranges are rejected explicitly.
The layer, expert, or global tensor requested by the adapter.
Maps the logical identity to a checked file range and layout.
Reads only the validated range into planned memory.
Hands the decoded region to the model-specific execution path.
Completeness and verification
A publication is complete only when the authoritative repository file set and the local copy agree, and completeness and content have separate authorities: the repository's pinned file list decides which paths must exist, while the digest tree decides what each of them must contain. The artifact's own index is a reconciliation claim it makes about itself, not an authority over either question.
A verified result is not a transferable label attached to a folder name. It is evidence for one publication and one set of local filesystem objects. Replacing bytes in place or substituting a different directory causes that evidence to stop matching.
Container support and runtime support
The app may understand enough of a container to list, size, and verify it while still lacking the runtime needed for chat. This is useful for future model families: storage management remains honest without promising execution that has not been integrated.
- Discover
- A recognizable Minirun repository or local container is enough for the app to make the model visible.
- Verify
- The app needs a complete authoritative tree and a container layout it can validate without guessing.
- Run
- Execution additionally requires full local verification, a compatible model adapter, tokenizer or media pipeline, runner, and device.