Kaldi online2 Streaming Decoder and nnet3 Models: Adapt Features at Runtime or Fail on Pipeline Mismatch?

Kaldi's online2 decoder performs streaming recognition by extracting features on the fly, and it relies on the acoustic model having been trained with a matching feature configuration — the same feature type, dimensionality, and normalization treatment. When an nnet3 model is loaded, the feature options stored alongside it act as the contract the live pipeline must satisfy, and a mismatch aborts decoding rather than being silently tolerated.

The open integration question sits at this boundary. nnet3 recipes keep feature options in the model directory, but there is no runtime mechanism that reshapes or renormalizes incoming streaming features to satisfy a model whose pipeline differs — for example, when decoding uses binaries built from a different Kaldi revision, or normalization options the decoder build predates. A runtime adapter has been proposed as a graceful-degradation path, but whether it belongs in the decoder, and how it should behave, remains unresolved.

Specific questions:

• Should online2 adapt streaming features at runtime to match a model's stored configuration, or should pipeline mismatches remain hard failures?
• Where is the supported compatibility boundary between online2 binaries and nnet3 models trained under different Kaldi revisions?
• If adaptation is added, how should the decoder signal that recognition ran on adapted rather than native features?