Add a few metrics in gsm.safety

[jwildfire]

gsm.safety is currently focused on charts from the clinical data, but could also include metrics and flags similar to the gsm.kri framework. Create a few metrics participant level metrics. start my proposing a set of metrics that make sense from our current charts (e.g. hy's law participants)

[obotclaw[bot]]

Filed as #138 — Requirement: participant-level metrics and flags in gsm.safety — a 2_metrics phase over the existing charts: #138

The gap is real and narrower than it looks: gsm.safety has the chart half of the gsm.kri architecture and none of the metrics half — inst/workflow/ holds only 3_reports/, there is no 2_metrics/ phase, and there is no Analyze_* / Flag / Summarize call anywhere in R/. The machinery itself is already available through gsm.core, which gsm.safety imports. Participant-level is a supported but rare pattern rather than a new invention: gsm.kri's pat0015.yaml runs GroupLevel: Subject with Model: Identity and GroupID == subjid, which is exactly the shape a Hy's Law flag takes — a deterministic rule scored by Analyze_Identity and cut by Flag thresholds, not a Poisson or normal-approximation rate model.

The issue leads with the proposed metric set you asked for: five candidates drawn from the widgets already in the package. The hep-explorer and QT thresholds are taken from the shipped inst/schema/*.json cuts and marked verified; the shift, AE and outlier rows are marked proposed — not in repo config, since no threshold for those exists in the repo yet. It is a superset to trim, and it is deliverable one — nothing gets built before you cut it down.

One gate is called out up front: the proposal must report actual flagged-participant counts against demo data before a metric is accepted. The nepExplorer pass on #35 measured demo data with zero participants above the KDIGO Stage-1 line, and a metric set that flags nobody fails the same way — on paper it reads fine.

Six decisions (D1–D6) are left open on the issue, including how this deconflicts with #9's Derive_* layer (its derived columns are plausibly the input here, not a competing implementation) and whether 2_metrics/ is created now or after #136's phase rename lands. The issue recommends a session-level design pass to resolve them before tasks are filed. Labeled draft — the metric table is a proposal, not a signed design.

Closing this as resolved; refinement continues on #138.

---

This was drafted by obot ideas-triage (Claude Code headless using Opus 5) — review by @jwildfire

🧮 run cost: 1307.5k tokens in / 23.7k out · ~$3.04 (Opus 5 orchestrator + subagents)