Skip to content

Porting guide: derived variables belong in the datamodule, base bindings in the report - #20

Merged
florian6973 merged 1 commit into
mainfrom
docs/porting-guide-predicates
Aug 4, 2026
Merged

Porting guide: derived variables belong in the datamodule, base bindings in the report#20
florian6973 merged 1 commit into
mainfrom
docs/porting-guide-predicates

Conversation

@florian6973

Copy link
Copy Markdown
Owner

Summary

Follow-up to #19 (the featurization backend), addressing two gaps a real port would hit. Docs only — template/docs/PORTING-A-MODEL.md.jinja, all changes inside the data_backend == 'custom_featurization' branch, so the mtd render is untouched.

Derived variables belong in the datamodule. The Step 3 mapping table read as if every source variable needed a predicate, which pushes a port toward inventing predicates for derived quantities (SF ratio, severity scores) — those match nothing, so the column is all-zero and the model is silently blind to a variable the report claims it has. Predicates are deliberately base quantities; deriving from them in datamodule.py is the intended flexibility, and porting a derived variable that way is a ported ledger row, not adapted or omitted. The only real finding is a base variable the dataset does not record.

Required predicates get written down, with evidence. Nothing previously required a port to state which concepts the model needs or how they were bound:

  • Step 1 enumerates the input variable list (base vs derived) before any code, then prescribes the binding workflow: search every MEDS-DEV dataset's predicates.yaml (not just the target — another dataset still tells you the ecosystem's name for a concept), reuse upstream names, and flag each gap as locally written / contributed upstream (preferred: it is per-dataset knowledge) / not recorded by the dataset.
  • Step 5 gains a required-concepts table (concept, source variable, kind, binding, origin, matched events) whose counts are copied from the patients artifact's featurization.match_counts rather than self-reported.
  • Step 7 gains the matching checks, including that no base concept has zero matched events.

Also drops a duplicated model architecture row that #19 introduced into the Step 3 table.

Test plan

  • uv run pytest tests/ -q — 85 passed
  • Both backends render clean: the mtd render contains zero featurization mentions, no stray blank lines from the new conditional blocks, EOF intact
  • ruff check / ruff format --check clean

🤖 Generated with Claude Code

…ngs in the report

Two gaps the TECO port would have hit. First, the Step 3 mapping table read as
if every source variable needed a predicate, which pushes a port toward
inventing predicates for derived quantities (ratios, severity scores) — those
match nothing, so the column is all-zero and the model is silently blind to a
variable the report claims it has. Predicates are deliberately *base*
quantities; derivation from them is what datamodule.py is for, and porting a
derived variable that way is a `ported` ledger row, not `adapted`.

Second, nothing required the port to write down which concepts the model needs
or how they were bound. Step 1 now enumerates the input variable list (base vs
derived) before any code and prescribes the binding workflow — search every
MEDS-DEV dataset's predicates.yaml, reuse upstream names where they exist, and
flag each missing binding as locally written, contributed upstream, or absent
from the dataset. Step 5 gains a required-concepts table whose matched-event
counts are copied from the artifact manifest's featurization.match_counts
rather than self-reported, and Step 7 gains the checks, including that no base
concept has zero matches.

Also drops a duplicated `model architecture` row introduced when the
featurization rows were added.
@florian6973
florian6973 merged commit d75b401 into main Aug 4, 2026
14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant