The Audit Test: Can You Explain One Decision End-to-End?

A Single Request

This article asks one thing of you. Not a strategic review. Not an organizational assessment. Not a working group or a framework evaluation or a gap analysis that will take three months and produce a report that will be reviewed and filed.

One thing.

Pick a decision, a specific, consequential determination that your organization's AI system has made or materially influenced in the past ninety days. A credit assessment. A risk score. A clinical recommendation. A hiring determination. A fraud flag. A pricing output. A resource allocation. Whatever decision your AI system exists to produce or inform, pick one instance of it. A real one, from the recent past, with a real output that was used in a real context by real people.

Now explain it.

Not how your system is designed to work. Not what your process documentation says should happen. Not a representative account of how decisions of this type are generally produced. This specific decision. This specific output. How it was produced, from the beginning of the chain to the end of it, with verifiable evidence at every step.

That is the audit test. It is deceptively simple. It is the test that regulators will apply to your AI systems, that legal challenges will impose on your organization, and that rigorous auditors will use to assess whether your governance is real or merely present. And it is the test that most organizations, when they attempt it honestly, cannot pass in full.

Work through it now, with your organization's actual systems in mind. The stages that follow are not rhetorical. They are a sequential probe of the chain that produced your chosen decision. At each stage, there is a question. Answer it, not with what you believe to be true, but with what you can demonstrate to be true with documentation that currently exists.

The difference between those two things is what this article is about.

Stage One: Data Origin and Provenance

Your AI system produced an output. That output was shaped, before the model ever touched it, by data. The first stage of the audit test is to account for that data completely.

The question: For every data input that contributed to this specific decision, can you identify its origin, the source system, the collection method, the point in time at which it was gathered, and produce documentation confirming that origin that was created at the time of collection, not reconstructed afterward?

This is more demanding than it sounds. Most organizations can identify their data sources at a general level. They know which systems feed their AI pipelines. What the audit test requires is not general knowledge of sources but specific, documented provenance for the data that shaped this specific output, evidence that the data came from where it is assumed to have come from, was collected in the way it is assumed to have been collected, and was current and complete at the point it entered the pipeline.

Adequate evidence at this stage looks like: source system documentation with version and timestamp, data extraction logs showing what was pulled and when, data quality assessments performed at the point of collection, and documented confirmation that the source system itself was operating within its normal and validated parameters at the time of extraction. It does not look like: a general data dictionary describing the sources your pipeline typically uses, an assumption that the source system was functioning normally because it has not flagged any errors recently, or a statement from a team member that the data comes from the system it has always come from.

If your provenance documentation exists at the general level but not at the specific level this stage requires, you have found your first gap. Note where the documentation stops and the assumption begins. That boundary is the first edge of your governance ceiling.

Stage Two: Transformation and Preparation

Data does not move from its source into your AI model unchanged. It is filtered, cleaned, normalized, joined to other sources, recoded, aggregated, or otherwise transformed. Each of those transformations was a decision, about what to include and exclude, how to handle missing values, what normalization approach to apply, how to resolve conflicts between sources. The second stage of the audit test is to account for every one of those decisions.

The question: For every transformation applied to the data that shaped this decision, can you produce documentation specifying what the transformation did, why it was designed that way, who authorized it, when it was last validated, and whether it was applied consistently and correctly to the data that produced this specific output?

Transformation documentation is where the audit test breaks most commonly and most consequentially. Transformation logic that seemed self-evident to the team that designed it was frequently left undocumented for that reason. Normalization approaches that were standard practice at the time of implementation have not been revisited as the data characteristics of source systems have changed. Exclusion criteria that were appropriate for the original use case have been carried forward into contexts for which they were not designed. Joins between data sources that introduce implicit assumptions about matching records have never been formally validated.

Adequate evidence at this stage looks like: transformation specifications written at the time of implementation, change logs documenting every modification to transformation logic since implementation, validation records demonstrating that the transformation produces the intended output across the range of inputs it is applied to, and execution logs confirming that the transformation was applied correctly to the specific data batch that produced your chosen decision. It does not look like: the code itself, without annotation or specification; a team member's explanation of what the code does; or a general statement that the transformation follows standard practice.

If you can describe your transformations but cannot produce contemporaneous documentation of why they were designed the way they were, you are navigating with institutional memory rather than documented fact. That memory is not transferable to an auditor, a regulator, or a legal proceeding. It is the second type of gap the test surfaces, and it corresponds directly to the transformation transparency property that article nine defined as a prerequisite for functional governance.

Stage Three: System Interactions and Boundary Crossings

The data that shaped your chosen decision did not travel through a single system under unified ownership. It crossed boundaries, between source systems and pipelines, between pipelines and feature stores, between feature stores and model serving infrastructure, between systems owned by different teams with different documentation practices and different standards for what constitutes adequate record-keeping. The third stage of the audit test is to account for every one of those crossings.

The question: For every point at which the data that shaped this decision crossed a system boundary or changed organizational ownership, can you produce documentation of what was handed across, in what state, under what assumptions, and with what validation that what was received matched what was sent?

This stage is where the hand-off fractures that article four examined become personally relevant. At each boundary crossing, there is a potential gap between what the delivering system provided and what the receiving system understood itself to have received. If the delivering system applied a transformation that the receiving system did not document in its own records, the receiving system's account of its inputs is incomplete. If the receiving system assumed the delivering system's outputs were fully validated when they were not, that assumption is now embedded in the chain of evidence underlying your chosen decision.

Adequate evidence at this stage looks like: interface specifications documenting what each system is contracted to deliver and receive at each boundary, validation logs confirming that the data received matched the specification at the time of transfer, and documented resolution of any discrepancies identified at the boundary. It does not look like: a general understanding that the systems are integrated and that the integration has been working, or a statement that the receiving team would have raised an issue if the data had been wrong.

If your documentation of boundary crossings is thin, if you can describe the integrations at an architectural level but cannot produce transfer validation records for the specific data batch that produced your chosen decision, you have found the third gap. This one is particularly significant because it is invisible to any governance function scoped to either side of the boundary. It exists in the seam, which belongs to no one, and its documentation is therefore no one's operational responsibility.

Stage Four: Model Inputs and Their Documented Characteristics

By the time data reaches your model, it has been through origin, transformation, and boundary crossing. What arrives at the model is a feature set, a structured representation of the inputs the model was trained to process. The fourth stage of the audit test is to account for that feature set with the specificity the model's behavior requires.

The question: For the specific feature values that were presented to your model for this decision, can you produce documentation confirming that each feature was within the range and distribution present in training data, that known data quality issues were assessed and addressed, and that the feature engineering applied was consistent with the documented specification under which the model was validated?

This stage probes the boundary between data preparation and model operation, the point at which the adequacy of the data becomes directly relevant to the validity of the output. A model that receives feature values outside its training distribution may produce outputs that its validation did not assess. A model that receives feature values affected by data quality issues that were not caught or documented may produce outputs that reflect those issues rather than the underlying reality the model was designed to represent. If the feature values are not documented at the point of model input, if you cannot retrieve the specific values that were presented to the model for this specific decision, then the model's output cannot be fully explained regardless of how thoroughly the model itself was validated.

Adequate evidence at this stage looks like: logged feature values at the point of model input with timestamp, documented distribution checks confirming inputs were within validated ranges, data quality flags assessed and resolved prior to model invocation, and feature engineering code that matches the specification under which the model was validated. It does not look like: confidence that the pipeline generally produces well-formed inputs, or a validation report demonstrating that the model performs well on average across a test set.

If your model input logging is incomplete, if you can describe what the model should have received but cannot retrieve what it actually received for this specific decision, you have found the fourth gap. It is the gap that makes individual decision explanation impossible even when system-level validation is thorough, because validation is a population-level activity and explanation is an instance-level requirement.

Stage Five: Model Logic and Its Validation Basis

Your model processed the inputs it received according to logic that was established during training and validated before deployment. The fifth stage of the audit test is to account for that logic with enough specificity to demonstrate that the output it produced for your chosen decision was within the scope of what validation assessed and approved.

The question: Can you produce the validation documentation for this model that covers the specific type of decision your chosen output represents, demonstrates that the model's behavior was assessed across the relevant range of inputs including edge cases similar to those present in your chosen decision, and confirms that the validation remained current at the time the decision was made?

Model validation is the stage most organizations feel most confident about, because it is the stage that AI governance frameworks most directly address. Validation processes exist. Documentation has been produced. Approval has been granted. The model is in production and its governance is, in formal terms, complete.

The audit test does not dispute the existence of validation. It probes its coverage and its currency. A model validated on data that does not represent the distribution of inputs it is currently receiving may be producing outputs that its validation did not assess. A model validated at deployment and not revalidated as the data environment has changed may be operating outside the conditions its original validation established. A validation report that demonstrates aggregate performance across a test set does not necessarily demonstrate that the specific decision pattern your chosen output represents was adequately assessed.

Adequate evidence at this stage looks like: validation documentation that covers the specific decision type your output represents, with performance metrics disaggregated enough to include cases similar to your chosen decision; documentation of the data used in validation and confirmation that it remains representative of current inputs; and a revalidation schedule with evidence that the schedule has been followed. It does not look like: a validation report demonstrating strong aggregate performance, without evidence that the specific decision pattern was within its scope.

If your validation documentation is comprehensive at the aggregate level but cannot speak to the specific decision type your chosen output represents, you have found the fifth gap. It is the gap that most directly challenges the claim that the model's outputs are governed, because governance of a model that cannot be validated at the instance level is governance of an average, not of the decision that actually affected a real person or a real outcome.

Stage Six: Output Generation and Downstream Use

Your model produced an output. That output was used, by a person, a system, or a process, to make or inform a consequential determination. The sixth and final stage of the audit test is to account for what happened between the model's output and the decision's effect.

The question: Can you document how the model's output was translated into the specific determination that was made, who or what applied that translation, what thresholds or rules governed it, whether any human review occurred and what that review assessed, and how the final determination was recorded and by whom?

This stage is frequently the least documented of the chain, because it occurs at the boundary between the AI system and the human or organizational process that uses it. The model's output is a score, a classification, a recommendation, or a ranked result. The determination is a decision, a yes or a no, an approval or a denial, an action or an inaction. The translation between them involves rules, thresholds, human judgment, and organizational process, all of which are part of the chain of accountability for the final determination and all of which must be documented to make that chain complete.

Adequate evidence at this stage looks like: documented decision rules specifying how model outputs are translated into determinations, audit logs recording the specific output and the determination it produced for your chosen case, documentation of any human review including who conducted it and what they assessed, and records confirming that the final determination was made in accordance with the documented rules. It does not look like: a general description of how the output is typically used, or a statement that the decision-maker applied their professional judgment to the model's recommendation.

If your downstream use documentation is thin, if the model's output is logged but its translation into a determination is not, you have found the sixth gap. It is the gap that makes the final determination legally and regulatorily most vulnerable, because it is the gap between the system and its effect on a real person or a real outcome, and it is the gap that affected parties and their representatives will examine first.

## What You Have Just Found

Stop here. Look at what the test produced.

If your explanation held at every stage, if you can produce documented, verifiable evidence at each point in the chain without relying on inference, institutional memory, or the cooperation of multiple teams across extended timelines, then you have something genuinely valuable: evidence of foundational governance that is real rather than present. Understand what made that possible, because it did not happen by accident. It is the product of deliberate investment in the foundational properties that article nine defined, and it is the condition that makes your AI governance framework's reach genuine rather than bounded by a ceiling you cannot see.

For most readers, the explanation did not hold at every stage. It held for some stages and broke at others. The break may have come early, at data provenance, where documentation exists at the general level but not at the specific level the test requires. It may have come at transformation, where the logic is navigable by the people who built it but not retrievable as contemporaneous documented fact. It may have come at a boundary crossing, where the integration is functional but the transfer validation records do not exist. It may have come at model inputs, where aggregate logging exists but instance-level feature values are not retrievable for this specific decision. It may have come at validation coverage, where the aggregate performance documentation is strong but the specific decision type your chosen output represents was not explicitly within its scope. It may have come at downstream use, where the model's output is logged but its translation into a determination is not.

Wherever the break occurred, note what type of gap it represents. A break at data origin or transformation is a traceability gap, the foundational property whose absence makes accountability impossible to assign because the chain of evidence does not exist. A break at transformation documentation is a transformation transparency gap, the property whose absence means the model's behavior cannot be fully explained regardless of how well the model itself is understood. A break at boundary crossings or system interactions is a visible system interactions gap, the property whose absence means governance cannot see the full scope of what it is overseeing.

Now note something more significant than the type of gap: the break you found is not an isolated finding. It is a signal about the condition of your foundation as a whole. The gap that broke your explanation of this decision exists in the same system that produces every other decision your AI makes. It was present before you chose this decision to examine, and it will be present in the next decision, and the one after that. The audit test does not reveal a single gap in a single decision. It reveals the condition of the foundation through the window of one decision, and what that window shows is the condition that applies to all of them.

You now know something about your organization that your current governance posture did not tell you. You know approximately where your governance ceiling is. You know what type of foundational condition placed it there. And you know that the ceiling is not a theoretical concern about a hypothetical future examination. It is the limit of your actual governance, today, applied to decisions your AI system is making continuously.

What that limit is costing your organization, in regulatory exposure, in operational risk, in the financial terms that make the case for foundational investment, is what the next article makes concrete.

This article is part of the Governance Debt Framework™, a structured exploration of how modern organizations accumulate invisible risk as decisions, systems, and responsibilities drift out of alignment. The goal is to both diagnose the problem and provide a clear lens for understanding what happens inside complex organizations, and develop a path toward restoring systems that can explain, justify, and sustain the decisions they produce.