How to Read Script Coverage (And What to Actually Do With It)
A working reader's honest guide to what each section of your coverage actually means — and what to do once you've read it.
Somewhere out there right now, a writer just opened a PDF, saw the word “PASS” in bold at the top, and closed their laptop.
I get it. I've written coverage that's landed exactly like that. But here's the thing most writers never get told: a coverage report isn't a grade. It's not gospel. It's one reader's structured, professional opinion of what's working, what isn't, and why — and like any opinion, it's only useful if you know how to actually read it. Most writers were never taught how. Nobody hands you a syllabus for this. You just get the PDF and you're on your own.
So let's fix that.
What is script coverage, actually?
Strip away the industry mystique and script coverage is a working document: a reader (sometimes freelance, sometimes on staff at a studio, agency, or platform like dev|cut.) reads your script and writes up a structured assessment — usually a logline, a synopsis, an evaluation of the craft (character, structure, dialogue, tone), and a recommendation. That's it. That's the whole job.
It exists because nobody in this industry has time to read every script cover to cover before deciding whether it's worth their time. Coverage is the filter. Not a perfect one, not an infallible one… but the filter that decides whether your script gets a second look from someone with the power to do something about it.
Once you see it as a filter instead of a verdict, the rest of this gets a lot easier to read.
Start at the bottom, not the top
Most coverage reports lead with the recommendation. Most writers read the recommendation first, feel something in their stomach, and then either skim the rest defensively or skip it entirely.
Don't do that. Read the synopsis first.
The synopsis is the reader proving they actually read your script — and it's the fastest way to catch something important: did they understand what you were going for? Sometimes a “weak” note isn't about your writing at all. It's about a misread. If the synopsis is off, that colors everything that follows, and it's worth knowing before you get to the recommendation, not after.
What “Pass,” “Consider,” and “Recommend” actually mean
This is the part that trips up almost every writer new to coverage, so let's be specific about it.
Pass doesn't mean “bad script.” It means: as written, right now, this reader isn't recommending it move forward. That's a narrower claim than it sounds like. A script can Pass because of fixable structural issues, a rough draft that needed one more pass before submission, or simply a mismatch between what the script is and what the reader (or the desk they're reading for) is looking for that week.
Consider is the “there's something real here” tier — strong elements, real craft, but something (often structural, sometimes just execution) is holding it back from a full recommend. This is usually the most useful note you'll get, because it means someone thinks the underlying idea is worth the work.
Recommend means the reader is putting their name behind it moving forward. It's rarer than writers assume, and it's not the only bar that matters — plenty of working, produced writers have shelves full of Considers and Passes on their way there.
Some services (dev|cut. among them) use more tiers than this three-part system — splitting “strong recommend” from “recommend,” or “consider” from “strong consider,” to be more precise about where exactly a script sits. But the three-tier logic above is the backbone underneath almost every version of it. Learn to read those three, and you can read any coverage report that lands in your inbox.
Read the weaknesses like a diagnosis, not a sentence
This is where most writers lose the plot emotionally, and I say that with real sympathy — it's your work, it's personal, and a stranger just told you what's wrong with it in writing.
Here's the reframe that actually helps: a good weakness note isn't “this is bad.” It's “here's specifically what's not working and why.” The why is the part worth your attention. A note that just says “the middle drags” isn't as useful as a note that says the middle drags because your protagonist stops making choices and starts reacting to plot for three acts running. One of those you can fix. The other one you can only feel bad about.
If the coverage you're holding doesn't explain the why, that's a fair critique of the coverage, not a reason to distrust the note itself.
Every note is a diagnostic, not a decree
You don't have to take every note. I want to say that plainly, because a lot of writers treat coverage like a mandate instead of what it actually is: analysis and suggested revision from someone whose job is to be sympathetic to your creative agency, not override it.
The test I'd use: if you disagree with a note, can you articulate why — specifically, not just “I like it the way it is”? If you can defend the choice on its own terms, keep it. If you can't quite explain why it's there beyond instinct, that's usually the note worth sitting with a little longer.
What to actually do with the coverage once you've read it
- Separate the notes into two piles. Structural (story isn't working the way it needs to) and craft-level (execution issues within a structure that's basically sound). They need different fixes, and conflating them is how a lot of revisions go sideways.
- Look for the note that shows up more than once. If your protagonist's passivity gets flagged in the synopsis, the character section, and the weaknesses, that's not three notes. That's one important note, said three ways.
- Revise the structural stuff first. Polishing dialogue in a scene that's getting cut in the next draft is time you don't get back.
- Keep the coverage. Not to relitigate it every day, but because six months and one more draft from now, you'll want to check whether the thing they flagged actually got fixed — or just moved.
One last thing
If you take nothing else from this: the point of coverage was never to tell you whether you're good enough. It's to tell you, as specifically as one professional read can, what's standing between the script you wrote and the script that gets a yes. That's a completely different question, and it's one worth actually reading the answer to.
This is the kind of read we try to give every script that comes through dev|cut. — not a report card, a genuine diagnostic, with a named reader's judgment behind it.
Want more of this? Subscribe to The Reader's Note.
[Soon] The story continues… — Brian Hanford, Writer & Founder, dev|cut.™ · devcut.io
← Back to Blog