Identify the version being reviewed
A proof request should name the file version, page or variant and required decision. Give the reviewer a reliable way to find that exact file. An approval of version 3 cannot silently approve version 4. Keep comments attached to the relevant proof and record whether later changes require another review.
Use distinct approval gates
Content review checks wording, numbers and ownership. Visual review considers placement, hierarchy and brand presentation. Technical acceptance checks the provider’s production requirements. Commercial acceptance concerns external scope and spend. One person may hold several roles, but the decisions should still state their scope. A screen preview is useful for layout review; it does not alone establish printed colour or physical fit.
Make the decision usable downstream
Record the approver, date, version and any conditions. “Approved subject to a measurement” is conditional, so the outstanding check should remain visible. A changed file opens a new review where required. Include the approved reference in the final handover and list the production file separately if it differs from the review copy. In this release, local proof notes organise a draft; private shared approval authority depends on the engine connection.
Worked example — fictional
In a fictional campaign, proof version 2 contains correct wording but an unconfirmed phone number. The content owner returns a conditional decision identifying that field. The designer updates it and issues version 3. The visual reviewer approves version 3, while the print provider still needs to confirm the supplied template. The budget owner has approved the quote’s base scope but has not accepted an optional installation service. Those four decisions remain distinct. Once technical acceptance arrives, the production manifest can bind the current approved artwork to the accepted specification. If the designer later replaces a logo, the affected artwork gate reopens. The previously recorded budget decision does not vanish, but it does not automatically cover any extra work needed for the late replacement.
Decision checkpoints
- Review identity: verify that the person deciding has authority for the requested scope and relevant records.
- Version identity: name the exact file, page or variant and preserve it with the decision.
- Decision wording: distinguish approved, rejected and conditional states, including every remaining requirement.
- Release relationship: confirm the manifest contains the same versions accepted by the responsible reviewers.
Common pitfalls
- A comment with positive wording can still be a suggestion, rather than an explicit approval.
- A screen layout decision cannot stand in for a production colour proof or physical fit test.
- New artwork can inherit a filename while changing its contents, so filename-only approvals are ambiguous.
Use it on your next job
Prepare a review request that states its purpose and exact version. Record feedback in the approval register and identify any conditions. Before releasing files, reconcile the accepted proof, technical specification and supplier scope. Use local notes as a draft until the shared engine provides tested identity, version binding, file access and revocation controls.
Take this to the next job
- Name the exact proof version
- State the approval scope
- Record conditions visibly
- Reopen affected gates after changes
- Link the decision to the handover
