# Unfinished-work state record Design one business request that must survive a wait or interruption. This hypothetical delivery example is a paper design. None of its proposed concurrency, storage, cancellation, or recovery tests has run. 1. If a worker disappears just after claiming Applying, where can the support lead find the request and its last known action? 2. Which order-system record can confirm whether DATE-41-1 changed the delivery, rather than merely showing a Friday date? 3. Can the system receiving the change reject an old worker's claim in the same update that changes the order? 4. What stops two replacement workers, or the original worker returning late, from making competing changes? 5. Who holds the case and checks again if the customer cancels, AP-9 expires, or the order lookup still cannot settle the result? ## Completed teaching example Request: move one permitted order's delivery to Friday. The support lead would own follow-up, with a named backup still to be assigned. The actual order system's update and recovery features, callers' identities, approvals, and operating team remain unverified. | Identity | Meaning | | --------- | ---------------------------------------------------------------------------------- | | D-41 | The continuing customer case | | D-41-a1 | One worker's attempt; a later attempt gets its own attempt ID | | AP-9 | Approval of one exact proposal, with source/policy versions, approver, and expiry | | DATE-41-1 | One intended external change; retries of that same change retain this operation ID | The support team must be able to open the case and see the requested Friday date, current status, unanswered question, next check time, and responsible person. Retain the verified customer/account, request and proposal versions, source references and checked versions, and links to the attempts, approval, intended operation, and confirmation evidence. Apply access and retention rules to the stored record. | State | Allowed next move | What must not happen | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------- | | Waiting for source | Retry the permitted read within its limit, or assign follow-up to a responsible person | Invent a current order or leave the case waiting without an owner | | Waiting for review | Obtain an authorized decision on the saved proposal | Apply it without approval | | Ready to apply | Recheck current permission, exact approval, expiry, order version, and slot availability; claim the expected case version only if it is not already claimed or cancelled | Treat the saved ready label as permission | | Applying | Preserve operation identity and coordinate one current worker | Start a competing operation because another worker restarted | | Effect unknown | Check permitted order-system records for DATE-41-1 to settle what happened | Blind retry, false success, or false cancellation | | Confirmed | Report the verified operation and resulting order state | Infer completion from a receipt alone or merely a matching Friday date | | Cancelled before application | Preserve the cancellation and refuse later application of the proposal | Apply a cancelled proposal | Approval expiry while waiting returns the case to review. A changed source requires current evidence and invalidation of the proposal or approval as applicable. Removed access stops affected work. A changed intended operation needs a new proposal and any required approval. Cancellation and a worker may arrive together. The case store must let only one change win against the same saved case version: cancellation before application, or one worker claiming it. If submission already began or its outcome is unknown, save the cancellation request but do not claim the external change was prevented. Check the original operation. If it occurred, reversal needs a new, separately authorized action. If evidence is unavailable, keep the case unknown with an owner and next check time. Claiming the saved case and changing the order are separate updates. The case could say applying when the order update failed, or the order could change before the worker saves confirmation. The case store cannot make both systems succeed or fail together. The order system must also enforce the expected version during its update and prevent the same operation being applied twice. If these features are unavailable, keep the first service review-only. Suppose D-41-a1 claims Applying, then stops reporting. Its lease, a time-limited claim on the work, expires, so a coordinator considers D-41-a2. The original worker might still be paused and could later resume. Claim expiry proves neither that D-41-a1 stopped nor that DATE-41-1 left the order unchanged. Hold the case and reconcile DATE-41-1 through permitted order-system records. If submission might have begun and the result cannot be established, keep Effect unknown; do not create a new operation or blindly resend the change. Before allowing a takeover to write, check how the receiving system, or trusted action service controlling the order update, rejects stale ownership in the same indivisible step that applies the effect. It must enforce current permission, the exact unexpired approval, the expected order version, and slot availability at that boundary too. A check followed by a separate update leaves a gap in which ownership or approval could expire. Two replacement workers must not both win the right to apply the change. A local lock does not stop a worker that resumes after losing its claim. A fencing token is a numbered ownership marker the receiver can use to reject an older owner. A token kept only in the case store, or ignored by the order system, cannot establish safe takeover. If the receiving boundary cannot enforce ownership with the effect, keep continuation supervised and the service review-only. A new worker is not permission to retry. During the hold, a delayed lookup may say not found because the submission is still processing or the lookup record is behind. Keep the result unresolved until the source can establish what happened. Record cancellation or AP-9 expiry without reporting that an unknown change was prevented. Block any new application under the old approval; only the permitted investigation may continue. If the original operation happened, reversal remains a separately authorized action. ## Proposed rehearsal | Failure to try | Required evidence | Actual result | | -------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | ------------- | | Worker stops while source is unavailable | Replacement finds D-41, checked evidence, open question, owner, and next safe read | Not run | | Worker stops while approval waits | Replacement finds the same proposal and current approval state | Not run | | AP-9 expires before application | No update under expired approval; case returns to review | Not run | | Two workers claim the same case version | Only one worker claims the saved case; no competing change starts in the order system | Not run | | Cancellation races with the worker | Do not report cancelled after the update begins; check unknown results against the order system | Not run | | Submission times out and source cannot be read | Same operation remains unknown, no blind repeat, owner alerted | Not run | | Stored case records are restored from a backup after an order change | Replacement worker finds the pending operation and checks it against the order system before resuming | Not run | | Worker stops after claiming Applying, before submission | Hold and reconcile DATE-41-1; claim expiry alone cannot release a replacement to write | Not run | | Worker stops after submission, before saving the result | Reconcile the same operation against order-system evidence; no blind resubmission | Not run | | Original worker resumes late after a replacement is considered | Receiving boundary rejects stale ownership with the effect and enforces current permission, approval, and order version | Not run | | Two replacement workers race after claim expiry | Only one current owner can apply the change; all attempts retain DATE-41-1 | Not run | | Customer cancels or AP-9 expires while the case is held | Record the change, block new application under the old approval, and preserve investigation of the original operation | Not run | | Delayed order lookup says not found | Do not infer no effect; hold until permitted source evidence can establish the result | Not run | A restored backup of the case records may predate an order change that already happened. Test that the replacement worker does not repeat the operation merely because those older records have no confirmation. Choose storage by testing competing workers, recovery, migrations, retention, and restoration of backups in the actual system. A local JSON file, atomic file rename, or saved conversation does not establish production durability. ## Blank case design - What is the customer asking to change, which system holds the order, and who owns follow-up? - Who covers for that person, and can the backup access the records needed to investigate? - Which verified customer/account does the request belong to, and who made it? - Which case ID follows the request across every worker and wait? - How will each attempt get its own ID and link back to that case? - What exact proposal is being reviewed, which revision is current, and which source records support it? - Who may approve that proposal, what does their approval cover, and when does it expire? Which source and policy versions does it cover? - Which operation ID will every attempt reuse for this same change, and how will the order system prevent duplicate effects? - Which statuses may follow each other? How will the case store refuse a transition if another worker has changed or claimed that saved version? - Where is the worker's time-limited claim recorded, when does it expire, and who holds the case if the worker disappears? - How will the receiving system reject a stale worker and enforce current permission, approval, and order version in the same update that applies the change? - If that receiving-system check is unavailable, how will the service stay supervised and review-only without a blind retry? - How long may each wait last, who checks next, and what alerts or facts stop the work? - What happens if the customer cancels before submission, after it begins, or while the case is held? - Which order-system evidence can establish that this operation happened, did not happen, or remains unknown? When is a not found response still inconclusive? - Who may access the saved records, how long are they retained, and how will recovery, migration, and backup restoration be tested? | Scenario | Expected safe next step | Observed result/evidence | Responsible person and due date | | ---------------------------------- | ----------------------- | ------------------------ | ------------------------------- | | Long source wait | | Not run | | | Approval expiry or source change | | Not run | | | Worker restart or competing worker | | Not run | | | Cancellation race | | Not run | | | Unknown external result | | Not run | | | Restore after an external change | | Not run | | | Worker lost just after claiming | | Not run | | | Worker lost after submission | | Not run | | | Original worker returns late | | Not run | | | Two replacements race | | Not run | | | Cancellation or expiry while held | | Not run | | | Delayed not found response | | Not run | | Next decision: which storage/source capability or operating responsibility must be demonstrated before this design can proceed?