Falsification Trigger

Most architectural decisions are made with incomplete information and end with "revisit in 12 months". That sentence has no owner, and a date is uncorrelated with whatever would make the decision wrong: the choice can become wrong in month three when a large customer lands, and still be right in month twenty if growth stalls.

A falsification trigger replaces the date with an observation. It states, at decision time, what would have to be true for this decision to be wrong, as a quantity someone can read off a dashboard. The record stops being an explanation and becomes a control.

Wrong if sustained write throughput on orders exceeds 4,000 writes/s or p99 commit latency exceeds 25 ms below 3,000 writes/s. Signal: the orders-db dashboard. Alert at 70% of each threshold. Owner: orders tech lead.

Why it matters

Architectural decisions have a feedback delay of one to three years, longer than the tenure of the people who made them. The loop never closes, so an organisation accumulates decisions whose justification nobody can evaluate and therefore nobody will touch.

Writing the trigger has a second effect worth more than the review it schedules. It forces the author to name the quantity that actually drove the choice, and the common discovery is that they cannot: a decision with no statable falsifier was made on taste. Finding that out costs half an hour rather than a migration in year two.

Implementation patterns

• Three fields and nothing more: signal, threshold, owner. Longer formats do not get filled in.
• Alert at a fraction of the threshold, sized to the remedy's lead time. If sharding takes two quarters, the trigger must fire at a level the current design can hold for two quarters — 70% is a common default.
• Prefer a signal that already exists. A trigger needing new instrumentation never gets wired up; if the quantity is unmeasured, that is the decision's first piece of work.
• Make it mechanical. The alert routes to the owner's team with a link to the record. A trigger nobody is paged for is a date with extra words.
• Audit the triggers, not the decisions, each quarter. For ten live decisions this is about an hour: does each signal still exist under that name, and has any fired unnoticed?

Industry example

Error budgets, standard in the SRE literature since 2016, are the same mechanism applied to reliability and the best-documented version of it. "Release freely while the budget holds, freeze when it is exhausted" is a falsifiable condition with a signal, a threshold and an owner, agreed before the argument and enforced by telemetry rather than by seniority — which is why it survives contact with release pressure. The same shape on a storage choice or a partition key produces a record reviewable in 30 seconds by someone who was not there.

Failure scenarios

• The dashboard is renamed in a migration and the trigger silently dies. Nothing errors; the decision simply stops being watched.
• The threshold is set at the point of pain, so it fires when the system is already degraded and the remedy needs two quarters.

Trade-offs

The uncomfortable cost is personal: naming a threshold accepts that a number on a shared dashboard can show you were wrong in public. That is the actual reason records say "revisit in 12 months".

When not to use it

Skip it for decisions cheap to reverse: the trigger costs more than changing your mind. Skip it where the driver is genuinely calendar-shaped — a contract expiry, a vendor end-of-life date — because there a date is the correct trigger. And skip it where the deciding quantity is unmeasurable in principle, such as a judgement about team structure; the honest artefact there is a written assumption with a named owner.

Interview question

Q: "Take a significant decision in your current system. Write the one line that would tell a new architect, from telemetry alone, that the decision has become wrong. Then tell me what you would do if that line is impossible to write."

What a strong answer covers: a specific quantity with a threshold rather than a direction; an alert level set from the remedy's lead time rather than the pain point; an owning role; and the honest second half, that an unwritable trigger means either the quantity is not instrumented, so instrument it, or the decision was aesthetic, so say so in the record.

Quick check

Quiz: Why is "revisit in 12 months" weaker than "wrong if sustained writes exceed 4,000/s"? A date has no owner and no correlation with the condition that invalidates the decision; a threshold is checkable from telemetry and names the quantity that drove the choice.

Flashcard: What three fields make a decision record reviewable? Signal, threshold and owner, with the alert set at a fraction of the threshold sized to the remedy's lead time.