A team runs a two-lane trial: two crews implement the same set of tasks in parallel, and the outputs will be compared task by task at the end. Before the trial starts, they make a defensible call: Lane A's output will not be integrated to main until the trial closes.
Three good reasons, all written down. Comparability: both lanes must fork from the same frozen base, and an integration landing mid-trial changes the ground under the comparison. Safety: Lane A is autonomous agent work, unvetted, and unvetted work belongs off main. Focus: the branch is live and mid-task, and an integration merge would collide with work in flight.
Hours later, the ledger reads one hundred and sixteen commits of integration debt spanning a milestone and a half of features. The rule that demanded reviewed, per-task integration has manufactured its opposite: a single mega-merge that will carry maximal conflict surface, review fatigue, and every discovery compressed into one dangerous session. Nobody broke the rule. The rule broke its own purpose.
The decision was right when it was made. It expired while everyone was still obeying it.
What expiry means
A decision is an answer to a condition, and conditions drift. Definition worth keeping: a decision expires at the moment when continued compliance starts producing the exact failure the decision was adopted to prevent.
That is a sharper test than "is the decision still comfortable," because comfort is a terrible instrument. Every rule develops constituents, habits, and sunk costs that feel like reasons. The failure-reversal test reads the rule against its own original purpose instead, and purpose does not flatter.
The deferral rule passes the test at trial start: deferring integration protects comparability and protects main. It fails the test hours later, when the accumulating un-integrated work has become the risk. The debt is not an accident that happened near the rule. The debt is what the rule does now.
There is also a measurable tell, and it deserves its own sentence: when the cost of waiting compounds instead of staying flat, a rule has outlived its rationale. A rule whose wait cost is constant can be obeyed indefinitely at the same price. A rule whose wait cost grows the longer you comply, conflicts aging, discovery compressing, review surface thickening, is quietly converting your compliance into the thing you adopted the rule to avoid. Compounding wait cost is the smoke alarm of expired decisions.
This is Most Technical Debt Is Deferred Judgment, Not Bad Code with the clock made explicit. Deferred judgment is expensive because the unmade decision keeps accruing interest. An expired decision is worse in one respect: the judgment was made, correctly, and the interest accrues anyway, because the world the judgment answered has moved.
How do you know a decision has expired?
Three checks, in order of cheapness.
Read the rule against its own purpose. Ask what failure the rule was adopted to prevent, then ask whether compliance is currently producing that failure. The deferral rule was adopted to prevent unreviewed integration. It ended by scheduling the least reviewable integration of the project. The reversal is visible to anyone who asks the question; almost nobody asks, because questioning a correct decision feels like indiscipline.
Watch the wait-cost curve. Flat cost, the rule can stand. Compounding cost, the rule is now a debt engine with a mission statement. The number to watch is not the debt size alone but its growth per unit of obedience: how much additional merge risk did this hour of deferral add versus the last hour.
Check whether the condition still exists. Decisions are answers to conditions. The deferral answered three: comparability, safety, focus. At trial start, all three held. By evening, the safety condition had been softened by the gate evidence each slice had accumulated, and the comparability condition, it turns out, was never quite what the team thought it was. Which is the second half of this story.
The invariant was smaller than the rule
Here is the move that dissolved the dilemma, and it is the most transferable part of the episode.
The team believed trial comparability required keeping main frozen. That belief created the trap: integrate and bias the trial, or defer and drown in debt. But comparability never required a frozen main. It required that both lanes fork from the same base. The trial base is a tag, and tags do not move. Lane B forks from the frozen tag tomorrow exactly as it would have yesterday, regardless of what happens to main in between.
The dilemma lived entirely in the gap between the invariant, the condition that must actually hold, and the mechanism, the particular way the team had chosen to hold it. Frozen fork base is the invariant. Frozen main was just a mechanism, one way of protecting it, and not even a necessary one. Naming the invariant precisely shrank the constraint until integration became safe mid-trial, and the false choice between fidelity and debt evaporated.
Most engineering dilemmas have this shape. Two things both seem mandatory, and the conflict feels like the cost of reality. Usually one of the two is an inherited mechanism wearing the costume of a requirement. The discipline is to write, beside every constraint, which it is: the condition that must hold, or the habit that currently holds it. Good Architecture Tracks Decisions Across Unfolding States argues that decisions need memory so they can be re-read against changed conditions. This is the sharper version: when the decision is re-read, test the constraint itself for costume.
The reconciliation design survived the same scrutiny, which is how you know the analysis is honest rather than convenient. Scoring the trial was never "merge both days' outputs." Both lanes implement the same tasks, so reconciliation is per-task selection of the better implementation. That procedure works identically whether or not Lane A's work has already landed on main. The dependency the team feared turned out not to exist in the design, only in the deferral policy's self-image.
Batch size is risk surface
The corrected sequence deserves to be stated plainly, because it is good engineering independent of the philosophy.
At the window close, before the Lane B handoff, Lane A's output lands on main as a series of small, per-task reviewed merges. Each slice already carries its gate evidence, so the review pass does double duty: it integrates, and it delivers the independent quality verdict on Lane A's day. Conflicts surface fresh, in small batches, where they are cheap. The one hundred and sixteen commits never become one merge; they become a dozen decisions, each small enough to actually review.
This is the standing argument for small batches wearing operational clothes. A mega-merge is not a large task. It is a compression artifact: many decisions forced through one gate, so that the review bottleneck receives everything at once and fatigue makes the gate decorative. From Pull Requests to Proof makes the same case for graduated trust with agents, and Confident Wrong Output Marked Done Is the Agentic Failure Mode names what fatigue at the gate lets through. The size of the batch is not a logistics preference. It is the size of the risk discovery session.
And then the structural close, which matters more than the sequence: after the trial, the rule flips, and a standing constraint goes with it. A lane may never outrun integration by more than one milestone. Not "should," not "prefer." May not. The debt that took an evening to build becomes structurally impossible to rebuild, because prevention lives in the constraint, not in anyone's future discipline. This is Every Taxonomy Needs a Death Rule generalized from structures to policies: anything with a creation ritual needs a retirement condition, and a policy whose expiry condition is written into it cannot quietly become a debt engine while everyone obeys it.
What this is not
Not an argument against process, nor a license to relitigate every rule the moment it pinches. Most decisions do not expire on a timescale of hours, and a team that treats every constraint as negotiable has traded one failure mode for a worse one. The unexpired decision deserves compliance. The test is purpose-reversal and compounding cost, not discomfort.
Not a claim that the original call was a mistake. Given what was known at trial start, deferral was the right decision. Blaming a correct decision for expiring is how teams learn to never decide at all. The mature posture is deciding well and re-reading decisions against their conditions on a schedule.
And not only a story about agent trials. The expiry pattern is everywhere in engineering: the freeze that protected a release and then froze a quarter, the hiring bar that protected quality and then starved the team, the migration window that protected uptime and then became the outage. Parallel lanes, frozen bases, and one hundred and sixteen commits are just this instance of it.
The move
- When you write down a consequential decision, write its expiry condition on the same page: the observation that would make this rule wrong. If no one can name one, the rule was never understood, only adopted.
- Beside every constraint, label which is true: the invariant that must hold, or the mechanism you chose to hold it. When a dilemma appears, re-read the labels first. The dilemma usually dissolves there.
- Track wait cost, not just debt size. When the cost of obeying compounds, the rule has expired regardless of how correct it was at creation.
- Convert the lesson into a standing constraint, not a resolution. "Integrate sooner next time" is a hope. "A lane may never outrun integration by one milestone" is architecture.
Take-home
- Take one rule your team obeys comfortably and ask the reversal question: what was it adopted to prevent, and is compliance producing that now? One honest pass per quarter is enough to catch most expiries.
- The next time two requirements seem to force a painful choice, write down the invariant each one protects. One of them is usually a mechanism in costume.
- End every postmortem of this kind with a standing constraint, not a commitment. Discipline decays. Structure does not.
Related reading:
- Every Taxonomy Needs a Death Rule
- Most Technical Debt Is Deferred Judgment, Not Bad Code
- Good Architecture Tracks Decisions Across Unfolding States
- From Pull Requests to Proof
- The Bottleneck Keeps Moving
- Confident Wrong Output Marked Done Is the Agentic Failure Mode
If your team keeps obeying a rule that keeps producing the failure it was written to prevent, the rule has expired, and no amount of discipline will revive it. If you want help installing expiry conditions and standing constraints into your engineering decisions, book a discovery call.
FAQ
What does it mean for a decision to expire?
A decision is an answer to a condition, and conditions drift. A decision expires when continued compliance starts producing the exact failure the decision was adopted to prevent. The test is purpose-reversal, not discomfort: read the rule against what it was written to stop, and check whether obedience now manufactures that thing.
How do you tell an expired rule from a merely uncomfortable one?
Watch the wait-cost curve. An uncomfortable rule with flat cost can be obeyed indefinitely at the same price. A rule whose wait cost compounds while you comply, aging conflicts, compressing discovery, thickening review surface, has outlived its rationale. Also check whether the condition the decision answered still exists at all.
What is the difference between an invariant and a mechanism?
The invariant is the condition that must actually hold. The mechanism is the particular way you chose to hold it. Dilemmas usually live in the gap: a frozen fork base is an invariant for trial comparability, while a frozen main is only one mechanism for protecting it. Naming which is which often dissolves the apparent conflict.
Why are mega-merges so dangerous?
Because batch size is risk surface. A mega-merge compresses many decisions through one review gate, so conflicts surface all at once, fatigue makes review decorative, and discovery happens in the worst possible session. Per-task reviewed integration surfaces the same conflicts fresh and small, and the review pass doubles as an independent quality verdict.
How do you prevent integration debt from rebuilding?
With a standing constraint rather than a resolution: a lane may never outrun integration by more than one milestone. Discipline decays and memories fade, but a structural cap makes the debt impossible to accumulate, the same way a death rule keeps a taxonomy from silting up with retired categories.