Correction note checklist for price, policy, and API changes

A correction note should be added when a changed price, policy, or API behavior would affect what a reader decides or implements.

Not every edit needs a public correction. Typos, formatting, duplicated wording, and clearer phrasing can usually be changed quietly. A correction note becomes important when the old version could have caused a different action: paying the wrong price, following an outdated eligibility rule, calling an API with the wrong field, using a removed product feature, or citing a policy that no longer applies.

The checklist has five questions. What claim changed? What source triggered the change? Was the old claim wrong at the time, or did the world change later? Does the update affect the conclusion, only the supporting detail, or only the date context? Does the page need a recheck trigger so the same stale claim does not return?

For price changes, include the checked date and the exact pricing surface. For policy changes, name the jurisdiction, version, or official page. For API changes, record endpoint, method, version, and whether the behavior came from docs or observed response. Do not include secrets, private account data, or personal user details.

The correction note should be short and close to the affected claim when the claim is central. For background details, an update note at the end may be enough. The purpose is to preserve reader trust, not to turn every page into a changelog.

A practical rule: if a reader might have acted differently after seeing the update, leave a correction note.

Correction note checklist for price, policy, and API changes

// COMMENTS

ON THIS PAGE