Why Algebraic Consistency Matters
A derived variable is often included because it expresses a quantity already determined by other variables. If those source variables change during chained-equation imputation, a stored derived value can stop describing them. The issue is not merely cosmetic: an analysis using both the sources and the derived variable would then use a record that violates the relationship defining that variable.
Passive imputation addresses this bookkeeping problem by recalculating a derived variable from the current values of its source variables. This tutorial establishes precisely what that operation guarantees—and what it does not. In particular, a guaranteed identity within each completed record is not, by itself, a guarantee that the imputation models are statistically compatible with an analysis model.
The guarantee depends on conditions. The defining function \(g\) must be specified correctly; its inputs must have current values; and the function must be defined at those values. If the function is only defined on a restricted domain, every completed source draw must lie in that domain. Recalculation must also occur before a later operation uses \(Z_i\). Recomputing eventually, after the chain has already used a stale value, does not make that earlier operation consistent.
For simplicity, the derivation below treats calculations as exact. Software uses finite-precision arithmetic, so a computed identity may hold up to a small numerical tolerance. Rounding can also be part of the definition, but it must be applied consistently: if \(g\) includes a rounding rule, the passive calculation must apply that same rule.
Why Recalculation Guarantees the Identity
Suppose the current source values for record \(i\) at a point in the chain are \(X_i^{(t)}\), where \(t\) labels the current state. If one or more source variables are updated, the next values are \(X_i^{(t+1)}\). Passive recalculation defines the next derived value using those updated sources:
The defining identity follows directly from the assignment. The equality is not a probabilistic approximation and does not require a large number of imputations: it holds record by record whenever the calculation is made using the current inputs.
For a chained procedure, the same argument applies after each update that changes an input to \(g\). If a complete sweep changes several inputs in sequence, the derived value must track the current inputs at the points where it is used. An induction makes the logic explicit. Initially, calculate \(Z_i^{(0)}=g(X_i^{(0)})\). Assume at an update step that all derived values used by the next conditional model have been recalculated from the current source values. After an input changes to \(X_i^{(t+1)}\), set \(Z_i^{(t+1)}=g(X_i^{(t+1)})\) before the next use. Thus the identity holds at the next use. Repeating this step preserves it throughout the sequence of updates.
The key qualification is “before the next use.” If an input changes but \(Z_i\) is left untouched, the identity is not guaranteed during the interval between that update and recalculation. If another conditional model uses \(Z_i\) during that interval, the chain has used a record inconsistent with the declared definition.
Worked Example: Converting a Temperature After an Imputed Draw
In a hypothetical data set, temperature is recorded in degrees Celsius, \(C_i\), and a derived variable stores the same temperature in degrees Fahrenheit, \(F_i=1.8C_i+32\). For one record, \(C_i\) is missing. Suppose a conditional draw fills it with \(20.0\ ^\circ\mathrm{C}\).
Recalculate. Substitute the current source value into the defining function:
The completed record now satisfies the conversion identity exactly under the stated formula. Suppose a later sweep replaces the Celsius draw with \(22.5\ ^\circ\mathrm{C}\). The new Fahrenheit value must be
Keeping the earlier value \(68.0\ ^\circ\mathrm{F}\) would leave a discrepancy of \(72.5-68.0=4.5\ ^\circ\mathrm{F}\). The record would no longer satisfy the defining identity. The discrepancy is caused by a stale derived value, not by uncertainty about the conversion formula.
Updates to More Than One Input
The same reasoning applies when a derived variable depends on several source variables. Write \(X_i=(X_{i1},\ldots,X_{ip})\) and \(Z_i=g(X_{i1},\ldots,X_{ip})\). Whenever any input changes, recalculate using the current values of all inputs—not a mixture of current and earlier values.
Worked Example: Updating an Elapsed-Time Variable
Consider a hypothetical record with a start time \(S_i\) and an end time \(E_i\), both measured in minutes from midnight. The derived elapsed time is \(D_i=E_i-S_i\). Suppose the current values are \(S_i=510\) minutes and \(E_i=555\) minutes.
The elapsed time is
Now suppose an imputation update changes the start time to \(S_i=525\) minutes while the current end time remains \(555\) minutes. Recalculation gives
If the stored value remains \(45\) minutes, it was calculated using the old start time. Substituting the current values into the definition gives \(555-525=30\), not \(45\); therefore the record is inconsistent. If an update instead changes the end time, the same rule applies: use the newly updated end time and the current start time.
This example also illustrates a domain check. If the data definition requires the end time to occur after the start time, then the completed values must satisfy \(E_i\geq S_i\). The subtraction itself can be performed for other values, but recalculation alone does not ensure that those values are substantively admissible. Domain or ordering constraints must be addressed by the data and imputation specification.
The argument does not depend on the number of source variables or on a special form of \(g\). It depends on applying the declared function to the current, complete set of inputs. Algebraic consistency is therefore a property of the completed record and its calculation rule, rather than a claim about how well a statistical model describes the data.
What the Guarantee Does—and Does Not—Establish
It is useful to separate three questions. First, does each completed record satisfy the deterministic definition? Passive recalculation answers this algebraic question. Second, are the conditional imputation models suitable for the variables and their relationships? That is a modeling question, not settled by recalculation. Third, do the resulting imputations support the intended analysis and its uncertainty estimates? That requires further statistical assessment.
For example, if a derived variable is recalculated perfectly, its identity can still be statistically awkward for a chosen set of conditional models. Conversely, separate conditional models might yield plausible-looking marginal distributions while producing source and derived values that contradict their definition. Exact algebraic consistency is necessary whenever an analysis treats a variable as a deterministic function of others, but it is not sufficient evidence of good imputation.
The algebraic guarantee also does not remove imputation uncertainty. Different completed data sets may have different imputed source values and therefore different derived values. Within each data set, the derived value is fixed by its sources; across imputations, it varies because the source draws vary. It would be incorrect to interpret the fixed relationship within each record as meaning that the underlying incomplete source value was known with certainty.
Worked Example: Checking a Derived Value Across Two Completed Data Sets
Suppose two hypothetical completed data sets contain different imputed Celsius values for the same record. In the first, \(C_i=18.0\ ^\circ\mathrm{C}\); in the second, \(C_i=21.0\ ^\circ\mathrm{C}\). In both, Fahrenheit is defined as \(F_i=1.8C_i+32\).
For the first completed data set:
For the second:
Both records satisfy the identity, even though their derived values differ by \(69.8-64.4=5.4\ ^\circ\mathrm{F}\). The difference reflects different imputed source values. Recalculation preserves the deterministic relationship in each completed data set; it does not force identical imputations across data sets.
Diagnostics, Alternatives, and Failure Modes
A direct diagnostic is to calculate the residual from the defining identity for every completed record:
With exact arithmetic and an exact calculation rule, each residual should be zero. In software, check that \(|r_i|\) is no larger than a tolerance appropriate to the measurement scale and numerical precision. A nonzero residual may reveal a stale value, a wrong formula, inconsistent units, an incorrect rounding rule, or a mismatch between the inputs used to calculate \(Z_i\) and the inputs currently stored. A zero residual checks the identity; it does not validate the imputation models or the scientific definition of \(g\).
The main alternatives differ in when, or whether, the derived quantity is calculated:
| Approach | Identity in completed records | Main consideration |
|---|---|---|
| Recalculate passively after source updates | Maintained if the function is correct, defined, and recalculated before use | Requires tracking the inputs and refreshing the derived value at the right time |
| Impute the derived variable separately | Not guaranteed | A separate draw can disagree with the value determined by the sources |
| Calculate the derived variable only for final analysis | Not maintained as a stored variable during the chain | May be sufficient if no imputation step uses the derived variable and it is calculated from final completed sources |
Separately imputing \(Z_i\) treats it as though it could vary independently of its defining inputs. That may be appropriate only if the recorded quantity is not truly deterministic—for example, if it has its own measurement error and is not defined as exactly \(g(X_i)\). In that case, the model should represent the measurement process rather than imposing a deterministic identity.
Calculating \(Z_i\) only after imputation can avoid maintaining a stored passive variable during the chain, but it cannot serve a procedure that needs \(Z_i\) earlier. The choice therefore depends on how the variable is defined and when it is used. Whichever approach is chosen, a deterministic identity should not be silently treated as both exact and optional.
Common Mistakes and Practical Checks
- Updating a source but keeping the old derived value. A value calculated from \(X_i^{(t)}\) generally need not equal \(g(X_i^{(t+1)})\). Recalculate after every relevant change.
- Recalculating at the wrong time. Updating at the end of a sweep is too late if a conditional model in the middle of that sweep uses the derived variable.
- Using mixed-time inputs. If \(g\) has several inputs, calculate it from all of their current values, including inputs updated earlier in the same sweep.
- Assuming recalculation fixes model incompatibility. It guarantees the declared identity only. It does not establish that the conditional models, analysis, or uncertainty assessment are appropriate.
- Ignoring conflicting observed values. If an observed \(Z_i\) disagrees with \(g(X_i)\), retaining both as exact values is impossible. Check units, coding, rounding, and data errors; do not silently claim that passive recalculation preserves both. If the discrepancy reflects measurement error, the deterministic definition may not be the right model.
- Ignoring an undefined or inadmissible input. If \(g\) is undefined at an imputed value, recalculation cannot produce a valid \(Z_i\). The input domain and any substantive constraints must be considered in the imputation setup.
A practical audit asks, for every deterministic derived variable: What are its inputs? What exact function defines it? Which updates can change those inputs? Is it recalculated before every use? Is it defined for all completed values? Finally, do the completed records satisfy the identity within a stated numerical tolerance? These checks assess algebraic consistency without confusing it with broader statistical adequacy.
Check Your Understanding
Answer each question, then compare your reasoning with the solutions.
- A derived variable is \(Z_i=4X_i-1\). An imputed update changes \(X_i\) from 3 to 5. What must the new \(Z_i\) be, and what stale value would result if it were not recalculated?
- For \(Z_i=g(X_{i1},X_{i2})\), explain why recalculating after an update to \(X_{i1}\) must use the current value of \(X_{i2}\), even if \(X_{i2}\) was not changed in that update.
- Does a zero residual \(Z_i-g(X_i)\) prove that the imputation models are statistically compatible with an analysis model? Explain.
- What should be investigated if an observed derived value conflicts with the value computed from its observed sources?
- When can calculating a deterministic derived variable only after imputation be adequate?
Solutions. (1) The new value is \(4(5)-1=19\). The old value was \(4(3)-1=11\), so retaining it would violate the identity by \(19-11=8\). (2) The definition depends on both inputs, so the correct value is \(g(X_{i1}^{\mathrm{current}},X_{i2}^{\mathrm{current}})\); using an older value of either input can produce a stale result. (3) No. A zero residual verifies the algebraic identity for that record, not the statistical adequacy or compatibility of the models. (4) Check the definition, coding, units, rounding, and possible data errors. If the discrepancy is genuine measurement error, reconsider whether the relationship should be treated as deterministic. (5) It can be adequate when no imputation step needs the derived variable and it is calculated from the final completed sources before the analysis.