Skip to content

Derive accepted age boundaries from reference metadata and table extents #109

Open

Description

@pacharanero

Problem

Reference age domains are currently encoded in several places: hard-coded checks in reference modules, age-grid constants, table contents, and hybrid-reference selection logic. These can drift. Issue #100 exposed one example in the UK Trisomy 21 BMI reference: the source and runtime tables end at 18.92 years, while code rejected ages above 18.82.

The canonical source collection is being developed in rcpch/growth-references. It is incomplete, but should ultimately supply the source data and applicability metadata from which runtime tables are generated.

Goal

Make accepted age domains data-driven for every reference, measurement, and sex while preserving clinically intentional boundaries and overlap precedence.

Raw first/last table coordinates alone are not always the clinical domain. WHO and UK-WHO tables contain overlap or source rows outside the interval owned by that segment, and hybrid references have policy-based boundary precedence. The model must therefore distinguish:

  • observed table extent;
  • clinically supported applicability interval;
  • inclusive or exclusive endpoints;
  • overlap ownership and precedence;
  • measurement-specific and sex-specific availability;
  • interpolation allowed only within a selected series, never extrapolation beyond it.

Proposed approach

  1. Inventory the observed minimum and maximum ages for every runtime LMS series by reference segment, measurement, and sex.
  2. Add explicit machine-readable applicability metadata alongside each canonical source reference in rcpch/growth-references.
  3. Generate or validate runtime JSON and age-grid metadata from those canonical sources rather than manually copying independent literals.
  4. Centralise reference selection and domain validation around this metadata.
  5. Retain explicit policy for hybrid and overlapping references, including exact two-year and five-year ownership rules.
  6. Fail build-time validation when a declared applicability interval lies outside the available table extent or when generated runtime data drift from the canonical source.

Acceptance criteria

  • No measurement-specific age boundary is duplicated as an unexplained literal in calculation code.
  • Every reference/measurement/sex combination has a declared applicability interval and source provenance.
  • Exact first and last accepted ages succeed; math.nextafter() immediately outside each endpoint fails with a specific error.
  • Interpolation is permitted only between available points in the selected series.
  • Hybrid-reference overlap behavior remains explicitly tested and unchanged unless separately clinically approved.
  • Runtime packaged tables can be reproducibly generated or verified against rcpch/growth-references.

Related

  • Immediate T21 BMI boundary correction: forthcoming PR for the confirmed 18.92-year endpoint.
  • rcpch/growth-references/trisomy21/UKReference/LMS_Downs.xlsx is the checked source for that correction.
  • Existing WHO and UK-WHO exact-boundary tests provide a pattern for endpoint coverage.

Activity

  1. pacharanero commented on Sep 5, 2026

    @pacharanero
    MemberAuthor

    The immediate confirmed T21 BMI correction is now in #110. The source workbook and packaged JSON both end at 18.92 years; #110 aligns the guard without changing reference data and adds exact endpoint/math.nextafter() tests.

  2. pacharanero commented on Sep 24, 2026

    @pacharanero
    MemberAuthor

    The immediate Trisomy 21 BMI endpoint mismatch is now fixed by #110; the broader reference-domain/source-metadata work remains open, so this issue stays active.

  3. pacharanero commented on Sep 24, 2026

    @pacharanero
    MemberAuthor

    The immediate BMI mismatch is corrected on #110: BMI now accepts 18.92, rejects the next representable float above it, and passes all four Python CI versions. The broader metadata-driven age-domain goal remains tracked in roadmap R25, so this issue stays open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions