Overview
A living tracking issue for the project's identified delivery risks, their
observable trigger conditions, pre-committed mitigation actions, and the
scope-reduction ladder to apply if delivery capacity is exceeded. The goal
is to make scope-cut decisions explicit and pre-agreed rather than
improvised under pressure, and to keep "compress quality" explicitly off
the table as a mitigation.
Background
This is a capacity-constrained project with limited maintainer bandwidth.
Rather than silently slipping deadlines or silently cutting corners, risks
and their mitigations are written down ahead of time so that when a trigger
condition is observed, the response is already decided.
Core Objectives
1. Maintain the risk register
- Numerical-precision risk: bath coefficient precision insufficient after a
backend/precision change
- Performance-regression risk: a generalization pass degrading a previously
specialized fast path
- Packaging-maturity risk: wheel build CI instability
- Physics-boundary risk: unit/frame/rotating-frame ambiguity between HELIX
and its consumer
- Partitioning-feasibility risk: multi-GPU strong-scaling POC failing
- CPU-performance risk: CPU backend falling short of a useful fraction of
single-GPU throughput
- Upstream-API risk: a reference library's HEOM API introducing a breaking
change
- External-resource risk: limited access to multi-GPU test hardware
2. For each risk, record
The observable trigger condition, the specific scope/plan change it causes,
and the escalation threshold if the mitigation itself doesn't resolve it.
3. Maintain an explicit, ordered scope-reduction ladder
Apply one cut at a time, observe before applying the next. Never apply
"reduce correctness tolerance" as a mitigation.
4. At each shipped increment, log
What shipped, any risk triggered, what scope was deferred as a result, and
what risk to watch for the next increment.
Success Criteria
| Metric |
Target |
| Every active risk has a written trigger condition and mitigation |
100% coverage |
| Scope reductions applied one at a time with an observation window |
process followed |
| Mitigations that loosen a correctness tolerance |
0 instances |
Dependencies
Cross-cutting; informed by all other Epics, blocking none of them.
Overview
A living tracking issue for the project's identified delivery risks, their
observable trigger conditions, pre-committed mitigation actions, and the
scope-reduction ladder to apply if delivery capacity is exceeded. The goal
is to make scope-cut decisions explicit and pre-agreed rather than
improvised under pressure, and to keep "compress quality" explicitly off
the table as a mitigation.
Background
This is a capacity-constrained project with limited maintainer bandwidth.
Rather than silently slipping deadlines or silently cutting corners, risks
and their mitigations are written down ahead of time so that when a trigger
condition is observed, the response is already decided.
Core Objectives
1. Maintain the risk register
backend/precision change
specialized fast path
and its consumer
single-GPU throughput
change
2. For each risk, record
The observable trigger condition, the specific scope/plan change it causes,
and the escalation threshold if the mitigation itself doesn't resolve it.
3. Maintain an explicit, ordered scope-reduction ladder
Apply one cut at a time, observe before applying the next. Never apply
"reduce correctness tolerance" as a mitigation.
4. At each shipped increment, log
What shipped, any risk triggered, what scope was deferred as a result, and
what risk to watch for the next increment.
Success Criteria
Dependencies
Cross-cutting; informed by all other Epics, blocking none of them.