After correcting a rejected document, should the earlier request simply become active again? I wanted to preserve both the changed content and the earlier decision.
This article follows a new synthetic SQLite model with explicit approval rounds. It contains no actual company reasons or approvers.
Rejection is not deletion
Deleting a rejected document makes the next person rediscover what needs correction. Clearing its rejection label can also erase the explanation of the first decision. The lab keeps the document in rejected state and retains reviewer and reason on the approval round. Current workflow position and historical review outcome have different records.
Reasons are short synthetic strings. A real screen should connect a reason to the relevant fields without inviting unrestricted sensitive customer text. A coloured rejection label alone is not enough to identify the next task. The package supplies a place for the explanation, while a company’s reason-writing and visibility policy remains separate.
The second submission does not rewrite the first round
Submitting content revision zero creates round one. A different coordinator rejects it. Editing quantity to eight advances content revision to one and returns the document to draft. Resubmission creates round two targeting that new revision. Round one remains rejected, so readers can see what is being checked again.
The example also permits resubmitting a rejected document without changing quantity, with a new reason and round. A rejection may ask for clarification rather than a new numeric value. A company can choose a stricter rule requiring particular corrections. Keeping content revision separate from review round makes that policy possible without pretending every resubmission changes the document’s data.
Editing a pending target invalidates its request
A document may change while review is pending. Leaving the earlier pending request active would let a coordinator approve a different quantity from the one submitted. The edit command marks existing pending rounds superseded and returns the document to draft. The earlier request no longer represents an approvable current target.
This is not a complete cancellation or withdrawal policy. A requester withdrawing a document and an administrator cancelling it may need different authority and reasons. The implemented boundary is narrower: changed content invalidates the pending target. Historical rounds remain available to explain why another review is needed.
Creating a round also needs a concurrency boundary
Two people could try to resubmit the same rejected document. The lab reads the current document version and latest round inside the write transaction. One successful submission advances the document version; another based on the old version conflicts. Calculating a round number outside that transaction would leave an avoidable race.
These conditions belong to the local SQLite storage contract. Another store needs its own conditional-write and uniqueness guarantees. Temporarily disabling a second button cannot enforce the database rule. Replaying the same request result and rejecting a different stale request are also distinct outcomes.
Let a new reviewer understand the earlier decision
The recorded resubmission scenario includes the current document and event count. The independent test compares a rejected first round with a pending second round and their different target revisions. It does not treat the current pending state as evidence that rejection never happened. All records come from temporary synthetic databases.
Adoption still needs rules for reason visibility, withdrawal, delegation, notifications and retention. No real external notification or operational approval was performed here. I designed resubmission to expose which decision is being requested again, rather than treating it solely as repeated data entry. The shared implementation and tests make that starting point inspectable.