Prefer the newest viable technology inside the requested work. This is a bias,
not permission for an unrelated upgrade sweep or novel architecture.
software-engineering-excellence remains the governor; maintainability wins
ties.
Stability ladder
| Rung | Policy |
|---|---|
| Newest stable | Default, including newly released majors |
| RC, beta, canary | Only for a concrete need or low-risk reversible trial |
| Nightly | Only for a documented blocker it resolves |
For an AI model, generally available releases are the stable rung and preview or experimental releases are pre-release. Confirm the model identifier, availability, and deprecation or retirement schedule from the provider's current model documentation; remembered model names go stale quickly.
Adoption contract
For every choice:
- Verify version and release status from the registry or official release notes.
- Read relevant migration notes and check known blockers for the use case.
- Pin any pre-release or nightly exactly.
- Record the reason, tradeoff, rollback path, and fallback when climbing beyond stable.
- Run the project's real validation gate without weakening it.
- Prefer the newer option only when capability, security, performance, developer experience, or longevity outweighs instability and churn.
Existing decisions
Project AGENTS, stack skills, and recorded decisions remain authoritative. Advance within an already chosen tool; never silently replace it. If another tool now appears materially better, present the evidence and tradeoff for human decision.
When the choice remains uncertain, state the rung and unresolved risk instead of quietly choosing the most novel option.