Lyotic Design System · v0.1
Form adapts. Meaning persists.
A design system for supervising delegated AI work. The interface changes shape with the work. What the work is, what is known, who allowed what, and what was verified do not change with it.
One item, four systems, two numbers. Everything above is the real resolver deciding and the real components rendering its plan. Press Play again or step through it; pressing a control inside the object moves the Case.
What stays the same
Lyotic lets a representation grow, shrink and change mode with the work. These never change with it.
One object, many forms
A Work Object keeps one surface from compact to compare, decide, approve, apply, verify and recover. Its identity never crossfades.
Evidence caps wording
No sentence, glyph or colour states a fact more strongly than its evidence. An unknown stays unknown, however fluent the explanation.
Completion is earned
Resolved, synced and a green check appear only for a scope that was verified. Applied is not verified.
Authority has five layers
Capability, permission, delegation, approval and validity at execution. An approval binds one version, and a later change spends it.
Attention is requested, exploration is free
The system opens the object only at a judgment point, and never moves your focus to do it. You can open or collapse anything, any time.
Outcomes are per target
Shopify applied and Amazon unknown is shown as exactly that. An unknown outcome is still, not spinning, and is reconciled before anything is retried.
A contract, not a look
Lyotic is built in four layers. Only the first two are visual, so Lyotic can wear another brand and keep its meaning.
| Layer | Is | Lives in |
|---|---|---|
| Foundation | Colour, type, space, shape, elevation, motion, density | --ly-* custom properties |
| Semantic presentation | Roles that present states: evidence, intended, attention, judgment, verified | --ly-role-* |
| Interaction state | Runtime values of each axis, set from the plan, never by hand | data-ly-* attributes |
| Policy | Which representation and which controls a state allows | @lyotic/core, never CSS |
import { resolve, checkDom } from '@lyotic/core';
import { WorkObjectShell } from '@lyotic/components';
const plan = resolve(caseState); // deterministic: same state, same plan
const shell = new WorkObjectShell(element);
shell.render(caseState, plan); // renders only what the plan allows
checkDom(element, plan).violations; // [] or the invariant that broke
Explore
- FoundationsThe integrity gapWhy one fluent answer or one green check can paper over what really happened.
- StylesStatus languageSolid, dashed, dotted. Lit and at rest. One shape for every state axis.
- ComponentsFifteen semantic partsEach with what it may claim and what it must never claim.
- PatternsThe morphOne surface, many representations. Springs, asymmetry, lit to rest.
- Reference case5,400 / 1,620Neither number is wrong. The full walk, with the plan and invariants live.
- DevelopPackagesTokens, morph, core and components. No framework, no build step.
What Lyotic is not
Not Systead. Systead is the first product built on Lyotic; it keeps business relationships across systems. Lyotic represents that work to people. Not H.A.R.D. H.A.R.D. reviews design choices; Lyotic is the interaction system under review. Not “AI makes the UI”. Generative UI, mixed initiative and mid-run approval already exist. Lyotic’s claim is narrower and testable: a contract that binds independent work state, evidence, authority and outcome to a bounded representation, and an implementation that detects when meaning is distorted.