Review ask

As a clinical trial statistician or programmer, challenge anything in this benchmark: describe a problem in Comments, or propose a fix with the Edit button on any source file.

  1. Task: Would a real study need this derivation, specified this way? Does it follow CDISC ADaM: variable names, controlled terms, record structure? Flag any rule that is ambiguous or that a sponsor would handle differently.
  2. Inputs: Do they look like data collected in a real trial, and do they include the situations you would expect to meet in one?
  3. Expected output: Would independent QC programming reproduce every value from these inputs and rules?

The other tabs beside Comments are background for assessment, not under review.

Summary

Lifecycle: draftEditUnder review
What this benchmark means
README.md

Goal: demonstrate a shared level declaring a study's demographics input once - its name and the AGE field type - while the stored file stays with the study's project, and derive AGE from it.

Input: two spec files and the project's demographics:

  • common/spec_common.yaml is the shared level, kept in its own directory as it would be when several studies inherit it. It names the demographics file ../input/dm.csv, gives the AGE field type, and declares every column;
  • spec_study.yaml is the entry: it names the shared level as its parent and declares the complete output;
  • input/dm.csv sits at the project root (this benchmark's directory), not beside the shared level.

Note: paths resolve from the directory of the file that declares them. The shared level writes ../input/dm.csv, which reaches the study's input from common/. The engine resolves that declaring-file path once.

expected/spec_resolved.yaml retains the historical reference view. It is excluded from public conformance until cutover under #1973 item 14.

Inputs

Under review
1 source file

input/dm.csv

Edit
2 rows
input/dm.csv
STUDYIDUSUBJIDAGE
STUDY0134
STUDY0158

Expected output

Under review
2 expected rows

expected/adsl.csv

Edit
2 rows
expected/adsl.csv
STUDYIDUSUBJIDAGE
STUDY0134
STUDY0158
Shaded columns are derived— = missing value

Comments and assessment materials

Comments

Signed in with GitHub; saved in repository Discussions

Mapping spec

Generated from the benchmark YAML; do not edit by hand

Variable NameVariable LabelTypeLengthControlled Terms or FormatOriginCoreConversion DefinitionVariable TypeVariable OrderComments for Define
VersionDateAuthorDescriptionReviewerSign-off
1.32026-09-29yamaa docs buildShow study codelist names, external dictionaries, and ISO 8601 formats in variable rows; list the document's codelist values and metadata
1.22026-09-29yamaa docs buildClassify ADaM copies from a declared input as Predecessor and recodes as Derived, and SDTM recodes of locally derived columns as Derived
1.12026-09-29yamaa docs buildResolve lookups into the donor record they select, and give every derivation shape a plain-language rule instead of its raw YAML
1.0yamaa docs buildInitial generation from spec.yaml

yamaa code

Runs the yamaa specification; its result must match the expected output

run.R

Edit
4 lines
library(yamaa)adsl <- yamaa_domain("spec_study.yaml")$outputadsl

run.py

Edit
4 lines
import yamaaadsl = yamaa.yamaa_domain("spec_study.yaml").outputadsl