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: carry each subject's AGE into ADSL as collected, listing a subject whose age falls outside 18 to 100 in a warning log rather than stopping the run, with every file in the Parquet format: the input, the output dataset, and the warning log (adsl-violations.parquet).

Input: one Parquet file, input/dm.parquet, carrying age (AGE) per subject.

Note: Parquet carries its own typed fields, so the spec declares no field types for the input, and a missing value is a null rather than an empty field. The golden files compare on what the bytes read back as: field names and order, logical types, row order, nulls, and values, not on the bytes themselves.

Inputs

Under review
1 source file

input/dm.parquet

Edit

Binary fixture; inspect it in the benchmark source.

Expected output

Under review
Expected artifacts

expected/adsl-violations.parquet

Edit

Binary fixture; inspect it in the benchmark source.

expected/adsl.parquet

Edit

Binary fixture; inspect it in the benchmark source.

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

Dataset NameVariable NameVariable LabelTypeCodelist/Controlled TermsCoreComputational MethodOrigin
ADSLSTUDYIDStudy IdentifiercharacterCopy value from DM.STUDYID.Predecessor
ADSLUSUBJIDUnique Subject IdentifiercharacterCopy value from DM.USUBJID.Predecessor
ADSLAGEAgenumericCopy value from DM.AGE.Predecessor
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
6 lines
library(yamaa)# Named `adsl`, not `dm`: the test harness binds the run.py variable to the# primary output's path stem, and this benchmark's output is `adsl.parquet`.adsl <- yamaa_domain("spec.yaml")$outputadsl

run.py

Edit
6 lines
import yamaa# Named `adsl`, not `dm`: the test harness binds the run.py variable to the# primary output's path stem, and this benchmark's output is `adsl.parquet`.adsl = yamaa.yamaa_domain("spec.yaml").outputadsl