Feature Store for Plasma and Diagnostic Signals

A shared feature store guarantees that the features a model saw in training are the exact features it sees in production, eliminating training-serving skew.

One definition, two read paths

The most common silent failure in deployed ML is training-serving skew: a feature computed one way offline and a subtly different way online. Kronos eliminates it with a feature store that defines each plasma or diagnostic feature once, then serves it through two backends: a batch path for L0 training and a low-latency path for the online layers. Both execute the same definition.

Features are versioned objects. A change to how normalized plasma current or plug field ratio is computed produces a new feature version; models pin the feature versions they were trained on, so a redefinition never silently changes what a deployed model consumes. Backfills recompute historical values so training sets stay internally consistent.

Example feature definitions

• Breeder: q95, normalized beta, Greenwald fraction, elongation, triangularity vs delta -0.30 target
• Burner: mirror ratio, plug field toward 26.49 T, ambipolar potential estimate, neutron fraction vs 5.44% design
• Shared: coil temperature margins, diagnostic health flags, control error integrals

@feature(name='breeder.greenwald_fraction', version=3,
         inputs=['ip_MA','a_minor_m','n_e_line_1e20'])
def greenwald_fraction(ip_MA, a_minor_m, n_e_line_1e20):
    n_gw = ip_MA / (math.pi * a_minor_m**2)   # 1e20 m^-3 units
    return n_e_line_1e20 / n_gw
# same code path: batch (L0 train) and online (twin serving)

The store is the boundary object between data lineage and live serving; feature versions become part of the model's lineage. It also gives drift monitors a natural place to attach reference histograms, since every monitored quantity is already a named, versioned feature.