An approved label can make a workflow appear finished. Checking a document and actually dispatching an order are different events.
The synthetic SQLite lab keeps execution after approval as a separate transition. It connects no external provider and demonstrates only the boundaries it actually implements.
Approval establishes a condition for execution
An approved document stays approved until a separate execution command occurs. The reviewer checked a particular content revision. Execution compares that target with current content again. Editing quantity back into draft prevents an old approval from authorizing the change.
Execution authority is also a policy choice separate from reading and approval. Coordinators can perform simulated execution in this example; owners remain read-only. Whether the approver and executor may be the same person depends on the company. The lab does not replace that complete policy. It exposes the question of which checked condition permits which next action.
Keep the meaning of execution narrow
The execute action changes a local database state to executed. It does not send a file or issue an external document. That marker cannot be evidence that a trading partner received anything. Interface wording and documentation need the actual boundary behind an otherwise familiar verb.
An operational service may distinguish request creation, transmission attempt, provider receipt and final completion. Losing a response does not always establish failure. This experiment does not manufacture those external outcomes; it implements the narrower fact that approval needs a distinct execution record. A convincing demonstration should not stand in for an absent integration.
Commit the need for follow-up alongside the change
Each successful transition adds an event and notification queue row inside the same transaction. A queue row means follow-up is required, not that notification was delivered. Recording that need alongside the document avoids a gap where the business change survives but its next task is lost. No long network operation is held inside the database transaction.
A unique event-and-target combination prevents duplicate queue rows for one event. It does not guarantee the external delivery provider acts once. Failed or unknown delivery remains a separate result from the document. Distinguishing queued work from finished work is necessary for an owner to understand what still needs attention.
Read each failure at the boundary where it occurred
A database failure during approval should roll back document state, event and request result together. A notification failure after the document and queue committed should not require repeating approval. Treating both failures as an instruction to press the first button again can duplicate work.
The tests separately cover injected transaction rollback and failed delivery without another document event. Storage failure and post-storage follow-up failure have different results. A production integration still needs real provider receipts, status queries and a retry policy. Simulated delivery outcomes in this package do not implement those facilities.
Leave a next check visible in the owner view
An approved but unexecuted document should be read as ready or awaiting action, without implying delivery or collection. This extends the experience’s earlier distinction between preparation, dispatch, delivery and receipts. Connecting confirmed events to the next person’s action gives a status label a readable basis.
Recorded runs compare the document before and after the separate local execution marker, and an independent test checks that separation. There are no company records, external messages or rendered-browser checks. I share the decision so readers can ask what remains behind a completion label before adopting a new program.