Draft count tells you how much content a system produced. It does not tell you how much of that work survived contact with a reviewer.

The missing measure is rework: the effort required after the first usable draft because the brief, source, claim, format, or approval path was wrong.

A fast first draft can have a high rework rate and still be an expensive process.

If the dashboard celebrates 100 drafts and hides that 64 returned for another attempt, it is measuring activity instead of production.

Define rework before counting it#

Use three levels:

Level	Definition	Example
Minor edit	A small change that does not alter the brief	Tighten a sentence
Material repair	A change to claims, structure, source, or audience	Replace an unsupported product promise
Repeat attempt	A new draft or request after return	Recreate the email from a changed brief

The exact threshold depends on the team. A typo and a new product explanation should not be treated as the same cost. Record both, then use material repair and repeat attempts for the budget view.

Calculate the rate two ways#

The basic rework rate is:

assets with material repair or repeat attempt ÷ assets entering review

Suppose 80 assets enter review. Thirty-six receive a material repair, and 20 of those need a second attempt. The material rework rate is 45%. The repeat-attempt rate is 25%.

Those numbers answer different questions. The first says how much output needed meaningful repair. The second says how often the process paid for another creation pass.

Also calculate the cost per accepted asset with and without rework:

View	Amount
Provider and tool spend	$1,600
Production time before review	$4,200
Review time	$2,800
Rework time	$1,900
Full cost	$10,500
Accepted assets	30
Cost per accepted asset	$350

If the team removes rework from the denominator, it will report $287 per asset and lose the largest improvement opportunity.

Record the reason, not only the return#

Use reason codes that connect to a fix:

brief_incomplete;
source_stale;
claim_unsupported;
audience_wrong;
format_wrong;
brand_rule;
approver_changed;
product_changed;
duplicate_request.

The top reason should change the next stage of the process. If source_stale creates most of the rework, improve source ownership. If brief_incomplete dominates, add a preflight check. If approver_changed dominates, fix routing before adding another editor.

Find the expensive part of the loop#

For each returned item, capture:

Field	Example
Original brief	`spring-launch-email-07`
Return reason	`claim_unsupported`
Reviewer minutes	18
Owner repair minutes	31
New attempt	Yes
Final outcome	Accepted
Added direct spend	$2.14

The extra model charge is often the smallest line. Human minutes and waiting time reveal why a simple correction became expensive.

The review-cost guide covers the attention side. The unit economics guide shows how to include it in the accepted-asset denominator.

Set a response for high rework#

Choose thresholds that cause a process decision:

Signal	Response
One material repair	Return with a specific reason and owner
Two repeat attempts	Recheck the brief and source set
Three attempts on one asset	Require campaign-owner approval
Rework above the team threshold	Pause new work in the same process
Rework reason repeats across campaigns	Fix the shared rule or source

Do not use a high rework rate to blame a writer or model without checking the inputs. A team can have excellent production discipline and still receive incomplete briefs, moving product facts, or conflicting approvals.

Compare like work over time#

A rework rate is meaningful only when the asset mix and acceptance rules are visible. Compare lifecycle emails with lifecycle emails, product pages with product pages, and high-review claims with high-review claims.

When the process changes, record the date and the changed boundary. A lower rework rate after a new source policy is evidence that the source policy helped. A lower rate after the team quietly stopped counting returns is not an improvement.

The savings proof guide makes the same demand of AI claims: name the old process, use the same output definition, and preserve the denominator. Rework is the bridge between an impressive draft count and a believable production result.