CCIR portability

The complete container is organised around a declared runtime profile. Its index binds logical assets to exact identities, lengths and digests: model weights, tokenizers and processing dependencies; authored identity and settings; retained memory; policy assets; and recovery state. A media profile includes its required encoders, projectors or specialist models.

These components form a dependency graph. The model needs its processing assets; memory retains its source references, revisions and scope; the checkpoint agrees with the replay representation. Packaging that graph makes the saved runtime usable without reconstructing its contents from the original component directories.

Provenance and licences accompany the required assets. File inspection can examine the container and its requirements without launching a model or loading native code. Activation is the subsequent decision that the complete set of required components is present, supported and permitted on this destination.

The running GPU remains authoritative while the disk drain maintains the CCIR mirror behind it. The drain acknowledges a generation when its required state and assets are represented coherently. Device progress and the durable file position are reported separately, giving the operator a precise boundary for recovery or transfer.

A complete runtime capture occurs at a supported completed-work boundary. Checkpoint publication agrees with the corresponding complete journal boundary, so the saved generation describes one state rather than a mixture of moments from a changing runtime.

The file has its own capacity and persistence conditions. A failed write or exhausted allowance is reported without acknowledging an unsaved generation. Active state may have progressed further than the last successful save; retained replay history also occupies space independently of the current active memory set.

A destination provides an installed compatible AOTX runtime, CUDA driver and suitable device. Its supported profiles, state formats and execution paths must meet the container's requirements, and the selected models and state must fit its available resources.

Activation validates the dependency graph, reconstructs logical state and establishes the complete-file persistence path before admitting new work. Required cognitive assets come from the container, so the original model directories can remain unavailable and those dependencies need not be downloaded again.

Machine-local resources are established afresh. GPU addresses and execution caches belong to the new device process; network connections, credentials and tool permissions belong to the new deployment. The saved logical state connects the two environments without attempting to migrate an arbitrary CUDA instruction or open socket.

A running CCIR has one authoritative writer. Participants can connect to that same instance through their granted scopes and contribute to one continuing history. This is the shared-service arrangement: multiple clients, one runtime authority.

A copied generation has a different purpose. Activating it on another host starts an independent continuation from the saved boundary. This supports transfer, recovery or a deliberate branch of the runtime's history. If both copies continue, their later changes belong to separate histories; the format does not automatically reconcile independent writers.

Operation receipts retain their meaning after transfer. A saved terminal result can be returned as the recorded outcome. An admission without a saved terminal result is restored as interrupted, leaving further work to a new explicit operation. External effects and earlier replies are not silently repeated to fill that gap.