[ROADMAP] bmyCure4MM — Multiple Myeloma Computational Research Platform

[andreazedda]

bmyCure4MM master roadmap

Project definition

bmyCure4MM is a modular computational research platform for Multiple Myeloma. It integrates longitudinal clinical evidence, Patient Twin state estimation, mechanistic and PK/PD models, exposure and toxicity analysis, clonal evolution, microenvironment and immune modelling, external validation, therapy-design research, drug discovery, causal-analysis protocols, and reproducible hypothesis testing.

Current intended use:

intended_use_level: E1_research_prototype
clinical_decision_support: false
patient_specific_prediction_validated: false
causal_effect_identified: false

Target release:

intended_use_level: E2_reproducible_research
clinical_decision_support: false

Milestone architecture

Milestone	Tracker	Purpose
M0-R — Canonical Scientific Baseline	#26	Canonical code, lineage, input identity, intended use, locked dependencies, run manifests, CI, QA, and documentation
M0-S — Safe Shared Research Platform	#27	Authorization, RBAC, security, quotas, platform architecture, production runtime, API, observability, and governance
M1 — Real-Patient Research Loop v0.1	#28	Source-verified data → observation model → Twin → calibration → exposure-aware toxicity what-if → temporal backtest → report
M2 — Measurement & Evidence Layer v0.2	#29	Evidence registry, biomarker semantics, genomic risk, MRD, imaging, functional outcomes, model and dataset cards
M3 — External Validation & Benchmark v0.3	#59	Governed external datasets, CoMMpass adapter, frozen benchmark tasks, baselines, and external evidence bundle
M4 — Multiscale Multiple Myeloma Model v0.4	#60	Clonal evolution, residual-disease hypotheses, marrow niche, immune recovery, normal lineage, bone and organ states
M5 — Therapy Design & Optimization v0.5	#61	Resistance and escape, multi-drug PK/PD, immunotherapies, Pareto optimization, causal protocol, drug discovery, and adaptive control
M6 — bmyCure4MM Research v1 — E2	#30	First coherent reproducible-research release

Critical paths

Scientific path

#11 canonical Twin lineage
→ #12 intended use
→ #15 dependency lock
→ #19 run identity
→ #13/#23 scientific CI and QA
→ #32 source-verified dataset
→ #33 observation model
→ #34 lenalidomide exposure
→ #35 toxicity attribution
→ #36 calibration and temporal validation
→ #18 Research Loop v0.1
→ M2 measurement and evidence
→ M3 external benchmark
→ M4 multiscale model
→ M5 therapy design
→ M6 Research v1

Shared-platform path

#8 authorization
→ #16 policy/service architecture
→ #20 API and artifact authorization

#9 production security
+ #10 cost controls
+ #15 dependency lock
→ #17 production runtime
→ #21 observability
→ M0-S complete

Decision rule

Prioritize work using:

increase in validity
+ increase in falsifiability
+ increase in external evidence
+ increase in reproducibility
+ reduction in privacy/security risk
-------------------------------------------------------
implementation cost
+ migration risk
+ model complexity
+ validation burden
+ non-identifiability risk

Issue execution contract

Every implementation or research issue must define:

scientific or operational question
current evidence
hypothesis or objective
exact scope and non-goals
inputs, units, sources, and versions
model or system contract
comparators or baselines
validation and falsification criteria
privacy and security impact
output artifacts
version and invalidation impact
rollback or rejection path
allowed and forbidden conclusions

Global completion condition

The roadmap is complete when #30 and #25 close with a reproducible E2 research release. Clinical-pilot, clinical decision-support, regulated/SaMD, or automated-treatment milestones require a separate roadmap and evidence base.

[YossiMH]

A useful release-governance addition would be to make the roadmap's causal stages machine-checkable rather than allowing merged or issue closed to stand in for scientific readiness.

Suggested acceptance gate for every M0–M4 item:

• Implementation evidence: exact commit/PR and deployed or runnable artifact.
• Semantic evidence: before/after examples proving that model, dataset, and report meaning did not drift unintentionally.
• Adversarial evidence: at least one test designed to make the claimed safeguard fail (authorization bypass, lineage mismatch, stale artifact, leakage, overfit, or prescriptive-output escape).
• External validity boundary: explicit statement of what population, time horizon, assay regime, and clinical context the result does not support.
• Rollback evidence: demonstrated recovery path for schema, model, and dataset changes, not only source-code rollback.
• Independent reproduction: for M2 onward, a fresh environment must reproduce the same run identity, inputs, outputs, and report hashes without relying on the original operator's local state.

Then define tracker closure as:

code merged → acceptance evidence attached → independent reproduction passed → known limitations recorded → tracker item closed.

For M4 specifically, I would add one release-blocking invariant: the published Research v1 artifact must make it impossible to confuse a generated hypothesis, fitted patient-specific parameter, or scenario comparison with a validated treatment recommendation. That should be tested across UI, exports, API responses, screenshots, and copied text—not only in prose disclaimers.

This would preserve the roadmap's strongest idea: evidence, not repository activity, determines readiness.