Imagine a laboratory dataset with a million records.

The SAP defines the analysis window, baseline, treatment groups and the summaries required. The ADaM specification translates those decisions into variables and derivations. The actual ADLB dataset contains multiple parameters, units, visits, collection times and treatment periods, along with the usual collection of awkward cases that looked much tidier in the document.

A reviewer may know exactly what could go wrong. Was a post-dose value treated as baseline? Were values compared before units were standardised? Did the analysis visit assignment behave correctly at the edge of a window? Did a record cross treatment periods after an exposure date changed?

A person can spot discrepancies between a SAP and a specification, or between a specification and the data, when the volume is manageable. But inspecting multiple combinations of data across a million records is not something a human brain can handle with ease. Nor is asking a large language model to read a million rows and ‘look for problems’ a credible control.

A qualified subject-matter expert defines what must be true and which exceptions matter. For example, the approved analysis definition may require values to be converted to a common unit before baseline is derived; baseline to be either the last non-missing assessment before first dose or the average of specified pre-dose assessments; and records collected after a treatment interruption to follow different derivation rules.

AI can help translate those requirements into candidate checks, compare their representation across the protocol, SAP and specification, and investigate patterns among the resulting exceptions. Code or database engines then apply the approved checks systematically to every relevant record. The expert reviews the discrepancies and decides what they mean.

That is the more useful role for AI in clinical analysis: people define meaning and acceptable evidence; structured metadata records approved analytical intent; AI helps interpret, translate and investigate; deterministic code applies approved rules at scale; and people decide the scientific and regulatory consequences. Generating another dataset or program faster is only one part of it.

The operating principle: people define meaning, structured metadata records approved analytical intent, AI interprets and investigates, deterministic tools apply approved rules at scale, and people decide the scientific and regulatory consequences.

The work is not divided into ‘AI’ and ‘human’

It is tempting to draw a line between work performed by AI and work performed by people. In practice, the more useful distinction is between different kinds of work.

Some review is mechanistic. Does the variable exist? Was the approved population applied? Do the numerator and denominator reconcile? Which outputs depend on a derivation that has changed? These questions can be stated explicitly and tested at scale.

Other review is judgemental. Is the analysis scientifically appropriate? Does an unexpected pattern change the interpretation? Is an ambiguity in the SAP consequential? Does the proposed handling remain defensible for this study? Those decisions need qualified context, not merely more computing power.

Automation does not make mechanistic review free. Checks still have to be designed, approved, maintained and investigated when they flag discrepancies. But it can stop scarce expert time being spent repeatedly reconstructing logic or searching large datasets for exceptions that a computational layer can surface more reliably.

Faster production is useful only if the system moves faster

This is where the Theory of Constraints can provide a useful, limited lens.

Anat Sadeh’s article, Why Less Is Often More When It Comes to AI, introduced me to the idea of AI-generated output as inventory. If one step produces work faster than the next step can absorb it, the queue grows. Local productivity improves; the complete system may not.

The same idea is useful in clinical data analysis. If AI accelerates ADaM specifications and programming while TFL finalisation is actually waiting for data cleaning, sponsor decisions, resolution of protocol–SAP conflicts, analysis-definition review or discrepancy investigation, the final analysis does not arrive sooner. We have accelerated a step that was not limiting delivery.

Human review is not always the bottleneck. But we need to test the assumption that the slowest visible activity is the constraint. A better starting point is evidence: Where does work wait? Where do unresolved decisions accumulate? Where does rework begin? Which queue delays reliable completion?

Constraints are not fixed. If programming effort is reduced, teams can redirect capacity towards earlier protocol and SAP review, structured analysis definitions or exception handling. Automating stable checks can reduce one part of review while moving the delay elsewhere.

The new workflow can also create constraints of its own: defining and approving metadata, configuring checks, investigating a growing exception queue, or validating and maintaining the automation. This introduces a new class of engineering and validation work. Deterministic rules must be maintained as standards and analysis definitions change; metadata pipelines must remain traceable; and AI prompts, retrieval sources and evaluation criteria can require controlled updates and revalidation. If this work is poorly designed or underestimated, the automation stack can become the next constraint.

The useful question is therefore not simply, ‘How much work did AI generate?’ It is, ‘Which delay did it remove, what new work did it introduce, and what became the next constraint?’

The value proposition must be reassessed at the level of the complete workflow, not assumed from the time saved on one activity.

Structured analysis definitions make the chain testable

ADaM datasets do not sit in a vacuum. They exist to support planned analyses and produce results for tables, figures and listings.

CDISC describes ADaM as supporting the generation, replication and review of statistical analyses, with traceability between results, analysis data and SDTM.

ARM for Define-XML supports the submission of analysis-results metadata alongside ADaM data.

The Analysis Results Standard (ARS) provides a structured model for analysis results and their metadata, including links to the protocol or SAP and input ADaM data.

CDISC frames ARS around automation, reproducibility, reuse and traceability.

ARS v1.0 was released in April 2024, and implementation examples and ARS-compliant packages are available. It can therefore be implemented today, but this article does not assume that it is already routine across the industry.

Varun Debbeti has made the practical connection that authoring analysis metadata can expose weaknesses in ADaM design. If an analysis cannot be represented without recreating logic inside an output program, that is evidence that the dataset is not carrying enough of the approved analytical intent.

In an AI-enabled workflow, approved analysis metadata could also provide an output-facing test of the chain: do the ADaMs, programs and results still represent the same analytical decision? I am inferring this use from the structure of ARS; it is not a claim about the standard’s stated purpose.

Using the earlier example again, consider a laboratory change-from-baseline summary. A structured analysis definition can identify the safety population, actual treatment, analysis parameter, analysis visit, baseline and post-baseline selections, summary method and output destination. The workflow can then test whether the referenced ADaM variables exist, the program applies the approved selections, counts and denominators reconcile, and each result traces to the intended analysis and supporting records.

If the baseline definition changes, the same metadata can identify every analysis and output that depends on it. Those results can be regenerated and compared. The reviewer does not have to remember the complete downstream impact unaided.

None of this proves that the approved baseline definition was scientifically correct. It tells us whether the implementation remained aligned with the approved decision. That is a different — and valuable — control.

Perfectly structured can still be perfectly wrong

Structured metadata does not remove ambiguity upstream.

Protocols, SAPs and shells are not always internally consistent. If AI converts ambiguous text into ARS metadata without a qualified person resolving the ambiguity, every deterministic check downstream can execute the wrong rule flawlessly.

The same risk appears when a single AI path interprets the SAP, proposes the analysis metadata, designs the ADaM derivation and generates the TFL program. The metadata, datasets, programs and results can all agree because they inherited the same mistake.

Agreement is not independence.

A separated architecture can reduce that risk. One AI system can generate the work while another reviews it using different instructions or source material. Deterministic code can also test the structure and implementation. But adding a second AI system does not automatically create an independent control. It is no different from production and QC programmers both following an incorrect specification without checking it against the SAP.

These AI agents can still inherit the same ambiguous source, model behaviour or evaluation assumptions. A separate reviewer agent is not automatically independent simply because it sits in another box. Independence has to be designed around the failure being challenged, not inferred from the number of agents in the diagram.

The control architecture therefore matters more than whether the tool is called an assistant, copilot or agent. Important analysis decisions need a clear, approved basis. The checks should be independent enough to catch errors in how the result was produced. Any exceptions should remain visible. And reviewers need to see how the result was reached before they can approve the final output.

Where AI output could influence the reliability of study results, this architecture should be tied to a defined Context of Use: the model’s specific role and scope with credibility evidence matched to that use. FDA’s January 2025 draft guidance draws this boundary explicitly and excludes purely operational-efficiency uses that do not affect patient safety, drug quality or the reliability of study results.

Where AI earns its place

In practice, the strongest starting point is a constrained use case: one high-volume review problem, an approved rule set, visible exceptions and a defined owner for the scientific decisions. End-to-end autonomy is neither the starting point nor the measure of success.

That can improve both speed and assurance. It can also change the bottleneck: less time on repeated mechanistic checks, more capacity for early analytical alignment and a smaller, better-defined set of exceptions to investigate.

Before automating a step, I would ask:

  • What delay in the complete analysis workflow are we trying to remove?
  • Which work can be expressed as approved rules and checked at scale, and which decisions require expert judgement?
  • What independent evidence, exception handling, maintenance and revalidation will the new workflow require?

AI can generate an ADaM faster. That matters when ADaM production is holding up the work.

The goal is not more output.

It is fewer avoidable gaps between the analysis we intended, the data we built and the results we finally approve.

Sources