Workshop tool - Document one token’s naming decision · Layer 4
Answer the six questions for any token. The decision record assembles on the right as you type — copy or download it straight into your documentation.
Token name
Tier
Status
Determines the vocabulary the name must speak. A primitive is infrastructure — it doesn't need to communicate meaning. A semantic token must be legible to both designers and engineers.
Describe the decision, not the value. What is this token not for? That negative boundary is often the most useful thing to document — it prevents misuse.
Global tokens apply everywhere. Contextual tokens apply within a specific theme or mode. Component-scoped tokens only operate inside one component — consuming them elsewhere creates invisible coupling.
Which theme or mode?
Which component?
What state or condition activates this token? For stateless tokens (most primitives), document that explicitly — it tells the reader this token has no interaction dependency.
This is the question most often skipped and the one that pays off most over time. The reasoning you document today prevents the same debate from being relitigated by every future team member who encounters this name.
Alternatives considered — one per line
A token is a node in a network, not a standalone object. Documenting its connections makes the network visible — and makes the system navigable by anyone, including an LLM.
References — what this token points to
Referenced by — what consumes this token
Family — related tokens in the same set
Systems thinking check — tick before you commit the name