QML validation and training controls

Purpose and scope

Expresses when training validates, when it stops and which parameter state is retained as the best checkpoint. Choices otherwise hidden in a UI become reproducible source contracts.

Core design rules

• Validation frequency, early stopping and learning-rate controls in train are evaluated within a bounded deterministic contract.
• The initial executable scope uses frozen train/validation splits of embedded supervised datasets.
• Restoring the best validation parameters within one run is distinct from a durable checkpoint artifact.

Example from the original

This example illustrates the design recorded in the original. It is not by itself a claim of executable or stable support; check required options and the current version.

module qml_training_controls;
param theta: Angle = 0.1;

fn main() {
  let q: QReg<2> = qreg[2];
  encode(sample_row(), q, method: "reupload");
  CNOT(q[0], q[1]);
  X(q[1]);
  Ry(q[1], theta);
  let cost = expect Z(q[1]);

  train {
    objective: minimize cost;
    optimizer: adam(lr = 0.2);
    steps: 40;
    loss: cross_entropy;
    dataset: xor_2d;
    validation: split = validation, every = 5;
    early_stopping: metric = validation_loss, patience = 3, min_delta = 0.001;
    scheduler: step(every = 10, factor = 0.5, min_lr = 0.01);
    checkpoint: best(metric = validation_loss);
  }
  return cost;
}

Limits and interpretation

• General data loading, distributed training and arbitrary optimization infrastructure are outside this slice.
• Lower validation loss alone does not demonstrate superiority to a classical baseline or real-world generalization.

Status and implementation boundary

The source records a runtime-experimental slice. Consult NM-RFC-0009 for durable continuation and examine dataset split and evaluation limits before interpreting results.