Skip to main content
A theme in Livry is a JSON document of tokens — the named values your interface renders with. Colours, spacing, radii, typography, shadows, whatever your design system defines.

​
Schema-less by design

Livry does not impose a token vocabulary. There is no fixed list of names you must use, and no required shape for the document. If your design system calls it surface.raised.border, that’s what you store. This is deliberate. Token taxonomies are opinionated and product-specific, and a theming service that forces its own taxonomy onto you means writing a mapping layer on both sides — one to publish, one to consume. The cost is that Livry can’t validate token names for you. A typo in a token name is stored faithfully and surfaces as a missing value at render time. Two consequences worth planning for:
  • Decide your token vocabulary before onboarding your second brand. Retrofitting a naming convention across many Organizations is painful.
  • Handle missing tokens defensively in your frontend. A sensible fallback beats an undefined value reaching CSS.

​
Nesting

Token documents are arbitrary JSON, so nesting is up to you. Flat maps and deeply nested structures both work.
Whichever shape you pick, keep it consistent across your default theme and every Organization’s overrides — override resolution matches on structure.