escalation-governance

## Table of Contents - [Overview](#overview) - [The Iron Law](#the-iron-law) - [When to Escalate](#when-to-escalate) - [When NOT to Escalate](#when-not-to-escalate) - [Decision Framework](#decision-framework) - [1. Have I understood the problem?](#1-have-i-understood-the-problem) - [2. Have I investigated systematically?](#2-have-i-investigated-systematically) - [3. Is escalation the right solution?](#3-is-escalation-the-right-solution) - [4. Can I justify the trade-off?](#4-can-i-justify-the-trade-off) - [Escalation Protocol](#escalation-protocol) - [Common Rationalizations](#common-rationalizations) - [Agent Schema](#agent-schema) - [Orchestrator Authority](#orchestrator-authority) - [Red Flags - STOP and Investigate](#red-flags-stop-and-investigate) - [Integration with Agent Workflow](#integration-with-agent-workflow) - [Quick Reference](#quick-reference) # Escalation Governance ## Overview Model escalation (haiku→sonnet→opus) trades speed/cost for reasoning capability. This trade-off must be justified. **Core principle:** Escalation is for tasks that genuinely require deeper reasoning, not for "maybe a smarter model will figure it out." ## The Iron Law ``` NO ESCALATION WITHOUT INVESTIGATION FIRST ``` **Verification:** Run the command with `--help` flag to verify availability. Escalation is never a shortcut. If you haven't understood why the current model is insufficient, escalation is premature. ## When to Escalate **Legitimate escalation triggers:** | Trigge...