Know where
the work stands.

Queued, running, waiting, completed, and failed should describe different operational conditions. A state becomes useful when people know what caused it, what can happen next, and whether intervention is expected. Avoid using “in progress” to cover every situation that is not complete.

The state model should follow the actual task. Some work requires an approval; other work waits for an external response. A compact model that explains those distinctions is preferable to an elaborate flow that nobody can interpret.

Each transition needs an agreed trigger and a record of its outcome. A worker may stop unexpectedly, an external request may time out, or the same event may be delivered more than once. The scope should identify where these conditions matter and how they are detected.

Potential work includes scheduled jobs, asynchronous processing, task-state interfaces, queue-based workflows, and bounded automation. Platform capabilities, expected volume, access requirements, and the consequences of repeating an action influence the design.

A retry is a technical action with a business effect. Before repeating work, determine whether the previous attempt may have completed and whether the operation can safely recognize the same request. Automatic retries need limits and a route for unresolved work.

A defined delivery can include a state-transition map, job implementation, retry boundaries, operator controls, and notes for inspecting or correcting a task. The operating model should say who can resume, cancel, or replay work.

A task identifier, relevant timestamps, and a concise outcome history can help someone reconstruct what happened. Avoid using logs as an unstructured substitute for a clear task record, and avoid recording confidential payloads simply because they are available.

The fieldbook note on repeated requests explores why an uncertain response requires more care than a second click. It uses a hypothetical export task to make the distinction concrete.