Corrections
Goal: Correct a value without losing the original - and document why.
Corrections happen. The point is that every correction is documented, justified, and traceable, and the original is never modified. This is the digital version of "don't use white-out": you cross it out, write the correction next to it, and say why.
Make a correction
- Select the record to fix and click Amend (or propose it - corrections are proposals too).
- Choose a reason (see below) and write a short justification.
- Review the diff - exactly which fields change, before and after.
- Submit. The correction is recorded with your identity, a server timestamp, the reason, the diff, and a link to the previous version.
The original record is untouched. Each correction links to the one before it, so the full chain - original -> correction -> correction - is always there to read.
Reasons
A short, configurable list, for example:
| Reason | When |
|---|---|
| Data entry error | Typo or wrong value entered |
| Transcription error | Misread from another record |
| Recalculation | Formula or unit change |
| Delayed entry | Added later from notes |
| Other | Explain in the justification |
Optional: require a second approver
Turn this on when a correction should not take effect on one person's say-so. The flow becomes:
- Someone submits the correction -> it's pending.
- A second teammate approves (it takes effect) or rejects (with a reason).
- The approver cannot be the person who submitted it - this is enforced, not just a UI nicety.
Both approved and rejected corrections stay in the chain - a rejected one documents that a change was proposed and why it was declined.
From any AI
Ask Azi: "Show me the correction chain for signups-config" or "Who corrected the alert threshold and
why?" Corrections also flow through Team Review. The endpoints (create / query
/ chain / approve / reject) are in REST API: Change history.
Next steps
- See the whole record -> Activity log
- A correction stuck pending? -> Corrections troubleshooting