Designing a System for Verifying Data Science code

Data science code often fails silently: the query runs, the tests pass, and the reported metric looks plausible, while the underlying measurement is wrong. We study DS/ML code verification as a systems problem rather than a single-model prompting problem. In internal comparisons, a verification system designed around DS/ML failure modes detected substantially more issues than single-pass LLM review, including failures in temporal validity, join grain, label construction, and metric integrity. We present these comparisons as evidence for a system-design hypothesis, not as a universal benchmark.

The comparisons above are internal and sample-based. They are intended to isolate the effect of system design against the stated baselines, not to serve as independent third-party benchmarks.

Problem definition: DS/ML code verification

We define the verification task as follows. Given code that constructs an analysis, a feature table, a model evaluation, or an ML training dataset, determine whether the code preserves the intended data semantics and supports the conclusion being drawn. The object under test is not only the program but the measurement the program produces.

This differs from generic code review. Generic review asks whether software is well-constructed: does it compile, is it correct against its specification, is it safe and maintainable. DS/ML verification asks a question on top of that — whether the reasoning encoded in the code is methodologically sound. Code can be flawless as software and still answer the wrong question. A pipeline can run to completion, a notebook can produce a clean chart, and a model can report strong validation metrics while the underlying analysis is invalid. Unit tests pass because they encode what someone already thought to check; line-by-line review approves because the code looks reasonable. The defect survives both and ships.

Failure modes are measurement failures

The most consequential DS/ML defects are not syntax errors; they are errors in what is being measured. Consider a SQL query that assembles a customer-level training table by joining orders, sessions, payments, and refunds. If a join fans out, it is not merely a style problem — it changes the measurement. COUNT and SUM run over exploded rows, so downstream counts and revenue are inflated; refund labels are over-weighted; and future sessions or payments can become available to earlier orders. The resulting table can look precise while measuring the wrong target.

On a concrete demo SQL review, the failures clustered into a recognizable set of measurement defects:

• Fanout bug. A join chain creates a cross-product per customer — the most damaging defect, because every aggregate computed afterward is wrong.
• Inflated metrics. COUNT and SUM over the exploded rows make all downstream metrics incorrect.
• Label leakage. A refund amount is used as both a feature and the target, which trivially breaks the model.
• Temporal leakage. Tables are joined without date bounds, so future data attaches to past orders.
• Lifetime-feature leakage. A "last order date" feature spans the full dataset, including events from after the prediction point.
• Retention-horizon logic. A retained_30d label has no 30-day upper bound, so the CASE expression does not encode the intended window.

What unites these is that they are semantically wrong while being operationally fine. A unit test checks that a function returns what its author expected; it cannot tell the author that what they expected was the wrong thing. This is why "the code runs and the tests pass" is a weak signal here, and why verification must reason about data, intent, and method — not just control flow.

Baseline comparison: one-shot model review

We compared a purpose-built Mitari verification system against single-pass GPT review over a sample of Data/ML repositories. The system detected 92% of issues in the sample, compared with 62% for the single-pass baseline. We do not present this +30 percentage-point difference as a universal benchmark; it is evidence that system design materially changes verification performance under the evaluated conditions.

Several mechanisms are consistent with why one-shot review underperforms:

• Attention is spread across a large diff or file, so cross-cutting methodological problems are easy to miss.
• There is no task decomposition, so distinct failure classes are not examined on their own terms.
• The prompt does not explicitly cover DS/ML failure classes such as leakage, evaluation validity, and join grain.
• Root causes are not always connected to their downstream measurement consequence, so the severity is under-stated.
• The output can be plausible but incomplete — fluent text that reads as thorough while omitting the defect that changes the result.

Baseline comparison: general-purpose code review

We also compared Mitari against a general-purpose code-review baseline (Anthropic Code Review) on the same SQL file, then asked Claude to evaluate the two outputs blind. On that file the general-purpose review identified two issues — it correctly flagged the retained_30d logic and described the fanout structure with concrete arithmetic — while Mitari surfaced the broader failure cluster, including label leakage, temporal leakage, future-dependent lifetime features, and the inflated downstream metrics that follow from the fanout.

The point is not that the general-purpose system is poor — it caught real structural issues. The point is the difference between identifying code structure and verifying methodological correctness. In the blind evaluation, Claude favored the Mitari output, noting that the general-purpose review alone would leave the model "trivially leaky." That phrase captures the gap: a review can be correct about structure and still miss the defects that determine whether the resulting model or metric is valid.

System design hypothesis

Our central hypothesis is that verification performance improves when the system around the model is explicitly designed for DS/ML methodological failure modes. The system is not a single prompt. At a high level, it is an orchestration pattern: break the verification task into narrower methodological questions, supply the relevant code context for each question, generate candidate findings, and then consolidate those findings into reviewer-facing claims with evidence, severity, location, and remediation guidance.

The design dimensions that appear to carry most of the effect:

• Task decomposition. Asking precisely-scoped questions — "is there leakage here?", "does this evaluation support this claim?" — keeps reasoning grounded and lets each check be judged on its own terms.
• Failure-mode-specific passes. Targeting known DS/ML failure classes raises coverage beyond a single open-ended prompt.
• Context selection. What is placed in front of the model — the relevant data flow, surrounding definitions, declared intent — often matters more than how much is placed in front of it.
• Code/data-flow reasoning. Tracing how values move through joins, aggregations, and splits is what connects a structural defect to its measurement consequence.
• Critic and consolidation. Generating candidate findings and then re-examining and consolidating them separates "propose" from "scrutinize," reducing noise and improving precision.
• Reviewer-facing rationale. Each finding carries why it matters, where it occurs, and how a proposed change would address it — so a correct judgment becomes an informed human decision.

What performance means in verification

"More issues" is not automatically better. A verifier that flags everything trains reviewers to ignore it; one that flags too little provides false comfort. Evaluating a verification system therefore requires looking past raw issue counts at several dimensions at once:

• Issue detection. Whether real defects are found at all — the headline recall measure.
• Severity-weighted recall. Whether the high-damage, outcome-changing failures are caught, not just the easy ones.
• Precision. Whether flagged items are genuine, so reviewers keep trusting the output.
• Actionability. Whether a finding can be understood and acted on, with location, rationale, and a remediation path.
• Avoided false comfort. Whether the system reduces the risk of a clean-looking review that hides an invalid result.
• Coverage of high-damage classes. Whether leakage, evaluation validity, and join-grain defects are addressed specifically rather than incidentally.

Under this lens, catching one real leakage or evaluation defect is worth far more than a long list of stylistic notes. The relevant question is whether a system catches the defects that change the conclusion.

Limitations

• Internal comparisons may not generalize to all repositories or coding styles.
• Issue labels in DS/ML verification can be ambiguous, because intent is not always explicit in the code, which makes scoring genuinely contestable.
• The current comparisons should be interpreted as evidence for the system-design hypothesis, not as a final or independently audited benchmark.
• The same-file comparison is a single case study; a broader, public benchmark would be needed to make a general claim.
• Larger public benchmarks for DS/ML methodological code correctness are needed, and the field would benefit from shared, representative datasets with well-characterized defects.

Conclusion

The evidence from these comparisons is consistent with the thesis that DS/ML verification is a system-design problem. Strong models matter, but the measured difference appears to depend on the verification harness around them: the decomposition, the context, the failure taxonomy, the validation step, and the presentation layer. The failures that do the most damage are silent and methodological — they pass ordinary tests and review — and catching them reliably is a property of the system, not of any single prompt.

We read these results as a direction to keep testing rather than a settled conclusion, and the natural next step for the field is better public benchmarks for methodological code correctness. This article is a draft perspective, and we expect it to evolve as the work and the evidence do.