A Lightweight Path for Minor Patches
The Decision Checklist offered five questions for choosing between the standard pattern and the shortcut pattern. But once you're actually doing the work, some tasks don't fit comfortably into either of those two options.
Fixing a typo. Changing a single line of configuration. Standardizing notation. When you route even fixes like these through consultation with the seven internal roles (asking for their input) and an external audit, the confirmation effort ends up far heavier than the work itself. This chapter is about a lighter path we set up for exactly this kind of minor patch.
When Consultation Outweighs the Work
The shortcut pattern is the path that skips the internal seven-role review cycle and goes straight to external audit. Even so, it still always passes through that one external audit step.
Consider how disproportionate this becomes for a single typo fix. Inserting an external audit for the sake of correcting one character means an auditor has to read the context, check the scope of impact, and decide GO or NO-GO. The time that takes can be many times longer than the fix itself.
If we kept applying the shortcut pattern to minor patches as well, the confirmation overhead would pile up, and small day-to-day fixes would start backing up. Fixes that back up tend to get left alone, and neglected typos and inconsistent notation would keep accumulating. We tightened the checks with good intentions, but the result would be more things going unchecked. That's the contradiction here.
So we set up a third path — neither the standard pattern nor the shortcut pattern. We call it the lightweight path.
What Counts as Minor
The lightweight path can only be used for work that meets every one of the following conditions.
1. It doesn't change the meaning
This covers things like typo fixes, notation standardization, and repairing broken links — work where the content the text conveys stays the same. Changes that touch meaning, like "adjust the claim made in this paragraph" or "reorder the explanation," are out of scope.
2. The impact stays contained to one spot
This is work that doesn't spread beyond the point being fixed. Changes that touch term definitions or shared rules can affect the basis for judgments elsewhere, even if it's only one line. Changes like that fall outside the lightweight path regardless of how few lines are involved.
3. Rolling back takes almost no effort
If a problem turns up, undoing the change has to be instant. The moment reverting a fix requires investigation or re-checking, it has exceeded the "lightness" the lightweight path assumes.
These three conditions are set stricter than the five questions in the Decision Checklist. The five questions were a standard for choosing between "standard or shortcut." The lightweight path sits one step further out, allowing treatment even lighter than the shortcut pattern. If we loosened the standard here, the range of work allowed through this path would keep expanding.
What We Don't Skip, and the Safeguard
Even on the lightweight path, there are two things we don't skip.
One is the record. What was fixed, when, and why always goes into the log. Skipping consultation and audit is one thing, but skipping the record too would leave us with things that "changed at some point without anyone noticing." That's treated the same way here as on any other path.
The other is reversibility. Since "rolling back takes almost no effort" is baked directly into the conditions for using the lightweight path, we don't use this path for work that fails to meet that condition. If this gives way, the whole premise of the path collapses.
Even after narrowing the conditions this far, one risk remains: self-declaration along the lines of "this one's small, so it's fine."
At first, someone genuinely uses the lightweight path for a truly minor fix. Then, a slightly broader fix gets judged as "probably still minor enough" and goes through the same path. Repeat this, and the work passing through the lightweight path gradually gets heavier than originally intended. Since the person making the call feels "this one is minor too" every single time, this creep is hard for them to notice on their own.
As a safeguard against this, work that goes through the lightweight path is recorded so it can be reviewed later. At regular intervals, we look back over the records and ask, "was this really minor?" Checking this in a space where accumulated records are reviewed, rather than in the moment of each individual decision, follows the same thinking as the periodic-review rule described in Never Over-Trust the Shortcut Pattern. Rather than relying on in-the-moment judgment, we build the timing of the check into the system itself.
The lightweight path isn't a path that abandons checking. It's another option for choosing a level of confirmation that matches the weight of the work.