A record needs a small, explicit set of states. Without them, "verified" becomes a flag someone toggled, and nobody can tell what was actually checked.
Last updated: 20 Oct 2026
The three questions a state set answers
May this record still change, and who may change it?
Is there a verification attached to the current version?
What is safe to put in a report right now?
If those three answers are not readable from the record itself, people will infer them from memory, chat messages or the shape of the spreadsheet — and the report inherits that uncertainty.
A five-state set that is enough
State
What it means
Who may move it out
draft
Editable, not yet handed to anyone
author
submitted
Frozen for review
reviewer
verified
A verification event exists for this version
reviewer
rejected
Reason recorded; back to the author
reviewer
archived
Out of the active process, still readable
supervisor
The states are deliberately boring. Any state that cannot be explained in one sentence usually means two processes were merged into one field.
Forbidden transitions are the useful part
Most systems model what is allowed and forget what is forbidden. The rules that protect a report are the forbidden ones:
A record may not leave "verified" without producing a new version.
A verification may not attach to a version that no longer exists.
A rejected record may not become verified without a new submission.
Nobody edits a submitted record; they withdraw it and resubmit.
Written this way, the rules survive a UI rewrite. Written as button visibility, they do not.
The common mistake
A single "approved" boolean looks simpler for a week. It cannot answer which version was approved, so the first edit after approval silently produces a report with data that was never reviewed.
These rules are a design choice, not an industry standard. Check your own sector requirements separately before adopting them.