---
title: "Token Framework: keep the meaning, change the expression."
url: "https://lindemann.design/work/token-framework/"
description: "Research and development of a design-token framework separating brand values, semantic meaning and runtime preferences, informed by naming studies and the earlier Zygo build tooling."
---

# Token Framework: keep the meaning, _change the expression._

A design token needs to carry more than a colour or a number. It needs to explain what that value is for, and remain useful as a product changes brand, theme or platform. I am developing a framework for that shared language, bringing together a naming catalogue, versioned architecture and lessons from the earlier Zygo build tooling. The framework is in development.

Framework

-   Semantic tokens
    
    ```text
    Interface uses bg.action.primary.default
    
    bg background
    action the role in the interface
    primary emphasis
    default interaction state
    
    Light mode {color.light.bg.action.primary.default}
    Dark mode {color.dark.bg.action.primary.default}
    
    The name describes intent. The theme supplies its value.
    
    Brand values palette and raw values
    Theme mappings connect values to meaning
    Public aliases stable names used by interface code
    ```
    
    The alias pattern is present in the earlier Zygo token files and carried into the framework draft. This is a structural example, not a generated interface.
    

Role

Research, architecture and engineering

Stack

-   JSON design tokens
-   Tokens Studio
-   Style Dictionary
-   CSS and Tailwind adapters

Status

Research and development

1.  **Meaning** Name the role a value plays in the interface.
2.  **Separation** Keep brand values, themes and public aliases distinct.
3.  **Continuity** Carry a stable interface across changing contexts.

The question

## What should a token name promise?

A name such as “blue-500” identifies a palette value. It does not explain whether that value belongs on a primary action, a selected item or a focus indicator. A component name provides context, but tying every decision to one component can make the system difficult to reuse elsewhere.

The framework investigates the space between those approaches: enough meaning to guide a decision, with enough independence to survive a different brand, platform or component implementation.

My work brings together the naming research, the organisation of the token catalogue and the architectural rules. The earlier Zygo tooling is a related implementation developed with Dave Musson. It provides concrete token files and build adapters against which to examine the model.

Research approach

## Compare the vocabulary with the things it has to describe.

The research is an investigation of token systems and their implementation, rather than a study of customer behaviour. The working materials include a naming workbook, earlier catalogue iterations, real theme and mode files, and a versioned framework specification.

The workbook separates dimensions such as type, purpose, family, state, scale and variant. It also records the vocabulary available within those dimensions. This makes naming decisions inspectable: a proposed term has to fit a defined role, rather than simply sound plausible in one example.

The references include token-naming work by Nathan Curtis and Lukas Oppermann, Radix colour scales, and the Asana presentation by Jina Anne, Ainsley Wagoner and Ivy Wang. These are influences on the investigation. The framework brings those ideas into conversation with the requirements and token files of this project.

Comparing the catalogue with implementation exposes disagreements worth resolving. For example, “large” can describe typographic prominence or a physical size. Those meanings should not be silently treated as interchangeable simply because they share a word.

Architecture

## Separate a brand's values from the role they play.

The architecture distinguishes raw brand values, semantic theme mappings and the aliases consumed by an interface. A brand owns its palette. A theme decides how that palette expresses actions, content and surfaces. The public alias gives implementation a name that remains stable when that expression changes.

Token resolution

```text
Brand value
brandOne.color.Primary.500 (Main)

Theme mapping
color.light.bg.action.primary.default
  -> {brandOne.color.Primary.500 (Main)}

Public alias
bg.action.primary.default
  -> {color.light.bg.action.primary.default}
```

This is a readable rendering of the reference structure. Each layer answers a different question: what the brand supplies, what the interface means, and what name an implementation can depend on.

The current draft keeps platform, domain and theme context outside the design-token path. It also treats mode, density, direction and other runtime preferences as separate axes. This avoids making a new public token name for every combination of context.

Naming decisions

## Let the name stay put when the mode changes.

The mode files in Zygo already demonstrate the alias pattern. Light and dark mappings can point to different theme values while exposing the same name to the interface.

Mode aliases

```json
{
"light": {
  "bg.action.primary.default": "{color.light.bg.action.primary.default}"
},
"dark": {
  "bg.action.primary.default": "{color.dark.bg.action.primary.default}"
}
}
```

This example flattens the paths from the separate JSON files to make the relationship visible. It is an explanation of the data, rather than the complete build input.

Another deliberate decision in the draft is to avoid component-prefixed tokens. Components consume reusable semantic families such as actions and controls. A unique requirement belongs in a theme mapping or a clearly named family, rather than creating a separate token catalogue for every component.

That is a design choice with a cost: the family vocabulary has to be precise enough to accommodate real differences. The research needs to test that boundary rather than assume that every exception can be absorbed without making the language harder to understand.

Implementation

## Use build tooling to test the architecture's demands.

Zygo supplies the earlier implementation work: a configurable Style Dictionary build, token-set variations and output adapters, including Tailwind-oriented CSS. Its sample data separates branding, themes, modes and density. Those files provide something concrete to inspect alongside the naming catalogue.

The newer framework is intended to guide the successor to that tooling. Its specification defines structure and constraints; it does not yet implement every output adapter or resolve every combination of runtime preferences.

That separation helps keep progress honest. The existing build code demonstrates implementation experience. The versioned framework records the direction of the next system. They are connected pieces of work, at different stages.

Next application

## Give people and tools the same rules to work from.

A structured token language can support more than manual implementation. The next step is to make its vocabulary and constraints consumable by automated tools, including AI-assisted interface generation.

The intended behaviour is specific: a tool should select an allowed semantic token, use the correct alias, and produce output that can be checked against the same rules a person follows. The framework's draft validation rules cover matters such as allowed dimensions, valid aliases and keeping raw brand references out of interface code.

This remains a development direction. A complete automated generation and conformance pipeline has not been established by the materials shown here. The immediate work is to make the contract unambiguous enough to build and test that pipeline.

Current outcome

## A defined model, and a visible set of open questions.

The work has produced a naming catalogue, a versioned architecture and a connection to real token data and build tooling. It makes important boundaries explicit: raw values and meaning, internal mappings and public names, stable paths and changing context.

The draft also records what still needs resolution. Typography prominence, border naming, forced-colour support and the interaction of multiple runtime preferences remain open. Mode and density composition needs practical testing, not just a convincing diagram.

The next milestone is to resolve those ambiguities against representative interfaces and encode the agreed rules in the successor tooling. That will turn the framework from a documented model into a contract that can be exercised and checked.