Online/Offline Feature Parity
A feature must compute identically live and from the archive; the fabric enforces this parity so models behave the same in training and operation.
The parity contract
A model trained on archived features will only behave correctly in operation if the live features are identical in definition to the archived ones. Training-serving skew — a subtle difference between the offline and online computation of the same feature — is a classic failure that would be intolerable in a control loop. The fabric eliminates it by defining each feature once and running that one definition in both paths.
How parity is enforced
- A single versioned feature definition is the source for both online and offline computation.
- Continuous parity tests re-compute live features from the archive and assert equality within a recorded tolerance.
- Feature versions are pinned to model versions so a model always sees the features it was trained on.
- Any divergence raises an alert and blocks promotion of the feature version.
Tolerance, not luck
Bit-exact parity is the goal for deterministic features; where floating-point or hardware differences make that impossible, the fabric records a tolerance and tests against it (a two-tier parity: exact where possible, bounded elsewhere). This mirrors the program's broader reproducibility discipline.
Why it matters here
The twin's predictive shadow and the anomaly ensembles are trained offline and then act online. If the instantaneous Q or a quench precursor computed live differed from the training-time version, the twin's forecast would silently drift. Parity is what lets a model trained on breeder or burner archive data be trusted when it acts on the live machine. This is a design and MLOps discipline for machines not yet built.