Before adding an approval button, I needed to define what was being approved. The same order identifier can refer to different quantities after an edit.
I extended the earlier revision example into an independent local-database experiment. It uses synthetic identities and records, not a company’s actual approval history.
An order identifier is not a complete approval target
Recording that S01 was approved does not explain which quantity was checked if the document changes later. Reading the current document to describe a past approval would let the historical decision follow edited content. I therefore introduced an explicit content revision alongside the document identifier. Each approval names that content revision.
Submitting or approving also changes stored state and needs concurrency protection. The experiment separates version, which advances for stored mutations, from content_revision, which advances when content changes. These numbers answer different questions. Pressing approve should not itself manufacture a new version of the quantity that the person was asked to check.
Follow an edit between submission and execution
The initial synthetic quantity is six and the content revision is zero. Submitting creates an approval round with target_revision zero. A different coordinator approves that round, recording identity and reason. Stored versions advance while the unchanged content revision stays zero. The relationship between the decision and the document can be compared directly.
Editing the quantity to seven advances the content revision to one and returns the document to draft. The old approval record remains historical evidence. Execution requires the current state, latest approval and approval target to agree. An approval of the earlier quantity cannot authorize the new one. Execution in this public lab is only a local simulation marker, without an actual order or external transmission.
A selected role is not a verified approver
Staff and coordinator are fixed synthetic identities. The model assumes trusted server context but does not implement a login service. A browser selection claiming a coordinator or owner role must not become an authenticated approver. Identity verification belongs at the real service’s server boundary.
The teaching policy rejects self-approval. Owners can review records but do not automatically gain approval authority, and another company’s documents remain out of scope. These are explicit example decisions rather than a universal organization chart. Delegation, absence, value-based approval levels and permitted self-approval require a company-specific policy before implementation.
Commit the document and its evidence together
An approved document without its approval record would lose the evidence of who checked it. The SQLite lab changes the document, approval round, event, request result and queued follow-up record inside one local write transaction. An injected failure verifies that they roll back together rather than leaving a partly approved result.
That lock belongs to this local SQLite experiment. It does not commit a fleet of regional servers and an external delivery provider at one instant. External work needs a separate result boundary outside the transaction. Keeping an approval record and completing the approved external action remain different accomplishments.
Start adoption with a written business decision
List the fields that require approval again, the people who request and approve, and the action allowed afterwards. Not every edit needs the same rule, but the program must not guess the exceptions. If quantity, amount and delivery-date changes have different consequences, expose those differences in the revision and approval contract.
The package tests target matching, self-approval denial, execution blocked after editing, and rejection followed by resubmission. Its viewer shows recorded local runs, not SQLite running inside the browser. The checks do not establish a live company approval system or a rendered-browser audit. I share the conditions and evidence together so a reader can decide which policy to add.