Article 6: The override protocol

The sixth article in my personal coding constitution is the rule that protects all the other rules from themselves. Every article in this series can be overridden. The override is a written-down, time-bound, recorded, reviewed-after action. It is not a thing you do quietly. It is not a thing you do twice in a row without somebody noticing.

The rules exist for a reason. The override is the escape hatch, not the habit.

I had to write this one down because I noticed the failure mode in myself before I noticed it in anyone else. The rules in this constitution are uncomfortable on purpose, the discipline is the discomfort. The first time you skip one, the world doesn't end. The second time, you've started a pattern. The fifth time, the rule isn't a rule anymore. It's a sticker on a wall. The constitution has rotted into theater and you can't tell, because the rot was small-step and quiet.

Article six is the rule that stops the rot. It says: yes, you can override. Here's exactly how. And every time you do it, the override leaves a mark, and the mark is reviewed.

What the override actually is

The override is not "I don't feel like following the rule today." That's not an override. That's an unlogged violation, and an unlogged violation is the start of the failure mode the rule is built to prevent.

The override is a written, time-bound, recorded action that says: for this specific situation, the cost of following the rule is greater than the benefit, and the deviation will be cleaned up by a specific date with a specific person responsible. It is shaped exactly like the issue the rule normally requires, title, intent, scope, clock.

Concretely, an override has four parts.

The justification. One paragraph on why the rule isn't fitting this situation. Not a vibe. A specific reason. "The rule says no destructive operation without a backup, but the disk is full and the only way to make room is to delete the partial dump that failed last night, and I have already verified it's the partial dump and not anything else." Specific enough that somebody reading it cold a month from now can decide whether the call was right.

The scope. What the override covers and what it doesn't. The line that stops the override from being a free pass. "Override applies to deleting /var/lib/dumps/2026-05-04.partial. Does not apply to anything else under /var/lib/dumps. Does not apply to future cleanups." The scope line keeps the override surgical.

The clock. When the override expires. Every override has an expiration. Some expire when the action completes. Some expire after the cleanup ("override stands until I've restored the missing audit log, target end-of-week"). None expire never. The override without a clock is the one that becomes the new normal.

The reviewer. Who looks at the override after the fact and confirms the call was right, or that the rule needs to change, or that the override should not have been granted. For solo work, the reviewer is future-me on a recurring calendar. For team work, a person with a name. The review isn't optional. It's the part that makes the discipline real.

If any of those four parts is missing, it isn't an override. It's just a violation with a paper trail.

Why the documenting is the discipline

Here is the thing that's easy to get wrong about this rule. The discipline isn't in the deciding to override. The discipline is in the writing down of the override.

I notice when I'm about to skip a rule. Most engineers do. The moment when "I'll just override this once" enters my head is itself a signal, the brain produces it because the brain knows the rule is supposed to apply. The signal is not the problem. The problem is what happens next. The lazy version of next is: I skip the rule, I do the thing, the thing works, I move on. No artifact. No memory of the skip. No review.

The override protocol is the friction that makes the skip expensive enough to be honest about. Writing the four-part override takes three minutes. Three minutes is more than zero. The three minutes is the price the protocol charges for the skip, and that price is what does the work.

Three minutes is enough that I won't pay it for the typo fix. Three minutes is also enough that, when I do pay it, I'm forced to say why the rule shouldn't apply, and saying the why is what surfaces the cases where the answer is actually "the rule should apply, I'm just impatient." About a third of the times I sit down to write an override, the act of writing it convinces me to follow the rule instead. That third is the discipline doing its job in the other direction.

The other two-thirds, I write the override, do the thing, and the artifact is there for the review.

The "I'll just override this once" failure mode

The single most dangerous sentence in any engineering culture is "I'll just override this once." It is the sentence that shows up at every site of constitutional rot I have ever seen, in my own work and in other people's. It turns a constitution into a wall sticker.

The sentence is dangerous for three reasons, and the protocol is built to defeat each one.

"Once" is rarely once. The conditions that produced the first override (pressure, fatigue, an external clock) are conditions that come back. The next time they show up, the precedent is "we overrode last time, and it was fine." The exception becomes the normal, and the normal accelerates because each next override has the previous one as cover. The protocol defeats this by making every override individually expensive. The fifth doesn't get to ride on the precedent of the first. It has to stand on its own justification, written from scratch.

"Once" is unmemorable. An undocumented override leaves no record. Six months later, when the consequence shows up, the system load-bearing on a tweak nobody recorded, the audit that asks where the deviation came from, there's nothing to read. The protocol defeats this by requiring the artifact. Article five (track everything) was partly written to make article six possible.

"Once" hides the trend. If overrides are unlogged, you don't know whether you're overriding the same rule weekly or yearly, whether they cluster around a particular system, a particular pressure. The signal that a rule needs rewriting is in the pattern of overrides, and the pattern is invisible without the records. After a quarter of them, the question becomes: is the rule wrong, or is the situation wrong? Either way, the next move is visible.

What the review is for

The review is the part of the protocol that's easiest to skip and most expensive to skip.

The review is not "did the override work?" Of course it worked. That's why I overrode the rule, because I had a specific outcome in mind and I got it. The review is two questions, both harder.

Should the override have been granted? Knowing what we know now, with the immediate pressure gone, was the deviation actually warranted? Or did I talk myself into a skip the rule was correctly designed to prevent? This question is uncomfortable because the honest answer is sometimes no. Sometimes the override was a mistake and the rule was right. Naming that out loud is the only way the rule keeps its teeth.

Does the rule need to change? If the override was correctly granted, the question becomes whether this is a new edge case the rule should encode directly. A rule that needs to be overridden quarterly is a rule that's slightly wrong; a rule that needs to be overridden weekly is a rule that's badly wrong. The review is where the constitution gets amended. Without it, the rules drift further from the situations they govern, and the override rate climbs, and eventually the constitution is honored only in the breach.

The review is what closes the loop. The justification surfaces the reason. The scope surfaces the boundary. The clock surfaces the expiration. The review surfaces the lesson. All four parts are needed, or the protocol degrades into paperwork that doesn't actually defend anything.

Where this rule sits in the constitution

Article six is shaped differently from the rules that came before it. Articles one through five tell me how to act. Article six tells me what to do when I'm not going to act that way. It's the meta-rule (the rule about the rules) and it's the one that keeps the rest of the rules from rotting.

The rule pairs with article one's no-issue-no-code directly. The override is itself an issue. Same shape, title, intent, scope, conversation. Every action that touches the system is attached to a tracked artifact, and the override is no exception. That's what makes it real.

The rule pairs with article five's track everything just as directly. The override is a state mutation in the rule-system, and it has to be in the trail. Without the trail, there's no review. Without the review, there's no protocol.

And it pairs with article four's three-strikes in a subtler way. Both rules are about admitting the model isn't working. Three-strikes admits the technical model isn't working. The override admits the constitutional model isn't fitting the situation. Both require you to stop, name what's true, and act on the new information instead of pushing through.

What the rule is really about

The article looks like it's about overrides. The rule underneath it is about honesty. A constitution that can't be overridden is a constitution that gets violated quietly. A constitution that can be overridden without documentation is a constitution that gets violated loudly. The protocol is the third option: a constitution that can be deviated from, openly, with a record, with a review, and with the deviation rate as a signal about whether the constitution still fits.

The other articles tell me how to keep the system honest. This one tells me how to keep the rules honest about themselves. The override isn't a weakness in the constitution. It's the mechanism that keeps the constitution from becoming a sticker on a wall.

So: the rules exist for a reason. The override is the escape hatch, not the habit. Justified, scoped, clocked, reviewed. Skip any of those four and you don't have an override, you have the start of the rot the constitution was written to prevent.

, Sid