Deferred by decision — recorded as a later priority
There is no audit or history table anywhere in the schema. Application.status is the only record of an outcome, and it can be rewritten freely by both the applicant and the reviewer.
Consequences carried knowingly in the meantime
- Literal "undo" is not implementable. Nothing records the prior status, so the reverse-transition control must name an explicit target ("Move back to Reviewing") rather than offering a bare "Undo"
- Reversed decisions are untraceable. An
accepted flipped to rejected and back is indistinguishable from one that was never touched — no who, no when
Proposed design when picked up
ApplicationStatusEvent — applicationId, from, to, changedById, changedAt — written inside the same transaction as every status update.
This would also enable a real undo, give the reviewer transition graph a history to reason about, and provide a paper trail for the withdraw/resubmit path.
Revisit before the platform is used for anything with a compliance or appeals dimension.
From the 2026-08-10 full platform audit.
Deferred by decision — recorded as a later priority
There is no audit or history table anywhere in the schema.
Application.statusis the only record of an outcome, and it can be rewritten freely by both the applicant and the reviewer.Consequences carried knowingly in the meantime
acceptedflipped torejectedand back is indistinguishable from one that was never touched — no who, no whenProposed design when picked up
ApplicationStatusEvent—applicationId,from,to,changedById,changedAt— written inside the same transaction as every status update.This would also enable a real undo, give the reviewer transition graph a history to reason about, and provide a paper trail for the withdraw/resubmit path.
Revisit before the platform is used for anything with a compliance or appeals dimension.
From the 2026-08-10 full platform audit.