u/shade_zie

I recently refactored my design system from:
Primitives → Semantic → Component
to:
Brand → Alias → Mapped

The new architecture feels much cleaner. Brand stores raw values, Alias defines reusable roles, and Mapped contains the actual UI tokens consumed by components and screens.

While migrating, I ran into one problem: Alpha tokens.
My Brand collection currently looks like this:
Brand
└── Alpha
├── White
│ ├── 2
│ ├── 5
│ ├── 10
│ ├── 20
│ ├── 80
│ └── 100
└── Black
├── 2
├── 5
├── 10
├── 20
├── 80
└── 100
For colors and spacing, the Alias layer is straightforward because it represents intent (Primary, Neutral, Success, Radius, Gap, etc.).

The problem is figuring out the right abstraction for Alpha.
My goal is to keep the architecture strict:
Brand
↓
Alias
↓
Mapped

I don’t want Mapped tokens referencing Brand directly.
So what should the Alias layer look like for Alpha? Would you create Alias tokens for Black/White opacity? If so, what would you call them? Or is Alpha one of the few cases where it makes sense to bypass the Alias layer and reference Brand directly?

I’d love to hear how others structure this in mature design systems.

I currently have my design tokens structured as:

Primitives → Semantic → Component

Let's say my main brand has a subset product that needs a different primary color. My understanding is that I can handle this by creating separate modes at the Semantic layer (e.g., Main Brand and Collegiate) and switching the semantic token values per mode while keeping the same component tokens.

My question is about a more specific scenario. What if, in the future, a stakeholder says: "Keep the brand color the same, but change only this specific button style to yellow." In that case, should I create a new semantic token for that button and map the component token to it, or is it acceptable to reference a primitive token directly from the component layer?

If creating a new semantic token is the recommended approach, how should it be named? It doesn't feel right to keep creating highly specific tokens like Action/Button-Primary-Yellow. How do mature design systems handle these one-off component-specific overrides while keeping the token architecture scalable and maintainable?