open.gismo · loading your own data · mockup 2 of 2

The bench behind the read

The intake report is the front door and answers four or five questions well. This is the room it sends you to when that is not enough — the fortieth transfer, the column nobody asked about, the judgement only you can make. It is working: bind a column, derive one, declare a constant, decline one, and watch the price move while you do.

What to try, in order

Press Accept identical matches. Then open Raw_SUBJ → subjid: two candidates, both plausible, and the one the alias list ranks first is the one that empties every join in the study. Bind it to USUBJID and press Measure the keys. Take the fix. Then open Raw_AE → aetoxgr and decline it, which is the only thing on any of these pages that lets you tell the product something it never thought to ask.

~/hep-204 — Data › Mapping

open.gismo

HEP-204

Overview
Intake report
Data › Mapping
Displays
Snapshots
Provenance

Data › Mapping · reached from finding 3 of the intake report

The bench

45 targets across the three domains you delivered, of 126 across all 14. Every row carries one of four dispositions, and every one of them writes into workflows/1_mappings/*.yaml — files you own, diff and commit.

0Bound to a source column

0Derived from a step

0Constant for the study

0Declined, with a reason

45Open — no disposition yet

Not run 30 of the 45 targets on this screen are named by a display. 0 of those 30 are settled. Readiness will not change until the mapping has executed against the real files.

Project files

There is no hidden state in this design. Everything above is a diff against files that already exist.

workflows/1_mappings/ · config/setup-log.md

Nothing written yet. Nothing on this screen is pre-filled — every line below is a click.

Two things this screen refuses to do

It never pre-fills a guess

Identical names bind on request and are marked identical. Everything else stays a proposal, printed in the row, until a person clicks it — and the click is recorded in the YAML as # accepted proposal. A data manager who finds one wrong pre-filled row stops trusting the other 125, and re-checking 126 rows by hand is worse than filling them.

It never shows a confidence number

Candidates are ordered and the reason for the order is printed. No score. The guided-setup session measured a value profiler scoring 1.000 on a wrong answer and 0.849 on a right one, on the study open.gismo ships. There is no threshold that admits one and rejects the other, so the number would only transfer the machine's certainty to the reader.

What is real on this screen

The left-hand side. 45 target columns with their declared types, read out of demo-301/workflows/1_mappings/{SUBJ,AE,LB}.yaml this morning.
The consumer counts. Resolved from the 42 metric and module workflows. Mapped_SUBJ$subjid carries 25, $invid and $country 12 each, Mapped_LB$lbtstnam and $lbstresn 7 each, $toxgrg_nsv 3.
The two spec keys. gsm.mapping::ApplySpec reads source_col and type and nothing else, and drops any spec entry whose source column is absent from the file — silently, at every verbosity level. That is the entire seam this screen writes into.
The key measurement. Reproduced on demo-301's own data this session: the long identifier and the short one share 0 of 765 values, and the inner join the study runs returns 0 rows from 57,200.
The delivered column names are constructed — a CRO transport, an EDC event listing and a central-lab extract, written from the CDISC and EDC-vendor conventions. The match rate you see is therefore an upper bound on a real one, which is survivable only because nothing here is ever applied without a click.