Why Imputation Provenance Must Travel With the Value
An imputed covariate may be the right value to use under a chosen imputation rule, but it is not an observed measurement. If a dataset stores only the final value, later users may be unable to tell which records were observed and which were filled in. The problem extends to variables calculated from those covariates: a derived value can look fully observed even though one of its inputs was imputed.
For example, body weight may be recorded at baseline for some participants and imputed for others. If body weight is then used to calculate body-mass index (BMI), retaining a flag only on body weight is not enough if the analysis file contains BMI but not an obvious link to its input. Provenance fields make this dependency explicit. They support review, sensitivity analyses, and accurate interpretation without replacing the covariate value itself.
A flag is metadata about a value, not a substitute for that value or a claim about its accuracy. For a simple analysis dataset, a binary flag can use 0 for observed and 1 for imputed. If a field can also be unavailable, keep that status distinct: for instance, retain a missing value with an explicit availability status rather than treating it as observed or as imputed. A more detailed provenance field can record a source category, such as measured, carried forward, or imputed by another specified rule. Use coding that can be interpreted unambiguously.
The provenance must correspond to the value actually used in the analysis record. If values are indexed by participant and time, flags must be indexed to the same participant and time. This is especially important for time-varying covariates: the earlier material on preventing look-ahead in time-varying imputation establishes that a future measurement must not be used to fill an earlier record. A flag does not make an invalid imputation valid; it makes the value’s origin traceable.
Propagating Flags Through Derived Variables
Suppose a derived covariate \(Z\) is calculated from inputs \(X_1,\ldots,X_k\). Let \(I_j=1\) if the value of input \(X_j\) used in that calculation was imputed, and \(I_j=0\) if it was observed. A direct derived-variable flag is 1 when at least one input was imputed and 0 when all inputs were observed:
For binary flags, this maximum is equivalent to the logical OR of the input flags. If a derived input already depends on imputed data, its flag must also be included. This gives a recursive rule: calculate a derived value’s flag from the provenance flags of all values on which it directly depends. Preserve the original input flags as well; a propagated flag does not identify which input was imputed.
The rule follows from the calculation itself. If \(Z=f(X_1,\ldots,X_k)\), then the stored \(Z\) is a function of the particular input values supplied to \(f\). When any supplied value was imputed, the stored result depends on that imputed value, even if the arithmetic or coding that calculates \(Z\) is deterministic. The flag describes this dependency; it does not quantify its effect on \(Z\) or assert that \(Z\) is necessarily biased.
Not every field called “derived” is a numerical transformation. A category indicator, a centered covariate, a ratio, or an interaction can all inherit input provenance. The same principle applies regardless of whether \(f\) is arithmetic, a lookup, or a recoding. Document the inputs and rule used, then apply the provenance rule consistently.
Worked Example: Imputed Weight Used to Calculate BMI
In a hypothetical baseline dataset, a participant’s height is observed as 1.70 m. Body weight is missing and is filled by the study’s selected baseline imputation rule with 68.0 kg. The BMI calculation is weight in kilograms divided by height in metres squared. Define `WT_IMP` and `HT_IMP` as binary input flags, and `BMI_IMP_DEP` as the derived dependency flag.
Input values and flags. Weight is 68.0 kg with `WT_IMP = 1`; height is 1.70 m with `HT_IMP = 0`. The weight flag records that the stored weight was imputed, while the height flag records that the stored height was observed.
Calculate BMI.
Propagate provenance.
The BMI is calculable, but it depends on an imputed weight. Its flag should therefore indicate imputation dependency. A downstream user can still distinguish the observed height from the imputed weight by inspecting the original input flags.
Examples Across Different Derived Covariates
Worked Example: Dose per Kilogram With One Imputed Input
In a hypothetical analysis record, the administered dose is 600 mg and is observed. The recorded weight is 75 kg and is imputed. The derived dose-per-weight covariate is defined as dose divided by weight. Let `DOSE_IMP = 0`, `WT_IMP = 1`, and `DOSEKG_IMP_DEP` be the derived dependency flag.
Calculate the derived value.
Propagate the flags.
The derived covariate is flagged because the denominator was imputed, even though the dose was observed and the division was performed correctly. Keeping only a weight flag would make the dependency harder to see when reviewing a dataset organized around derived covariates.
Worked Example: A Category Indicator From an Imputed Covariate
In a hypothetical dataset, a participant’s age is imputed as 17 years. A derived indicator is defined as 1 when age is at least 18 and 0 otherwise. Let `AGE_IMP = 1`, and let `ADULT_IMP_DEP` flag whether the indicator depends on an imputed input.
Calculate the indicator. Since \(17 < 18\), the derived indicator is 0.
Propagate provenance.
The indicator is 0, but its provenance flag is 1: its classification depends on the imputed age. The flag is not itself the indicator and should not be substituted for it. If age were unavailable and no imputed age were supplied, the indicator should generally remain unavailable rather than being assigned 0; missing must not be silently recoded as “not adult.”
Implementation and Quality Checks
Build the provenance fields alongside the corresponding covariates. For each input, retain its value, its observed/imputed status, and enough documentation to identify the imputation rule and source. For each derived field, document its inputs and calculation, and create a separate dependency flag. If a value can be unavailable, represent that state explicitly rather than overloading a binary imputation flag with several meanings.
Specify the participant and, for longitudinal covariates, the relevant time or occasion. Confirm that the value and its flag refer to the same record.
For each covariate, distinguish observed values from imputed values and preserve unavailable values as unavailable. Use the documented imputation rule.
Use the documented inputs and formula or recoding rule. Do not substitute missing values silently.
Set a derived flag to 1 if any input used was imputed; otherwise set it to 0 when all required inputs were observed. Keep unavailable derived values distinct.
Compare flags with source and imputation records, and verify that recalculated derived values and their provenance agree.
Useful diagnostics include checking that each imputed value has an appropriate provenance status, that observed values have not been marked imputed, and that every derived flag agrees with its inputs. Recalculate a sample of derived values from their recorded inputs and check units. For longitudinal fields, verify that the flag travels with the correct time-specific value. A mismatch between a flag and its input is a data-quality issue, even when the covariate value itself appears plausible.
Several shortcuts create avoidable ambiguity. A single dataset-wide flag cannot show which covariate was imputed. Replacing a missingness indicator with an imputation flag loses the distinction between “was missing before imputation” and “is still unavailable.” Recording provenance only for raw fields hides the dependence of derived covariates. Conversely, marking every derived field as imputed because any covariate anywhere in the participant’s record was imputed is too broad: the flag should reflect the actual inputs used in that derivation.
Choosing a Provenance Strategy
| Approach | What it tells the analyst | Main limitation |
|---|---|---|
| Store only the final covariate value | The value used in the analysis | Does not reveal whether it was observed or imputed |
| Store input-level flags | Which covariates were imputed | Does not by itself reveal whether a derived field depends on them |
| Store input flags and derived dependency flags | Which inputs were imputed and whether a derived value depends on imputed data | Requires documented input relationships and consistent updates |
| Store a detailed provenance category | Whether a value was observed and, if not, the documented source or rule | Needs a clearly specified coding scheme and careful maintenance |
Input flags plus derived dependency flags are a practical minimum when the analysis dataset includes calculated covariates. More detailed provenance can be useful when different imputation rules or sources need to be distinguished. Whatever the strategy, retain sufficient source and transformation documentation for another analyst to reproduce the value and understand its status.
Why the Distinction Matters
Provenance supports interpretation of covariates in model development and review. An estimated relationship involving a derived covariate may be based partly on observed inputs and partly on imputed ones. Explicit flags let analysts describe that construction accurately and identify records for targeted data review or sensitivity analyses. They do not, by themselves, correct for missing-data mechanisms, establish that an imputation rule is appropriate, or determine how a model should use the covariate.
A common mistake is to say, “BMI is calculated, so it is observed,” because the formula was applied directly to stored values. That reasoning confuses the calculation with the provenance of its inputs. The correction is to separate the two questions: was the derived value calculated from available inputs, and were those inputs observed or imputed? In the example, BMI was calculated, but it depends on imputed weight. A reliable dataset records both facts.
Check Your Understanding
Answer each question, then compare with the solutions below.
- A derived ratio uses an observed numerator and an imputed denominator. What should its dependency flag be, and why?
- Weight is observed and height is imputed. A derived BMI value is calculated from both. State the BMI dependency flag using the binary convention in this tutorial.
- An age value is unavailable and was not imputed. Should an adult indicator derived from that age be set to 0 or flagged as imputation-dependent?
- A dataset stores input-level imputation flags but no flags for derived covariates. What provenance information may be difficult to recover?
Solutions. (1) Set the ratio’s dependency flag to 1: the calculated value depends on its imputed denominator. (2) Set the BMI dependency flag to 1 because at least one required input, height, was imputed. The observed weight retains its own input flag of 0. (3) Neither choice is appropriate by itself: the adult indicator should be unavailable because the age input is unavailable. It was not calculated from an imputed value, so it should not be labelled imputation-dependent. Record availability separately. (4) It may be difficult to identify which calculated fields depend on imputed inputs, especially when the derived fields are stored without an obvious record of their calculation inputs.