Check the Actual Treatment File You Intend to Send

The treatment looked right when you closed it. The client approved the direction on Tuesday. On Friday the file goes out — and the only thing the recipient will ever see is the attachment and whatever they have to do to open it.

So that is the whole job here, and it is smaller than it feels. You are not asking "is the treatment good?" You settled that already, with the client, in the workspace. You are asking one narrower question: is the thing about to leave your hands the thing that was approved, and can the person receiving it actually use it?

The editable document is not the delivery. Neither is the preview your workspace shows you when you click the file name. Neither is the export you made last week and remember as correct. The delivery is one specific file, in one specific format, arriving through one specific route — and that combination is what you inspect.

Your findings will fall into two piles, and the piles need different treatment. One pile changes the film being proposed, misstates a fact, blocks reading, or exposes material to the wrong people. Those you fix before sending. The other pile is cosmetic — a loose line, an uneven gap, a color slightly off from what you'd choose — and those you write down and leave alone. A delivery check that turns into an open-ended redesign usually ends with nobody sending anything.

A sample to work on

Everything below is invented, and it stays fixed as we go. It is a paper walkthrough of a method, not a case I inspected. No file here was exported, opened, or sent.

Rook & Ivy, a four-person agency, is pitching Tumbrel Spring Water on a 30-second brand spot called "First Light." The treatment is a 14-page designed document. The workspace document is version 4, and the client approved it on a Tuesday call, with three revisions agreed: the opening moves from a kitchen to a public pool at dawn, the closing voiceover line is rewritten, and the key image on page 3 changes from the wide shot of the empty pool (Version A) to the same dawn shot with the kid already in the water (Version C).

The designer applies the text changes on Wednesday and swaps in Version C on Thursday afternoon. But the PDF that gets attached on Friday was exported Thursday morning, from a file named First Light treatment final.pdf. It has the new opening and the new closing line. It does not have Version C.

That is the situation. Now the checks.

Identify the actual candidate for delivery

Before you look at a single page, say out loud which file you are checking. Filename or version, intended recipient, and which copy is authoritative — meaning the one that, if something disagrees, wins. That is almost always the approved workspace document.

Then open that candidate. Not the workspace, not the thumbnail, not the version you exported for your own review. The attachment itself, in the format it will arrive in.

Compare it to the approved source on the things that carry meaning: title, the essential copy, the sequence of pages, and any material the client specifically agreed to. A document can look entirely plausible and still open on the wrong image, run a page out of order, or carry the ending from the previous draft.

In the sample, the comparison surfaces the problem immediately, and it surfaces it in a way a glance would not. The title matches. The opening scene matches. The closing line matches. Page 3 does not. The workspace holds Version C; the attachment shows Version A — the empty pool, no kid, an image the client asked to replace. Nothing about the PDF announces its own age. The only thing that exposes it is putting the two documents side by side on the page that changed.

The filename deserves its own minute here. First Light treatment final.pdf tells the recipient nothing about which version it is, and if someone on their side already has a file with that name, they will open whichever one their mail client hands them. A name that carries the version and the recipient costs you four seconds and prevents a whole class of confusion.

If the creative review isn't finished — if you're still deciding what the treatment promises — stop here and do that first. Delivery checks confirm a decision; they don't make one.

Check meaning and use in the delivered form

Now read the export as a reader, not as its author. You are looking for four kinds of damage: images that are missing or substituted, text that is clipped or reflowed, sequence that doesn't hold, and links whose behavior depends on you.

Start with anything that ends mid-thought. In the sample, page 14 closes with this sentence in the workspace:

Shoot dates are held pending confirmation of the location fee by the 22nd. If the fee is not confirmed by then, the shoot moves to the rain date of the 29th and the delivery schedule shifts by one week.

The exported page shows:

Shoot dates are held pending confirmation of the location fee by

The rest sits below the page edge, inside a text box that was always slightly too short. Nobody caught it in review because the workspace view let the box run past the margin into a space nobody scrolls to. In the export, that overflow becomes a cut-off sentence — and not a trivial one. The deadline and the consequence both vanish. A producer reading that page cannot tell when the fee is due or what happens if it isn't paid.

The repair belongs in the source document, not the PDF. Drag the PDF's margin and you'll produce a file that no longer matches the approved document, and the next person to export from the workspace will reintroduce the problem. Fix the box, re-export, reopen.

Then check legibility under the conditions a reader will actually have. Text over a busy image, thin type at small sizes, a caption in the gutter — all of these can be perfectly readable in your design tool at 100% and unreadable on a phone. Zoom out. Print a page if you can. Look at it the way the recipient will, not the way you made it.

And decide what happens when the visual document isn't the whole story. A designed treatment carries meaning in its composition — the sequence of spreads, the caption under a frame, the relationship between an image and the paragraph beside it. Some recipients need that content in a form that survives without the layout: a plain-text companion listing the beats, the shot list, and the schedule conditions in order. If you're supplying one, check that it agrees with the export you're sending. Two documents that disagree are worse than one document that's hard to read.

One honest limit: no checklist you run on your own machine proves the document works for every recipient, every device, or every assistive technology. A screen-reader route through a designed PDF depends on reading order and alternative text, and whether those survived the export is not something you can establish by looking at the page. If the client needs that path, either test what you can genuinely test and say what you didn't, or supply the text companion and remove the dependence.

Check access without confusing ownership with permission

You own the file. That tells you nothing about whether the recipient can open it.

The test is not "does this open for me." Sign in as yourself and every link you made in your own account works, because your account is the thing granting permission. The question is what happens when someone with no relationship to your workspace clicks the same link.

Page 9 of the sample carries a line reading "Animatic — 2:10," pointing to a file inside the studio's shared project folder. The designer clicks it while signed in and the animatic plays. The client clicks it and gets a request-access screen, because the folder's sharing scope is set to Rook & Ivy only.

The obvious fix — flip the folder to "anyone with the link" — is the wrong one, and it's worth understanding why. That folder holds active work for other clients. Widening access to make one link resolve would expose material that has nothing to do with this pitch. A delivery fix that creates a disclosure problem isn't a fix.

The right move is narrower. Either attach the animatic as its own file so no link is needed, or place a copy somewhere scoped to this recipient, or share the single file rather than the folder. Whatever you choose, the link's permission should match the recipient's identity, not the least restrictive setting available.

An incognito window is a useful partial check here, and only partial. It tells you the link doesn't depend on your signed-in session. It does not tell you what the client sees. A file shared with one email address fails in incognito and succeeds for that person; a file open to anyone with the link succeeds in incognito and proves only that it is unrestricted, not that it is correctly scoped to the recipient. Use it to catch the obvious failure, then treat the recipient's actual experience as still untested.

Where the application has specific steps for this, follow the steps in the current version of that application, with the actual settings in front of you. Sharing interfaces change, and instructions copied from a post written two years ago will lead you somewhere the menu no longer goes.

Use labels and watermarks for the limited job they can do

A version label does one thing: it identifies which candidate this is. A recipient watermark does one thing: it makes an intended copy recognizable as that copy. Both are worth having. Neither is security.

In the sample, someone was asked to mark the client copy clearly and did. Every page now carries "TUMBREL — REVIEW COPY — DO NOT DISTRIBUTE" as a diagonal band across the top third. It is unmistakable. It also lands directly on top of the margin note on page 11 that reads: Client note, Tuesday: pool should read public, not private — no lane ropes, no signage. The band's opacity is high enough that the note is illegible.

So the marking did its job and took something with it. The fix is not to remove the watermark — it's to move it. Headers, footers, and image-free bands exist for exactly this. Check the placement, check the opacity, and then read every page as though the marking might be sitting on top of the one piece of information that mattered.

Check two more things while you're there. Does the label match the file it's on? A watermark naming the wrong recipient, or a footer reading "v3" on a v4 export, is worse than no label, because it argues for a version that isn't there. And does the labeling obscure nothing else — no caption, no frame reference, no schedule line?

What a watermark cannot do is keep anyone from copying. It travels with the file, so a forwarded copy carries it, but someone can screenshot a page, retype a paragraph, or photograph a screen at a meeting. It is not access control, not confidentiality protection, and not proof against disclosure. If the treatment contains something the client genuinely must not see before a certain date, the answer is who you send it to and when — not what you stamp on it. This check only asks whether the mark you chose matches the job of labeling.

Fix the material defect, then stop

By now you have a list. Sort it, and be a little ruthless about the sorting, because the temptation is to treat everything as equally urgent.

Four repairs, one note-to-self. Fix the four in the source document — shorten the text box, replace the image, move the watermark, decouple the animatic access. Then export again, and reopen the new export as a fresh candidate. Not "I already know what it says." Open it. The whole point of this exercise is that familiarity is what hid the problems the first time.

Then record what you did, in a form someone else can read:

• Checked: FirstLight_Treatment_v4_Tumbrel.pdf, exported from the v4 workspace document, compared page by page against the approved source.
• Repaired: clipped closing condition; page 3 image replaced with Version C; animatic attached as a separate file instead of linked; watermark moved to the footer.
• Not tested: how the file renders in the recipient's email client; reading order and alternative text under a screen reader; whether the attachment survives their gateway's size limit; whether an earlier draft was already forwarded to their media partner.

That last list is the part people skip, and it's the part that decides whether you can honestly say the file is ready. "Ready" means the material defects are fixed and the untested conditions are named. It does not mean every route was proven.

Two closing cautions, both about the same mistake. Don't call the file checked because the source document was checked — they are different objects, and the sample exists to show you how far apart they can drift in a single afternoon. And don't let a late round of polish push an unresolved access problem off the table. The spacing on page 5 can wait until the next draft. The link that the client can't open cannot.

Frequently asked questions

What question is a delivery check actually answering?

Not whether the treatment is good—that decision was settled earlier. It asks whether the specific file about to leave your hands is the approved thing and whether the recipient can use it. The editable document, a workspace preview, and last week's export are not the delivery.

How should material findings and cosmetic findings be treated differently?

Material findings change the film being proposed, misstate a fact, block reading, or expose material to the wrong people; fix these before sending. Cosmetic findings such as a loose line or uneven gap should be written down and left alone. A delivery check that turns into redesign often prevents anything from being sent.

Why did the page 3 image problem survive a glance in the sample?

The workspace held Version C, the dawn pool shot with the kid already in the water, but the attached PDF was exported earlier and still showed Version A, the empty pool. The title, opening scene, and closing line matched, so the stale image surfaced only when comparing the changed page side by side.

Why is changing the folder to 'anyone with the link' the wrong fix for the animatic link?

That folder held active work for other clients. Widening access to make one link resolve would expose unrelated material. A narrower fix is to attach the animatic as its own file, place a copy scoped to this recipient, or share the single file rather than the folder.

What can a watermark do, and what can it not do?

It can identify which candidate or intended copy this is, and it travels with forwarded files. It cannot prevent copying, screenshots, retyping, or photographing a screen; it is not access control, confidentiality protection, or proof against disclosure. Placement and opacity still need checking so the mark does not hide a client note.

Further reading

• Build an InDesign Preflight Profile for a Treatment Handoff — Build a repeatable preflight that flags overset text and broken links before export, and learn what its green result still cannot tell you.
• Make a Treatment Readable Beyond Its Visual Layout — Read when a recipient needs the treatment without its layout: it covers reading order, alt text, and a text companion that arrives agreeing with the export.