When Contextual Palette Shifts Break Your Design System

You've got a design token for primary-500. In light mode it's #3B82F6. In dark mode it needs to be #60A5FA. And in high-contrast mode it shifts again. That's a contextual palette shift — a color token that changes its value based on the user's context, not just the component's state. Sounds simple. But once you scale to 50+ tokens across 3 themes, you're suddenly managing a matrix of values, and your build pipeline may start crying.

So who has to make this call? Design leads, front-end architects, and DevOps engineers who own the token pipeline. The deadline? Usually before the next theme rollout — most teams hit this when they add dark mode and realize their existing token system assumes one fixed palette. This article compares three approaches, gives you a criteria framework to evaluate them, and walks through the implementation gotchas. No fake vendors. No buzzwords. Just the trade-offs.

Who Must Choose and By When

Stakeholders involved in palette-shift decisions

Most teams assume palette shifts are a front-end concern. A designer picks a few dark-mode overrides, an engineer maps them to CSS custom properties, and the work lands within a sprint. That assumption blows up the moment you try to ship a contextual shift that touches three brands, two accessibility levels, and an inherited component library nobody fully owns. I have seen product managers schedule a palette-shift meeting as a footnote on a grooming call—and watch the entire theme release slip by three weeks because no one had authority to approve a single contrast token. The real stakeholders are rarely the people in the room. Engineering owns the build pipeline. Design systems owns the token schema. Accessibility owns the contrast ratios. Brand marketing owns the emotional tone of a palette. And somewhere above them, someone holds the release date.

Wrong order.

The hardest stakeholder to identify is the one who can veto a shift without writing a line of code—usually a director who quietly hates how a palette feels at 11 p.m. That veto arrives late, after the theme is assembled and the QA run has already passed. Once that happens, you're not debating color; you're negotiating rescheduling. The catch is that most teams skip the stakeholder map entirely. They hand the palette to an engineer and say “make it consistent.” Consistent for whom? The user on a dimmed phone? The accessibility auditor? The brand guard who wants every shade to carry emotional weight? If you can't name everyone who holds a veto, deferring the choice is not neutral—it's handing those vetoes sequential power.

“We spent six weeks building a dark palette that matched our light system. Then legal showed up and said the new blues violated the trademark. Back to zero.”

— Design systems lead, e‑commerce, 2024

Timeline pressure points for dark mode and theming

Contextual palette shifts carry a hidden deadline: the next theme release. That release is not a soft date you push because the color math feels unfinished. It hits when the OS ships a dark-mode toggle, when a client demands a rebrand before Q3 close, or when a compliance deadline forces contrast ratios to shift by a specific patch Tuesday. You're not choosing a palette approach in a vacuum—you're choosing against a calendar window that won't bend. I have watched teams burn two months arguing over whether to compute shifts through lightness curves or hand-picked swatches, only to realize the release lock was ten days away. They shipped whatever compiled.

That hurts.

Three timeline pressure points always surface. First, the design freeze—the date after which palette changes cascade into broken component tests, broken accessibility audits, and broken brand reviews. Second, the engineering integration window—typically two weeks where the theme system must be stable enough for QA to run contrast sweeps. Third, the dark-mode launch itself, which often coincides with an OS update cycle. If you miss that window, your users experience a jarring flash from light to dark—no gradual shift, no perceptual continuity. That seam blows out your UX metrics and your brand trust at the same moment. The pressure is not artificial; it's mechanical.

What happens if you defer the choice

Deferring a palette-shift decision feels like avoiding a fight. You tell yourself the team will circle back after the feature ships, that you can patch the color logic later, that the current system is “good enough.” What actually happens: the team builds the theme release without a binding rule for how palettes shift across contexts. One engineer hard-codes a correction for dark mode. Another writes a quick luminance filter that breaks the brand’s secondary hue. The component library accumulates two competing patterns for the same semantic token. By the time the release lands, the palette is internally inconsistent, the accessibility report shows three failures in high-contrast mode, and nobody remembers which override is supposed to govern the shift.

Not yet a disaster. But now every future theme—every client skin, every seasonal variant, every OS-level appearance switch—inherits that mess. The cost of retrofitting a systematic approach later is almost always higher than building it before the first shift. Why? Because you must untangle six months of ad-hoc decisions, reconcile conflicting token patterns, and retest every component for contrast violations. That takes time your next release doesn't have. What usually breaks first is not the code. It's the confidence of the team. They stop believing the design system can handle context at all. That doubt smells like launch delays, like scope cuts, like a product manager saying “just hard-code it for now.”

Three Approaches to Contextual Palette Shifts

CSS Custom Properties with light-dark()

The browser-native approach. You define a single set of custom properties, then let light-dark() decide which value to serve based on the user's system preference. Works beautifully in one context — a static site where everyone follows OS light or dark mode. I have seen teams implement this in a few hours, shipping palette shifts with zero JavaScript. The catch: it only handles two contexts. No third palette for high-contrast winter themes or branded subdomains. Worse, light-dark() can't read your design tokens. It maps values directly. So when your brand team swaps --color-accent from blue to teal, you edit every light-dark() call site instead of one token file. That hurts. If your design system lives inside a single product with binary theme needs, this is your fastest path. But the moment you need context‑aware shifts — say, a tenant‑specific brand — the approach buckles.

Why does that matter? Because most teams I talk to start here, then realize their palette must shift not just for dark mode but for editor backgrounds, print outputs, or guest‑user states. light-dark() gives you a toggle, not a spectrum.

Design Token Pipeline (Style Dictionary or Specify)

Here the mapping happens before the CSS ever reaches the browser. You define tokens as JSON — color.brand.primary — then transform them into platform‑specific values per context. Want the button.primary.bg token to resolve to #0055aa in the default palette and #003377 in the high‑contrast context? Write that aliasing once in your token repository. The pipeline spits out separate CSS files, each a complete, context‑specific palette. We fixed a cross‑product bleeding issue this way: one team accidentally used a token referenced a raw hex instead of the contextual alias. The pipeline caught it at build time. No runtime cost, no JavaScript overhead. The trade‑off? You must commit to a token workflow. Changing a palette means editing a JSON file, running a build, and redeploying. For teams with frequent palette experiments, that delay can frustrate designers. But for consistency across dozens of contexts — think white‑label portals, seasonal campaigns, accessibility overrides — this is the only approach that scales without manual error.

That said—the pipeline only helps if your design team actually defines every token. Most skip the edge cases. Then you get a partial build.

Odd bit about harmony: the dull step fails first.

Odd bit about harmony: the dull step fails first.

Runtime Theme Switching via JavaScript

Maximum flexibility, maximum risk. Here you load a JSON palette object at runtime, apply CSS custom properties through JavaScript, and mutate them on user action. I have seen this used brilliantly: a dashboard that lets admins preview brand changes before committing. Swapping a palette takes 200ms, no page reload. But the same approach, poorly implemented, can cause a flash of unstyled content, or worse — a 400ms layout shift as every component re‑renders. The pitfall is state management. If you store the active palette in localStorage but another team writes to the same key, your dark mode suddenly applies the high‑contrast palette. We fixed that by namespacing every palette key with the component domain. Still, runtime switching introduces JavaScript as a single point of failure. Disable scripts? Your palette defaults to the lightest possible value, which might break for users who need high contrast. The approach is ideal for teams that need per‑user, per‑session, or per‑route palette shifts without waiting for a deploy. But it demands testing across network speeds, browser crashes, and script blockers.

'Runtime feels liberating until you realize you just turned your design system's color logic into a JavaScript dependency — one that breaks the moment your CDN blinks.'

— senior front‑end architect, after an incident review

How to Compare These Approaches Fairly

What Are You Actually Comparing? The Three Axes

Feature checklists won't save you. I have watched teams produce a tidy table of pros and cons, nod at each other, and then pick the wrong method anyway because they never asked for whom those pros mattered. A fair comparison needs three dimensions: developer experience (DX), runtime performance, and long-term maintainability. DX covers how fast a new engineer can push a palette shift without breaking three other components. Performance is about paint cost, layout thrashing, and bundle size—things that show up in your Lighthouse report, not in a code review. Maintainability is the quiet killer: a brilliant approach that works on Monday can be a tangled mess by Friday when the design team adds "but also for dark mode variants on nested cards."

That sounds fine until you weigh them wrong.

For a startup shipping daily, DX might count for 60% of your decision—your palette shift only has to work, not be elegant. A team of ten designers and forty engineers should treat performance and maintainability as nearly equal. But a platform team supporting five products? I would weight maintainability at 50% and let DX slip. Why? Because you will live with that choice for two years, and rotating engineers need rules, not clever flex. The catch is that almost nobody writes their weights down. We compared methods once at a client and discovered the senior architect had been prioritizing performance silently while the lead designer assumed DX was the goal. Six weeks of friction over an unspoken split.

Red Flags That Kill an Approach

Three signals end the debate immediately. First: if the method requires a custom build tool that's not widely supported, you're hiring a future rewrite. Second: if the palette shift depends on runtime JavaScript to recompute every token on every theme change, and you have more than fifty components on the page—you will see a jank. I have measured this. A single re-layout can cost 120ms on mid-range hardware. That hurts. Third: if the approach stores color tokens in property strings that cascade through ten layers of shadow DOM, your maintainability score drops to zero. One engineer leaves. Another replaces them. Nobody understands why a button turns purple in one context but teal in another.

'We spent three sprints debugging a palette that worked in Storybook but broke in production. The culprit was a five-line token override buried in a mixin.'

— DesignOps lead at a 200-person product company (shared during a Slack thread I was in)

Performance regressions are the hardest to catch because they only appear under load—try simulating that in a code review. Most teams skip this: run your actual app under the three candidate approaches with Chrome DevTools Performance tab open. Watch the paint cycles. If you see a flash of unstyled content? Dead on arrival. Wrong order. A palette shift that introduces a white flash between themes ruins user trust faster than a slightly less elegant architecture.

What about the team size test? A single-person team can survive high-maintenance approaches because that one person holds all the context. A team of twenty can't. If your evaluation shows that the second-best DX method requires a weekly "palette sync" meeting, that's a red flag dressed up as process. The best framework I have seen is simple: each engineer on the team anonymously assigns a weight to the three dimensions, then add up the scores. The winning approach is the one that passes all three red-flag checks and scores highest on the weighted average. Not scientific. Brutally effective.

One Anecdote That Sealed It for Us

We tested a CSS-custom-properties approach against a build-time token injection on a real app with 47 themes. The CSS method won on DX—easy to debug, obvious in DevTools. But under stress it introduced a 90ms cascade delay. The token-injection method was slower to write but rendered at 12ms flat. For a team shipping to international markets where users switch themes frequently, that 78ms difference meant the difference between a smooth toggle and a perceived stutter. The choice became obvious. Yet the entire room had to see the flame chart to believe it.

Trade-Offs at a Glance

Build-time vs. runtime: the latency nobody budgets for

A build-time palette swap—where every context variant gets pre-rendered into separate CSS files—loads instantly for the user. No paint delay, no JavaScript frame drop. That sounds ideal until you push your first update. A team I worked with shipped five brand-specific palettes at build time: each new theme required a full re-deploy, cache purge, and three developer hours of fighting Sass maps. Build-time saves the user's milliseconds but steals your engineering afternoon. Runtime shifts—calculating contrast and swapping tokens in the browser—feel magical during prototyping. The catch is a 40–120ms visible flash on first paint. Not acceptable for a checkout button. One shop tested runtime themes on their product grid and saw a 14% drop in add-to-cart clicks during the first 500ms. You trade developer speed for user friction. Pick your scar.

Browser support and the fallback trap

Modern CSS light-dark() and oklch() color interpolation let you shift palettes contextually—theme toggle, ambient light sensor, even viewport segment queries. Beautiful on Chrome 127. On Safari 16? Fallback town. What usually breaks first is the accent color. You write accent-color: light-dark(var(--blue), var(--teal)), and four weeks later a tester on Firefox ESR sees a flat black square. The fallback logic grows: a @supports block for every query, a polyfill for the polyfill, and eventually a 14KB JS bundle that reconstructs what the browser should have done for free. Worst of all, inconsistent palette shifts across browsers erode trust—a user sees a purple background in one session and a green one in another. That seam blows out on mobile Safari where palette queries re-evaluate mid-scroll. We fixed this by shipping a single static fallback palette on browsers that failed the support test, then layering dynamic shifts only where the engine reported full support. Not elegant. But no one complained about a dead button.

'The palette shift that fails on one browser doesn't fail—it silently makes your product look careless.'

— Principal designer, enterprise design-systems team (anonymous survey, 2024)

Developer experience vs. end-user performance

I have seen teams spend three sprints building a beautiful runtime palette engine—custom property cascades, reactive context listeners, a debugging overlay—only to benchmark it on a mid-range Android phone and discover a 200ms layout jank on every context change. The developer experience was sublime; the user experience was a stutter. Conversely, build-time palettes let you write vanilla CSS with zero runtime overhead, but you maintain five, ten, twenty static files. Every new context—dark mode, high contrast, reading mode, store-specific branding—multiplies the asset count. Dev tooling suffers: your variable inspector shows only the last loaded palette, and hot-reload stops working. The trade-off is cruel: do you want your engineers fast or your users fast? Most teams skip this step—they optimize for the demo, not the real device. Wrong order. We ended up baking a palette-diff checker into our CI pipeline: if a context shift added more than 4KB of runtime code or pushed layout shift past 0.05, the build failed. That forced us to accept runtime only on low-priority contexts. Pain now, less pain at 10 million sessions.

Implementation Steps After You Decide

Auditing existing tokens for contextual needs

Before you move a single hex value, audit your token library context by context. I have seen teams spend two weeks building a beautiful shift pipeline, only to discover their --color-surface-subtle token carried five different intended meanings across product areas. That hurts. Pull every token used in your design system and tag it with the actual environments it lives inside: light mode, dark mode, high-contrast mode, component-specific overrides, and—critical one—the same component rendered inside an iframe or a side panel. What usually breaks first is a token that worked fine in a full-width layout but looks washed out when nested inside a contextual container with its own background. You will find ghost tokens: variables that exist in your system but are never consumed, and tokens that are consumed but were never assigned a contextual behavior. Delete the ghosts, and map the rest to a simple matrix—token name, current value, all contexts where it appears, and whether that appearance must stay visually identical or can shift. That matrix becomes your ground truth. Skip this, and your transformation pipeline will transform the wrong things.

Odd bit about harmony: the dull step fails first.

Odd bit about harmony: the dull step fails first.

Setting up the token transformation pipeline

Once the matrix is clean, build a pipeline that separates intent from value. The catch is that most design-token formats treat a variable like a simple key-value pair—fine for flat systems, lethal for contextual shifts.

Instead, define a token as a key linked to a set of contextual aliases. One token, four possible values: default, dark-context, panel-context, forced-contrast. Your pipeline then resolves which alias to emit based on the consuming environment at build time. We fixed this by adding a middle layer in our Figma plugin and our CSS export script—both read the same JSON schema, but the CSS output wraps values in custom media queries and container queries. That sounds fine until you realize you need to test every alias combination. Most teams skip this: they test light mode and dark mode, but they never check what happens when a user switches to forced-colors while inside a dark-themed embedded widget. I have debugged that exact scenario.

One more layer: the pipeline should flag any token whose contextual aliases resolve to an identical value across all contexts. Why ship four identical colors? That's a signal you either over-abstracted or you mislabeled the intent. Collapse those back to a single alias and save yourself future confusion.

‘We shipped four shifts. Three were identical because nobody updated the Figma library after the audit.’

— senior design ops engineer, SaaS platform

Testing across themes and contexts

Now you test—not just visual regression, but contextual regression. Write a test that mounts every component inside every context your system supports, then compares the computed color value against the expected alias. Automation catches the obvious mismatches. But the seam blows out when a component inherits a background from a parent context it was never designed for. Pull up a component like a hoverable card that lives inside a dark panel and a light main area—does its background shift correctly in both? We test this by generating a matrix of screenshots and diffing them, but we also add runtime assertions that fire when a token resolves outside its allowed alias range. Returns spike when users see a button that looks enabled but is actually disabled because a contextual shift changed its contrast ratio. One extra test per context per component prevents that. Wrong order? Test the most complex nesting first—the one that combines dark mode, a container query, and a forced-colors override. If that passes, the simpler paths almost always follow.

End with a preflight checklist: token audit complete, pipeline emitting aliases per context, regression tests covering all nesting combinations. Ship the changes behind a feature flag in staging for three days, then roll out to 5% of production traffic. Watch for support tickets about color weirdness. Fix. Uncap. That's the sequence—not the other way around.

Risks of Choosing Wrong or Skipping Steps

Accidental hardcoding and token drift

The most common failure I see isn’t dramatic—it’s a thousand small cuts. A designer picks one contextual palette, likes the result, and exports the hex value directly into a component. No token, no alias, just #2A6B9F burned into the button file. That single act fractures your system. Six weeks later, three different buttons all render slightly different blues. Token drift becomes institutional. Nobody remembers who hardcoded what, and the color audit—if anyone bothers to run one—turns up 47 orphaned values. The palette shift you chose? It never actually shifts. It just breaks consistently.

Fixable? Barely.

The catch is that hardcoding feels harmless in the moment. You’re shipping a feature; you have hours, not days. “I’ll refactor later.” Not yet. Later arrives as a Jira ticket nobody touches for three sprints. Meanwhile, your dark-mode palette shift fails because the hardcoded blue lives outside the token stack. We fixed this on one project by burning a Friday for a full-color grep across the codebase. 312 files needed updates. Three hundred twelve. That's not a refactor—that's archaeology.

Performance regressions from runtime switching

Choosing a runtime-driven palette shift (CSS custom properties swapping via JavaScript) sounds elegant. No build step, instant reactivity. The reality? It can crater your paint pipeline. Every context toggle—user scrolls into a new section, theme changes, component re-renders—triggers a full style recalculation. I watched a team ship a product page that stuttered on every hero-section entry. The palette shift demanded six custom-property overwrites per element. Chrome DevTools showed layout thrashing that peaked at 280ms per frame.

That hurts.

Most teams skip the performance audit. They assume CSS variables are free. They're not free—they just defer the cost. Swap contexts aggressively, and you introduce jank that erodes trust. The trade-off is brutal: a “clean” design-system abstraction that feels sluggish to the user. What usually breaks first is the scroll-linked animation, then the hover states, then the developer’s patience. The worst part? You can't revert without auditing every component that now depends on runtime resolution. Skipping that step means your elegant shift becomes a permanent drag.

Developer confusion and inconsistency

A contextual palette shift without documentation is a guessing game dressed as a design system. I have walked into teams where two developers implemented “primary surface” in the same sprint—one used a static token, the other a dynamic context query. Both compiled. Both looked correct in isolation. But when viewed side-by-side, the gap was obvious: the dynamic version shifted warmer under the same section. No consensus, no audit, no single source of truth.

Wrong order. The team chose the approach—runtime switching—but skipped the documented contract.

Developer confusion ripples outward. New hires read the token file, see three different patterns, and pick the one that feels safest. That's often the hardcoded fallback. The palette shift you designed to unify context ends up fragmenting it further. One concrete anecdote: a product engineer spent four days debugging a color mismatch only to discover the original token referenced a deprecated palette. Nobody had retired the old values. The shift was correct; the map was rotten. — artifact from a 15-person frontend guild, mid-2024

Honestly — most color posts skip this.

Honestly — most color posts skip this.

The fix is boring but necessary: enforce token linting in CI. Flag any raw hex within component files. Reject PRs that introduce context-switching logic without an accompanying spec. That day the engineer lost? It was preventable—if the audit step hadn’t been skipped.

“We chose the easiest palette-shift method on Friday. Tuesday morning, three developers hardcoded around it. The system never recovered.”

— lead engineer, re-platforming project, after their first sprint review

Your turn: audit your repository this week. Search for # followed by six characters in your component folder. Count the hits. That number is your risk score. If it exceeds twenty, pause your palette-shift rollout before it compounds the mess.

Frequently Asked Questions

Can I mix contextual and static tokens?

Yes, but the boundary has to be hard and explicit — not a grey area. I have seen teams try to thread one or two contextual tokens into an otherwise static system, and the result is always the same: six months later nobody remembers which tokens shift and which stay fixed. The seam blows out on dark mode pages, or a marketing microsite ignores the shift entirely. Set a rule: static tokens for things that never change meaning (border-widths, breakpoints, core brand colour), contextual tokens for everything that can trade meaning across surface, ambient light, or interaction state. Write the rule in your component README. Then enforce it in code review — because someone will try to inline a hardcoded hex next to a contextual reference. That hurts.

The catch is maintenance overhead. Two token systems mean two documentation paths, two migration scripts, two sets of designer handoff annotations. If your team is small, that friction may outweigh the flexibility. Consider starting all colour tokens as contextual — you can always freeze a subset later once you see which values never shift. Wrong order: freeze first, then complain about inflexibility.

How do I test shifts without visual regression tools?

You don't need Percy or Chromatic on day one. You need a manual grid — and a second pair of eyes. Build a single HTML page that renders every component in every palette state (light, dark, high-contrast, forced-colours override, maybe a third "vivid" mode). Display them side by side in a 2×2 or 3×2 table. Zoom to 200%. Walk the grid top to bottom. What usually breaks first is contrast: a contextual token that looked fine on a white background washes out on a dark surface because the shift only adjusted hue, not luminance.

One concrete trick: screenshot the grid at three browser widths — 360px, 768px, and 1280px — then drop the images into a diff tool (even Google Slides with opacity overlay works). Flag any pair where a button loses its border or a label merges into its background. Do this after every palette shift, not once per sprint. I fixed a production incident once by running exactly this grid — the shift was swapping two blues that looked identical to me but failed a colour‑blind simulation. The grid caught it. The unit tests didn't.

“A grid page costs one afternoon to build. A regressed palette costs a week of hotfixes and designer trust.”

— senior design‑ops engineer, after a forced-colours launch

What about high-contrast mode and forced colors?

Forced-colours mode (Windows High Contrast, macOS Increase Contrast) overrides your palette entirely if you used CSS system colours — or locks your tokens in place if you didn't. The trap: your contextual shift might work beautifully in normal contrast, but in forced-colours mode the browser discards your entire shift and remaps buttons to `ButtonText` and `Canvas`. Unexpected, but predictable if you test it.

Fix this by assigning a forced-color-adjust: none only on elements where the contextual shift carries semantic meaning — a status badge that changes colour to indicate error, for example. Let the rest of the UI defer to the user's system preference. I have seen teams apply forced-color-adjust: none globally to protect their palette shifts, and the result was a high-contrast user seeing the same green‑on‑green button that caused their original complaint. That's trading one failure for another. Test both: your shift with forced colours active, then your fallback without it. If the shift degrades to unreadable, your fallback is wrong.

Next step: open your grid page in Edge with High Contrast Black, then in Firefox with Reader View forced. If any contextual token disappears against its new background, revert that token to a system colour — today, not after the sprint. The seams are easiest to patch when you can still see them.

Which Path Fits Your Team?

Small team, junior palette, tight deadline

You have two designers, one front-end engineer, and a backlog that never shrinks. The decision criteria from earlier—team bandwidth, color-consistency tolerance, and how often your palette actually shifts between contexts—point to one clear path. Pick the lightest-weight approach: token-based manual overrides per page type. I have seen teams burn two sprints trying to build an automatic context-detection engine, only to discover that their product had only three distinct palette shifts anyway. That hurts. The catch? Manual overrides scale poorly past about seven contexts. Your team will hit a wall if the blog, the checkout, and the onboarding flow each demand a different accent color. But for now, with a tight deadline, you ship faster and you ship correctly. One concrete anecdote: a three-person team I worked with cut their palette-debug time by 70% just by declaring a single `--palette-context` custom property on the `` of each section. Ugly? Yes. Practical? Absolutely.

'We stopped designing for every possible environment and started designing for the three we actually had.'

— Lead engineer, early-stage SaaS product

Large design system, distributed ownership, regulatory contexts

Now flip it. You have twenty product teams, a central design-ops crew, and a color palette that must shift for accessibility thresholds, dark mode, and brand-sub brand variations. Here the wrong choice multiplies debt faster than any other decision. Your path is the formalized context palette map, likely inside a design-token pipeline with semantic aliasing. That sounds expensive—and it's, upfront. The payoff arrives the third time a product team accidentally uses the wrong palette token and your linting catches it before the pull request merges. What usually breaks first in large systems is trust: one team overrides a token for a legitimate reason, five teams copy that override, and suddenly you have six flavors of "primary blue." We fixed this by enforcing a single source of truth: a JSON file keyed by context (base, elevated, interactive, danger) and by mode (light, dark, high-contrast). The rule was brutal—no team could author a new palette context without a written use case reviewed by design-ops. That slowed velocity for three weeks. Then it eliminated palette drift entirely for the next eight months. Worth flagging—this approach demands a dedicated token maintainer. Without one, the map rots.

Which path fits your team? Ask yourself one question: Will your palette contexts multiply faster than your capacity to document them? If yes—go formal now, endure the upfront tax. If no—pick the manual overrides, ship the feature, and revisit this choice after your next quarterly review. Don't skip the step where you name every context explicitly; unnamed contexts breed the very inconsistency you're trying to avoid. The last thing you need is a design system that works perfectly in theory but crumbles the instant a product team loads a dark-themed checkout inside a marketing landing page. That seam blows out. And then you have a bug, not a blog post.