Runtime fingerprintToken readout from the active provider chain.
Live DS
Runtime
PlatformRottay
Rottay / ModernPlatform Flagship
Primary
#FFFFFFSecondary #A0A0A5
Radius
Compact runtime evidence across 3+ token signals.
Published DS package · Developer Docs · Rottay / modernShared route metadata for the active runtime, kept inline so the shell reads like a thin header band.
The design system scales because capability, page framing, and product semantics do not live in the same layer.
This page is meant to stop accidental complexity early. It shows how engines, tiers, and app-level semantics work together so new shared work lands in the right place from the first decision.
Core model4 tiers
Primitives, patterns, structures, and surfaces each own a different level.
Runtime leverageEngines + themes
Implementation tone changes without forcing API forks.
Key decisionCapability vs semantics
Shared UI belongs in DS. Product rules stay in the app.
Decision support
4 common architecture calls
Decision board
Use this when someone asks where new shared work should land so the answer is based on capability shape, not on folder familiarity.
How tiers, engines, tokens, and tenant branding connect internally.
Runtime controls
TenantRottay
EngineModern
Runtime flowRead this from top to bottom when a team is unsure what belongs in the app, what belongs in shared DS code, and where runtime styling actually resolves.
01
App route decides the domain task.
02
Surface describes the screen contract.
03
Structures add page chrome and context.
04
Patterns solve repeated workflows.
05
Primitives render through the active engine.
06
Tokens and BrandTheme finish the visual result.
01
Need a reusable kanban workflow across products?
Recommended tierPattern
OwnerDesign System
02
Need a users page header with filters and actions?
Recommended tierStructure
OwnerDesign System
03
Need a route that wires business data into a complete admin screen?
Recommended tierSurface + app orchestration
OwnerShared contract, app-owned semantics
04
Need a tenant-specific hiring policy or approval rule?
Recommended tierConsuming app
OwnerConsuming App
Shared system map
Choose the smallest tier that truly fits
The 4-tier model
Each layer exists to reduce ambiguity in how shared UI grows, so teams can escalate only when the work truly changes shape.
Primitives
Atomic UI parts
Primitives
Engine-aware leaf components with stable APIs. They solve local UI rendering, spacing, and interaction primitives.
Engines change implementation tone while preserving the consuming API. That stability is the reason the same shared system can serve different products without fragmentation.
ClassicStructured, precise, and admin-heavy.
Ant Design 5.21
ModernRounded, spacious, and contemporary.
Tailwind / DaisyUI
RusticQuiet, minimal, and intentionally restrained.
Vanilla CSS
Engine selectionToken-aware snippet from the active showroom runtime.
tsx
Guardrails
Do not put tenant semantics into shared components.
Do not rebuild page-level contracts with ad hoc primitive glue on every route.
Do not treat engine differences as product forks instead of runtime variants.
Ownership split
Belongs in Design System
Reusable UI capability and interaction patterns
Engine-aware rendering behavior and visual language
Shared page chrome and config-driven screen recipes
Theme, token, icon, and chart infrastructure
Belongs in Consuming App
Domain models, permissions, and workflow semantics
Route-specific data fetching and orchestration
Tenant business rules and product-specific exceptions
Mapping API responses into DS configuration objects
Decision ruleUse when the same behavior should travel across products and routes.