Art Rework Rate: What’s Normal and What Signals a Vendor Problem

Art rework rate in outsourcing is useful only when the team defines what it counts, which submissions it covers and how it distinguishes defects from planned revisions and scope changes. A raw round count cannot establish responsibility or show the effort needed to correct the work.

Imagine a milestone review where a producer sees “round four” and assumes a vendor problem. The vendor reads the same four rounds and counts a silhouette that changed after approval, two sets of notes that arrived a week apart and one texel density miss. Without a record that links each return to a requirement and a decision, the conversation rests on recollection.

An external benchmark is useful only if its definition, denominator, asset mix and review conditions are comparable with yours. A studio’s included revision allowance describes a commercial boundary, not an observed industry rate.

This guide gives a method instead: what to log, how to separate feedback type from supported cause, how to set a project baseline, and how to test a diagnosis without delaying action on a serious defect. If you are a producer sizing a buffer against an external team’s capacity, the log is what lets you size it against rework you can explain.

What is art rework rate? For this guide, art rework rate is an operational return ratio: completed review decisions requiring another submission at the same acceptance gate, divided by all completed decisions in the defined cohort. Record feedback type, supported causes and stage separately. The ratio does not measure correction effort, establish liability or distinguish planned refinement from defects on its own.

Why a Raw Revision Count Cannot Show Cause or Effort

A raw revision count puts feedback of different kinds and causes under one number, so it shows neither what drove a return nor how much work it took.

The count looks the same whether an asset missed a written requirement, a requirement was unclear or absent, direction changed after approval, the review loop added a cycle, or the work was planned creative refinement inside the agreed scope. Each calls for a different response, and the count merges them. Acting on the count alone can aim the response at the wrong cause while the real one keeps producing returns.

“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”

Unattributed rework shows up in three places. In the schedule, where float disappears one extra cycle at a time and the first visible symptom is a milestone gate that slips. In the capacity plan, where a buffer sized against a rate nobody can decompose may protect against the wrong risk. And in the vendor scorecard, where every return lands on one line even when the brief or a late change contributed.

For a producer, the useful question is which constraints are generating correction work and threatening dependent activities. Several causes may operate at once.

For a vendor manager, a raw revision count is a weak basis for attributing a breach. Compare the documented failures with the agreement’s acceptance, correction, notice and termination provisions, with the responsible commercial or legal owner.

What Counts as Rework, and What the Record Supports

Rework here means any return of delivered work for further correction or refinement. Feedback type and cause are separate dimensions, and each return should carry both.

This guide uses a broad return measure rather than a universal industry definition of rework. Our guide to concept art iteration planning uses the word in a narrower sense, a restart from a new direction after one was approved, which suits scoping a quote. Here that narrow case is one possible cause of a return, not the definition.

Separate three feedback types: correction of nonconforming work, planned in-scope creative refinement, and a scope change. They match the three categories described in our guide to review gates, which also notes that the commercial handling of each belongs in the contract. Progression to the next planned stage is not a return at the previous gate.

For planned refinement with no supported failure or changed commitment, record the origin as not applicable. Do not force it into a vendor, input, change or process fault category. Normal creative work is not somebody’s gap.

For returns that do have a supported failure or changed commitment, use five working cause tags, supported by the records.

“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”

Tag	What the record shows	Example	Production response
V – Vendor	A written, clear requirement was available before delivery and the submission did not meet it	Texel density outside the specified range; file naming off the convention	Correct against the requirement; record the defect class and watch recurrence
I – Input	The requirement was missing, contradictory or open to two reasonable readings	The brief asks for a “weathered” finish with no reference; two documents disagree on pivot placement	Clarify the brief, record the effective version, compare later results separately if review conditions changed
C – Change	An approved requirement, reference or specification changed after delivery or approval	Silhouette changed after approval; the engine version was updated	Follow the agreement’s change procedure; record affected work and schedule impact
P – Process	The review or coordination process demonstrably caused an additional correction cycle or restart	Conflicting notes forced another cycle; delayed feedback caused documented additional correction or a restart	Name who controlled the process; correct the affected work and address the process that caused the extra cycle
U – Undetermined	The available evidence does not settle the cause	Feedback says an asset “doesn’t feel right” and cites nothing checkable	Investigate attribution while addressing verified defects and blockers

More than one cause may contribute to a return. Record supported combinations and mark each attribution as agreed, provisional or disputed. U means the evidence does not settle the cause; it does not mean the asset has no verifiable defect. A large share of U is itself a finding about the documentation.

Count each return once in the total. If a return has a supported vendor contribution, count it once in the vendor-contributing numerator and disclose that rule. Tag totals may overlap, so do not present them as an exclusive percentage split.

For a process-origin return, record who controlled the process; it may be the client, the vendor or both.

An unresolved clarification supports an input-related contribution. Before excluding a vendor contribution, check whether the vendor was required to pause the affected work, what assumptions were authorized, and whether other defects were independent of that ambiguity.

Preserve the original requirement and tag history. Later clarifications may update the attribution, but they should not retroactively make an earlier submission fail a requirement that did not apply when it was delivered. Assign tags when the return is issued, with the cited requirement attached, and read contested tags first.

At Nasty Rodent, every batch passes internal art review by the lead artist against the client’s style guide and art bible before a client sees it, and delivery runs on milestones with a defined revision path. Both give each return a named requirement to point to, which the tags depend on.

How to Measure It: The Log, the Decision and Two Ratios

Measuring art rework rate takes a defined cohort, one fixed definition of a review event and a log that links every decision to its evidence.

A review event is one completed acceptance decision on a specific asset submission and revision at a named gate. Link all notes supporting that decision to the same event. A subsequent decision on a resubmission is a new event.

Record fragmented, late or conflicting messages separately, with timestamps. They count as an additional return only when they cause another documented decision requiring further work. A message by itself is not a review event.

Keep pending reviews visible, but exclude them from completed-decision ratios until their outcome is recorded. State the reporting period and cohort. If there are no completed decisions, report the ratio as unavailable, not zero.

Two ratios come from the same log. The return ratio is returns divided by completed decisions. The vendor-contributing ratio is returns with a supported vendor contribution divided by completed decisions. Both use all completed decisions as the denominator.

Seven groups of fields are enough to start:

Field group	Why it exists
1. Asset ID, category and cohort	Lets you read each category and batch on its own
2. Gate, submission ID and file revision	Ties a decision to the exact work reviewed
3. Review event ID and linked feedback records	Keeps all notes behind one decision together
4. Submission, decision and resubmission timestamps	Gives turnaround and feedback latency from the same log
5. Result, feedback type, severity and recorded effort	Separates refinement from defects and shows how heavy each return was
6. Applicable requirement version and supporting evidence	Makes each cause tag checkable
7. Supported origin tags, attribution status and action owner	Preserves mixed and disputed causes and names who acts next

Accepted with exceptions, pending review and internal corrections must stay visible as their own outcomes. Do not present an internal fix as a return to the vendor when no such return happened.

First-pass approval rate falls out of the same log at no extra cost. The onboarding protocol defines it as the share of assets that clear all acceptance criteria at first review and builds the first baseline in weeks five and six. It cannot show how many times an asset came back or why.

This invented example follows the final-delivery acceptance sequence for eight assets, from first submission to acceptance. Earlier approvals are background context and are outside this measurement window. The 13 events include every completed decision in these sequences: five returns and eight acceptances. Each return has one supported cause in this simplified example. It is not a client project and not a benchmark.

“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”

Asset	Completed decisions	Returns	Work affected by each return	Supported cause of each return
Crate (modular prop)	1	0	–	–
Lantern	1	0	–	–
Barrel	2	1	Surfacing	V: texel density outside the written range
Door	1	0	–	–
Shelf	2	1	Geometry and finish definition	I: finish level not specified in the brief
Generator (hero prop)	3	2	Surfacing and silhouette; in-engine validation	C: silhouette changed after approval; P: a second reviewer’s conflicting notes, issued after the first set was addressed, forced another cycle (client-controlled review)
Console	1	0	–	–
Pipe rack	2	1	Pivot setup and in-engine validation	V: pivot placement off the written specification
Total	13	5		V 2 · I 1 · C 1 · P 1

Five of 13 completed decisions requested further work, about 38.5%. Two had a supported vendor cause, about 15.4% of all decisions and 40% of the five returns. Four of eight assets passed their first final-delivery review, 50%.

These figures describe this example; they do not establish poor vendor performance. The other three returns have input, change or process causes in the illustration. That attribution does not decide who performs or pays for the work.

If you run a vendor pool, treat the vendor-contributing ratio as one scorecard input, not a standalone quality measure. It can fall when unrelated client-origin returns increase, even if vendor defects do not change. Read it with raw counts, affected assets, recurrence, severity, effort and schedule impact.

Set a Project Baseline Before You Judge the Rate

A project baseline describes what has been observed under defined conditions. An acceptable target describes what the project needs. Keep them separate: a stable pattern of severe defects is not acceptable merely because it matches history, and an included revision allowance is not a performance target.

Borrowed figures are hard to use as a baseline for a simple reason. Our guide to RFP and SOW terms defines a feedback round as one consolidated set of notes from a named point of contact. A contractual feedback round and a completed acceptance decision are different units. Document how they map to each other in your engagement. Fragmented messages remain linked to their decision rather than automatically creating new events. Denominators differ as well: per asset, per milestone and per decision are three different numbers.

Build the baseline from four inputs:

Input	What it gives you	Limit
Contract allowance	Defines included work and the treatment of corrections or additional scope	Commercial context, not a forecast
Strata by category and gate	Separate baselines for modular props, hero assets, concept pieces and other asset types	Needs enough decisions in each stratum; a single batch may not fill them
Calibration batches	The first observations for this vendor and this style	Keep calibration and later production separate if their conditions differ
Your internal review history	A like-for-like comparison with your own team’s work at the same gates	Exists only if it was logged with the same definitions

The contract input needs a precise reading. The included allowance already varies by asset type and production stage, as our breakdown of what a quote leaves out explains. It says what is included and how corrections or extra scope are treated. It does not say how many returns a healthy project should see.

Strata matter inside a single engagement. On Squad, Nasty Rodent delivered concept art and unique skins alongside final vehicle and weapon assets for Offworld Industries. A project with that mix has concept reviews and final-asset reviews running side by side, and one blended rate would describe neither.

To compare cohorts, hold the asset category, acceptance gate, feedback definitions and complexity reasonably similar. Show each batch’s counts and denominators. If you pool batches, divide summed returns by summed completed decisions rather than averaging percentages without weighting.

Describe the observed variation and its limitations. Do not call a min–max interval an industry norm or a statistical control limit. Annotate changes in requirements, reviewers and staffing instead of silently resetting the baseline.

For an asset-based proportion with a fixed denominator, one asset changes the result by 16.7 percentage points at n = 6 and 3.3 points at n = 30. These increments do not describe an event-based ratio whose denominator also changes with repeat reviews. Report small samples as provisional. More observations improve the description of a pattern, but sample size does not determine whether a single severe defect needs immediate action.

Six Ways the Rate Can Mislead You

Six measurement effects can move art rework rate without any change in vendor performance, and each has a check.

Effect	What can happen	Check
Small sample	One asset moves an asset-based proportion by double digits in a batch of 6	Report small samples as provisional and show the counts
Mix shift	A different complexity or asset mix can change the rate; the direction depends on the actual review outcomes	Compare within one category; record batch composition
Stage shift	An added gate changes the opportunities for acceptance and return, and can raise or lower the event ratio	Read decisions by gate; compare correction effort
Definition drift	“Round” versus completed decision, consolidated versus fragmented notes, reviewers who tag differently	Freeze definitions at kickoff; record any change as a dated annotation
Context change	A new reviewer, engine version, reference or staffing change on either side can move the rate	Annotate the log before reading a trend
Masked rework	Acceptance with exceptions or internal fixes can hide unresolved work from a return count	Record those outcomes and their effort separately; do not invent a vendor return

An apparent rise may reflect changed review coverage rather than declining execution. A new blockout gate, for example, adds acceptance decisions as well as returns, so the event ratio can move either way while earlier detection may reduce later correction effort. Compare the gate structure, detected issues and correction effort before assigning a cause.

Read the rate next to delivery timing as well. A low rate on late batches, or on batches that drift toward simpler assets, is not a clean result. Our guide to keeping an outsourced team on schedule covers those schedule-side signals and the sizing of a buffer against approval rate together with rework turnaround. The step added here is to split a rising rate by supported cause before reading it as an early warning.

Vendor Problem or System Problem? Test It Without Delaying Action

Use three checks to improve the diagnosis, while addressing urgent defects, production risks and contractual deadlines in parallel. The checks are not prerequisites for escalation.

Check 1: read supported causes with severity, recurrence and schedule impact. A minority of vendor-origin returns can still contain the most serious defect. Input and process problems may coexist with a vendor problem; replacing the vendor may leave those problems unresolved and add a second onboarding. Match each input-origin and process-origin cluster to a gap in our six failure modes, from the brief and art bible to acceptance criteria, iteration planning, technical specification and communication.

Check 2: correct documented gaps, then compare. Fix the documented input and process gaps in writing: a dated brief revision note with annotated pass and fail examples, rewritten acceptance criteria, an agreed feedback window, one decision owner and one set of consolidated notes per review. Then compare subsequent work under recorded conditions. Similar category, gate and complexity make the comparison more useful, but a before-and-after batch is observational evidence, not a controlled experiment or proof of cause. Staffing, learning, review coverage and batch composition may also change.

“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”

What the comparison batch shows	Reading (Hypothesis)	Next move
Input- and process-origin returns fall; vendor-origin returns stay low	Consistent with an improvement in the recorded input or process issues; confirm what changed	Keep logging; compare cohorts under the same conditions
Repeated material vendor-origin failures persist on comparable requirements after corrective action	A vendor-origin pattern	Escalate with the log extract and request a written corrective plan
Vendor-origin returns concentrate in one criterion or one asset category	Investigate a category-specific execution, requirement interpretation or review issue	Compare capability, onboarding, files and review capacity before reallocating
Little changes and many decisions sit in Undetermined	Attribution is unresolved	Investigate it while addressing verified defects and blockers

Clusters and dispersed failures can both arise from vendor, input or process causes. Their distribution helps focus the investigation; it does not establish responsibility.

Check 3: escalate with evidence. Bring submission revisions, applicable requirements, verified defects, disputed points, actions already taken and production impact. Include client-side gaps without treating them as a reason to disregard an independent vendor defect. Check required notices immediately; the responsible commercial or legal owner handles formal steps while diagnosis continues. The path itself, from a written recovery plan to named senior contacts to the transition provisions, is set out in our vendor risk register guide for missed deadlines. The log supplies the evidence that same path needs when the trigger is rework.

What Each Cause Calls For in Production

Each supported cause points to a different next action. The agreement, not the tag, decides who bears the charge.

Cause	Where the effect lands	First production response
Vendor	Correction effort, review capacity and schedule impact; the agreement determines who bears the charge	A written list of the defect class and a corrective plan with a stated exit criterion, checked in the next comparable batch
Input	Review time on both sides and schedule float	Clarify the brief, record the effective version and compare later results separately if the review conditions changed
Change	Rework of approved work and downstream assets built on it	Follow the agreement’s change procedure; record affected work, price or capacity implications, approvals and schedule impact
Process	Errors replicated while feedback waits; conflicting notes	Name the process owner; correct the affected work, then set one decision owner, one set of notes per decision and a feedback window
Undetermined	Unknown until attribution is settled	Investigate attribution while addressing verified defects and blockers

Cause attribution, the owner of the next action and commercial responsibility are separate questions. The agreement determines whether a defect correction consumes an included round, must be completed without an additional charge, or is handled under time-based billing. Input and process issues are not automatically shared costs. Apply the agreement’s correction and change procedures to the documented facts.

Changes to approved scope follow the agreement’s change procedure, and the record should show the affected work, price or capacity implications, approvals and schedule impact before work proceeds where the agreement requires it. Our guide to scope creep covers how to keep that procedure light enough to be used, including the rule that work on changed scope starts only after the change is approved.

From Rework Log to Vendor Decision: Conditions, Not Thresholds

The decision to keep, supplement or reconsider a vendor rests on the evidence in the log and the agreement, not on a rate crossing a line.

Path	What the record may support	First step
Keep	Verified progress and effective corrective action support acceptable quality and a workable forecast	Continue to address client-side and shared constraints
Supplement	A separable category may benefit from specialist support	Compare capability, onboarding, available files, coordination, review capacity and integration before reallocating work
Reconsider	Material failures remain unresolved, progress is unreliable, or the vendor cannot support a credible corrective plan	Assess severity, alternatives, transition cost and the agreement’s process

These conditions guide the decision; they are not universal preconditions for taking action. A serious problem can exist after a single failure, and a gap on your own side does not cancel an independent vendor defect. Read the notice period and exit provisions in the MSA before you need them, since they set how early a decision has to be made.

Check the Records Before Interpreting the Rate

Ten checks expose measurement gaps. Tick each one you can show on paper.

• 1. The reporting cohort, gates and period are defined.
• 2. Each decision links to the reviewed submission and revision.
• 3. Notes are consolidated; fragmentation is recorded separately.
• 4. Pending reviews and internal fixes remain visible.
• 5. Feedback type is separated from supported cause.
• 6. Applicable requirement versions and visual references are linked.
• 7. Mixed and disputed causes are preserved.
• 8. Counts, denominators, severity and available effort data are shown.
• 9. Comparisons account for category, complexity and changed conditions.
• 10. Urgent actions and contractual deadlines have named owners.

Missing records limit particular conclusions; they do not prevent action on independently verified defects. The checklist helps expose measurement gaps. It does not prove responsibility, guarantee a successful diagnosis or require every item to be complete before escalation.

Start With a Defined Batch and a Review Log

A shared spreadsheet is enough to start. Define the batch, acceptance gates and recording rules, then link each completed decision to the reviewed revision, feedback type and supporting evidence. Keep pending reviews, internal fixes and disputed causes visible.

Use comparable batches to understand recurring patterns. Read the counts alongside severity, correction effort and schedule impact. The log supports a production decision; a single return ratio cannot make that decision for you.

Seeing too many revision rounds? Send your revision log and acceptance criteria to sales@nastyrodent.com, or use the request form on our game art outsourcing services page. We get back to you within 1–2 business days.