The Sentence That Went Into the Document
When the vendoring decision was written down, it did not stop at the reasoning. It carried an escalation path: if the consumer count grows past roughly five, or if the kit starts needing its own dependency pins, revisit packaging — and record the outcome.
Two conditions, both observable by anyone, neither requiring the original author to be present. That is the whole feature. The conclusion is checkable because the premises are stated.
What Happened When It Was Actually Revisited
Eight days later, at the fourth consumer, somebody asked the question anyway — the stated trigger was five, so it had not fired yet. That is worth noticing: a written condition makes the question askable EARLY as well as on time, because it names what the question is about. The revisit produced the same answer — keep the copies — but the useful part is that it produced a new record rather than a shrug. The reasoning was re-run against current facts: the consumers are still loopback siblings on one machine, a package would still add install ceremony and version skew for zero isolation gain, and the drift tests already fail by name when a copy is edited. Then the next trigger was restated: a consumer that genuinely needs pinned kit dependencies.
Notice what that costs and what it buys. It costs ten minutes and a paragraph. It buys the difference between a decision that has been re-examined once and a decision that nobody has looked at since the day it was made — and from the outside, six months later, those two are indistinguishable unless one of them left a note.
Writing One That Is Actually Checkable
Most reversal conditions in the wild are unusable because they are moods. "Revisit if this becomes painful" cannot be evaluated — pain is continuous, nobody agrees on the threshold, and the person feeling it is usually too busy to file the observation. A usable condition has three properties:
- Observable without judgment — a count, a presence, a fact you can query. Five consumers is a number. "Too much friction" is not.
- Attached to the mechanism it would change — the condition names dependency pins because dependency pins are precisely what vendoring cannot express.
- Written where the decision is read — in the architecture document, next to the reasoning, not in a ticket that closes.
And when it fires and the answer is unchanged, that is not a wasted check. A decision re-confirmed against current facts is meaningfully different from one that was never re-examined, even though the code is identical either way.