Main idea

While reading another team's documentation — a work-order closing procedure, a backup policy — you spot an error. You know what to fix; it would take thirty seconds. It is better to propose the correction than to make it.

Whoever spots the error does not decide where the knowledge ultimately belongs. It is the team responsible for it that judges whether the correction really describes its scope, or only the particular case of the person proposing it. What the reader sees as an error may be a rule that is right outside their own case.

Why it matters

It stops a local result from quietly becoming a general truth. A direct correction has every appearance of a favour; yet it can rewrite a rule from a single point of view, without the owner knowing.

It also keeps the owning team informed of what others see in its documentation — a signal that a silent correction erases.

Nuances and limits

The rule assumes that proposing is cheap and that the proposal gets handled. If it goes unanswered, the temptation to fix it yourself, or to copy a corrected version into your own space, comes back — and the rule produces the effect it meant to avoid.

For a typo with no bearing on substance, the cost of the proposal outweighs the risk.

Open questions

• What turnaround time must an owning team keep for proposing to remain preferable to correcting directly?