Practical guide and verification
Treat the scale as a design system candidate
The workspace reuses the exact OKLCH-derived scale above, then shows contrast evidence, an interface preview and export formats. Generated step labels are local tokens, not claims that the colors match Tailwind, Material or another framework’s official palette.
Check foreground and background pairs, not colors in isolation
Accessibility depends on the luminance contrast between two colors used together. The evidence table reports white and black text ratios for each swatch and the pair count within the scale, but the actual interface still needs the intended font sizes, states and non-text contrast reviewed.
Use the preview to catch hierarchy problems
A technically valid set of colors can still produce weak visual hierarchy. Inspect buttons, body text, borders and surfaces together and confirm that important actions remain distinguishable without relying only on hue differences.
Expect gamut and device differences
The scale is calculated and displayed in browser color models and converted to sRGB values. Out-of-gamut adjustments, displays, operating-system color management and print workflows can change appearance, so a screen preview is not a physical color proof.
Export tokens only after naming the role
CSS, JSON or Tailwind-style exports make the values portable, but token names should reflect their intended semantic role in the consuming system. Keep the generated numeric scale as a starting point and map it to primary, surface, text or status roles after the contrast and hierarchy review.