Reject Invalid Sex

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.

Task: Is this a specification error a study team could realistically make, and should the build stop on it rather than continue?
Inputs: Do they trigger the failure for the reason the summary gives?
Expected failure: Is this the right error, raised at the right point, and would it tell the programmer what to fix?

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

Summary

EditUnder reviewWhat this benchmark means

README.md

Goal: carry the recorded sex (SEX) for each subject from collected demographics, accepting only the study codes M and F.

Input: collected demographics with study and subject identifiers and recorded sex (SEX).

Variables:

SEX is the subject's recorded sex, copied from collected SEX, and blank when none was recorded. Only the exact codes M and F are recognized, so a lowercase m, an X, or a U is not accepted.

A code the study does not recognize rejects the run at the final check, after the values are derived, so no artifact is accepted.

How to fix

Correct the offending records at collection: m, X, and U are not codes the study defines, so query the sites for the subjects' sex. Widen the accepted codes only when the study genuinely admits another value, such as U for unknown:

verifications:
  - allowed_values:
      values: [M, F, U]

Expected failure

Editthe run is rejected; no artifact is accepted

expected/error.yaml

phase: verification
condition: allowed_values_failed
requirement: REQ-0376

expected/error.yaml

phase: verification
condition: allowed_values_failed
spec_paths:
  - columns.SEX.verifications[0].allowed_values
requirement: REQ-0376
context:
  column: SEX
  failure_count: 3
  keys:
    - STUDYID: YAMAA-01
      USUBJID: YAMAA-01-104
    - STUDYID: YAMAA-01
      USUBJID: YAMAA-01-105
    - STUDYID: YAMAA-01
      USUBJID: YAMAA-01-106

YAML specification

1 spec file

spec.yaml

Edit30 lines

1schema_version: "1.0"2domain: ADSL3keys: [STUDYID, USUBJID]4input:5  DM: input/dm.csv67output:8  path: adsl.csv9  columns: [STUDYID, USUBJID, SEX]1011columns:12  - name: STUDYID13    type: str14    label: Study Identifier15    derivation: DM.STUDYID1617  - name: USUBJID18    type: str19    label: Unique Subject Identifier20    derivation: DM.USUBJID2122  - name: SEX23    type: str24    label: Sex25    derivation: DM.SEX26    # Checked once SEX is derived: any non-missing code other than M or F27    # fails the run. A missing sex passes this check.28    verifications:29      - allowed_values:30          values: [M, F]

Inputs

Under review1 source file

input/dm.csv

Edit6 rows

input/dm.csv
STUDYID	USUBJID	SEX
YAMAA-01		M
YAMAA-01		F
YAMAA-01		—
YAMAA-01		m
YAMAA-01		X
YAMAA-01		U

Unexpected Output

Under reviewNo artifact is produced

No fixture files in this directory.

Shaded columns are derived— = missing value

Comments and assessment materials

Dataset Name	Variable Name	Variable Label	Type	Codelist/Controlled Terms	Computational Method	Origin
ADSL	STUDYID	Study Identifier	character		Copy value from DM.STUDYID.	Predecessor
ADSL	USUBJID	Unique Subject Identifier	character		Copy value from DM.USUBJID.	Predecessor
ADSL	SEX	Sex	character	M, F	Copy value from DM.SEX.	Predecessor

Variable	Permitted values
SEX	M, F

Version	Date	Author	Description
1.3	2026-09-29	yamaa docs build	Show study codelist names, external dictionaries, and ISO 8601 formats in variable rows; list the document's codelist values and metadata
1.2	2026-09-29	yamaa docs build	Classify ADaM copies from a declared input as Predecessor and recodes as Derived, and SDTM recodes of locally derived columns as Derived
1.1	2026-09-29	yamaa docs build	Resolve lookups into the donor record they select, and give every derivation shape a plain-language rule instead of its raw YAML
1.0		yamaa docs build	Initial generation from spec.yaml

How to fix

input/dm.csv

Comments

Mapping spec