Trigger Condition

Architectural decisions are made against assumptions about scale, load, usage, team size and requirements. Those assumptions change, and nothing notices. The decision remains in force long after the reasoning has expired, until a crisis forces a reconsideration that could have been scheduled.

A trigger condition fixes this cheaply. Alongside the decision, record the specific observable condition under which it should be revisited: a throughput figure, a latency percentile, a customer requirement, a team size, a date.

Why it matters

It converts "we decided this in 2024" into "this holds while X remains true." The difference is enormous in practice: the first is archaeology and the second is a monitorable position with an owner.

It also defuses disagreement. A dissenting view recorded as "I expect this to fail when we reach X, because Y" is a testable prediction; when X arrives the organisation revisits on evidence rather than on who is more insistent. A general objection provides nothing and is remembered as obstruction.

And it licenses simplicity. The strongest argument against over-engineering is "build the simple thing now, here is exactly what would tell us we need the complex thing." Without the trigger, that argument sounds like deferral; with it, it is a plan.

Implementation patterns

• Make it observable. "When traffic grows significantly" is not a trigger. "When sustained write throughput exceeds 4,000 per second" is.
• Prefer conditions already instrumented, or instrument them as part of the decision — an untracked trigger never fires.
• Alert on it where it is a metric, so the trigger reaches someone rather than waiting to be noticed.
• Name an owner, since a trigger belonging to nobody is a note.
• Include the non-scale triggers: a customer with a residency requirement, a regulatory change, a team falling below a size, a vendor deprecation.
• Record it in the ADR, alongside the assumptions it protects — the assumptions are what the trigger monitors.
• State it neutrally, especially when recording a dissent. A trigger framed as a prediction of vindication is read as positioning and ignored.
• Review triggers periodically, since some become irrelevant and their presence dilutes the rest.

Industry example

The practice is embedded in mature architecture decision record templates, which include consequences and revisit conditions rather than only the decision, and in the "disagree and commit" convention, where the recorded dissent is only useful if it names what would settle it.

It is also the practical form of the standard advice against premature optimisation and premature distribution. The defensible position in an over-engineering argument is never "we do not need that" — it is "here is the simpler design, and here is the specific fact that would justify each rejected pattern later", which is a set of trigger conditions.

Failure scenarios

• A vague trigger that cannot be evaluated, so it never fires.
• A trigger on an unmeasured quantity, which is the same failure with more words.
• No owner, so the condition is met and nobody acts.
• Triggers recorded and never reviewed, accumulating until they are noise.
• A trigger used as an argument-ender rather than a genuine revisit condition, which is detectable and destroys the practice.
• Only scale triggers, missing the customer, regulatory and team-composition changes that are frequently what actually invalidates a decision.
• The trigger fires and is overridden repeatedly, which teaches everyone that it is decorative.

Trade-offs

Triggers require instrumentation and periodic review, which is a small ongoing cost, and a large collection of stale triggers is worse than none because it dilutes attention.

They also cannot cover the unanticipated. The condition that actually invalidates a decision is frequently one nobody thought to write down — a new product direction, an acquisition, a technology shift — and a trigger-based approach can create false confidence that the decision is being watched.

The trade is small ongoing maintenance against the risk of a decision outliving its reasoning silently. For any decision made under acknowledged uncertainty, the cost is trivial relative to the benefit — and the act of writing the trigger is itself valuable, because it forces the decision-maker to state what they are actually assuming, which is frequently the first time it becomes explicit.

Interview question

"You are recommending a single Postgres instance over a distributed database, and someone senior thinks we will regret it. Write me the trigger conditions you would record with that decision — and tell me which of them we can currently measure."