Skip to content

Packages

DynUI ships as ten packages with zero runtime dependencies. Each package’s README in the repository is its API reference; this page maps the toolkit.

Package Role
@dynui/contracts Public types, runtime schemas, JSON Schema export, version migrations
@dynui/validate The render gate — structural and context-aware tree validation
@dynui/generate Generation orchestrator, model providers, repair, deterministic engine
@dynui/signal Signal evaluation and domain-configurable segment inference
@dynui/profile Profile adapters, consent handling, behavior ingestion, storage
@dynui/privacy Prompt minimization, redaction, anonymization, consent primitives
@dynui/experiments Component experiments: assignment, guardrails, SRM, analysis
@dynui/telemetry Behavior events, exposure tracking, aggregation
@dynui/figma Contract extraction from Figma, manifest lint and diff
@dynui/cli dynui binary: validate, lint, and export schemas from the shell

Most product teams touch the packages in this order:

  1. @dynui/contracts and @dynui/validate to define and prove the manifest.
  2. @dynui/profile and @dynui/privacy to resolve anonymous, consent-aware profiles.
  3. @dynui/generate in deterministic mode to produce safe trees.
  4. A product-owned renderer registry in the app.
  5. @dynui/telemetry and @dynui/experiments once exposure and outcomes matter.
  6. @dynui/figma and @dynui/cli for design-system governance and CI.

Live model providers are optional. They belong after the deterministic path, renderer compatibility, privacy path, and telemetry path are stable.