The mapping problem is the core technical problem in brief-to-screen generation. A brief says "a primary action button". A design system has a token named --button-bg-primary-default that aliases to --color-interactive-default, which in turn resolves to a specific hex value. The generation step has to traverse from the natural language description in the brief to the terminal token value in the design system, without losing precision at any step of the chain.
This sounds straightforward in the abstract. In practice it requires resolving ambiguity at two levels: the natural language level (what does "primary action" mean in this system's vocabulary?) and the structural level (which token path is the right path when multiple plausible paths exist?). This post explains how we approached both problems when building Flowstep's resolution engine.
The vocabulary gap between briefs and token systems
Briefs are written in the language of product intent. "Primary action button" is a product-level concept that describes a button's role in the user flow, not its visual specification. "Destructive variant" describes an interaction consequence, not a color token name. "Secondary surface" describes a container's hierarchy, not its background token.
Design system token names, by contrast, are written in the language of the system's architecture. A system might have --color-danger-default or --color-negative-600 or --color-feedback-error or --button-destructive-bg for the same concept: the background color of a destructive action button. All of these are reasonable token names for the same semantic concept. None of them directly match the phrase "destructive variant" that a PM might write in a brief.
The vocabulary gap is the mapping problem's first dimension. Solving it requires a conceptual vocabulary layer that maps intent-language to token-language without requiring the brief author to know the design system's naming conventions.
The structural ambiguity problem
Even after resolving the vocabulary gap, structural ambiguity remains. Consider a design system with both semantic tokens and component-scoped tokens:
/* Semantic layer */
--color-interactive-default: var(--color-violet-700);
--color-interactive-hover: var(--color-violet-800);
/* Component layer */
--button-bg-primary: var(--color-interactive-default);
--button-bg-primary-hover: var(--color-interactive-hover);For a primary button, both --color-interactive-default and --button-bg-primary resolve to the same value. They are not equivalent for mapping purposes. Using --color-interactive-default on a button background means bypassing the component token layer. If the team later adjusts --button-bg-primary to deviate from --color-interactive-default for design reasons, a generated screen that bypassed the component layer would not reflect that deviation.
The resolution engine has to prefer the most specific applicable token path. For a button component, the component-scoped token is more specific than the semantic token, even when both currently resolve to the same value. The structural choice matters for future correctness, not just present correctness.
The resolution algorithm
Flowstep's mapping approach works in three phases for each component identified in a brief.
Phase one: component identification. The brief is parsed to identify component concepts: what types of elements are described? A "navigation bar" is a distinct component type from a "modal dialog" and from a "settings panel". The parser extracts component type, stated variant (primary, secondary, destructive, ghost), and any explicitly mentioned states (default, hover, error, disabled).
Phase two: token path resolution. Given a component type and variant, the resolution engine searches the connected token file for applicable token paths. It prefers component-scoped tokens over semantic tokens over primitives. When multiple component-scoped paths exist for the same property (for example, a design system that has both --button-bg-primary and --cta-bg-default), the engine uses naming distance to the component identifier from the brief to select between them. "Primary action button" is closer to --button-bg-primary than to --cta-bg-default in naming space.
Phase three: alias chain walking. Once a token path is selected, the engine walks the alias chain to confirm the terminal value. A component token that aliases to a semantic token that aliases to a primitive that resolves to a hex value produces a fully-traced path. A component token that hardcodes a hex value directly (skipping the semantic layer) is flagged as a broken chain and reported in the generation output, because this pattern is a common source of future drift.
Where the mapping produces uncertainty
The algorithm above handles well-structured design systems with clear component-scoped tokens and intact alias chains. Not all design systems are well-structured, and the resolution engine has to make reasonable choices when the structure is incomplete.
The most common incomplete structure: a design system with a semantic token layer but no component-scoped tokens. In this case, the engine falls back to semantic tokens, which requires more inference about which semantic token applies to which component property. A button background in a system without component tokens might map to --color-interactive-default based on naming proximity, or it might map to --color-brand-500 if the system uses a flat naming structure. When the correct path is ambiguous, the engine selects the most probable path and marks the selection as an inferred mapping rather than a resolved mapping, so the output can be reviewed before handoff.
The second common case: a design system with component tokens but no explicit state encoding. A system that has --button-bg-primary but no --button-bg-primary-hover cannot provide hover state mapping. The engine generates the default state correctly and flags missing states rather than silently applying the default to the hover as well. Missing states are better surfaced explicitly than silently collapsed.
We are not claiming the resolution engine handles every design system structure correctly on the first pass. Our position is narrower: for systems with a defined semantic layer and component-scoped tokens, the mapping is mechanical and precise. For systems without that structure, the mapping is inferential, and the output is annotated to indicate where inference was used so the designer can review and correct before treating the output as a final token assignment.
What a well-mapped output looks like
A generation output with complete token mapping for a button component would carry, at minimum, the following token assignments:
/* Button component - primary variant */
background: var(--button-bg-primary) /* resolved */
background-hover: var(--button-bg-primary-hover) /* resolved */
color: var(--button-text-primary) /* resolved */
border-radius: var(--button-border-radius) /* resolved */
padding: var(--button-padding-horizontal)
var(--button-padding-vertical) /* resolved */
box-shadow: var(--button-shadow-focus) /* resolved, focus state */Each assignment carries its resolution status. A "resolved" assignment means the engine followed the alias chain to a primitive value and confirmed the path is intact. A resolved output for a button component in a mature design system typically requires 6-10 token assignments. Each one the generation gets right is one fewer that a developer has to re-derive from a flat image. That is where the re-derivation cost from flat handoffs becomes a non-issue: the token context is already in the file.
