The same app.A differentscreen for theindividual user.
DynUI composes real, registered components into a screen per user driven by behavior, consent, and experiments. Your design system is the boundary. Dynamic, personalized UI.
scroll — the vocabulary is below ↓Compose.Validate.Then render.
A deterministic engine — or an optional model provider — emits a server-driven UI tree from your component manifest. A strict validator is the render gate. Consent and experiments are enforced in code, not prompts.
$ npm run demo — ✓ 22 rules, 0 errors, fails closedA design tool defines the vocabulary. A model composes a screen per user. A validator refuses anything off-contract — so the model never free-draws.
One activity.Three screens.
The same morning run, rendered for three different people — composed from the same nine components, never the same way.
✓ validateRenderableTree — 22 rules, 0 errors, every screen
The tree isthe contract.
Providers emit JSON, never markup. Unknown types, oversized trees, consent violations, and ungated experiments are rejected before render — then the fallback composes deterministically.
$ PROVIDER=anthropic npm run demo — first try valid, fallback unused
Consent is code,not a checkbox.
Deny-by-default. Without consent the engine composes a neutral screen and the validator rejects anything targeted. The model never sees user IDs — prompts are minimized and redacted.