Model State Contract

A model state contract records what must be saved, restored, and compared when a paper, project, or experiment claims a trained model result. A checkpoint is not only weights.

The reproducible training state is:

where are model parameters, is optimizer state, are hyperparameters, is random state, is data-loader or sampler state, and is code/config context.

State Types

StateMeaningExample
Parameterslearned tensors updated by gradient descentweights, biases, embeddings
Buffersnon-gradient model tensorsBatchNorm running mean, running variance
Optimizer stateupdate memorymomentum, Adam first/second moments
Scheduler statelearning-rate timelinewarmup step, decay step
Hyperparameterschosen settings, not learned by the updatelearning rate, batch size, loss weights
Random statestochastic process positionseed, RNG state, sampler state
Data stateorder and identity of examplessplit version, epoch, shard, cursor
Code/config stateexecution contextcommit, environment, model config

Parameter vs Hyperparameter

Parameters are optimized by the training objective:

Hyperparameters choose how training happens:

Changing creates a different candidate model. If is selected using validation data, the final test claim must account for that selection boundary.

Checkpoint Contract

FieldRequired Question
Model weightswhich architecture and parameter tensors are saved?
Buffersare non-gradient state tensors included?
Optimizercan training resume with the same update dynamics?
Scheduleris the current learning rate and schedule position restored?
Step countis the checkpoint indexed by optimizer step, sample count, token count, or epoch?
RNG statecan stochastic training or sampling be resumed?
Configare architecture, tokenizer, featurizer, loss, and data paths versioned?
Data splitis the train/validation/test split identity recoverable?
Artifact linkare metrics, predictions, and logs tied to the checkpoint?

Paper Reading Use

When a paper reports a checkpoint or released model, separate:

ClaimNeeded State
best validation scoreselection rule, validation metric, candidate set
final test scoreselected checkpoint and untouched test protocol
fine-tuned resultbase model identity, adapter/full-weight state, fine-tuning data
reproducibility claimcode version, config, seeds, data split, environment
efficiency claimbatch size, precision, hardware, sequence length, step count

Failure Modes

  • Only weights are saved, but optimizer/scheduler state is needed for resume.
  • The best checkpoint is chosen on test performance.
  • Metrics are logged without linking to the exact checkpoint.
  • Seeds are recorded, but data split or sampler order is not.
  • Fine-tuning notes omit whether the base model, adapters, or full weights changed.
  • A released model lacks the preprocessing, tokenizer, featurizer, or coordinate policy.