Making Preprocessing Steps Deterministic

Why Deterministic Preprocessing Matters

MICE operates on variables as they are represented in the input data. Before imputation, a workflow may convert special numeric codes to missing values, define categorical variables, or transform a skewed measurement. If those steps depend on row order, observed values, or undocumented software defaults, two runs that appear to use the same data can give MICE different inputs. Reproducibility therefore requires more than saving a random seed: the preprocessing rules themselves must be explicit and repeatable.

This tutorial concerns the construction of a fixed MICE input from a specified raw data set and preprocessing specification. It does not imply that MICE is deterministic: imputation may involve random draws, and its results also depend on the imputation configuration and random-number handling. The earlier material on Using Configuration Files for Imputation Runs provides a place to record settings; here the focus is on making the transformations those settings describe unambiguous.

Determinism is a property of the rule and its inputs, not a claim that the rule is statistically appropriate. For example, a fixed but incorrect recoding is perfectly repeatable. The analyst must therefore justify each rule using the variable definition and data provenance, then make the implementation match that rule.

Specify Operations Before Applying Them

A preprocessing specification should answer three questions for each variable: which raw values are valid, what action is taken for each value or category, and how is the resulting variable represented? Avoid letting software infer answers from the values that happen to be observed in one run.

• For special missing codes, state exactly which codes are converted to missing and whether they apply to the whole variable or only under a defined condition.
• For categorical variables, state the complete permitted set of levels, their order, and any reference category used by a model.
• For numerical transformations, state the formula, the domain on which it is defined, and any constants or rounding rules.
• State how unexpected values are handled. A clear error is often safer than silently creating a new category or leaving an invalid value in place.

These choices should not depend on “first value encountered,” automatic alphabetical sorting, or the categories present in a particular batch of rows. Nor should a transformation silently estimate a new constant from each run when a fixed constant is intended. If a rule genuinely uses a data-derived quantity, its data source and calculation must be specified; the resulting operation is not a fixed row-wise map.

Fix Factor Levels and Their Order

A categorical variable is more than a collection of labels: software may use its level order when constructing model matrices, selecting a reference category, or displaying summaries. If levels are inferred from whichever categories occur in the current data, a category absent from one subset may disappear. If ordering is inferred from first appearance, shuffling rows can change the order. Both behaviours can alter the representation supplied to an imputation model even though the underlying category labels have not changed.

Declare the allowed levels from the variable definition, rather than discovering them afresh from each processed data set. If a model uses a reference level, name it explicitly and verify that it is among the declared levels. A level with no observations is not thereby evidence that its definition should be discarded; however, an empty or sparse category may cause model-fitting problems that need separate diagnosis.

Make Transformations and Constants Explicit

A transformation should specify both its mathematical operation and how it handles values outside the operation’s domain. For example, the logarithm \(\log(x)\) is defined for \(x>0\). If zero or negative values are possible, the preprocessing rule must say whether they are invalid, represent a special code, or require a different justified transformation. Silently producing undefined values is not a reproducible handling strategy.

Standardization is another common source of variation. Given a fixed reference mean \(a\) and positive scale \(b\), the standardized value is \(z=(x-a)/b\). The values \(a\) and \(b\) must be stated if the transformation is intended to be fixed. Recomputing a mean and standard deviation on each data set defines a different operation, potentially yielding different transformed values. Whether constants should be fixed or estimated is a substantive design decision, not a software default to leave undocumented.

Why Row-Order Invariance Follows from a Fixed Rule

For a purely row-wise preprocessing rule, order invariance is straightforward to justify. Let the raw rows be \(x_1,\ldots,x_n\), and let a fixed rule \(f\) apply the same specified mapping to every row. The processed sequence is \(f(x_1),\ldots,f(x_n)\). If a permutation \(\pi\) reorders the raw rows, processing afterward gives \(f(x_{\pi(1)}),\ldots,f(x_{\pi(n)})\). That is exactly the original processed sequence in the same permuted order.

Thus, a fixed row-wise rule commutes with reordering: it does not create a different value for a row just because that row moved. This justification assumes the mapping is fixed and does not use row position, the order of first appearance, or a quantity recalculated from the changing data. Operations that estimate quantities from the whole data set need their own specification and checks; the simple argument above does not establish their invariance or appropriateness.

Diagnostics, Alternatives, and Limitations

Useful diagnostics include comparing the processed data from repeated runs, checking that row-wise outputs match after aligning records by a stable identifier, and summarizing values before and after each recode or transformation. For categorical variables, inspect the declared level list, counts by level, and the intended reference category. For numerical variables, check the range and the number of values outside each transformation’s domain. Unexpected levels, remaining sentinel codes, changed reference categories, and unexplained new missing values are warning signs that preprocessing is not behaving as specified.

A common mistake is to assume that setting the same random seed guarantees identical MICE inputs. The seed controls random-number use; it does not fix a factor whose levels depend on row order, or a transformation whose constants are recalculated differently. The correction is to make preprocessing explicit and test it separately. Conversely, identical preprocessing does not guarantee identical imputations if software versions, imputation settings, or random streams differ.

There are two broad alternatives to implicit defaults. One is explicit rule-based preprocessing, which is generally easiest to audit and reproduce. Another is data-adaptive preprocessing, in which categories, cut points, or scaling constants are estimated from observed data. Data-adaptive choices can be appropriate, but must specify exactly which data determine them and how they are computed. Their implications for the imputation workflow require careful assessment; they are not interchangeable with fixed rules. This tutorial does not address whether a particular transformation is scientifically suitable or how to prevent information leakage.

Deterministic preprocessing also has limits. It cannot correct an inaccurate variable dictionary, establish that a missing-value code was used consistently, or guarantee that a chosen transformation fits the scientific question. Nor does an order-invariance test prove that all possible inputs are handled correctly. Test representative edge cases, including sentinel values, unexpected categories, missing values, and transformation-boundary values. A clear failure on an invalid input is often preferable to a plausible-looking but incorrect MICE data set.