Use case · Treatment effects in the data

Treatment effects your analysis programs can actually find.

Analysis datasets and the outputs built on them are programmed months before any data arrives, and usually tested on data with no signal in it. Verdatic lets you build the treatment difference in on purpose — per field, per arm, previewed before generation — so the derivations that matter get exercised on data where you already know the answer.

The problem

Analysis datasets and the outputs built on them are programmed months before there is any data to run them against. So they get tested against whatever is available: a handful of hand-made rows, a previous study’s extract with the wrong structure, or dummy data with no signal in it at all.

Data with no signal proves almost nothing. A change-from-baseline derivation runs cleanly on flat data and on wrong data alike. Subgroup logic, visit windows, responder flags and dropout handling all pass when there is nothing to get wrong.
Degenerate test data hides real defects. Constant values, one visit per subject, no missingness, no discontinuations — exactly the conditions your programs will never meet and your bugs are hiding behind.
The first real extract becomes the first real test. Which puts pipeline rework in the busiest week of the study, not the quietest.
Design questions get asked too late. “What if we add an arm, widen the window, change the schedule?” is a planning conversation when it should be a five-minute experiment.

Risk and cost profile

We don’t publish savings percentages, and there is no benchmark study behind this page. These are the drivers; your rates and your study history are the inputs.

The cost here is mostly displaced time rather than wasted time. The analysis programming still gets done — it just gets done later, under more pressure, by people who are simultaneously answering questions about live data. Work that could have been finished and reviewed in a quiet quarter lands in the loudest one.

Cost driver	How it shows up	Price it with your own numbers
Analysis code with nothing to run on	Derivations and flags are proven syntactically, then properly tested at first data.	programmer-weeks that can’t start until real records exist
Degenerate test data	Flat or single-visit data can’t exercise change-from-baseline, windows or dropout.	count the derivations you couldn’t truly test on your last study
First-data-in rework	The first real extract is also the first honest test of the pipeline.	days of rework, in the weeks you have least of them
Blinded dry runs	Without a modeled effect there’s nothing to blind — and nothing to test blinding against.	see the masking use case
Late design questions	Adding an arm or shifting a window is a planning exercise rather than an experiment.	hours to re-plan on paper, against minutes to re-simulate

What we won’t claim: Verdatic does not write your tables, listings and figures, and it does no statistics — no models, no p-values, no estimands. It builds the signal into the data so that the programs which do those things can be written, run and reviewed early. Simulated effect sizes are a design input you chose, never evidence about a compound.

The workflow, at a glance

An arm is a label, an allocation ratio and — optionally — its own schedule. Each subject is randomized to one, and each field can carry a per-arm setting: how much it should move from visit to visit, and in which direction. Everything else about the field is inherited, so the difference between arms is exactly the difference you declared.

The preview sits before generation on purpose: you tune the design against a chart, not against a finished dataset you then have to throw away.

The Verdatic workflow

Real screens from the product — and the exact vocabulary the product uses, which is deliberately mechanical: arms, drift per visit, a maximum percentage change per visit.

STEP 01

Define the arms and how subjects land in them

An arm has a label, an allocation ratio shown as a percentage, an active flag and an optional schedule requirement — leave the schedule blank and the arm applies to any of them. Randomization happens per subject in proportion to the ratios, and the assignment is carried on the subject record, so the arm follows that patient through every dataset and stamps the treatment variables and the trial-design rows in the standards output.

STEP 02

Set the effect where the effect belongs — on the field

Open a numeric field and there are two numbers that matter: drift per visit, a signed value where the sign is the direction, and maximum change per visit, which governs how noisy the path is. Set them once for the study, then open per-arm overrides and give the active arm its own. Blank cells inherit, so a placebo arm that overrides nothing simply behaves like the base study — and the separation between the two is precisely what you typed.

Being exact about the model: the drift is a constant step applied at each visit, with a random draw around that target and clamping to the field’s bounds. It is not a per-visit effect curve, and Verdatic does not ask you for an effect size, a treatment model or an estimand — the vocabulary is deliberately closer to “how much does this move” than to statistics.

STEP 03

Preview it before a single record exists

The same dialog runs a preview on demand: subject trajectories with the mean and a one-standard-deviation band, the final-visit distribution against the theoretical curve, the visit-to-visit percentage change against the limit you set, and — when the study has arms — a mean-per-visit comparison of each arm against the universal setting. It includes edits you haven’t saved yet, so tuning is a conversation with a chart rather than a generate-and-inspect cycle.

STEP 04

Generate, then look at what the setting produced

After a run, the charts lens shows the real thing: every subject’s trajectory for a chosen field, filtered to one arm, with the distribution of the generated values against the theoretical curve underneath and the field’s configured model spelled out along the top.

Systolic blood pressure for 22 subjects on the active arm across six visits: the whole band of trajectories drifts downward between day −14 and day 198, with a histogram below comparing the observed values against a normal curve. — Systolic blood pressure on the active arm — 22 subjects across six visits, the whole band drifting down, none of it hitting the lower bound. The strip along the top names the model actually in force: normal, with its bounds and its maximum change per visit. The tag beside the field name means visit-to-visit coherence is **configured** for it; the shape below is what that configuration produced.

STEP 05

Check it holds up at the patient level

A treatment effect that only exists in aggregate isn’t much of a test. Individual subject profiles show the arm’s effect alongside everything else that has to stay believable — measurements that wander the way real ones do, events that start after dosing, treatments that follow the events they answer.

The same subject's visit strip — six visits from D-14 to D198, three of them highlighted in amber where an adverse event starts — above trend charts for diastolic blood pressure, pulse, respiration, systolic blood pressure and temperature. — One subject’s six visits, with the three where an adverse event starts picked out, above the vital signs recorded at each. Both blood pressures fall across the study; pulse, respiration and temperature wander the way real measurements do.

STEP 06

Add the imperfections your programs have to survive

A clean signal is only half a test. At project level you can set a dropout mechanism — completely at random, dependent on an observed covariate, or dependent on the unobserved value — with a per-visit dropout rate and a between-site variation term. Per field there are distribution choices, missing and blank rates, ranges, and an intra-visit offset pattern. And any run can be generated deliberately dirty, so the pipeline meets the kind of data it will actually be given.

The Generate Simulated Data panel: number of sites and subjects per site, a mode selector offering Clean, Dirty, Paired and Test Case, a categorical output convention, a row sort order, and a global missing rate. — Run size, mode and a global missing rate — the study-wide dials. Dropout mechanism and site variation live with the simulation profile on the project; distributions and per-field missingness live on the field.

STEP 07

Carry it into the analysis layer

The generator produces the collected and tabulation data; the analysis datasets are derived from it by programs Verdatic writes — a subject-level dataset with its treatment and population flags, basic data-structure datasets for findings carrying parameter, visit, baseline, change and percent-change variables, and occurrence datasets for adverse events, medications and medical history. Analysis datasets are bundled separately from the tabulation ones, each with its own Define.xml, and the bundle can be executed in place for R and Python.

That is the point of modelling the effect in the first place: your baseline flags, your change-from-baseline and your visit windows get exercised on data where the answer is known, because you chose it.

A build plan for the study: an 18-domain resolved emission order, and a code bundle set to SDTM and SAS with buttons to preview, generate the bundle, open Define.xml and open traceability — the packed ZIP is 481.4 KB with a sha256 checksum. — The build plan, here set to the tabulation standard and SAS. The standard selector is where the analysis bundle is chosen instead — a separate package, in dependency order, with its own Define.xml.

Executive summary

The problem. Analysis datasets and outputs are programmed long before there is data with any signal in it, so the derivations that matter most are the ones tested least.
The cost. Displaced rather than wasted: the work lands at first-data-in, in the busiest weeks of the study, instead of the quiet ones.
What Verdatic does. Arms with allocation ratios and per-subject randomization; a signed drift per visit and a maximum change per visit set on each field, overridable per arm, with blanks inheriting.
See it before you build it. A preview charts arm against arm — including unsaved edits — and after generation the charts lens shows every subject’s trajectory for the arm you pick, against the configured model.
The honest boundary. No tables, listings or figures, and no statistics of any kind. Verdatic puts the signal in the data so the programs that do that work can be written and tested early — on synthetic data, never as evidence about a compound.

Pick an endpoint and watch it move.

A good first session is one endpoint from a study you know: set the drift, preview the arm comparison, generate, and run your own derivation against the result.

Request access

Or email [email protected]. If the analysis has to stay blinded, the masking use case covers the other half.

The other three use cases

Study build & edit-check UATProve the study build and its edit checks with data made to break them. SDTM & ADaM mapping from rawMap raw data to SDTM and ADaM and get runnable programs in all three languages. Masking unblinding dataDeclare what unblinds, apply it everywhere, and produce the record that proves it.