Execution provenance

An operation run records the intended operation key, source revision, input hash, timing, status and result reference. Ordered steps retain action names, input and output references, external receipt details and step status. Execution attempts provide a separate record of each try against the case. Together, these records let an authorized person inspect what ran for a case and which result is available. They also support investigation when a provider result is uncertain or reconciliation is required.

The source revision matters. A result for one revision should not be interpreted as a result for a changed case. The input hash and operation key help distinguish a repeated attempt at the same work from an action using different inputs. State history keeps the case transition record, while operation records show the execution path behind it.

• Run identity. The operation key and source revision identify the intended execution.
• Ordered steps. Each step has a number, action and state, plus receipt details when available.
• Reviewed mappings. Field mappings document source and target names, types and transform rules for a service.

Agree which actions need an external receipt and who verifies its reference. Decide how long the team waits before treating an unknown result as an exception requiring investigation. Review the source mapping version for each service and sample the transformed values. An input that appears familiar can have a different type or meaning, so use a real application to check the mapping before the first operating cycle.

Name the person who owns reconciliation. A failed step, failed attempt and a run requiring reconciliation call for different follow-up. The team should know how to find the external receipt, identify the existing operation key and record the final result without losing the first attempt.

For an approved service case, inspect an operation run recorded for its current revision. The first step prepares the outbound request; the next records an external receipt. The provider’s reply is delayed, leaving the attempt unknown. The operator opens the run from the Cases Workspace and checks the operation key, step receipt and provider reference. After finding the external result, the operator records the correct outcome and delivery reference. The trace explains why there was a delay and which result was accepted.

Try the same scenario after the case has been corrected. The earlier run should remain associated with its earlier revision. The reviewer should be able to inspect the older decision and the successor decision without confusing their evidence. This rehearsal makes the execution trace useful when a delivered outcome is later questioned.

• Runs requiring reconciliation — Operation runs needing a confirmed result.
• Failed execution attempts — Attempts with their operation keys and failure reasons.

• Delivery and exception resolution explains result handling.