Chapter 54. Acceptance Criteria and the Release Gate#

54.1 Acceptance must be observable#

Nobody can sign off on "more premium, more striking, smoother." Rewrite it: the lead matches CH_LINYUN@v03 in every hero close-up; key names, amounts and dates are readable in one playback on the target phone; dialogue is intelligible on a phone speaker at low volume; P0 and P1 are zero.

54.2 Criteria carry conditions and tolerances#

State the device, version, speed and reference used for the check, and the deviation permitted. A wide does not require the mole to be visible; a hero close-up permits no face-shape drift. Background extra variation can be waived; key evidence fields cannot.

54.3 The release gate#

Story approval, asset approval, continuity, technical master, commercial materials, compliance and rights, and the platform package are each signed. Any P0, P1 or rights gap blocks release.

Figure 54-1 Story, continuity, technical, commercial, compliance and platform evidence together form the RC. Blocking items go to rework; low-severity problems may pass only through a recorded waiver. Final release still requires an explicit human signature.

Do not read this as averaging six scores. Any rights gap, wrong fact or P0/P1 is enough to block, and excellence in the other five cannot offset it. A waiver is not a bypass either: it still enters the RC manifest and the audit record, and escalates to a systemic issue when it recurs.

release_gate:
  candidate: RC_E001_V12
  evidence:
    story_qc: QC_E001_STORY_V07
    continuity_qc: QC_E001_CONT_V05
    technical_qc: QC_E001_MASTER_V12
    rights_qc: RIGHTS_E001_V04
    phone_preview: PASS
  open_issues:
    P0: 0
    P1: 0
    P2: 2
  decision: approved_with_waivers

54.4 The release candidate#

An RC is a set of files that cannot change silently: video, audio, subtitles, graphics, cover art, metadata, advertising, rights and hashes. Any modification produces a new RC version and re-runs the affected checks.

54.5 Waivers#

P2 and P3 items may be waived once risk, visibility, reason, expiry and approver are explicit. A waiver does not delete the problem. The same waiver recurring across episodes should trigger an upstream fix.

54.6 Client acceptance#

Bind feedback to timecode, a standard and a scope of change. The contract states in advance the number of free rounds, staged approvals, and the cost of changing locked assets. A client changing the visual route after approving styleframes is not an ordinary revision.

54.7 The platform package#

Check file specification, title, description, cover, subtitles, generation labelling, content rating, proof of copyright and contact details. Platform rules are time-sensitive; re-verify the official requirements on the day of release.

54.8 Rollback#

Keep the previously approved version, its master and its configuration. When platform transcoding misbehaves, a subtitle is wrong, or a rights problem appears, you can withdraw or replace quickly and know which version is affected.

54.9 Post-release verification#

After going live, check the first frame, aspect ratio, sound, subtitles, occlusion in the interaction area, episode order, and the payment or advertising path. A successful publish does not mean the version users see is correct.

54.10 Write criteria in four parts#

A criterion states object, condition, expectation and evidence. For example: on a six-inch phone at normal brightness, in one normal-speed playback, a cold viewer can read the fund name and Lin Yun's name on the authorization; evidence is at least four of five testers retelling it correctly. That is far more executable than "the authorization is clear."

A continuity criterion can read: every tier-A close-up of Lin Yun matches identity_v03, and any missing identity anchor blocks; tier-B shots permit the small mole to be invisible, and do not permit face shape, hairline and perceived age to deviate simultaneously. Criteria are fixed before production or before the gate — never lowered after seeing a result somebody likes.

54.11 The RC manifest and immutability#

A release candidate is not just a video. It is a matched set of files: clean master, subtitled version, subtitle files, mix and stems, cover art, title and description, episode order, ad creatives, CTA, rights evidence, platform fields and a hash manifest. The RC number corresponds to the whole set.

Any change to a member produces a new RC. Even fixing one typo updates the subtitle or burned-in video hash and re-runs the affected checks. Overwriting old files while retaining a signed-off RC number is forbidden. Immutability is what lets a team answer which version the client reviewed and which version is on the platform.

54.12 A waiver does not lower the standard#

A waiver records the problem, the conditions under which it is visible, the audience impact, why it is not being fixed this time, the approver, the scope and the expiry. It permits release with known risk; it does not rewrite a defect as compliant. P0 and P1 are not waivable in principle: defects involving rights, wrong amounts, key identity or the payment path must be closed.

The same waiver recurring across episodes or batches escalates automatically to a systemic issue. Slight flicker on a background screen may be acceptable in one shot; appearing in ten episodes means the output route needs correcting.

54.13 Classifying client feedback as change#

Client notes divide into defect repair, choices within scope, reversals of already-approved content, new requirements, and platform-mandated changes. Only the first is necessarily free; the rest follow the contract's rounds, lock stages and scope of impact. Classification is not a refusal to be creative — it makes time and cost visible.

"It doesn't feel premium enough" should be translated into an observable difference: is it costume material, lighting, composition, sound, pacing or brand presence? If the client cannot point to it, offer a limited set of comparison versions to choose from rather than having every station guess simultaneously.

54.14 Release-day operations and rollback triggers#

Freeze the RC before release and verify account, territory, timing, episode order, paid or ad configuration, cover art and generation labelling. After upload, someone other than the uploader walks the real user path: search or entrance, first frame, playback, subtitles, sound, next episode, payment, back, share.

Define rollback triggers in advance: wrong episode order, no audio, severe subtitle misalignment, a rights complaint, payment failure, the wrong version, a P0 content risk. Rollback is not an ad-hoc discussion; it needs account permissions, an owner, the previous version and an external communication template.

54.15 An RC conflict on Backlit Takeover#

RC12 for E001 had passed when the client asked to change an amount in the dialogue. That is not a small subtitle edit; it is a change of story fact affecting dialogue, ledger graphics, later evidence, ad copy and every language version. Rather than editing the burned-in subtitle, the team raised a change request listing the dependencies and the cost, and the client ultimately confirmed the original figure.

The example shows that a release gate does more than catch errors. It protects a work that has already achieved consistency, and stops a seemingly trivial change at the end from quietly creating contradictions across a season.

54.16 SOP for acceptance#

First, write observable criteria per layer. Second, prepare the RC manifest and hashes. Third, aggregate the QC evidence. Fourth, close P0 and P1. Fifth, approve waivers. Sixth, verify the platform package against current rules. Seventh, sign and release. Eighth, verify online. Ninth, retain the rollback version and the release record.

54.17 Fault tree#

Symptom: acceptance keeps changing its mind. The criteria are feelings. Rewrite them as versions, references and observable conditions.

Symptom: the published file is not the reviewed file. The RC has no hashes, or was overwritten. New changes require a new version.

Symptom: subtitles are covered after going live. Only the master was reviewed, not the real UI. Verify after publishing and prepare a replacement.

Symptom: small problems accumulate indefinitely. Waivers are not counted. Escalate repeated waivers to systemic defects.

54.18 Checklist, exercises and deliverables#

Check that criteria are observable; that device and tolerance are stated; that P0/P1 are zero; that the RC carries hashes; that waivers are signed; that platform rules are verified for the current period; that the live version is re-checked; and that rollback is possible.

Exercise one: convert ten feeling-words into acceptance statements. Exercise two: build the E001 release candidate manifest. Exercise three: simulate a rollback for a platform transcoding error.

Deliverables for this chapter: acceptance criteria, the release gate, the RC manifest, the waiver log, client approval, the platform package, online verification, and the rollback record.

54.19 The acceptance evidence package#

Each release candidate carries an evidence package rather than a single final file. It contains at minimum the RC manifest and hashes, the five-layer QC conclusions, a query showing zero blocking issues, waivers and their approvals, a rights provenance summary, loudness and technical reports, subtitle and graphic checks, device tests, client confirmation and the online verification plan.

Figure 54-2 QC, rights, client and platform evidence enter a locked RC. Observation continues after release. Once a preset threshold is exceeded, the system restores the intact previous RC while retaining the failed version and its evidence for investigation.

The rollback arrow does not return to the production timeline; it returns to a verified historical RC. An ad-hoc field patch with no complete evidence cannot be a rollback target. The point of a rollback is restoring a known reliable state, not hastily generating another unknown one.

Evidence must answer who approved what, under which conditions, on what basis. Screenshots, logs and reports reference a specific RC hash, so files cannot be replaced later while inheriting an old approval. A client email saying it looks fine is not formal acceptance of the delivery specification, the rights and every version.

Different release purposes have different evidence requirements: the episode, ad creatives, an international version and a client's internal preview differ in licensing, subtitles, CTA and platform specification, and cannot share one vague green light.

54.20 The freeze window and the responsibility table#

Enter a freeze window before release: only P0/P1 repairs and explicitly approved commercial necessities are accepted. The release manager judges for each change whether it breaks the RC, widens regression, or should be deferred. Creative refinements go into the next version rather than being substituted in the final hours.

The responsibility table names who uploads, who verifies title and cover, who checks playback, who monitors metrics, who may roll back, and who contacts the client and the platform. Key accounts, materials and the rollback package are verified as available before release. No single person being unreachable should leave the project unable to withdraw a wrong version.

Record every request during the freeze, including the ones refused and why. That lets the team assess afterwards which processes lock too early and which feedback should have arrived sooner — instead of mistaking discipline for refusal to cooperate.

54.21 Rollback drills and post-release observation#

Rollback plans must be rehearsed. Off-peak, the team practises withdrawing or replacing a private version, restoring the previous RC, re-binding subtitles and cover art, and measures how long it takes. A document that merely says "roll back if necessary" tends to discover during a real incident that permissions, caching or platform review block the action.

Post-release observation covers technical, content and commercial layers. Technical watches playback failures, sync, subtitles, sharpness and links. Content watches comments for confused characters, factual errors and sensitive feedback. Commercial watches entrance to next-episode rate, payment and retention. Write the trigger thresholds into the runbook in advance, so nobody argues about them while the numbers move.

A rollback is not a way to bury a failure. Once the incident closes, keep the timeline, the affected users, the root cause, the actions taken and the preventive improvements. Withdrawn files stay in controlled archives — the evidence is never deleted — while public channels ensure the faulty version is no longer distributed.

A note on sources#

Staged confirmation and measurable acceptance protect the client and the producer alike. A release gate merges creative judgment, technical fact and rights evidence into an auditable decision.