Quality Control for Outsourced Game Art: Building Gates That Actually Catch Problems
-
Written byDenys Zadoienyi
-
Updated on31.08.2026
-
Time to read12 min
- Why the Review Doesn’t Start at Delivery
- The Gate Sequence, Generalized Across Asset Categories
- What Makes Acceptance Criteria Hold Up at Each Gate
- Who Actually Has Sign-Off Authority
- What Happens When an Asset Doesn’t Pass
- Building This Into How You Select a Vendor
- How We Approach This at Nasty Rodent
“How do I know they’ll do it well” is usually answered with a portfolio review, and a portfolio review is the wrong tool for the question being asked. A portfolio shows the quality level a studio has demonstrated, but not necessarily how consistently it reaches that level across milestones, revisions, and production pressure. Quality control is the answer to that second question — not a single check at delivery, but a sequence of gates that catch problems while they’re still cheap to fix.
“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”
This isn’t about writing better contract language. Acceptance criteria as contract terms — the clauses that define what “done” means and specify the remedies if a deliverable doesn’t meet it — set the standard. Review gates are the operational process that applies that standard before final delivery, asset by asset, milestone by milestone. This article is about that process: what actually has to happen for the standard on paper to hold up in production.
Why the Review Doesn’t Start at Delivery
The instinct is to think of quality control as something that happens when a milestone package arrives — you open the files, check them against a list, accept or reject. By the time that review happens, though, a genuinely broken asset represents days or weeks of committed work on both sides. Catching a problem at final delivery doesn’t prevent the cost of the problem; it just tells you the cost has already been incurred.
A review gate is a checkpoint placed earlier in the production sequence, before an asset is fully built, so that a wrong direction gets caught while correcting it is still a small adjustment rather than a rebuild. A blockout reviewed for scale and proportion before any surfacing work begins is a review gate. A first-pass texture reviewed against project-defined PBR ranges and the approved palette before the final polish pass is a review gate. The final delivery check is still necessary, but it’s the last gate in a sequence, not the only one.
The Gate Sequence, Generalized Across Asset Categories
The specific checkpoints differ by asset type — a character rig has stages a static prop doesn’t need, and UI work has its own localization, accessibility, and platform-compliance checks rather than an in-engine geometry pass. For 3D asset production specifically, the underlying sequence usually looks like this; other disciplines use equivalent gates placed at different stages:
Concept or reference lock. Before any 3D or final-art work starts, the visual target itself gets signed off — a concept sheet, a mood board, or an approved reference pack. Skipping this gate doesn’t save time; it just moves the disagreement about direction to a later, more expensive stage.
Blockout or first-pass structure. Rough geometry, layout, or a rough pass at final scale, reviewed for proportion, composition, and fit before detail work begins. Skipping this gate doesn’t remove the check — it just moves it to a later stage where correcting a proportion or layout problem means reworking finished surfacing instead of adjusting rough geometry. A validated example from environment production shows why Nasty Rodent treats this specific gate as a hard checkpoint rather than an optional step.
Technical or first-pass surfacing review. Texturing, materials, or rigging in a first-pass state, checked against the technical specification — texel density, project-defined PBR value ranges, naming conventions, topology — before the asset gets its final polish. This gate exists because polish hides technical problems rather than fixing them; a beautifully lit render of an asset with the wrong texel density still fails in engine.
In-engine or final validation. For 3D production specifically, the asset imported into the actual target engine, checked for import errors, LOD behavior, and how it reads under production lighting rather than in a DCC viewport render. Lookdev specifically treats this as a validation loop — beauty shot, review against the visual target, revision, repeat — rather than a single pass/fail check. That loop structure is a reasonable pattern to carry into review for other asset categories too, even where the final check isn’t an engine import.
The number of gates and how much they overlap depends on asset complexity and production timeline — a simple prop might compress blockout and first-pass into one review, while a hero character needs each stage reviewed separately. What doesn’t change is the principle: each gate exists to catch a specific category of problem at the point where it’s still cheap to fix, not to duplicate the gate before or after it.
What Makes Acceptance Criteria Hold Up at Each Gate
A gate without a written standard to check against isn’t a gate — it’s a conversation that happens to occur at a scheduled time. The criteria at each stage need to be specific enough that two people looking at the same asset reach the same verdict independently, which means they need to be checkable rather than impressionistic. “Looks good” isn’t an acceptance criterion; “texel density within the specified range for this asset category” is.
Not every criterion can be made fully objective, though, and pretending otherwise creates its own problem. Silhouette readability, whether a character’s proportions match the established style, whether a material reads correctly at the intended viewing distance — these carry a visual judgment that a checklist alone doesn’t capture. The practical answer isn’t to exclude these from review; it’s to anchor them against something concrete — the approved reference pack, a side-by-side comparison with an already-accepted asset in the same category, a specific camera angle and lighting condition specified in advance — so the judgment is being made against a fixed target rather than the reviewer’s mood that day.
Who Actually Has Sign-Off Authority
This is where a lot of outsourced QC breaks down in practice, not because criteria are missing but because it’s genuinely unclear who has the authority to say yes or no. A common mid-core/AAA setup separates these responsibilities across four functions, though titles and authority vary by studio and by commercial model:
The producer or project manager typically owns the schedule and the process — confirming the milestone is complete, the right files were delivered, and the review happened on time. This sign-off is usually procedural rather than qualitative, though on smaller teams a producer may also hold approval authority directly.
The art director or lead artist often owns the visual sign-off — does this asset match the established style, does it hold up at the intended fidelity tier, does it read correctly in context. This is the most judgment-dependent approval in the sequence, and it’s the one most worth anchoring against the reference material described above rather than leaving to open interpretation.
The technical lead or technical artist often owns the technical sign-off — topology, naming conventions, texel density, engine compatibility, everything on the checklist that has a correct answer rather than a matter of taste. Both visual and technical criteria need to be satisfied before an asset is ready; whether that means two separate sign-offs or one role covering both depends on team size and asset complexity.
Whoever holds contractual acceptance authority makes the formal accept/reject decision under the agreement — which may trigger a milestone payment, unblock the next phase, or simply close out that deliverable, depending on the commercial structure in place. On a well-run engagement, this decision rarely comes as a surprise, because the substantive visual and technical review has already happened upstream of it.
The failure mode isn’t usually that nobody reviews an asset — it’s that feedback arrives from multiple uncoordinated directions with no one reconciling it into a single verdict. Several reviewers weighing in isn’t the problem by itself; the problem is when no one is responsible for consolidating what they say into one decision. A named decision owner per gate — informed by the relevant visual and technical reviewers, not necessarily doing all the reviewing alone — is what keeps a review from turning into a negotiation. How these roles typically sit in a production team is worth mapping explicitly for a given engagement rather than assuming everyone already agrees — and worth naming in the MSA or SOW itself, so the escalation path is defined before a disagreement forces the question.
“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”
What Happens When an Asset Doesn’t Pass
This is the part most guidance skips, and it’s the part that determines whether a rejected asset becomes a two-day fix or a two-week dispute. A working rejection process has a specific shape:
The rejection names the specific criteria that weren’t met, not a general impression. “The silhouette reads muddy at the target camera distance” is actionable. “This doesn’t feel right yet” isn’t — it gives the vendor nothing concrete to correct, and it invites a guessing-game revision cycle that burns rounds without converging.
Feedback arrives as one consolidated set of notes, not a trickle. When feedback comes from the art director on Monday, the technical lead on Wednesday, and a stakeholder’s aside on Friday, the vendor is reworking against a moving target. Consolidating notes into a single round — even if that means the internal team has to reconcile disagreements before sending anything — is what keeps a revision round actually functioning as one round.
There’s a defined point at which repeated rework changes the conversation. Fixed-scope engagements often define how many feedback or revision rounds are included per milestone; T&M or capacity-based engagements typically handle rework as part of ongoing billed effort instead. Either way, three categories are worth keeping separate rather than lumping them into one “revision round”: correcting a deliverable that fails the agreed acceptance criteria, making an in-scope creative revision, and requesting work outside the original brief. Which of the three a given piece of feedback falls into — and how each is handled commercially — is something the contract should define, not something worked out in the moment. If an asset continues to fail the same acceptance criteria across successive correction cycles, that’s a signal worth treating differently than round one — not necessarily a vendor problem, sometimes a sign the brief or reference material itself was ambiguous, but either way, the conversation needs to move into escalation rather than simply generating another identical round of feedback.
Repeated failures on the same criteria escalate, rather than cycling indefinitely. If an asset fails against the same criterion across successive review cycles, that’s a pattern worth escalating rather than a fluke worth another identical round — and it belongs in front of whoever owns the vendor relationship rather than staying inside the day-to-day review loop. This is exactly what an escalation path is for — a defined route so a slipping first-pass approval rate doesn’t sit unaddressed across several reporting periods until someone happens to notice. It’s worth setting up during onboarding, not improvised after the first pattern shows up, since a vendor scorecard is only useful if the numbers get looked at on a schedule rather than only when something already feels wrong.
None of this replaces the contractual remedy — the SOW should define what happens if an asset never reaches acceptance, and depending on the contract, that may include accepting with documented exceptions, commissioning additional paid revision rounds, or invoking termination provisions for that deliverable. But a well-run rejection process reduces the likelihood that an asset ever reaches that contractual-remedy stage — it’s the daily discipline underneath the fallback, not a substitute for it.
Building This Into How You Select a Vendor
Quality control isn’t something you set up after you’ve already picked a studio — it’s a legitimate thing to evaluate during selection, and it’s more informative than a portfolio review because it asks about process rather than output. Ask a shortlisted vendor what their internal review looks like before anything reaches you: do they have their own gates, or does everything arrive at your desk unfiltered? What’s their own first-pass approval rate, and do they actually track it, or are they describing quality control verbally without a number behind it? If a vendor provides a first-pass approval rate, ask how they define it and on what asset mix — a number is only useful for comparison across vendors if the denominator and the pass criteria behind it are actually comparable.
“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”
Vendor scorecards built during evaluation should include this alongside portfolio and technical fit — a studio with a strong portfolio but no internal review discipline is asking you to be their only quality gate, which defeats a large part of what a review-gate structure is supposed to catch before it reaches you at all. For a vendor manager running more than one studio across a vendor pool, this is also a fair basis for comparison across day rate: a lower rate that comes with a weaker internal review process may not actually be cheaper once your own team absorbs the gate-checking work the vendor should have caught first.
How We Approach This at Nasty Rodent
At Nasty Rodent, review gates are built into the production schedule from the start rather than added when something goes wrong — every batch goes through internal art review by the lead artist before a client sees it, using the client’s style guide and art bible as the reference, so style drift is caught at the QA stage rather than after full delivery. Our project structure uses milestone-based delivery with a defined revision path, so a rejected asset has a clear next step instead of an open-ended back-and-forth.
If quality control is the part of outsourcing you’re least sure how to verify before committing, that’s a reasonable thing to ask a shortlisted partner to walk through directly — not just what they’d deliver, but how they’d catch a problem before you ever saw it. Send us your production context and we can map what a review gate structure would actually look like for your specific asset mix and timeline.
