Runs and corrections

Processing an asset, authorizing playback and correcting a revision each run as an operation with numbered steps. The run records its operation key, the revision it was based on, when it started and finished, a hash of its inputs, its result reference and its status: Queued, Running, Succeeded, Failed or reconciliation required. Each step records its action, its input and output references, its status and, where another system was involved, the external receipt and its evidence.

State history is the permanent log of every status change on an asset: from and to, when, the revision, the operation key, the reason and the person. Nobody edits it.

• Runs with a frozen input. Each run fixes the revision and the input hash at the start. A rerun on changed input is a new run.
• Steps with receipts. A step that calls another system keeps the external receipt. A step whose result cannot be confirmed is marked Unknown.
• Corrections that add. A correction keeps the earlier revision, its evidence and its completed steps. It either stops with a precise reason or adds a successor revision with a compensating output.

Agree who watches failed and reconciliation-required runs each day. Agree how external receipts are referenced for your transcoding and delivery providers. Agree the reasons that block a correction: a duplicate correction, a downstream restriction such as a title already in a live promotion, or a stale input hash. Decide who approves a re-run after correction.

A published episode turns out to have the wrong end credits. The Content Operator requests a correction for revision 3. The correction keeps revision 3, its review decision and every completed step. It checks that no correction is already open and that the input hash is current, then adds revision 4 with the corrected master as the compensating output. The Content Reviewer approves the re-run, processing completes and revision 4 is published.

A second operator, working from an old copy, requests the same correction an hour later. It stops with the reason “duplicate correction”, and the run history shows both requests.

• Failed and Reconciliation Required Runs — Runs that failed or need reconciliation, with operation key, revision, input hash and failure reason.
• Asset Pipeline Board — Where each corrected asset now stands.

• Correction and supersession: Correct an executed revision with its history kept.

Review the data model for how runs and steps link.