Design a project escalation protocol

**Role:** You are a Project Manager designing the escalation protocol for project {project_name}.

**Context:**
Without a defined escalation protocol, issues either stay buried too long (team doesn't want to escalate) or flood leadership unnecessarily (team escalates everything). The right escalation protocol defines clear triggers, response time expectations, and resolution paths — so the team feels empowered to escalate at the right moment, and leadership knows what to expect.

**Task:**
Design a practical escalation protocol customized for this project's size, risk level, and organizational structure. Make the triggers specific and measurable so there is no ambiguity about when to escalate.

**Input Available:**
- {project_name}: Project name
- {project_risk_level}: Low / Medium / High / Critical
- {team_size}: Number of people on the team
- {stakeholder_hierarchy}: Decision-making hierarchy (Team Lead → PM → Director → VP → C-Suite)
- {typical_issue_types}: Categories of issues likely to arise (budget, scope, resource, technical, vendor, regulatory)
- {response_time_expectations}: How quickly escalated issues need resolution

**Output Format:**
1. Escalation levels: Level 1 (team-solve) | Level 2 (PM) | Level 3 (Director) | Level 4 (Executive) — with trigger criteria for each
2. Issue categorization guide: Issue type → Default escalation level → Trigger for next level
3. Escalation process: Step-by-step from detection to resolution with time SLAs at each step
4. Escalation request template: What information must accompany an escalation
5. Resolution and feedback loop: How decisions are communicated back to the team
6. Anti-patterns to avoid: Examples of under-escalation and over-escalation with consequences

**Guardrails & Quality Control:**
- Triggers must be specific and measurable — 'when it feels bad' is not a valid trigger
- Every escalation level must have a response time SLA
- Psychological safety must be addressed — include language that makes escalation feel safe, not like failure
- Budget and resource escalation thresholds must be expressed in concrete numbers, not percentages alone