Steps and attempts

A run can contain steps with their own order, action name, timing and status. A step also holds input and output references and, when a provider returns one, an external receipt. This is the record an Operations Operator checks when the final run status does not explain why a result was accepted or why work stopped.

Attempts record the operation key, attempt number, provider reference and failure reason. They help the team distinguish a retry from a separate run. A failed attempt may lead to another attempt, but a provider timeout calls for checking the receipt and the outside system first. A local failure reason is useful evidence; it is not a substitute for finding out whether an external action occurred.

• Step order. Trace the action sequence within one operation run and inspect the result of each action.
• Receipt. Keep the provider’s receipt identifier, source and dated evidence with the step.
• Attempt. Compare timing and failure reasons across tries that share the same operation key.

Agree which providers return a receipt and where the team will verify it. Define a shared operation key rule and the circumstances that allow a retry. Decide who resolves an Unknown step and who reviews a run marked for reconciliation. Set a retention practice for receipt evidence so an auditor can reconstruct an older execution.

During the pilot, capture a successful action and a failed attempt. For each, locate the parent run and the definition that supplied the instructions. The Operations Operator should be able to explain the source record, attempted action, provider response and next safe step from those linked records.

A provider accepts a request but the response arrives after a timeout. The attempt shows a failure reason, while the step may contain an external receipt. The Operations Operator checks that receipt with the provider before retrying. If the action already occurred, the team reconciles the run and keeps the first attempt in the record. If no action occurred, the operator can use the same source context to decide whether another attempt is appropriate under the retry policy.

A separate case has a step marked Unknown. The team should not mark the whole run successful from the absence of a failure message. Inspect the outside receipt and result reference, then record the resolution where the next reviewer can see it. Keep the original attempt history so a later investigation can distinguish the provider’s behavior from the operator’s response.

• Step exceptions — Locate failed and uncertain actions by run and receipt.
• Failed attempts — Review operation keys, attempt numbers and failure reasons.
• Runs requiring attention — Follow the exceptional run back to its source definition.

Use receipt and exception review to check the evidence before another attempt.