How to Write a Retake Note an Operator Can Act On Without a Call

Forty notes out on a Tuesday afternoon. Eleven come back as questions by Wednesday morning. Each question costs a message, a wait, a reply and a context switch on both sides, and the eleven that came back consumed more reviewer time than the forty took to write. The generation queue did not move for a day, not because anything was hard to fix but because the instruction was not complete enough to act on. On a seventy episode series with a standing review gate, this pattern is the difference between a review function that accelerates the pipeline and one that throttles it.

A retake note is a piece of operational writing with one success condition: the operator reads it once and generates. Nothing else about it matters. This is the structure that meets that condition, the information a note has to carry, and the phrasings that reliably come back as a question instead.

1. Why a Retake Note Fails

Notes fail for four reasons and only four. The location is ambiguous, so the operator cannot tell which shot or which part of a shot is at issue. The defect is named in a way that describes a feeling rather than an observable, so there is nothing to aim at. The acceptance condition is missing, so the operator does not know what would count as fixed. Or the note carries a fix that conflicts with something the operator knows and the reviewer does not, which forces a conversation about authority rather than about the shot.

None of these is a writing talent problem. They are structural omissions, and they are detectable before sending. This is the practical value of treating note writing as technical writing rather than as feedback. Technical writing has a reader, a task and a completion test, and it is judged entirely on whether the reader completed the task. Feedback is judged on whether it was fair and well expressed, which is a different and much easier bar that produces notes nobody can execute.

2. The Four Parts of an Actionable Note

Every note carries four parts in a fixed order. Location, which identifies the asset and the moment inside it. Observation, which states what is visibly wrong in terms an operator can verify on screen. Acceptance condition, which states what the corrected version has to show. Severity, which tells the operator where this sits against the other eleven notes on the same block. Four parts, one line to three lines each, and the order is fixed so that a reader scanning forty notes develops a rhythm and stops rereading.

The fixed order matters more than the wording of any individual part. An operator working through a batch reads the first element of every note to triage, then the second element of the ones they are about to work on. If location sometimes comes first and sometimes arrives in the middle of a sentence, that triage pass becomes a full read of all forty, which is the single largest avoidable cost in the whole review cycle. Standardising the order costs the reviewer nothing and saves the operator roughly half the reading time on every batch.

3. How to Locate the Problem Precisely

Location means the shot identifier plus a time reference inside the clip. The shot identifier comes from the naming convention, not from a description, because a description like the kitchen argument matches fourteen shots across the series. The time reference is a second or a range, stated in seconds from the start of the clip rather than from the start of the episode. An operator opens one clip at a time, so an episode relative timecode forces an arithmetic step at exactly the moment the note was supposed to remove one.

Where the defect is spatial rather than temporal, locate it spatially in plain frame terms. Upper left of frame, behind the left shoulder, at the lower edge below the wrist. Avoid screen direction language that depends on whether the reviewer means the perspective of the camera or of the character, because that ambiguity produces a call every time it appears. Where a defect runs through an entire clip, say so explicitly rather than giving a start time, because a start time implies an end time that the operator will go looking for and fail to find.

4. How to Name the Defect Without Naming the Fix

Name what is observable. The left hand has six fingers. The wall sconce is lit in this shot and unlit in the two shots either side. The eye line is directed above the other performer rather than at them. The wardrobe collar is open here and buttoned in the preceding shot. Each of these is checkable in under a second by someone looking at the frame, which means the operator can confirm the note is correct before spending generation budget on it. A note the operator cannot verify is a note the operator has to trust, and trust is slower than verification.

Naming the defect rather than the fix is a deliberate separation of roles. The reviewer owns the observation because the reviewer has the comparison set across episodes. The operator owns the method because the operator knows which prompt layer, reference input or seed is actually governing that element. A note that says warm the key light by half a stop is a note about a method the reviewer may not control, and if the warmth is coming from a reference plate rather than a lighting term, the instruction is not executable and a call follows. State the condition, leave the route.

5. When to Specify the Fix Anyway

There are three cases where naming the fix is correct. The first is when the reviewer holds information the operator cannot see, typically a cross episode continuity fact. If the sconce has to be lit because it is lit in eleven other shots in the same location, say that, because the operator working one block cannot know it. The second is when the same defect has already been returned once and the previous attempt went in an unproductive direction. Naming the route closes a loop that would otherwise repeat.

The third is when the fix is cheap and the diagnosis is expensive. A background element that needs removing is faster to specify than to describe, and an operator who has to infer intent from a description of the problem will often regenerate the whole shot when a targeted change would have done. In all three cases, mark the fix as a suggestion distinct from the acceptance condition, so that an operator who finds a better route is not in breach of the note. The condition is binding. The route is advisory.

6. How to Set the Acceptance Condition

The acceptance condition states what the corrected version must show for the note to close. It is the part most often omitted and the part that prevents the most calls. Without it, an operator generates a version that addresses the observation, submits it, and waits to find out whether it passed, which introduces a second round trip that the note was supposed to prevent. With it, the operator can self assess before submitting, and a second round becomes the exception rather than the norm.

Write the condition as an observable state, not as an absence. Sconce lit and matching the warmth of the two adjoining shots is checkable. Fix the lighting is not. Where the condition is a match to another asset, name that asset by its identifier so the operator can open it side by side rather than searching for the shot the reviewer had in mind. Where multiple elements in one shot need to pass, list them as separate notes against the same location rather than as a compound condition, because a compound condition closes partially and partial closure is what generates the longest conversations.

7. How to Rank Severity So the Queue Orders Itself

Three levels are enough. Blocking means the shot cannot be delivered in this state and the episode is held. Correctable means the shot needs a new version but nothing downstream is waiting on it. Noted means the observation is recorded for the next series or the next reference revision and no regeneration is expected now. Three levels can be applied consistently by several reviewers across a long series, which is the only property that matters, because an inconsistently applied five level scale is worse than no scale.

Severity is what lets an operator sequence a batch without asking. Given forty notes with severity attached, the operator works the blocking set first and submits it, which unblocks the episode while the correctable set is still open. Given forty notes without severity, the operator either works them in the order received or asks which ones matter, and both outcomes delay the episode. Severity also feeds the retake log, where blocking notes clustered against one prompt or one reference set are the earliest available signal that an input needs revising rather than an output.

8. The Note Shapes That Always Generate a Call Back

Four phrasings generate a call every time and are worth banning outright. Anything that reads as a comparison to an unnamed standard, such as this does not match the rest of the episode, because the operator has to guess which part of the episode and which property. Anything that states a preference without a condition, such as this would be better slightly wider. Anything that bundles three observations into one sentence, because the operator cannot tell whether all three must pass. And anything that asks a question, because a question in a note moves the decision back to the reviewer and halts the shot until the reply arrives.

The fifth shape is subtler and more expensive. A note that describes a symptom when the reviewer has already inferred a cause, without stating the inference, sends the operator down the diagnostic path the reviewer has already walked. If the reviewer suspects the reference set rather than the prompt, saying so converts a twenty minute investigation into a two minute check. Withholding the inference out of a sense that the operator should reach it independently is the most common way an experienced reviewer slows a pipeline while writing technically correct notes.

9. How to Review Your Own Notes Before Sending the Batch

Run two passes before the batch goes out. The first is a completeness pass, checking that every note carries all four parts. This is mechanical, takes about four minutes on forty notes, and catches the large majority of what would otherwise come back as a question. The second is a conflict pass, reading the notes grouped by shot rather than in the order they were written, which is the only way to catch two notes against the same shot whose acceptance conditions cannot both be satisfied. Conflicting notes are rare and extremely expensive, because they stall rather than slow.

Then track what comes back. A reviewer who records which notes generated a question, and what was missing from them, converges on a clean batch within a few weeks. This is ordinary corrective and preventive action applied to the review function rather than to the output, and it is the fastest available route to a review gate that does not throttle generation. The return rate is the metric. A batch where fewer than one note in twenty comes back as a question is working. One in four is a note writing problem, not an operator problem.

Axis AI Studios Perspective

Axis AI Studios treats the retake note as a production artefact with a measurable failure rate rather than as correspondence between reviewers and operators. The four part structure is standing practice on native vertical series, the return rate is tracked per reviewer, and notes are written against shot identifiers from the naming convention rather than against descriptions. That practice sits on the production side, which is the side Axis controls, and it runs on live work for production clients including Den Tolmor and Good Fight Production LLC, and HolyWater.

The reason it holds is that review is positioned as a step inside the generation pipeline rather than as an approval gate sitting above it. A reviewer whose output is measured on the clarity of instructions writes differently from one measured on the number of defects caught, and the difference shows up in the queue rather than in the review document. Both metrics matter, but only the first one determines whether the review function makes the schedule faster or slower.

What this buys a commissioning platform is a review layer that scales with episode count instead of becoming the constraint on it. Review capacity on a long series is bounded by round trips, not by viewing hours, and round trips are a function of how notes are written. For production enquiries, including review gate structure on a series already in progress, write to business@axisaistudios.com.

FAQ

Should a quality reviewer suggest how to fix a shot or only describe the problem?

Describe the problem by default, because the operator holds the knowledge of which prompt layer or reference input governs the element and the reviewer usually does not. Specify the fix in three cases: when the reviewer holds cross episode continuity information the operator cannot see, when a previous attempt went in an unproductive direction, and when the fix is cheaper to state than the diagnosis is to run. Mark the suggestion as distinct from the acceptance condition.

How many severity levels should a retake note system use?

Three. Blocking, correctable and noted. The constraint is consistency across several reviewers over a long series, and three levels survive that where five do not. The purpose of severity is to let an operator sequence a batch without asking which notes matter, so a scale that different reviewers apply differently defeats its own function and produces the question it was meant to remove.

What is a reasonable return rate on a batch of retake notes?

Below one in twenty coming back as a clarifying question indicates the structure is working. One in four indicates a note writing problem rather than an operator problem, and the fix is almost always a missing acceptance condition or an ambiguous location. Tracking the return rate per reviewer, and recording what was missing from each returned note, converges on a clean batch within a few weeks.

Further Reading

For the same exchange seen from the receiving end, the operator guide to handling retake notes covers how a generation operator triages a batch, when to push back and how to avoid the round trips this piece is written to prevent.

For where severity data goes once notes are closed, the retake log guide covers the log structure that turns clustered blocking notes into a signal that an input needs revising rather than an output.

For the sampling decisions that determine which shots generate notes at all, the quality control guide for large shot counts covers how to review a nine hundred shot series without watching every clip end to end.