nnet3 decode fails in production after moving a working Kaldi chain recipe: i-vector input mismatch

A Kaldi chain/TDNN acoustic model decodes correctly inside the original recipe directory, but the same model fails when deployed in a separate production pipeline. The nnet3 decoding binaries abort with low-level errors around the i-vector input — missing final.ie or a feature-dimension complaint from the nnet3 computation — rather than any explicit configuration diagnostic.

The production setup reuses the recipe's final.mdl and decoding graph, but the feature frontend and i-vector extraction were re-implemented outside the recipe scripts. Known constraints: the decode-time MFCC configuration, CMVN handling, and splice options must match training exactly; the ivector_extractor directory contents must be the ones the model was trained with; and the graph, model, and phone symbol table must come from the same training tree. The production path also needs to decide between offline per-utterance i-vector extraction and online estimation via the online2 binaries, since the recipe used offline extraction.

Which specific mismatch most commonly causes this class of failure when a recipe is moved to production: the MFCC/CMVN frontend config, the i-vector extractor splice options, or a graph/model provenance mismatch?

Does switching from offline to online i-vector extraction require any change on the model side, or only in the decoding pipeline configuration?

What is the most reliable way to verify configuration equivalence between the recipe and the production pipeline before decoding?