Parent map: #1
Decision to resolve
How should TinyHarness evolve native explicit model routing into automatic model selection that remains visible and overridable?
Product requirement
Choose models according to task or prompt type, difficulty, capability, latency, and cost; briefly explain the choice and allow override. Preserve native routing capabilities by default.
Questions
- What routing behavior already exists and where does it apply?
- Should routing occur per session, user turn, plan task, or provider retry?
- Which signals are reliable without adding another expensive model call?
- When must the user choice override automation?
- How are unavailable models, routing failure, and mid-session model changes handled?
- What observations are needed to evaluate routing quality later?
Output
A recommended product behavior and measurable routing policy boundaries, not an implementation.
Resolves when
Automatic routing has predictable user control, fallback, and visibility semantics.
Parent map: #1
Decision to resolve
How should TinyHarness evolve native explicit model routing into automatic model selection that remains visible and overridable?
Product requirement
Choose models according to task or prompt type, difficulty, capability, latency, and cost; briefly explain the choice and allow override. Preserve native routing capabilities by default.
Questions
Output
A recommended product behavior and measurable routing policy boundaries, not an implementation.
Resolves when
Automatic routing has predictable user control, fallback, and visibility semantics.