You built a beautiful, accessible, role-assigned palette in PaletteRx. You exported it to your platform. The site looks perfect on launch day. Six months later, five off-palette colors have crept into production because a new developer did not know the palette existed, and the designer could not remember the exact hex values. The fix: documentation.
What to Document
Color values: Every color with its hex, RGB, and HSL values. PaletteRx's JSON export provides these automatically. Role assignments: Which color is Primary, Supporting, Light Base, Dark Base. Usage rules: Primary is for CTAs and active states. Supporting is for secondary UI. Bases are for backgrounds and text. Forbidden uses: Primary should not be used for body text (contrast too low). Dark base should not be used for large backgrounds in light mode.
Accessibility Pairs
Document which color pairs pass AA and AAA. A quick reference table prevents developers from accidentally creating inaccessible combinations. PaletteRx's Step 3 contrast grid is essentially this table. Screenshot it and include it in your documentation.
Dark Mode Mappings
If your site supports dark mode, document the color mapping: which light mode variable maps to which dark mode value. Every override should be documented so future changes maintain parity.
Code References
Include the exact CSS variable names and how to use them in code: color: var(--color-primary), background: var(--color-light-base). Developers should never need to look up a hex value if the variable names are documented and the variables are properly set up.
Living Documentation
The best color documentation is a living page on your site or in your Storybook that shows actual rendered examples using the real CSS variables. This stays automatically current because it reads from the same source as production.