Escalation & Stop-Work Policy
QCK WordPress Infrastructure & Dev Governance Framework
1️⃣ Purpose
This policy defines when technical risk requires escalation or controlled pause before work proceeds.
Escalation does not mean refusal. It means:
- Risk documented
- Leadership informed
- Stabilization path proposed
- Timeline adjusted appropriately
2️⃣ Red Risk Triggers
Immediate escalation is required if any of the following are present:
- Master Risk Score = Red (13+)
- No staging environment for structural changes
- Unsupported or abandoned critical plugin
- Headless architecture without repository access
- Rewrite rule uncertainty affecting indexed URLs
- No confirmed backup prior to deployment
- Multiple caching layers with no visibility
- Design Lock not confirmed before development begins
- Permalink changes affecting high-traffic ranking URLs
3️⃣ Headless Escalation Protocol
If the site uses headless architecture:
- Repository access confirmed
- Deployment workflow documented
- Build pipeline understood
- Hosting environment identified
- Rollback plan confirmed
If repository access or deployment clarity is missing:
- Dev does not modify live structure
- Escalate to leadership
- Recommend stabilization phase
- Require documentation before proceeding
4️⃣ Unsupported Plugin Escalation
If a plugin is classified as 🔴 Red, escalation is required.
Typical Triggers
- No updates in 12+ months
- Marked incompatible with current WordPress
- Custom undocumented code
- Security vulnerabilities
- Critical WooCommerce override conflicts
Required Action
- Document plugin risk
- Notify AM
- Present options to the client
Option A
Replace plugin
Option B
Controlled refactor in staging
Option C
Proceed under Limited Infrastructure Scope
5️⃣ No Staging Policy
Structural changes include:
- Permalink changes
- CPT creation
- Template overrides
- WooCommerce checkout modifications
- Major CRO experiments
If no staging environment exists, the following options should be considered:
Option A
Client provides staging
Option B
Temporary staging created
Option C
Controlled deployment window defined
Option D
Proceed under Limited Infrastructure Scope
6️⃣ Limited Infrastructure Scope Rules
Limited Infrastructure Scope applies when:
- Hosting access denied
- CDN visibility denied
- Server configuration unknown
- No staging available
- Backup system not confirmed
Under Limited Scope:
- Dev operates only at application layer
- No server-level guarantees
- Redirect behavior depends on unknown configuration
- Cache performance cannot be guaranteed
- Rollback depends on client infrastructure
7️⃣ Stop-Work Authority
Stop-Work may be recommended if:
- Structural risk is extreme
- Deployment safety cannot be confirmed
- Rewrite logic is unclear
- Backup is not verified
- Client declines all stabilization options
- Red Risk Score with no mitigation
Stop-Work means:
- Pause structural changes
- Document risk
- Align leadership
- Propose stabilization phase
8️⃣ Escalation Communication Template (Internal)
Subject: Escalation — Infrastructure Risk Identified
Client: __________________
Project: __________________
Trigger Identified: __________________
Risk Summary:
__________________
Recommended Action:
__________________
Timeline Impact:
__________________
9️⃣ Escalation Communication Template (Client)
Hi [Client Name],
During our technical review, we identified infrastructure constraints that increase implementation risk.
Before proceeding with structural changes, we recommend addressing the following:
- __________________
- __________________
Our goal is to protect stability, SEO integrity, and long-term performance.
We will proceed carefully and align on next steps.
🔟 Governance Philosophy
Escalation exists to:
- Protect rankings
- Protect revenue
- Protect conversions
- Protect timelines
- Protect team morale
1️⃣1️⃣ Final Rule
Responsibility is shared, but clearly defined:
Dev
Responsible for identifying structural risk
AM
Responsible for expectation alignment
Leadership
Responsible for final go/no-go decision when Red triggers exist