Repeated notifications for one edit make people check whether anything changed again. A click count is not enough to identify the notification’s meaning.
The SQLite lab links a business event to queued follow-up and simulated delivery outcomes. It uses no actual addresses or company accounts and sends no messages.
Identify the event and intended recipient
Using only a document number can suppress legitimate notifications for a later edit. Using only a request key can miss an event arriving through another route. The lab defines uniqueness by company, business event sequence and synthetic target. The question is which change this notification describes.
The target is a fixed synthetic name, not an email address. A real company needs a policy for role-based recipients, named assignees and people holding several roles. Sending everything to everyone can obscure the next action. Queue identity also includes company scope: matching document numbers in separate companies must not collapse into one notification. The package supplies the identity structure without inventing that company policy.
Queued is not delivered
A successful document transition creates a queued outbox row alongside its event. That row says follow-up is needed. It is not network transmission or proof of receipt. A connected screen must distinguish pending delivery from a person already knowing the result.
Instead of a sender, delivery_result records simulated failed or delivered outcomes and attempt counts. Even delivered does not mean a human read the message. Operational adoption needs an evidence contract for provider acceptance, final delivery and user acknowledgement. The model avoids counting unimplemented confirmations as completed work.
Replaying a save does not schedule another notification
Repeating an identical committed request returns its stored result. It creates no new document event and no extra queue row for that event. A concurrent two-connection test requires exactly one event and one queued item. That storage condition is separate from temporarily disabling a button.
Repeated external events need their own identity contract too. The lab does not implement webhooks or signature verification. An outbox uniqueness constraint must not become a claim of deduplication for every remote input. Another ingress route needs its identifiers and trust boundary verified before being connected.
Definitive failure and unknown receipt need different treatment
A synthetic failed row may later be marked delivered. Already-delivered rows are not processed again. Unknown delivery also stops automatic progression, because it does not prove the recipient failed to receive the message. Sending again could duplicate a successful transmission.
No provider outcome query or operator reconciliation screen is implemented here. The example is not a finished sender that safely resolves every unknown outcome. Retry delays, limits, status reconciliation and manual handling remain production responsibilities. A narrow policy makes those missing pieces visible instead of hiding them behind a success label.
Retry follow-up without recreating the order
Notification recovery should not begin by repeating the original quantity edit. The independent test checks that failed and retried delivery leaves one document event. An operator screen should likewise show order and delivery states together while offering distinct actions for them.
The evidence viewer includes failed and unknown records from actual local synthetic runs. It does not send mail from the browser or expose company recipients. I share a structure for identifying necessary notifications and handling duplicates and uncertainty, rather than treating a greater number of messages as a useful feature by itself.