The data pipeline is part of the decision.

The model did not change. The system did.

When an AI result shifts, teams often begin by asking which model version changed. That is an important question, but it is not the only one. The model can remain identical while the source data, reference set, filters, transformations, retrieval index or prompt assembly changes underneath it.

The result may look like model drift even when the movement began earlier in the pipeline. If governance records only the model name and final output, the most consequential change can disappear between those two points.

The practical lesson is simple: the data pipeline is part of the decision system. It should be versioned, reviewed and tested as such.

Genomics learned to preserve the path

Bioinformatics makes this problem easy to see. A genomic result depends on more than an analysis method. It also depends on the reference sequence, data version, quality-control choices, preprocessing steps, workflow definition and compute environment. Change one of those, and the interpretation can change even when the final analytic code is untouched.

The Global Alliance for Genomics and Health describes its Workflow Execution Service as a standard protocol for running the same genomic workflow in different environments. Its refget work addresses reliable identification of reference sequences because reproducible analysis depends on clear provenance back to reference data. These are not AI-governance rules. They are useful engineering precedents: preserve enough of the path that another authorized reviewer can understand what actually ran.

Govern transformations, not just endpoints

NIST's current AI RMF Playbook asks organizations to document data provenance, including sources, origins, transformations, augmentations, labels, dependencies, constraints and metadata. Its GOVERN guidance also points to inventories, data dictionaries and change-management policies. NIST notes that AI RMF 1.0 is being revised, so any implementation should date the framework version it uses.

For a production AI system, that means linking the decision record to the exact pipeline state: source snapshot, reference data, preprocessing code, feature and exclusion rules, augmentation, retrieval corpus and index, prompt construction, model and tool versions, policy version, reviewer and observed effect.

This is more than technical lineage. Each transformation can carry authority conditions. Data may be permitted for one purpose but not another. A filter may protect privacy while changing representativeness. A retrieval update may improve freshness while introducing a source whose use has not been approved.

Run a pipeline-change test

Take one bounded workflow and hold the model constant. First replay it with the approved pipeline state. Then change one element at a time: the reference dataset, a preprocessing rule, an exclusion threshold, the retrieval index or the prompt assembly step.

Compare more than output similarity. Measure legitimate task completion, unsupported claims, material decision changes, reviewer disagreement, correction acceptance and the time required to reconstruct the cause. Record proposed actions, control decisions and independently observed effects as separate events.

The goal is not to freeze data forever. A governed system must accept better evidence and discover that an earlier decision was wrong. The goal is to make change visible, attributable and reversible instead of allowing the pipeline to rewrite the decision boundary silently.

A research and building principle

My work in genomics is part of the foundation for how I think about accountable AI systems today. The current AI-governance program includes architecture work and proposed evaluations; this article does not claim new measured performance.

The building principle is direct: if a decision matters, preserve the pipeline that produced it. Before blaming the model, ask whether the data path changed—and whether an authorized reviewer can prove where, why and with what consequence.