Ethical Limits and When to Leave

Two pre-commitments, built together because they are the same machinery at different thresholds. First, the Ethical Limits Document: what you will not do regardless of consequence, what you will do only with documented objection, and the conditions under which exit becomes obligatory. Second, the stay-or-leave framework: the honest math of remaining in a degraded environment versus leaving it, run on your actual current configuration. Ethical limits are input validation. Without explicit validation, constraints are implicit in downstream behavior — bad inputs cause weird failures far from the boundary, state corrupts, and the app appears to work until it doesn't. With validation at the boundary, rejection is automatic, cheap, and legible. Section 2 is the deprecation warning: the call still goes through, but a record is created that flags it for review — the warning phase is what gives the system time to fix the underlying cause before the action becomes an error condition. Section 3 is the circuit breaker: thresholds calibrated in advance, in calm conditions, so the breaker trips automatically when conditions are met. Without calibration the breaker trips too early (every difficulty becomes an exit conversation) or too late (you stay through conditions that should have triggered exit months earlier). And the five-cost-category analysis is the breaker threshold for the slow-degradation case: when the system is degrading and recovery isn't credible, fail fast. Most engineers stay because they confuse loyalty with sunk cost and "things might get better" with a strategy.