Revisit Condition

Most decision records capture context, the decision and its consequences. That documents an outcome and leaves the future reader with two bad options: leave it alone out of superstition, or change it and discover why it existed.

A revisit condition removes both:

Revisit when: the largest tenant exceeds one partition's practical limit, or cross-tenant analytical queries exceed 20% of load.

Now the decision has a trigger someone can check, and the question "is this still right?" has an answer rather than an argument.

Why it matters

Architectures decay less often from bad decisions than from good decisions whose premises expired quietly. The volume assumption moved, the platform limitation was lifted, the team's expertise changed, the regulation was replaced. Nothing announces any of these, and without a recorded trigger the decision becomes permanent by default.

Untouchable decisions accumulate, and eventually the architecture is a museum in which every component is preserved because nobody knows why it is there.

Implementation patterns

• Express it as a measurable threshold, not a date. "Review annually" is theatre; "when tenant size exceeds N" is checkable.
• Instrument it. A condition nobody measures is a condition nobody notices. The assumption belongs on a dashboard with an alert — and the alert belongs in a weekly review, not on a pager, because these are rarely urgent.
• Record the rejected options alongside it. If an option was rejected for a reason that still holds, re-proposing it wastes a quarter; if the reason has expired, that is itself the trigger.
• Name an owner, so the trigger firing produces an action rather than a notification.
• Keep it with the code and link it from the affected components, so the reasoning is encountered by the person changing the thing.

Industry example

The archetypal case is a partitioning scheme chosen a decade ago, whose original architects have left, with a diagram as the only artefact. The team cannot answer whether the partition key was chosen for query locality, for maintenance windows, for regulatory separation, or because of a limitation in a version that no longer ships — so the scheme becomes untouchable and every design around it is shaped by an unexamined constraint.

The same shape appears wherever a design was sized against numbers: a recommendation path built when sessions pulled twenty items and now pulls two hundred; a synchronous render path built when every export was a single page; a capacity topology chosen for a peak that has since moved. In each case there was no bad decision, and in each case a recorded and instrumented trigger would have surfaced the choice while it was still a design change rather than an emergency.

Failure scenarios

• Conditions written and never measured, discovered during the postmortem.
• Calendar-based review instead of threshold-based, which produces either rubber-stamping or nothing.
• A condition with no owner, so the trigger fires into a channel nobody reads.
• Conditions only on new decisions, so the register describes an architecture that no longer exists.
• Alerting on the symptom rather than the assumption — knowing latency degraded is far less useful than knowing the number the design assumed has moved tenfold.

Trade-offs

Writing and instrumenting conditions is discipline that produces mostly-idle metrics, and there is a real risk of fatigue if they are treated as urgent. The mitigation is that assumption triggers are almost never urgent and belong in a periodic review.

What it buys is the ability to meet architectural decay as scheduled work rather than as an unexplained incident — and, equally valuable, the ability for a future team to change an inherited decision with confidence rather than fear.

Interview question

"You inherit a ten-year-old partitioning scheme and nobody knows why it was chosen. What would you have wanted the original team to write down, and what would you write down now for your successor?"