Skip to content

DOMAIN:CREATIVE — REQUIREMENTS_TRACEABILITY_FOR_CREATIVE

OWNER: leah ALSO_USED_BY: anna (spec authoring), antje (spec clarification), faye (team alfa PM), sytske (team bravo PM), aimee (scoping), jasper (test reconciliation) UPDATED: 2026-03-28 SCOPE: tracing requirements from client brief through strategy, design, and final deliverable — ensuring nothing is lost, contradicted, or invented

PURPOSE

Creative traceability answers one question: Can every element in the final deliverable be traced back to a requirement?

Without traceability: - Designer adds a feature nobody asked for (scope creep) - Brief says "minimalist" but deliverable is visually dense (drift) - Client asked for navy blue, strategy says dark blue, design shows #000080 which is actually very dark blue-black (telephone game) - Nobody can prove the deliverable satisfies the brief (audit failure)

Leah uses the traceability matrix to verify that creative output fulfills its requirements completely and without contradiction.

THE CREATIVE TRACEABILITY CHAIN

CLIENT_BRIEF (what the client wants)
      |
      v
BRAND_STRATEGY (how to achieve what the client wants)
      |
      v
BRAND_IDENTITY (visual/verbal system derived from strategy)
      |
      v
DESIGN_SPECIFICATION (concrete tokens, components, layouts)
      |
      v
CREATIVE_DELIVERABLE (the actual output)
      |
      v
LEAH_VALIDATION (does output match all upstream layers?)

Each layer MUST be traceable to the one above it. Each layer ADDS specificity but MUST NOT contradict the layer above.

BUILDING THE CREATIVE TRACEABILITY MATRIX

MATRIX STRUCTURE

Req ID Source Requirement Strategy Decision Design Decision Deliverable Element Status Notes
BRF-001 Client brief "Professional but approachable" Tone: warm professional Color: #1976D2 (trust), rounded corners (friendly) Header uses #1976D2, 8px radius TRACED Full chain verified
BRF-002 Client brief "Must work on mobile" Mobile-first responsive Breakpoints: 320, 768, 1024, 1440 Layouts at all 4 breakpoints TRACED All breakpoints present
BRF-003 Client brief "Show pricing clearly" Pricing table on homepage 3-tier pricing component Pricing component present PARTIAL Missing annual toggle from spec
STR-001 Strategy doc "Target: SME owners 35-55" Photography: real business owners Stock photo library: diverse professionals Hero image: young tech startup CONTRADICTION Image targets wrong demographic

COLUMN DEFINITIONS

Req ID: Unique identifier. Prefix indicates source layer: - BRF-xxx: Client brief requirement - STR-xxx: Strategy-derived requirement - BID-xxx: Brand identity requirement - DSP-xxx: Design specification requirement

Source: The document where this requirement originates.

Requirement: The actual requirement text, quoted verbatim where possible.

Strategy Decision: How the strategist interpreted this requirement.

Design Decision: How the designer implemented the strategy decision.

Deliverable Element: The specific element in the output that fulfills this.

Status: - TRACED: Full chain from brief to deliverable, no contradictions - PARTIAL: Requirement partially addressed, gaps identified - CONTRADICTION: Downstream layer contradicts upstream - MISSING: Requirement has no corresponding deliverable element - UNTRACED: Deliverable element has no corresponding requirement (potential scope creep)

DESIGN CONTRACTS

Borrowed from software engineering's "design by contract" (Bertrand Meyer, Eiffel language). Applied to creative work, a design contract defines:

PRECONDITIONS (What must be true before creative work starts)

  • Approved client brief exists
  • Brand guidelines document is finalized
  • Design tokens are defined and versioned
  • Content (copy, images) is available or realistic placeholders are documented
  • Target audience is defined with specificity

POSTCONDITIONS (What must be true when creative work is complete)

  • Every element traces to a requirement (no orphans)
  • Every requirement traces to an element (no gaps)
  • All design tokens used correctly (verified against token file)
  • Accessibility requirements met (contrast, typography, responsive)
  • Cross-deliverable consistency verified (if multi-deliverable project)

INVARIANTS (What must ALWAYS be true)

  • Brand primary colors are never modified, tinted, or approximated
  • Logo clear space is never violated
  • Typography hierarchy is never inverted (H2 never larger than H1)
  • No content is clipped, truncated, or hidden unintentionally
  • Interactive elements are always distinguishable from static elements

CONTRACT_VIOLATION = automatic QA failure. No exceptions, no judgment calls.

DETECTING CONTRADICTIONS BETWEEN SPEC LAYERS

This is Leah's most critical function. Contradictions between layers cause the worst creative failures because everyone thinks they're following the spec — they're just following DIFFERENT specs.

COMMON CONTRADICTION PATTERNS

Pattern Example Detection Method
Brief vs Strategy Brief: "bold and disruptive" / Strategy: "trustworthy and conservative" Compare adjective clusters between documents
Strategy vs Identity Strategy: "youthful energy" / Identity: serif fonts, muted palette Check if visual language matches strategic intent
Identity vs Spec Identity: "clean minimalism" / Spec: 47 components on the dashboard Count element density, compare against identity principles
Spec vs Deliverable Spec: "8px corner radius" / Deliverable: mixed 4px and 12px Measure actual values against token definitions
Brief vs Deliverable Brief: "must work for colorblind users" / Deliverable: relies on red/green distinction Simulate color vision deficiency on deliverable
Cross-deliverable Website: flat design / iOS app: skeuomorphic elements Visual comparison across deliverables

CONTRADICTION SEVERITY LEVELS

Severity Definition Action
CRITICAL Deliverable contradicts explicit client requirement BLOCK delivery. Return to designer with brief reference.
HIGH Strategy and design are misaligned on target audience or tone BLOCK delivery. Escalate to strategist for arbitration.
MEDIUM Design spec violated (wrong token value, missing state) RETURN for correction. Specific, actionable feedback.
LOW Minor inconsistency across deliverables (e.g., slightly different hover states) LOG and include in QA report. Fix in next iteration.

CONTRADICTION RESOLUTION HIERARCHY

When two spec layers contradict, which one wins?

1. CLIENT_BRIEF (highest authority — client's explicit words)
2. BRAND_STRATEGY (interpretation of brief, approved by client)
3. BRAND_IDENTITY (visual system derived from strategy)
4. DESIGN_SPECIFICATION (technical implementation of identity)
5. DESIGNER_JUDGMENT (lowest — must defer to all above)

If the contradiction is between layers 1-2 (brief vs strategy), ESCALATE to account manager. If between layers 2-4, ESCALATE to the author of the higher-priority layer. NEVER resolve contradictions by Leah's own judgment — she identifies, she does not arbitrate.

TRACEABILITY FOR MULTI-AGENT CREATIVE PIPELINE

In GE's pipeline, creative work passes through multiple agents. Each handoff is a potential traceability break.

AGENT CHAIN AND TRACEABILITY RESPONSIBILITIES

Agent Role in Chain Traceability Duty
Aimee Scoping & requirements Creates initial requirements (BRF-xxx IDs)
Anna Specification Maps requirements to design spec (DSP-xxx IDs), must reference BRF-xxx
Margot Design production Implements spec, must reference DSP-xxx for each design decision
Boris Visual production Produces final assets, must reference DSP-xxx for each asset
Tobias iOS-specific design Implements HIG-compliant design, must reference DSP-xxx
Leah Validation Verifies full chain BRF → STR → BID → DSP → deliverable

HANDOFF TRACEABILITY TEMPLATE

Every handoff between agents MUST include:

HANDOFF_FROM: [agent]
HANDOFF_TO: [agent]
REQUIREMENTS_COVERED: [list of Req IDs addressed]
REQUIREMENTS_DEFERRED: [list of Req IDs not yet addressed, with reason]
DECISIONS_MADE: [list of design decisions with rationale and req reference]
OPEN_QUESTIONS: [anything ambiguous that needs clarification]

If a handoff arrives without traceability metadata, Leah flags it as QA_BLOCKED.

AUTOMATED VS MANUAL TRACEABILITY CHECKING

AUTOMATABLE CHECKS

Check Automation Approach
Design token compliance Parse deliverable CSS/tokens, compare against design system JSON
Color hex matching Extract colors from deliverable, compare against brand palette
Font family verification Parse font-family declarations, compare against spec
Asset dimension verification Read file metadata, compare against spec dimensions
Naming convention compliance Regex match filenames against naming spec
Breakpoint coverage Check if deliverable has styles for all specified breakpoints
WCAG contrast ratio Calculate contrast for all text/background combinations

MANUAL CHECKS (Require Leah's judgment, anchored to specs)

Check Why Not Automatable
Visual hierarchy alignment Requires understanding of brief's priority intent
Tone/mood consistency Requires interpreting strategy's emotional direction
Photography appropriateness Requires understanding of target audience and cultural context
Copy-visual congruence Requires understanding semantic relationship between text and imagery
Cross-deliverable family resemblance Requires holistic assessment across multiple outputs
Layout balance and composition Requires understanding of design principles in context of brief

PRINCIPLE: Automate everything that CAN be automated. Reserve Leah's judgment for what REQUIRES judgment. Never waste cognitive load on things a script can check.

TRACEABILITY METRICS

Track these to measure traceability health across projects:

Metric Target Red Flag
Requirements coverage 100% of BRF requirements traced to deliverable Any requirement at MISSING status
Orphan elements 0% of deliverable elements untraced Elements that trace to no requirement
Contradiction rate <5% of requirements have contradictions Rising rate across iterations
Handoff completeness 100% of handoffs include traceability metadata Any handoff missing metadata
First-pass QA rate >80% of deliverables pass QA on first review Dropping rate indicates spec quality issues
Time-to-resolution <4 hours for MEDIUM, <1 hour for CRITICAL Growing resolution times

ANTI-PATTERNS

Anti-Pattern Why It's Wrong What to Do Instead
Tracing to "the brief" without specific requirement ID Cannot verify which requirement is satisfied Always reference specific BRF-xxx
"Implied" requirements "Everyone knows we need a footer" — no, if it's not in the brief, it's not required If it should be there, add it to the spec explicitly
Post-hoc traceability Building the matrix after the deliverable is done Build the matrix as requirements are created, update as design progresses
Tracing to deleted/superseded requirements Requirement was changed but matrix not updated Version requirements, mark superseded ones
Skipping strategy layer Brief → deliverable with no strategy documentation Strategy layer catches contradictions early — never skip it
Single-direction traceability Only checking forward (req → deliverable), not backward (deliverable → req) Always check BOTH directions: gaps AND orphans

REFERENCES