Token Transform Pipeline

End-to-end pipeline from designer anchor choices through generation, layering, and output to CSS custom properties.

The token transform pipeline traces how a designer's color anchor choices become consumable CSS custom properties through six stages. This is a custom pipeline — not Style Dictionary or Token Studio — built to handle the dimensional model's alias chains and multi-mode resolution. Figma integration occurs at defined sync points between stages.

Pipeline Overview

Anchors ──► generate-ramps.ts ──► Primitives ──► Semantics ──► Component Slots ──► CSS
                 ▲        │
                 │        ▼
              Pull     Push        ◄── Figma Push/Pull sync
                 │        │
                 └── Figma ─┘
                      ▲
                      │
                   PRISM            ◄── MCP bridge layer

The six stages form a single direction: each stage's output feeds the next. Figma Push/Pull and PRISM sit alongside the pipeline as integration points, not stages themselves.

Stage 1: Anchors

Designers choose anchor hex values and assign each to a step in the 12-step color ramp. An anchor defines the hue and chroma that a given step should hit — the generator fills in the rest.

A palette can have multiple anchors. When it does, hue interpolates between them using shortest-arc (circular) interpolation, keeping transitions smooth across the ramp.

See Anchor Model for the full specification.

Stage 2: generate-ramps.ts

The generator script converts anchor definitions into complete primitive ramps:

Parse anchor hex values into OKLCH
Apply lightness targets per scheme (LIGHTNESS_TARGETS_LIGHT, LIGHTNESS_TARGETS_DARK)
Interpolate hue between anchors (shortest-arc)
Distribute chroma using a bell-curve (σ = 0.28)
Gamut-map results back to sRGB
Emit outputs in three formats: CSS custom properties, JSON, and Figma variable schemas

The lightness targets are fixed arrays that define each step's L value. Light and dark schemes use approximate mirrors — step 50 is near-white in light mode, near-black in dark mode.

See Generation Pipeline for the algorithm details.

Stage 3: Primitives

The generator's output: raw OKLCH color values plus size, typography, and scale tokens. These are the lowest-level tokens in the system.

Naming: --{category}-{name} (e.g., --colors-neutral-500, --size-16)
Theme-aware: light and dark modes produce different values for the same token name
Rule: never reference primitives directly in component code — they exist only to feed semantic tokens

See Primitives and Primitive Naming.

Stage 4: Semantics

Semantic tokens are purpose-driven aliases that map primitives to intent.

Naming: --{element}-{variant}-{state} (e.g., --background-neutral-weaker-rest, --foreground-brand-hover)
Elements: page, foreground, background, border, overlay, space, radii, sizes
Pairing rule: foreground and background tokens must come from the same family and emphasis level to guarantee accessible contrast

Semantics insulate components from primitive changes. Swapping a brand palette only requires updating the semantic-to-primitive mapping — no component code changes.

See Semantics and Semantic Naming.

Stage 5: Component Slots

Component slots are named openings inside a component's variable collections. Each slot declares which semantic token fills a role under a given combination of dimensions (sentiment, emphasis, state, size).

The flow from design to code:

Designer defines variable collections per component in Figma
Transformer extracts collections into a component manifest
Component publishes compiled slots
Resolver reads slots at runtime, resolving the active dimensional combination to a concrete CSS value

See Component Slots and Resolver.

Stage 6: CSS Output

The pipeline generates separate CSS files per category:

File	Content
`colors.css`	Color tokens with dark/light mode via `@media (prefers-color-scheme)`
`scale.css`	Spacing, radii, shadows, z-index, opacity, borders
`typography.css`	Font families, sizes, weights, line heights, letter spacing
`semantics.css`	Semantic aliases that reference the above

Figma variable paths map to CSS custom property names — slashes become hyphens, with a category prefix where needed:

Figma path	CSS variable
`colors/brand-dark/500`	`--colors-brand-dark-500`
`size/16`	`--size-16`
`background/brand/rest`	`--color-bg-brand-rest`

Integration Points

Figma Push/Pull

Figma Push/Pull sync is documented separately in a dedicated sub-plan.

Push/Pull provides bidirectional sync between the local pipeline and Figma. Pull retrieves anchor definitions from Figma variable collections so generate-ramps.ts can consume them. Push writes the generated primitive values back into Figma as variables, keeping the file in sync with the pipeline output.

PRISM

PRISM is documented separately. See the PRISM interface definition for the full spec.

PRISM is the MCP bridge layer that enables local scripts — including generate-ramps.ts and the push/pull sync — to read from and write to Figma files programmatically. It connects via STDIO or local HTTP and discovers available operations at runtime.

Validation

At each stage boundary the pipeline validates alias integrity:

Every alias reference points to an existing variable
No circular alias chains
Color tokens in component collections alias semantic tokens, not primitives directly
Mode counts match across related collections

Validation failures produce clear error messages with the broken alias path. See Token Audit for the full cascade integrity methodology.