WCNREVIEW & APPROVAL MAP08 · GOVERNANCE → D
← 08 · GOVERNANCE
Review & approval · D
The gate
before it ships.
before it ships.
Quality is a process, not a hope. This cluster defines the review gates, the QA checklist, the workflow, the legal pass, and how exceptions are handled. Tap any card to open its spec.
GATESQA
WORKFLOWLEGAL
EXCEPTIONS20%
REVIEW COVERAGE
0 shipped
2 in progress
3 planned
08D01
Review gates
WIP
Work shouldn’t reach launch unchecked. Review gates put a small, explicit bar at each stage — so problems surface early, when they’re cheap to fix.
GATESThree
ENTRYCriteria each
OWNERNamed per gate
PASSExplicit
D01.1 · THE GATES
Three checkpoints.
Concept, design, and pre-launch. Each is a deliberate pause where work is checked against the brand before it earns the right to continue.
G1Concept
G2Design
G3Pre-launch
PAUSEDeliberate
D01.2 · ENTRY CRITERIA
What gets you in.
Each gate lists what must be ready to even start the review. Incomplete work is bounced before it wastes a reviewer’s time.
LISTPer gate
READYRequired
INCOMPLETEBounced
SAVESReviewer time
D01.3 · GATE OWNERS
Someone holds it.
Every gate has a named owner who runs the check and makes the call. Gates without owners quietly stop happening.
OWNERNamed
RUNSThe check
CALLSPass / fail
UNOWNEDDecays
D01.4 · PASS / FAIL
A clear verdict.
The outcome is explicit — pass, or fail with reasons and a path back. “Probably fine” is not a verdict; ambiguity is what gates exist to remove.
OUTCOMEPass / fail
FAILWith reasons
PATHBack defined
VAGUENot allowed
DON'T
×
Don't skip under deadline — A skipped gate is a deferred problem.
×
Don't leave gates unowned — Named owner each.
×
Don't accept “probably fine” — Explicit pass or fail.
×
Don't gate everything — Three meaningful checks, not ten.
“A cheap no early beats an expensive no late.”
08D02
Brand QA checklist
WIP
Most brand errors are small and repeated. The QA checklist is the fixed last look before anything ships — the same questions, every time, so nothing obvious slips.
WHENPre-ship
ITEMSFixed list
RESULTPass / fail
OWNERReviewer
A
B
C
D
D02.1 · WHEN
Right before it ships.
The checklist runs at the final gate, after the work is done and before it goes out. It’s a catch-net, not a design phase.
STAGEFinal gate
AFTERWork done
BEFORELaunch
ROLECatch-net
D02.2 · THE CHECKLIST
Logo, colour, type, voice.
Fixed items: correct logo and clear-space, on-palette colour, type styles, voice and tone, contrast, and the legal mark. Short enough to actually run.
LOGOMark · clear-space
COLOUROn-palette
TYPEStyles
LEGALMark present
D02.3 · COMMON MISSES
Where it usually fails.
The list leads with the errors that recur most — stretched logos, off-palette accents, low contrast. Putting them first catches the majority fast.
LEADSFrequent errors
LOGOStretched
COLOUROff-palette
CONTRASTToo low
D02.4 · SIGN-OFF
One name on it.
A reviewer runs the list and signs. Their name on the pass means it was actually checked — accountability is what stops the list becoming a formality.
RUNSReviewer
SIGNSBy name
MEANSActually checked
LOGRecorded
DON'T
×
Don't tick blindly — Each item is really checked.
×
Don't let it sprawl — Short enough to run every time.
×
Don't ship unsigned — A name on the pass.
×
Don't ignore repeat misses — Feed them to the do/don’t library.
“The same five mistakes, caught every time.”
08D03
Approval workflow
PLANNED
A clear path from “I need this approved” to “it’s approved.” The workflow defines how requests are made, routed, and turned around — so nothing sits in limbo.
FLOWRequest → review → yes
ROUTINGBy type
TURNAROUNDSLA
STATUSVisible
D03.1 · THE FLOW
Three steps.
Submit with the required inputs; a reviewer is assigned; a decision is returned. Every request follows the same three steps, tracked in one place.
1Submit
2Review
3Decision
TRACKEDOne place
D03.2 · ROUTING
To the right desk.
Requests route by type — visual, legal, partner — to the owner from the RACI matrix. No more “who do I send this to?”
BYType
TORACI owner
AUTOWhere possible
CLARITYBuilt in
D03.3 · TURNAROUND
A clock, not a void.
Each request type has an SLA — most within days. If a reviewer can’t meet it, that’s flagged, not ignored. Silence is not an answer.
SLAPer type
MOSTDays
MISSFlagged
SILENCENot allowed
D03.4 · ESCALATION
When it sticks.
If a request stalls past its SLA, it escalates automatically to the steward. The workflow assumes things will sometimes jam and plans the unjam.
TRIGGERPast SLA
TOSteward
AUTOYes
ASSUMESJams happen
DON'T
×
Don't approve in DMs — One tracked path.
×
Don't leave routing to guesswork — By type, to the owner.
×
Don't ignore the SLA — Miss it visibly, not silently.
×
Don't let it stall — Auto-escalate past SLA.
“Approval should have a path and a clock.”
08D04
Legal & trademark
PLANNED
Some work carries legal weight — public claims, the trademark, third-party rights. This review makes sure it’s cleared before it ships, not litigated after.
WHENPublic · claims
CHECKTrademark
RIGHTSCleared
OWNERLegal
D04.1 · WHEN REQUIRED
Not always, but clearly.
Legal review is triggered by defined conditions — public campaigns, factual claims, new markets, partner co-branding. Internal work usually skips it.
PUBLICCampaigns
CLAIMSFactual
NEWMarkets
INTERNALUsually not
D04.2 · TRADEMARK
Protect the mark.
Anything touching the mark, name or new sub-brands gets a trademark check — clearance, correct ™/® usage, and no dilution of what’s registered.
CHECKClearance
SYMBOL™ / ®
DILUTIONAvoided
SUB-BRANDSReviewed
D04.3 · RIGHTS & CLAIMS
Say only what’s true.
Claims are checked for substantiation; third-party content — fonts, images, names — for rights. If it can’t be backed, it doesn’t ship.
CLAIMSSubstantiated
3RD PARTYRights cleared
UNBACKEDCut
RECORDKept
D04.4 · THE RECORD
Proof of the pass.
Each legal review is recorded — what was checked, by whom, the verdict. The record protects the brand if a decision is ever questioned.
LOGPer review
FIELDSWhat · who · verdict
PROTECTSThe brand
LINKEDTo asset
DON'T
×
Don't self-clear claims — Substantiation, reviewed.
×
Don't drop ™/® — Correct symbols on the mark.
×
Don't assume rights — Third-party content cleared.
×
Don't lose the record — Proof of the pass, kept.
“Cheaper to clear it now than defend it later.”
08D05
Exceptions
PLANNED
No system covers every case. The exceptions process is how the brand bends a rule on purpose — approved, time-boxed, and logged — instead of breaking it quietly.
WHOSteward
FORMWritten
SCOPETime-boxed
LOGRecorded
D05.1 · WHEN
A real reason.
Exceptions are for genuine edge cases — a platform constraint, a regulatory demand — not for taste or haste. The bar to request one is deliberately real.
FOREdge cases
NOTTaste · haste
BARHigh
DEFAULTFollow the rule
D05.2 · WHO APPROVES
The steward, only.
Only the steward grants an exception. Centralising the call keeps exceptions rare and consistent — and keeps one person aware of every bend in the system.
GRANTSSteward
WHYConsistency
RAREBy design
AWAREOne owner
D05.3 · SCOPE & TIME
Bounded, and temporary.
Every exception names exactly what it covers and when it expires. An exception without an end date is just an undocumented rule change.
COVERSNamed
EXPIRESDated
OPEN-ENDEDNever
RENEWRe-request
D05.4 · LOGGING
A pattern to watch.
Exceptions are logged in one place. When the same exception keeps getting requested, that’s a signal the rule is wrong — and the log is how the system notices.
LOGOne place
SIGNALRepeats
MEANSFix the rule
REVIEWQuarterly
DON'T
×
Don't bend without asking — Approved, or it’s a break.
×
Don't skip the end date — Time-boxed, always.
×
Don't spread approval — Steward grants, centrally.
×
Don't ignore repeats — Recurring exception = wrong rule.
“An exception is a rule bent on purpose — and written down.”
Early
How work earns the mark.
Review gates and the QA checklist are drafting. Workflow, legal review and the exceptions process are scoped — the cluster that protects everything upstream of a launch.
WCN Review & Approval Map · 5 topics · D01–D0508 · GOVERNANCE · D · v1.0