For biostatistics and statistical programming

Agent-assisted ADaM,
audit intact

BuildADaMs derives CDISC ADaM datasets from frozen SDTM with propose-only AI agents, human approval at every gate, deterministic fallbacks, and matching R and SAS output.

21 CFR Part 11CDISC ADaM Admiral RDual R + SAS Propose-only AI
Use the arrows below, your keyboard's ← → keys, or swipe
The cost of the status quo

AI you cannot audit is AI you cannot submit

Analysis derivations are slow because every variable is double-programmed by hand, and generic AI copilots are opaque, so regulators do not trust them. When the SAP changes or someone asks how a value was derived months later, the answer is guesswork pieced together from scripts and memory.

× Double programming is slow

Every analysis variable is built twice by hand to satisfy QC, and the second build is pure cost with no new science in it.

× Black-box AI fails review

A suggestion you cannot trace or reproduce has no place in a regulated derivation, so most copilots never make it past the reviewer.

× Derivations drift from the spec

When the SAP changes, keeping code, spec, and QC in step is manual and error-prone, and the drift surfaces only at inspection.

The solution in one line

Propose-only agents suggest, humans approve, the record proves it

Four propose-only agents work alongside a gated workflow. They read specs and bounded metadata, never patient rows, every proposal is hashed and audited, and a human applies or rejects each one before it touches a dataset.

Propose-only

Agents suggest derivations, QC logic, and code. They never write to a dataset or skip a gate, the human decision is always the one that lands.

Deterministic by default

Every agent has a fallback heuristic, so the workflow finishes even with no model available and a study is never blocked on AI.

Audited end to end

Each proposal is hashed and linked to the user action that applied or rejected it, so the record shows exactly what AI suggested and who decided.

Walkthrough · 1 of 7
The authoring workflow

A gated path from spec to sign-off

How it works
  • Each dataset moves through spec ingestion, derivation, codegen review, QC double-programming, execution, output review, and sign-off.
  • A human approves each gate, and the workflow cannot skip a state or advance without an audit event.

Why it mattersNothing reaches analysis without review, QC, and sign-off, and the path is the same every study, so the state of every dataset is provable.

app.buildadams.io
Spec Derive Codegen QC Execute Review Sign-off
Dataset ADSL · current state QC · three gates signed off
Walkthrough · 2 of 7
Propose-only agents

Four agents that suggest, never decide

How it works
  • spec_ingestion parses the SAP, derivation proposes analysis variables, qc proposes double-programming logic, and codegen_assist drafts the code.
  • Every proposal is hashed and audited, and a human applies or edits it before anything is written.

Why it mattersYou get the speed of AI with a human decision and an audit record on every suggestion, so review is fast and the trail is intact.

app.buildadams.io/derive
ADAE · treatment-emergent flag derivation agent proposed
Derive TRTEMFL from adverse event start versus first dose. Flag a record as treatment-emergent when AESTDTC is on or after TRTSDT and on or before TRTEDT plus the safety window. Keep the human-authored imputation rule for partial dates.
Walkthrough · 3 of 7
Source merge

Many SDTM domains into one analysis dataset

How it works
  • Derive an analysis dataset from several frozen SDTM domains at once, with the lineage of every ADaM made explicit.
  • ADSL draws on DM, EX, and DS, and ADLB draws on DM, VS, and LB, all visible in one tree.

Why it mattersThe inputs to each dataset are visible and reproducible, not buried in a program, so a reviewer can trace any value back to its source.

app.buildadams.io/lineage
Analysis datasets frozen SDTM
ADSL - Subject Level 3 sources
DM  Demographics
EX  Exposure
DS  Disposition
ADLB - Lab Analysis 3 sources
DM  Demographics
VS  Vital Signs
LB  Laboratory
Walkthrough · 4 of 7
Code generation

One spec, matching R and SAS

How it works
  • The derivation spec compiles to Admiral-based R and to SAS that follow the same logic line for line.
  • Run the R in the platform on a pinned image, or take the SAS to your own validated environment.

Why it mattersYou are not locked in. Reviewers read the generated code, and it runs the same on your platform as on ours.

adsl.R
R
# ADSL - Subject Level (generated)library(admiral)adsl <- dm %>% derive_vars_merged( dataset_add = ex, new_vars = exprs(TRTSDT, TRTEDT) ) %>% derive_var_trtdurd() %>% derive_var_age_years(AGE)
adsl.sas
SAS
* ADSL - Subject Level (generated);data adsl; merge dm ex(keep=USUBJID TRTSDT TRTEDT); by USUBJID; TRTDURD = TRTEDT - TRTSDT + 1; AGE = input(AGE, best.); AGEU = "YEARS";run;
Walkthrough · 5 of 7
Reproducibility

QC double-programming, reconciled by hash

How it works
  • The QC agent suggests an independent second build of the dataset.
  • The platform content-hashes the production build and the QC build, and confirms they match before sign-off is allowed.

Why it mattersDouble programming converges to a provable match, not a manual eyeball compare, so QC sign-off rests on evidence rather than judgment.

app.buildadams.io/qc
build dataset rows cols sha256 production ADSL 312 48 b40f2a7c QC ADSL 312 48 b40f2a7c
0 differing values · production and QC builds are identical
Walkthrough · 6 of 7
AI boundary

Agents see metadata, never patient rows

How it works
  • Agents receive specs and bounded column profiles, never subject-level data.
  • Patient-level rows stay inside the platform and never cross to the model.

Why it mattersYou get assistance without exposing subject data, which keeps privacy and compliance intact while the agents still do useful work.

app.buildadams.io/boundary
Metadata only

Subject-level analysis data never leaves the platform, the model sees only specs and bounded metadata.

Stays in
patient rows, subject-level ADaM
metadata only
Crosses
specs, variable metadata, proposed code
Walkthrough · 7 of 7
Audit

Every proposal and sign-off, on the record

How it works
  • Apply, reject, and sign-off events are append-only, each carrying the actor, server time, and a content hash.
  • The ledger links every agent proposal to the human action that accepted or rejected it.

Why it mattersAn inspector can see exactly which AI suggestion was accepted, by whom, and when, with nothing reconstructed under deadline.

app.buildadams.io/audit
WhenActorEventHash
09:14:02j.okaforADSL sign-off7c1a…e9
09:02:51systemQC build matchedb40f…2a
08:47:19m.reyesderivation applieda3f1…9c
08:31:08derivation agentproposal hashed5d8e…11
Why BuildADaMs

Built for derivations regulators can trust

CapabilityManual programmingGeneric AI copilotSAS-only stackBuildADaMs
One spec, matching R and SAS output
Propose-only AI with a hashed audit trail
Deterministic fallback, no hard model dependency
QC double-programming reconciled by hash
Metadata-only AI, no patient rows to the model
Append-only Part 11 audit trail
Built for every seat

One derivation engine, six points of view

Biostatistician

Trust that every analysis variable traces back to a frozen SDTM source and a reviewed spec, with the derivation visible for any value.

Lead statistical programmer

Author the derivation spec once, see every dataset's state on one board, and approve gates with the agent proposals and evidence attached.

QC programmer

Take the QC agent's independent build, confirm the hash match in one place, and sign off knowing the compare is provable.

Medical monitor

Read the analysis-ready ADaM with confidence that flags like treatment-emergent followed a reviewed rule, not an undocumented script.

Submission lead

Ship analysis datasets with the generated R and SAS and a clean trail of which AI suggestion was accepted and by whom.

QA / auditor

A read-only, tamper-evident trail links every agent proposal to a human decision, ready for inspection on demand.

Compliance and trust

Regulatory rigor, by construction

The controls auditors look for are inherent in the system, not bolted on after the fact.

21 CFR Part 11

A gated workflow with human sign-off at every gate, server-time stamping, and access control on every dataset.

AI audit trail

Every agent proposal is hashed and linked to the user action that applied or rejected it, so AI involvement is fully traceable.

Metadata-only AI access

Agents never see patient rows, they receive only specs and bounded metadata, so subject data stays inside the platform.

Tenant isolation

Row-level security separates every tenant's data and audit at the database, verified through the request path.

Derive one of your analysis datasets in a 30-day pilot

See BuildADaMs ingest your SAP, propose derivations, generate R and SAS, and reconcile QC by hash in days. Humans approve every step, and the code is yours to keep.

  • We load one of your studies into a private workspace
  • Your team runs spec to sign-off on an analysis dataset
  • You keep the generated R and SAS
  • A readout on QC time saved against your current build
Talk to us · info@the-bdkm.com · BDKM LLC · Back to Life Sciences