glm-5.1
4244c054b7
Critical fixes: - Rename qualityDegradation → qualityRetention across all docs (semantically inverted: 0.9 meant 90% quality RETAINED, not 90% degradation). Updated schemas, graph-model, cost-benefit, ADRs. - Add TaskInput → TaskGraphNodeAttributes transformation section to graph-model.md, documenting how Nullable(Optional) input fields map to Optional graph attributes - Fix DuplicateEdgeError fields: source/target → prerequisite/dependent to match the established edge direction convention - Fix resolveDefaults signature: Partial<TaskGraphNodeAttributes> → Partial<...> & Pick<TaskGraphNodeAttributes, 'name'> to require the name field - Move Nullable helper definition before its first use in schemas.md - Fix 'construction never throws' contradiction: rephrase to 'construction enforces uniqueness, not data quality' - Define all 6 enum value sets in schemas.md (previously only TaskScope and TaskRisk were explicit) - Add EvConfig parameter table with defaults and semantics - Document WorkflowCostOptions.limit parameter - Add construction error handling table to graph-model.md - Add graph.raw mutation safety warning to api-surface.md - Update build-distribution.md error class list to include DuplicateNodeError and DuplicateEdgeError
1.4 KiB
ADR-005: No depth-escalation heuristic in v1
Status: Accepted
Context
In the DAG-propagation model, each hop compounds another <1.0 factor. This implicitly captures depth effects — deeper chains have more compounding. An explicit depth-escalation heuristic (increasing risk at deeper chain levels) would add another multiplicative penalty on top.
Decision
Defer depth-escalation to v2. The multiplicative propagation model already captures depth effects implicitly. Adding an explicit depth heuristic would double-count the depth effect until we have empirical calibration data from actual task outcomes.
Consequences
Positive
- No double-counting of depth effects
- Simpler model to explain, implement, and debug
- Architecture supports future depth-escalation via per-edge
qualityRetentionadjustments orriskcategorical escalation without API changes
Negative
- May underestimate cost for very deep dependency chains where risk genuinely escalates with depth
- The model treats all "hops" as equivalent — a 5-hop chain where each step is moderate risk may actually be worse than the model predicts
Future
If empirical data from actual task outcomes shows that depth-escalation is needed, it can be added without API changes — either by adjusting qualityRetention per depth, or by escalating the risk categorical. This is a calibration question, not an architecture question.