Review & approval
An approval gate separates a finished encode from a released deliverable. A gated job holds after verification until a reviewer approves or rejects it.
Some deliverables require sign-off before release: a network delivery that must clear standards and practices, a client cut that requires a producer's review, a mezzanine that a supervisor approves before it moves downstream. In each case a completed job is not yet a released one.
Gate behaviour#
A job that passes verification normally completes immediately, and its output is ready to use. A gated job takes one additional stop: it holds, encoded and verified but not released, until a reviewer decides.
Nothing about the encode changes. Chunking, dispatch, assembly, verification, correctness and QC all run exactly as they would otherwise. The gate changes only what happens after the job would have finished.
Gate a job#
A job is gated by either of two independent routes. The routes combine with OR: either is sufficient, and neither can disable the other.
- The preset requires it. A preset can carry the requirement in its definition, so every job submitted with it is gated automatically.
- The operator requests it.A toggle in the submit flow's Advanced step, independent of what the preset specifies.
An operator can add a gate to a job whose preset does not require one. An operator cannot removea gate the preset mandates. This asymmetry makes a rule such as "every broadcast preset requires sign-off" an enforced policy rather than a convention.
For a studio-wide rule, set the requirement on the preset. Use the per-submit toggle for a single job that requires review although its preset does not.
Reviewer role#
Approving is a distinct permission from submitting or managing jobs. A first-class reviewer role exists for staff who sign off on deliverables but do not manage the fleet.
Administrators can also approve and reject; reviewer is additive, not a replacement. An administrator grants the role under Settings → Access → Users, and it is enforced on the server the moment it is set.
The reviewer role also carries permission to stream preview media, which is required to scrub a gated deliverable.
Review queue#
Reviewers work from a dedicated queue at /review, which appears in navigation only for accounts that hold the access. It lists every job waiting on a decision, oldest first, so the longest-waiting deliverable appears at the top rather than being buried under new arrivals, with the pending count shown at the top of the page.
Opening a job expands an inline player. The finished deliverable is transcoded to a scrubbable low-resolution HLS stream on first request and cached for subsequent viewers, so the reviewer scrubs the actual deliverable and then approves or rejects it with a comment.
The preview is generated from the actual deliverable, not from a proxy encoded with different settings. Signing off does not require the full-resolution file locally or the codec installed.
The first open of a given job takes a few seconds while the preview builds. Subsequent opens are immediate.
Approve or reject#
| Decision | Effect |
|---|---|
| Approve | Completes the job as if it had never been gated. The output proceeds to the configured downstream steps: delivery, MAM write-back, NLE sidecars. |
| Reject | Fails the job. The reviewer's comment becomes the recorded reason, so the submitter sees why the job was refused. |
A comment is required to reject and optional to approve. Both decisions record who decided, when, and the comment. Both surface as a chip on the job's row in the main queue, so an approved job is distinguishable from an ordinary completed one, and a rejected job is distinguishable from an encode that failed on its own.
A decision is final. Once a job leaves the waiting state, a second decision on it is refused rather than silently accepted. Two reviewers cannot record conflicting decisions on the same job.
Scope#
Approval gating governs the release of work that is already encoded. It is unrelated to account entitlements or license seats.
Permission to submit is governed by the operator role, not the reviewer role. Reviewer governs release, not submission.