Here's the failure mode: you build a clean three-tier token system. Primitives hold raw values. Semantic tokens map intent to those primitives. Component tokens reference semantics. The architecture is textbook. Six months later, engineers are hardcoding #0F172A because nobody can remember whether to reach for color.text.primary, color.fg.strong, or --fg-default. The tokens didn't fail. The semantic layer did — and it did so quietly, while everyone was shipping features.
I've written about semantic naming from a few angles over the past few months — the velocity cost of premature semantic layers, why they age well in theory but ship slowly in practice. What I haven't addressed directly is the lifecycle problem: semantic layers don't just fail at creation. They fail at a specific moment in a product's growth, and the signal is almost always the same.
The Semantic Layer Has One Job, and It's Fragile
The whole point of a semantic token is that its name describes intent, not appearance. 72Technologies puts it plainly: color.gray.100 is a variable; color.surface.subtle is a token. The name should read like a sentence describing what the thing does. When the brand refreshes and blue.500 shifts, every downstream semantic and component token updates for free — because the semantic layer absorbed the change.
That's the promise. The problem is that "intent" is only stable as long as the product's mental model is stable. And at a startup, the mental model changes constantly.
A semantic token named color.action.primary survives a palette swap. It does not survive a product decision that the primary action is now contextual — green in one product line, blue in another, amber in a third. At that point, the semantic layer isn't describing intent anymore. It's describing a past intent that no longer maps cleanly to any real surface. And as the PIXMA UX Guides taxonomy piece notes, the name is supposed to be the stable identifier that never changes even when the value behind it does. When the name itself becomes ambiguous, the whole aliasing chain loses its anchor.
This is when engineers stop trusting the system and start reaching for primitives directly — or worse, hardcoding values. The semantic layer hasn't been deleted. It's just been abandoned in place.
The Taxonomy Problem Nobody Warns You About
Honcho's token taxonomy reference describes the standard pattern as category.concept.property.variant.state — something like color.background.surface.elevated.hover. The argument for this structure is that it's predictable and parseable, which is true. The argument against it is that it front-loads a lot of architectural decisions about how your product is organized, and those decisions calcify.
The category.concept.property.variant.state chain works beautifully when your product has stable, well-understood surfaces. It becomes a liability when you're adding a new product area every quarter and nobody can agree whether the new dashboard's sidebar is a surface.elevated or a surface.raised or something that doesn't fit either. The taxonomy debate absorbs review time — exactly the friction the Honcho piece says a clear taxonomy is supposed to prevent.
The signal that your semantic layer has outlived its usefulness: when engineers spend more time arguing about where a new token belongs in the hierarchy than it would take to just ship the component.
What Actually Survives
The 72Technologies post offers a useful sniff test: if a name contains a color, size, or number, it belongs in the primitive layer only. Semantic tokens should be appearance-agnostic. That's a good rule. But there's a companion rule worth adding: if a semantic token name requires institutional knowledge to interpret — if a new engineer has to ask what "surface.raised" means in your specific product — the name has already failed its primary job.
The Design Systems Collective piece on token naming frames the core tension well: a token name is not just a label, it's a piece of system language that needs to be understood across designers, product teams, and developers over time. The "over time" part is where most semantic layers quietly break. They're designed for the team that built them, not for the team that inherits them eighteen months later.
The teams I've seen handle this well do two things differently. First, they treat semantic token names as public API — they version them, deprecate them explicitly, and don't let them accumulate silently. Second, they keep the semantic layer thin. Not every concept needs a semantic token. The components that genuinely have product-specific rules get component tokens; everything else resolves straight to a semantic value. A smaller semantic surface is a more maintainable one.
The semantic layer outlives its usefulness the moment it stops being a shared vocabulary and starts being a historical artifact. The fix isn't a better naming convention — it's treating the layer as something that requires active maintenance, not just initial design.
