How to Build an Editing Process That Catches Problems Before Publish, Not After

A draft goes live, and a week later someone notices the answer is buried under three paragraphs of background, or that a step the reader needs is missing entirely. Nobody was careless. The draft was "edited," but nobody had agreed on what that word meant. This guide is for content and marketing leads who manage writers and reviewers, and it walks you through a content editing process that puts a real gate between draft and publish, so structure and clarity problems get caught while they are still cheap to fix.

By the end you will have an owner, a set of pass criteria, an intake packet, a rule for deciding between fixing and sending back, and a record of what was approved. You will need an approved brief, the current draft, one accountable editor, a place to show tracked changes and comments, and a way to record approval.

A process like this can help prevent content rewrites that only surface after a piece is live, but it will not remove revisions altogether. The aim is to move the unavoidable ones to a point where they cost less.

1. Name the editing owner and define the gate

Give one editor the authority to decide whether the draft meets the agreed criteria, and make that decision a required handoff instead of an informal comment thread.

Start with one sentence that says what your content editing process is for at this stage: it checks whether the draft fulfills the brief, presents information in a usable order, and communicates clearly enough for the intended reader to act. That sentence separates improving a document from deciding whether it can move forward. A checklist helps an editor improve a draft. A gate also says who decides, what evidence supports the decision, and what happens when something fails.

Then assign four responsibilities before the first draft enters review:

• The brief owner or marketing lead owns the reader, the intended outcome, the scope, and any decision to change the assignment.
• The writer owns a complete draft, answers to substantive queries, and the agreed revisions. Submitting revisions does not give the writer final release approval.
• The accountable editor owns structural diagnosis, clarity review, issue classification, and the pass decision for this stage. The editor does not invent missing content or quietly change the brief.
• The publisher or release owner publishes the approved version once all release conditions are met, and does not decide that an unresolved blocker is fine because the calendar is tight.

Four people is not the goal. These are responsibilities in an editing workflow for teams, not four separate hires. One person can hold more than one role, as long as the decision authority stays explicit.

Next, set up a visible status sequence: writer drafting, ready for structural review, structural approved, clarity review, editing approved, ready for release, published. Add two return routes. "Author revision required" sends the draft back to the writer and then to the stage that failed. "Brief clarification required" sends an unresolved question about purpose or scope to the brief owner before anyone writes or edits further.

"Editing approved" means only that the structural and clarity checks passed. Fact-checking is a separate review with its own owner. Brand voice review is another. "Ready for release" depends on all of them.

You are done when the writer, the editor, and the publisher can each say what they are responsible for, what must be true before they hand the draft on, who decides whether it passes, and where it goes if it fails.

Common mistake. Setting the status to "reviewed" without recording an outcome. Someone opening the document does not mean the draft passed.

Seeing a handoff in a real system helps. The GOV.UK guidance for Whitehall Publisher is a concrete example. An author submits a draft for second eyes and shares it with an editor, who can publish it or reject it, and rejected content returns to draft. The same guidance notes that submitting for review does not automatically notify anyone, so check how your own system behaves.

2. Turn the brief into pass criteria

Translate the assignment into conditions an editor can observe in the draft, so approval never depends on a general feeling that it reads well.

Before reviewing anything, record the intended reader, the task the article must resolve, the outcome the reader should reach, the format, the required topics, examples, or steps, the explicit exclusions, and who approves changes to the assignment. Then build a coverage map: for each requirement, note where it appears in the draft, and write "missing" when it does not. Don't infer coverage from a heading alone.

Here is a structural edit checklist you can adopt and adjust. These are recommended checks written for this guide, not a quoted professional standard.

The decision rule is simple. A draft passes when all applicable required criteria are satisfied and no structural blocker is left unresolved. It fails when at least one required criterion stops the intended reader from completing the promised task. Don't average away a missing core step with strong scores elsewhere, since a draft with excellent headings can still fail because it never answers the assigned question. Keep optional suggestions in a separate list so a stylistic preference doesn't quietly become a condition for publishing.

You are done when the editor can explain any failed decision by naming the criterion, pointing to a place in the draft, and describing what the reader cannot do as a result.

3. Require a complete brief-to-edit handoff

An editor should receive the assignment, the current draft, and the writer's open questions together, not a document with a note that says "please take a look."

Ask the writer to submit a short intake packet with the approved brief, one clearly identified current draft, a requirement map showing where each brief requirement is addressed, a list of any missing material, the writer's specific questions about structure or intended meaning, any deviations from the brief and whether they need approval, and the owners and dates for writer, editor, brief owner, review deadline, and release target.

The Institute of Professional Editors publishes guidance on briefing an editor that lines up well with this list. It covers the editing level, who has authority, timelines, file format, all the material to be edited, and how variations to the brief are handled. In a team that iterates, "final version" should mean the current authoritative submission for this round, not a promise that no more changes will ever be needed.

Add an intake rejection rule. Don't start detailed editing when the intended outcome is unresolved, when nobody is sure which version is current, or when missing material makes structural review impossible. Return the packet to the person who can fix the problem: a missing commissioning decision belongs with the brief owner, and a missing section in a clear assignment belongs with the writer.

You are done when the editor can start without searching chat history for the assignment, guessing which file is current, or finding out halfway through that a required section was never written.

Pro tip. Ask for a requirement map, not a ceremonial checklist. "Section 4 contains the routing decision and examples" is something an editor can check. "I followed the brief" is not.

4. Diagnose structure before editing sentences

Read once for the reader's route through the article, then reverse-outline the draft before anyone spends time on sentence polish.

Work in this order:

1. Read the title, opening, headings, and conclusion together, and check whether they promise and deliver the same task.
2. Read the whole draft without heavy sentence edits. Mark where the reader lacks a prerequisite, loses the thread, or runs into repetition.
3. Reverse-outline the structure and compare it with the brief, the coverage map, and the structural edit checklist from step 2.
4. Record the moves, cuts, additions, and format changes that are needed.
5. Decide whether each change is an editor fix or a writer revision before going further.

Reverse outlining is simple. Purdue OWL describes reverse outlining with two short notes per paragraph: the topic, meaning what the paragraph is about, and the function, meaning how it moves the argument along. For task-focused marketing content, it helps to change the second note to what the paragraph helps the reader understand, decide, or do. That adaptation is a recommendation here, not Purdue's wording. Purdue also suggests that if you can't write each note in about 5 to 10 words, the paragraph may need work. Treat that as a prompt to look closer, not a rejection rule.

You are done when the reverse outline shows a coherent route from the reader's problem to the outcome, every section that stays has a necessary job, and every brief requirement has a location or an assigned revision.

Common mistake. Polishing paragraphs that will be deleted or rewritten. Record the structural work first, and hold off on a full line edit while the architecture is still unsettled.

5. Decide what to fix and what to send back

Fix bounded problems when the editor knows the intended meaning and can keep it. Send work back when the repair needs the writer's intent, missing material, or a substantial rebuild, and escalate to the brief owner when the assignment itself is unclear.

Ask four questions about each issue:

1. Is the intended meaning clear?
2. Is the material needed for the repair already in the draft?
3. Is the change within the agreed editing scope and authority?
4. Can it be made without materially changing other sections or the article's promise?

If all four answers are yes, an editor fix is usually right. If any answer is no, query, return, or escalate instead of guessing. The Editors Canada fundamentals support this kind of judgment about when to query and when to resolve a problem without consulting anyone.

In practice, the routing looks like this:

• A repeated paragraph, a heading that misdescribes a sound section, a prerequisite that appears too late, or a sentence with an obvious, meaning-preserving repair: the editor fixes it and shows the change.
• A sentence that can reasonably mean two things: query the writer, because a fluent rewrite could pick the wrong meaning.
• A required example or explanation that is absent: the writer supplies it, because the editor should not invent it.
• Several sections that need a different argument or procedure: return a scoped structural revision.
• A draft that answers a different question than the brief, or a brief that never set the reader, scope, or outcome: go to the brief owner, since purpose has to be settled before anyone polishes.
• A deadline that cannot fit the required work, or an edit that exceeds the agreed intervention level: the brief owner decides a new date or scope. Calendar pressure does not make failed criteria pass.

Label each issue with a severity that reflects reader impact and not the editor's irritation. A blocker means the article cannot fulfill the agreed task or its meaning is still unresolved. A required fix is a bounded defect that has to be corrected before approval but does not need a new article plan. A suggestion is a nonessential improvement that does not stop the draft from passing. A sensible release threshold is zero unresolved blockers and required fixes.

It is tempting to add a numeric trigger, such as "rewrite if more than 20 percent of the text changes." The sources behind this guide do not support any particular percentage, so it is better not to invent one. Reader impact and decision authority matter more than raw edit volume.

You are done when every issue has a severity, an owner, a next action, and a destination, and the editor is neither quietly becoming the writer nor sending a query about every small change.

6. Return one actionable revision plan

Give the writer one prioritized plan tied to the failed criteria, with clear limits on what has to change and what should stay.

Consolidate structural feedback before you return the draft. A short editorial memo carries the overall diagnosis, and comments in the document carry the exact locations. For each required revision, state where the problem is, the criterion that failed, what the reader cannot do as a result, the specific action requested, what to preserve, the owner and due date, and the pass evidence the editor will check on return.

On resubmission, the writer answers every required item with the change made and where it is, or a short explanation of why they disagree. A reply of "done" is not approval, and you don't need to restart the whole review unless the changes altered the draft as a whole. One consolidated plan is a goal, not a promise that a single round will always be enough.

You are done when the writer can act without interpreting the editor's taste, and the editor can judge the return against the same criteria used to ask for it.

Common mistake. Adding new preferences in every round. If a new requirement changes the assignment, label it as a scope change and get the brief owner's decision.

7. Check clarity after structure passes

Once the reader's route is sound, review paragraphs and sentences for meaning, logical connection, and instructions a reader can follow, and change only what is necessary.

This is the line-editing stage for writer-produced content, which differs from an AI-draft editing workflow. If your drafts come from AI, the line-level checklist covers that pass. In this guide, line editing means improving sentence and paragraph clarity after the structure has been accepted. The term varies between editors, so write your own definition into the process.

Check that each paragraph has a clear point, that each sentence has an identifiable actor, action, and condition, that transitions connect ideas the text actually set up, and that every instruction says what to do and how to recognize completion. Also check that cuts for brevity did not take out an essential step.

One small repair shows how this looks. "Once reviewed, it can be approved" has no actor. If the roles are already established, it becomes "After the editor completes clarity review, the release owner can approve the article for publication." If they are not, query the writer and don't invent them.

Readability guidance can help as long as it stays a prompt. The Nielsen Norman Group plain-language article for expert audiences recommends short sentences and paragraphs, with a 15 to 20 word sentence guideline. It also suggests familiar vocabulary and scannable formatting. Use it to find passages worth a second look, not as a rule that every sentence must come in under 20 words. A reading-level score can't show that the draft answers the brief, so it should never be the only gate.

You are done when there are no unresolved meaning queries or required clarity fixes, and the editor can explain the main instructions without filling in missing actors, conditions, or connections.

If your team works on articles that already sit in Produced Content in DeepSmith, the preview and the editor for the body, title, and slug are a convenient place to apply approved clarity changes and see how the article will look. Whether a human-written draft passes is still decided by your editor and your criteria, and the product does not make that call for you.

8. Approve the exact version and hand it to publishing

Approval belongs to a specific version, so confirm that what will be published matches the draft that passed before the publisher releases it.

Put the pass decision where the publisher can see it. An editing-stage approval names the article, the approved draft version, the brief version, the structural result, the clarity result, any unresolved required items, the editor, the approval date, where the approved document lives, the next owner, and any separate release requirements that are still outstanding.

After that, look at the rendered preview for anything that changed in transfer: the heading hierarchy, section order, lists, tables, captions, leftover comments or placeholders, and anything dropped, duplicated, or swapped back to an older version. This is a targeted check that the approved structure and meaning made it through publishing preparation, not a full technical QA pass or fact-checking.

Decide in advance what reopens a gate. If someone adds a new section after structural approval, reassess the structure around it. If a late wording change adds ambiguity, reopen clarity review for that change. Define a material change as one that could alter the article's promise, coverage, sequence, or meaning, and let harmless formatting fixes skip full review. The Editors Canada version-control standards support identifying the current version and making sure previously approved material has not changed by accident.

You are done when the publisher can identify the approved version and its editing record, the preview matches that version, and any separate publication requirements have their own approvals.

Common mistake. Approving one document and then publishing a different one. A pass does not carry over to every later draft with the same title.

In DeepSmith, the review-and-publish path lets your team review and edit content before it goes to your CMS. It publishes directly to WordPress, Strapi, and Webflow, supports a custom webhook route, and offers Markdown and HTML export. Record your team's pass decision first, then use that path as the reviewed handoff. The pass decision itself lives in your approval record, since DeepSmith does not enforce your editing criteria.

Measure whether the gate is working

Keep the records small: a shared status record, the coverage map, an issue log, and an approval record are enough. A few measures tied to the purpose of the stage are enough too. These are proposed operating measures, not industry benchmarks:

• Intake completeness rate, which shows whether the handoff is improving.
• First-review structural pass rate, which shows whether briefs and drafts line up.
• Revision rounds before editing approval, which show repeated issues or shifting requirements.
• Active editing time versus elapsed time including waiting, which separates the editor's workload from queue delays.
• Post-publication escape rate, meaning published articles that needed a correction for a structural or clarity problem present at release.

With small samples, report counts next to percentages. A higher first-pass rate is not automatically better if reviewers are getting less rigorous. When something is found after release, sort it into a cause, such as an unclear brief requirement, a skipped criterion, or the wrong version released, and don't count new scope as an editing escape.

There is no universal pilot size or acceptable escape rate to borrow, so build a local baseline. Run the same criteria on a small batch of comparable articles, note which failures recur, and then change the brief template or the gate.

What to do next

Pick one writer-produced article that is about to enter review. Attach the intake packet, run structural review before clarity review, and write down which problems the gate catches. After your pilot batch, update the brief template or the checklist for the failures that keep coming back, instead of adding more informal reviewers. Over time that is how a team starts to prevent content rewrites that used to show up after publishing, and how an editing workflow for teams becomes something the whole team follows and not one editor's habit.

If your team also produces content in DeepSmith, you can use the preview and editor to review a finished article before it publishes, and the 7-day free trial lets you see the review-and-publish experience for yourself.