Define your error budget in writing

When This Fires

• When setting up monitoring for any recurring system (habits, processes, workflows)
• When you find yourself constantly anxious about whether a system is "working" — an error budget provides clarity
• When deviation investigations happen either too frequently (reacting to noise) or too rarely (ignoring real problems)
• Complements A complete feedback loop needs three elements (feedback loop components) with the monitoring and tolerance specification

Common Failure Mode

Vague standards without numeric thresholds: "My writing practice should be consistent." What's consistent? 5 days a week? 4? 3? Without a numeric threshold, every minor deviation triggers self-judgment, and every major deviation gets rationalized. "I write 4 out of 5 weekdays, and 3 is my minimum — below 3 for two consecutive weeks triggers investigation" is an error budget. "I should write consistently" is not.

The Protocol

(1) For each system you want to monitor, write four components: Ideal: "This system runs optimally when [specific, measurable description]." Example: "When I write for 30+ minutes on 5 out of 5 weekdays." Minimum acceptable: "The minimum acceptable performance is [specific, measurable]." Example: "Writing for at least 15 minutes on at least 3 weekdays." Deviation threshold: the numeric gap between ideal and minimum. This is your error budget. Example: "Up to 2 missed days per week is within budget." Investigation trigger: "If performance falls below minimum for [time window], investigate." Example: "Two consecutive weeks below 3 sessions triggers root cause analysis." (2) Write these down. Unwritten error budgets don't survive memory distortion. (3) Monitor against the written budget. Within budget → accept and continue. Budget exhausted → investigate (When error budget is exhausted, analyze the pattern…).