Feature Kill Switch Criteria

Template Overview

When deploying new software features, teams are vulnerable to escalation of commitment: hoping an alarming error spike is a temporary blip rather than an active disaster. The Feature Kill Switch Criteria template establishes objective, non-negotiable numerical thresholds that mandate an immediate feature rollback or disablement. It documents the exact command sequences, responsible roles, and verification procedures to de-risk feature launches.

Markdown Template Structure

Copy the block below or click Download .md File to add this template directly to your personal vault:

---
title: "Kill Switch Spec: [Feature Name / Flag Key]"
date: [YYYY-MM-DD]
launch_owner: "[[Feature Lead / PM]]"
on_call_engineer: "[[SRE / Tech Lead]]"
feature_flag_key: "ff_[feature_name]_enabled"
canary_percentage: [e.g., 5% / 25% / 100%]
tags: [feature-flags, kill-switch, sre, rollback, launch-safety, incident-prevention]
---

# Feature Kill Switch Criteria — [Feature Name]

## 1. Feature Context & Rollout Strategy
- **Feature Name:** `[e.g., Local Streaming Whisper Transcription Pipeline]`
- **Feature Flag Key:** `ff_local_whisper_streaming`
- **Rollout Schedule:** Canary 5% (Day 1) → 25% (Day 3) → 50% (Day 5) → 100% GA (Day 7).
- **Target Impact:** 4x faster real-time transcription rendering for active desktop users.

## 2. Objective Kill-Switch Activation Thresholds
*If ANY SINGLE metric below crosses the specified redline threshold, the feature MUST be immediately killed without debate:*
| Monitored Metric | Baseline Value | Warning Threshold | **KILL SWITCH REDLINE** | Telemetry Query / Monitor URL |
|---|---|---|---|---|
| Application Crash Rate | 0.05% sessions | > 0.15% sessions | **≥ 0.50% sessions** | Datadog `trace.client.crashes` |
| Peak Memory Consumption | 380 MB | > 650 MB | **≥ 950 MB (OOM risk)** | `macos.process.resident_size` |
| Audio Ingestion Dropped Frames | 0.01% frames | > 0.10% frames | **≥ 0.50% frames** | `audio.buffer.dropped_packets` |
| Negative User Bug Tickets | 2 / day | > 6 / day | **≥ 15 tickets in 4 hours** | Linear Tag `#regression-v2.4` |

## 3. Instant Kill-Switch Execution Protocol
*Step-by-step instructions executable by any on-call engineer within 60 seconds:*
### Step 1: Flip Remote Feature Flag
```bash
# Disable flag via API or CLI
curl -X PATCH "https://flags.internal/api/v1/flags/ff_local_whisper_streaming"   -H "Authorization: Bearer $FLAGS_ADMIN_TOKEN"   -d '{"enabled": false, "reason": "Redline crash threshold breached"}'

Step 2: Invalidate Edge Cache

# Flush edge flag cache immediately
pnpm flags:flush-cache --flag ff_local_whisper_streaming

Step 3: Broadcast Rollback in Incident Channel

• Post in #incidents-production: ”🚨 KILL SWITCH ACTIVATED for ff_local_whisper_streaming. Feature disabled globally. Investigating crash spikes.”

4. Safe Fallback Behavior Verification

• Application automatically reverts to standard chunked transcription engine with zero user crash dialogs.
• Active audio recordings remain safe and uncorrupted on local disk.
• System memory returns to normal baseline (<400MB) within 15 seconds.

5. Post-Mortem & Re-Rollout Conditions

• The feature flag must remain permanently disabled until:
  1. The root cause of the memory spike is isolated and reproduced in local staging.
  2. A regression unit test is merged into main.
  3. A 24-hour canary run passes clean on internal dogfooding devices.

## Filled Real-World Example

Here is a realistic example demonstrating how this template captures actual deliberations:

```markdown
---
title: "Kill Switch Spec: Core ML Neural Quantization Engine"
date: 2026-10-09
launch_owner: "[[Marcus Vance]]"
on_call_engineer: "[[David Chen]]"
feature_flag_key: "ff_coreml_neural_quantization"
canary_percentage: 10
tags: [feature-flags, kill-switch, sre, rollback, launch-safety, incident-prevention]
---

# Feature Kill Switch Criteria — Core ML Neural Quantization Engine

## 1. Parameters & Redlines
- Crash Redline: ≥ 0.25% of audio sessions crashing.
- Memory Redline: ≥ 800MB resident set size.
- Verification: Audio recordings must never be lost under any crash condition.

## 2. Emergency Trigger
- Command: `gh workflow run disable-flag.yml -f flag=ff_coreml_neural_quantization`
- Immediate fallback: System falls back to CPU float16 Whisper engine within 200ms without interrupting active recording.

When to Use and When to Avoid

When to Use

• Use prior to launching any major backend architecture change, client algorithm update, or UI overhaul.
• Use to establish cold, emotionless guardrails before rolling out canary flags.
• Use to empower junior on-call engineers to shut down failing features without fear of managerial blame.

When to Avoid

• Avoid using for minor documentation or static marketing landing page copy updates.
• Avoid using when a feature cannot be toggled independently via feature flag or configuration.

On-Device AI Integration

Summarize your recording in Oyma with this local instruction:

Review the feature kill switch criteria:
1. Verify that the rollback instructions can be executed cleanly in under 60 seconds without complex dependencies.
2. Confirm that the fallback state leaves customer data completely uncorrupted.
3. Check that the redline thresholds are statistically distinguishable from normal operational noise.
Output in structured Markdown.

Your data remains securely on your Mac with zero cloud exposure.