processes · documentation
How a correction should flow back into the document
"That's wrong, we do it differently now" is the most valuable sentence in operations and the most often lost. A design for the loop from correction to precedent to suggested edit to retraining.
Somewhere in your company today, an experienced person will look at an answer — from a colleague, a wiki, a chatbot — and say that's wrong, we do it differently now. Then they'll fix the ticket and move on. The correction will live in their head and, if the colleague is lucky, in theirs. The document stays wrong.
This is the single biggest leak in how companies maintain their processes. Not that people don't know the real process; that the real process never makes it back to the page.
What a correction is
A correction is three facts at once:
- The document's default was wrong for this case. Maybe always, maybe only for this kind of item.
- Here's what we actually do. Usually from someone who was in the meeting the document wasn't updated after.
- The document should probably say so. But the person correcting is busy, not the owner, and editing a Confluence page is nobody's job at 4 pm on a Tuesday.
Most systems keep none of these. A good one keeps all three and does something different with each.
The loop
Record it where it happened. The correction belongs to the item (ticket 48230), the process (LP triage), the stage (escalate), and the person. That's enough to group it later: three corrections at the same stage from three people are a document defect, not three opinions.
Apply it immediately as a precedent. The document won't be updated for weeks. In the meantime, similar items should get the corrected answer. "On a connector-content LP, sync first, then escalate" should apply tomorrow, with the source shown — corrected by Olivia on #48230 — so the next person knows why the answer differs from the page.
Turn it into a proposed edit, for the owner. Not an automatic change: a specific one. Replace this paragraph with that one, because of these three signals. The owner approves, rejects or rewrites in a minute, which is the amount of time owners actually have. For documents kept in your own tool the edit can be applied in place; for a Confluence page, posted as a comment the owner can lift.
Record the new version and say what changed. A diff is for the owner. For everyone else — especially the people trained on the old version — one paragraph: the connector check now comes before escalation; this affects stage 2; you'll see it in your next refresher. If only the wording changed, say that too, and don't make people retake a course for a comma.
Feed the training. The scenario that four people got wrong last month was about exactly this gap. Rebuild it from the new text. The next cohort learns the process as it is, not as it was.
Why this rarely happens today
Because each step belongs to a different tool and a different person. The correction is in Slack, the document in Confluence, the training in the LMS, and the owner in a meeting. No single thing is hard; the hand-offs are where it dies.
Putting the loop in one place — follow, correct, propose, version, retrain — is the design idea behind Ovenbird. But the loop is worth building even by hand: a weekly fifteen minutes where the process owner reads the week's corrections, grouped by stage, would fix more documents than most companies fix in a year.