Preserving Raw Data and Tracking Provenance

Why Provenance Matters for Imputation

A MICE analysis depends on the data that entered preprocessing and on the choices made before imputation. If a source file is overwritten, replaced by a similarly named file, or changed during a transfer, a later analyst may be unable to determine which data produced a reported result. A project can have orderly scripts and still lack a reliable answer to that question.

The earlier material on Structuring a Reproducible MICE Project provides the broader project structure. Here the focus is narrower: preserve the original files, record their origins and relevant dates, and connect each imputation run to the exact input-file contents. This is an operational safeguard, not a statistical method; it does not establish that the data are accurate or that the imputation model is appropriate.

Keep Source Files Separate From Analysis Files

Treat a file received from a data provider, repository, or colleague as a source artifact. Preserve it unchanged in a designated raw-data location, preferably one that ordinary analysis scripts cannot overwrite. Do not use that copy as a scratch file: import it, then write any cleaned or transformed data to a separate location. The resulting directory structure might distinguish raw, intermediate, and analysis-ready files. The exact names are less important than maintaining a clear boundary between the source and its descendants.

“Unchanged” has a practical meaning: do not edit, resave, rename in a way that loses identity, or replace the preserved source file. If a provider sends a corrected file, retain both versions as separate artifacts and record which one supersedes the other. Record the original file name as received, even if a stable project file name is also assigned. Preserve an independent backup when feasible; a checksum can reveal that a file changed, but it cannot restore the original bytes.

For each source file, record its origin and the date it was obtained. Also record the modification date reported by the source, if available, and the file size. These are different facts. An acquisition date describes when your project received or accessed the file; a modification date may describe a timestamp set by the provider or file system. Copying, downloading, or archiving a file can alter file-system timestamps, so a date alone does not identify file contents.

Make a File Manifest

A manifest is a compact, human-readable record of the files associated with a project or run. For each input, include enough information to locate it and check its identity. A useful record includes the project-relative path, source name, origin, acquisition date, source-reported modification date if known, size in bytes, checksum algorithm, and checksum value. Note unknown information as unknown rather than guessing.

Use a cryptographic hash over the exact file bytes. For example, SHA-256 produces a 256-bit digest, usually written as 64 hexadecimal characters. The digest is not a summary of the file's statistical content: two files with the same rows but different encoding or line endings can have different digests. That is expected, because the files are not byte-for-byte identical.

This notation expresses the checksum operation, not a statistical model. Its practical value relies on the hash algorithm being deterministic and collision-resistant: for distinct files, a matching digest is extraordinarily unlikely under ordinary use, but not logically impossible. A digest should therefore be used to check identity, not treated as proof of origin, accuracy, or authenticity. If an attacker can replace both a file and its manifest, an unsigned manifest alone does not protect against that deliberate change.

Connect the Manifest to Each MICE Run

A project-level manifest identifies files that exist in the project; a run-level record identifies which exact inputs a particular analysis used. The distinction matters when a project contains several source versions or when preprocessing creates a new data file. A run record should point to the input artifacts actually read by the analysis, including relevant derived files, and record their checksums. It should also identify the run unambiguously, for example with a run label and date, and refer to the analysis code or project revision used.

If preprocessing converts a raw export into an analysis-ready data set, record that output as a separate artifact with its own path and checksum. The provenance record should make the connection explicit: which raw file was read, which preprocessing step produced the derived file, and which derived file entered the MICE workflow. This records the chain without making the raw file appear to be the direct input when it was not.

Justification: Why a Checksum Detects a Changed Input

A checksum is useful because it maps a potentially large file to a compact digest in a reproducible way. If the input bytes are unchanged and the algorithm is the same, the computed digest is the same. If bytes change, the hash's design makes a digest change overwhelmingly likely. For SHA-256, there are \(2^{256}\) possible digests; this large output space makes accidental collisions negligible for routine file verification, although no finite digest can uniquely encode every possible file.

The second implication is deliberately probabilistic, not absolute. The number of possible files exceeds the number of 256-bit digests, so collisions must exist in principle. For ordinary provenance checks, a well-established cryptographic hash is a practical way to detect accidental changes. For stronger protection against deliberate tampering, restrict write access and preserve the manifest in a protected or independently controlled location; a checksum stored beside a mutable file can be changed along with it.

Diagnostics, Alternatives, and Limits

When verification fails, treat the mismatch as a signal to investigate, not as a minor warning to dismiss. Check whether the run is pointing to the intended path, whether a file was overwritten, whether a transfer or archive process altered it, and whether the recorded checksum was computed with the stated algorithm. Compare the file size and available source records. If an intentional correction or transformation explains the difference, preserve the new artifact and document its relationship to the old one; do not edit the old digest to make the check pass.

Checksums complement, rather than replace, other provenance tools. File names are easy to read but can be reused for different contents. Modification dates are convenient clues but can change during copying and may not be trustworthy. Backups can restore a file but do not by themselves identify which version was analyzed. Version control can help track scripts and small text files, but is not a substitute for a data manifest or an appropriate archive for large or sensitive data. A manifest is especially useful for connecting file identity with origin and run context; a checksum alone cannot supply that context.

A byte-level checksum also has a deliberate limitation: harmless formatting changes produce a different digest. Re-saving a table with a different line ending, encoding, or column order may change the bytes even if the records appear equivalent. Do not respond by ignoring the mismatch or replacing the original checksum with a checksum of a normalized version. Preserve the source checksum, then, if a normalized artifact is needed, save it separately and record its own checksum and transformation. This keeps “same bytes” distinct from “same interpreted data.”

Provenance records can be incomplete or misleading if entered carelessly. A checksum computed only after a source file has already been modified cannot show what the original contained. A correct digest attached to the wrong file name still misidentifies the input. A file may be accurately tracked but contain incorrect or incomplete data. Provenance supports auditability and reproducibility; it cannot certify data quality or resolve statistical assumptions about missingness.

Common Mistakes

• Editing the raw file and calling it the source. Keep transformations in separate outputs so the received artifact remains available for verification.
• Using a timestamp as proof of identity. Dates can be altered or changed by copying. Record them as context, and use a checksum to compare exact bytes.
• Updating a manifest in place after a mismatch. Preserve the earlier record and document a new artifact or a correction. Otherwise, the record no longer explains what an earlier run used.
• Assuming a matching digest proves the data are correct. It identifies bytes relative to a recorded digest; it does not validate content, origin, preprocessing, or analysis.
• Checking only the original source when the run reads a derived file. Record and verify every relevant file actually used as input, including processed data.