AI Design System Prompt Architect for Web UI

=== AI DESIGN SYSTEM FOR WEB UI ===

Project
NovaPilot AI Workspace

Product Category
Multi-tenant B2B AI automation SaaS

Primary Users
Operations managers, marketing teams, customer success teams, agencies, and startup teams

Primary Product Jobs

• Build AI workflows
• Connect business systems
• Review AI outputs
• Approve high-risk actions
• Monitor workflow health
• Investigate failures
• Manage permissions
• Track usage

=== EXECUTIVE SUMMARY ===

NovaPilot requires a coherent product system that communicates intelligence and technical capability without creating visual noise or operational ambiguity.

The recommended system should combine

• Dark graphite foundations
• Deep indigo working surfaces
• Electric-blue primary actions
• Restrained cyan accents
• High-contrast typography
• Semantic status colors
• Medium corner radii
• Subtle borders
• Limited elevation
• Restrained glass effects
• Clear data hierarchy
• Accessible focus
• Predictable interaction behavior

The system should be structured in six layers:

1. Product and brand principles
2. Foundations and tokens
3. Layout primitives
4. Reusable components
5. Product patterns
6. Page templates

=== BRAND ATTRIBUTES ===

Intelligent
The interface should reveal useful context and next actions without appearing mysterious.

Calm
System states, alerts, and AI activity should remain understandable without excessive motion or visual urgency.

Precise
Data, status, permissions, and operational actions should use consistent alignment, labels, and state communication.

Premium
Typography, spacing, surfaces, and motion should feel refined but restrained.

Trustworthy
Risk, confidence, permissions, automation status, and human review should remain visible and explainable.

Efficient
Frequent actions should be direct, predictable, and reusable across screens.

=== DESIGN PRINCIPLES ===

Principle 1:
Clarity Before Intelligence Theater

Meaning
AI capability should be demonstrated through useful workflows rather than decorative futuristic effects.

Application
Show status, confidence, review requirements, sources, and outputs clearly.

Anti-Pattern
Excessive glow, abstract AI symbols, and unexplained automation.

Principle 2:
Exceptions Deserve Priority

Meaning
Failures, review requests, usage limits, and permission problems should be visible and actionable.

Application
Use operational queues, alerts, and explicit recovery states.

Anti-Pattern
Hiding exceptions beneath decorative analytics.

Principle 3:
Semantic Tokens Before Raw Styling

Meaning
Components should use purpose-based tokens.

Application
Use color.action.primary instead of raw electric-blue values.

Anti-Pattern
Hard-coded visual values across screens.

Principle 4:
Accessibility Is Part of the Component Contract

Meaning
Every interactive component must define semantics, keyboard behavior, focus, states, and error recovery.

Principle 5:
One System Across Product and Marketing

Meaning
The application and landing page may use different compositions but should preserve the same brand foundations.

=== VISUAL DIRECTION ===

Direction Name
Premium AI Operations

Page Background
Deep graphite

Primary Surface
Dark neutral with restrained indigo influence

Elevated Surface
Deep indigo panel

Primary Action
Electric blue

Secondary Accent
Cyan

Typography
High-contrast modern geometric sans-serif

Borders
Subtle cool-gray and indigo borders

Radii
Medium and consistent

Elevation
Restricted to overlays, sticky surfaces, and high-priority cards

Glass
Limited to selected floating overlays and hero visuals

Charts
High-contrast, restrained, non-decorative

Motion
Short, purposeful, explainable

Avoid

• Neon cyberpunk appearance
• Uncontrolled glow
• Excessive transparency
• Random gradients
• Decorative charts
• Inconsistent cards
• Mixed icon families
• Unreadable microtext

=== TOKEN ARCHITECTURE ===

Primitive Tokens

• Raw colors
• Spacing values
• Font values
• Radius values
• Shadow values
• Motion values
• Breakpoint values

Semantic Tokens

• Background
• Surface
• Text
• Border
• Action
• Focus
• Feedback
• Status
• Overlay
• Disabled

Component Tokens
Use only when a shared component requires a stable exception.

Example Relationship

Primitive
color.blue.600

Semantic
color.action.primary

Component
button.primary.background.default

=== PRIMITIVE COLOR TOKENS ===

Neutral

• neutral.0
• neutral.50
• neutral.100
• neutral.200
• neutral.300
• neutral.400
• neutral.500
• neutral.600
• neutral.700
• neutral.800
• neutral.900
• neutral.950

Indigo

• indigo.100 through indigo.900

Blue

• blue.100 through blue.900

Cyan

• cyan.100 through cyan.900

Feedback

• green scale
• amber scale
• red scale
• informational blue scale

Exact values require contrast validation in both themes.

=== SEMANTIC COLOR TOKENS ===

Background

• color.background.page
• color.background.surface
• color.background.elevated
• color.background.subtle
• color.background.inverse

Text

• color.text.primary
• color.text.secondary
• color.text.muted
• color.text.disabled
• color.text.inverse
• color.text.link

Border

• color.border.default
• color.border.subtle
• color.border.strong
• color.border.focus
• color.border.error

Action

• color.action.primary
• color.action.primary-hover
• color.action.primary-pressed
• color.action.secondary
• color.action.destructive

Feedback

• color.feedback.success
• color.feedback.warning
• color.feedback.error
• color.feedback.info
• color.feedback.neutral

AI Status

• color.ai.running
• color.ai.review-required
• color.ai.failed
• color.ai.paused
• color.ai.complete

AI statuses must remain understandable without color alone.

=== THEME ARCHITECTURE ===

Dark Theme
Primary operational theme

Light Theme
Required for customer preference, print-oriented contexts, and selected marketing use

Theme Rules

• Preserve semantic token names.
• Validate each theme independently.
• Do not mechanically invert every color.
• Preserve hierarchy.
• Preserve visible focus.
• Preserve status meaning.
• Tune shadows independently.
• Validate charts independently.

=== TYPOGRAPHY SYSTEM ===

Display
Marketing and launch surfaces only

Heading 1:
Page title and major landing-page sections

Heading 2:
Primary product sections

Heading 3:
Cards, panels, and grouped content

Body Large
Introductory explanations

Body
Default application text

Body Small
Secondary descriptions

Label
Form fields and controls

Caption
Metadata

Data Value
KPIs and operational metrics

Table Header
Column headings

Code
Workflow payloads, identifiers, and technical values

Typography Rules

• Use readable body sizes.
• Preserve line height.
• Use tabular numeric forms where useful.
• Avoid tiny secondary text.
• Support text expansion.
• Limit font families.
• Verify font licenses.

=== SPACING SYSTEM ===

Base Scale
4-pixel system

Primitive Tokens

• space.0 = 0
• space.1 = 4
• space.2 = 8
• space.3 = 12
• space.4 = 16
• space.5 = 20
• space.6 = 24
• space.8 = 32
• space.10 = 40
• space.12 = 48
• space.16 = 64
• space.20 = 80
• space.24 = 96

Semantic Spacing

• spacing.page.inline
• spacing.page.block
• spacing.section
• spacing.card
• spacing.panel
• spacing.form.field
• spacing.control.inline
• spacing.table.cell
• spacing.modal
• spacing.navigation
• spacing.hero

=== DENSITY MODES ===

Comfortable
Default for most screens

Compact
Tables, operational queues, and high-density administrative workflows

Spacious
Marketing pages, onboarding, and selected executive views

Accessibility Rule
Compact mode must preserve usable targets, readable text, visible focus, and sufficient control separation.

=== RADIUS SYSTEM ===

• radius.none
• radius.small
• radius.control
• radius.card
• radius.panel
• radius.round

Recommended Usage

• Controls: radius.control
• Cards: radius.card
• Large panels: radius.panel
• Pills and circular controls: radius.round

Avoid
Unique radius values for individual pages.

=== ELEVATION SYSTEM ===

Elevation 0:
Flat application surfaces

Elevation 1:
Cards and low-priority panels

Elevation 2:
Sticky surfaces, dropdowns, and popovers

Elevation 3:
Drawers and modals

Elevation 4:
Critical temporary overlays only

Rules

• Elevation must communicate layering.
• Borders may replace shadows.
• Dark-theme shadows require dedicated tuning.
• Avoid making every card appear floating.

=== MOTION SYSTEM ===

Durations

• motion.duration.instant
• motion.duration.fast
• motion.duration.normal
• motion.duration.slow

Easing

• motion.easing.standard
• motion.easing.enter
• motion.easing.exit

Use Cases

• Component state change
• Overlay entrance and exit
• Workflow progress
• Feedback
• Spatial continuity

Reduced Motion
Remove nonessential spatial movement and preserve all information.

=== BREAKPOINT SYSTEM ===

Small
0–639 px

Medium
640–1023 px

Large
1024–1439 px

Extra Large
1440 px and above

Rule
These values are a starting model. Final transitions should be validated against content pressure, shell behavior, tables, navigation, and component minimum widths.

=== LAYOUT PRIMITIVES ===

Container
Controls maximum width and page gutters.

Stack
Controls vertical layout and spacing.

Inline
Controls horizontal groups with wrapping.

Grid
Controls repeated responsive modules.

Split
Controls two-region layouts.

Sidebar
Controls main and secondary content.

ScrollArea
Contains deliberate overflow.

PageShell
Defines sidebar, top bar, content, and overlays.

Section
Defines semantic page regions and section spacing.

=== COMPONENT INVENTORY ===

Actions

• Button
• IconButton
• Link
• SplitButton
• MenuButton

Forms

• FormField
• TextField
• TextArea
• Select
• Combobox
• Checkbox
• RadioGroup
• Switch
• DatePicker
• SearchField
• FileUpload
• ErrorSummary

Navigation

• Sidebar
• TopBar
• Breadcrumbs
• Tabs
• Pagination
• CommandPalette
• WorkspaceSwitcher
• AccountMenu

Data

• KPICard
• ChartCard
• DataTable
• DataGrid
• StatusBadge
• Avatar
• Progress
• Timeline
• ActivityFeed

Feedback

• Alert
• Toast
• Banner
• Skeleton
• Spinner
• EmptyState
• ErrorState
• OfflineState
• PermissionState

Overlays

• Modal
• Drawer
• Popover
• Tooltip
• DropdownMenu
• ConfirmationDialog

Commercial

• PricingCard
• BillingSelector
• UpgradePanel
• PlanLimitBanner

=== BUTTON SYSTEM ===

Variants

• Primary
• Secondary
• Tertiary
• Destructive
• Ghost
• Link
• Icon

Sizes

• Small
• Medium
• Large

States

• Default
• Hover
• Focus-Visible
• Pressed
• Loading
• Disabled

Rules

• Preserve width during loading.
• Use native button semantics.
• Prevent duplicate activation.
• Require accessible labels for icon-only controls.
• Avoid adding visual variants for page-specific styling.

=== FORM SYSTEM ===

FormField Anatomy

• Label
• Required or optional indicator
• Control
• Prefix
• Suffix
• Helper text
• Error text
• Character count

Rules

• Use persistent labels.
• Associate errors programmatically.
• Preserve entered values.
• Provide an error summary for complex forms.
• Use mobile-appropriate input behavior.
• Do not rely on placeholders as labels.

=== NAVIGATION SYSTEM ===

Desktop
Persistent sidebar with top utility bar

Tablet
Collapsed navigation rail or drawer, depending on content pressure

Mobile
Accessible navigation drawer

Required Behavior

• Active state
• Current-page state
• Keyboard access
• Focus management
• Escape behavior
• Focus restoration
• Long-label support
• Internal scrolling
• Safe-area support

=== TABLE SYSTEM ===

Desktop
Full data table or grid

Tablet
Prioritized columns with contained horizontal scrolling where necessary

Mobile
Card transformation, expandable rows, or separate detail view based on user task

Required States

• Loading
• Empty
• Filtered Empty
• Error
• Permission Restricted
• Partial Data
• Offline

Accessibility

• Semantic headers
• Sorting state
• Selection state
• Keyboard access
• Responsive relationships
• Screen-reader validation for complex grids

=== FEEDBACK SYSTEM ===

Toast
Brief noncritical confirmation

Alert
Contextual message inside a workflow

Banner
Persistent page-level notice

Skeleton
Structural loading state

ErrorState
Explains failure and recovery

PermissionState
Explains access requirements

OfflineState
Explains unavailable actions and preserved work

PlanLimitState
Explains the limit, reset condition, available options, and upgrade path without false urgency

=== DASHBOARD ARCHITECTURE ===

Dashboard Types

• Executive Overview
• AI Operations
• Workflow Performance
• Usage
• Administration

AI Operations Dashboard

• Workflow health KPIs
• Performance trend
• Human review queue
• Failed-run queue
• AI confidence distribution
• Usage summary
• Integration health
• Recent activity

Rule
Every module must support a user decision or action.

=== DASHBOARD PROMPT ===

Create a premium AI operations dashboard for NovaPilot, designed for operations managers who need to monitor workflow health, investigate failures, review uncertain outputs, and coordinate human approval.

Use the approved NovaPilot design system with dark graphite page backgrounds, deep indigo surfaces, electric-blue primary actions, restrained cyan accents, high-contrast typography, semantic status colors, medium radii, subtle borders, limited elevation, and controlled motion.

Include a persistent sidebar, top utility bar, four KPI cards, workflow performance chart, human review queue, failed-run queue, AI confidence panel, usage summary, integration health, and recent activity.

Use realistic fictional data, explicit loading and error states, responsive behavior, accessible contrast, visible focus, non-color status labels, and implementation-believable components.

Do not introduce unapproved colors, random radii, unrelated shadows, mixed icon families, duplicated controls, decorative charts, fake logos, private data, illegible text, excessive glassmorphism, or uncontrolled glow.

=== LANDING PAGE ARCHITECTURE ===

Section Sequence

1. Header
2. Hero
3. Trust
4. Problem
5. Product Demonstration
6. Feature System
7. Use Cases
8. Workflow
9. Human Control And Security
10. Verified Testimonials
11. Pricing
12. FAQ
13. Final CTA
14. Footer

System Rule
The landing page may use more generous spacing and stronger brand expression, but it must preserve the same typography, colors, radii, icons, status language, and interaction principles as the application.

=== LANDING PAGE PROMPT ===

Create a premium responsive landing page for NovaPilot, an AI automation platform designed for business teams that need to build, monitor, and control AI-powered workflows.

Use the approved NovaPilot design system with intelligent, calm, precise, premium, trustworthy, and efficient brand characteristics.

Include a product-led hero, verified trust placeholders, problem explanation, workflow demonstration, feature system, use cases, human review and permission controls, pricing, FAQ, final CTA, and footer.

Maintain one coherent visual system across every section. Use realistic fictional content, one dominant CTA hierarchy, accessible contrast, semantic section structure, responsive behavior, and implementation-believable components.

Avoid random styles between sections, fake testimonials, fake logos, unapproved colors, arbitrary cards, inconsistent buttons, excessive gradients, private data, and illegible text.

=== INTERACTION STATE MODEL ===

Every interactive component should define

• Default
• Hover
• Focus-Visible
• Pressed
• Selected
• Disabled
• Loading
• Success
• Warning
• Error
• Empty
• Read-Only
• Permission Restricted
• Offline
• Partial Data
• Plan Limited

For each state, document:

• Trigger
• Visual change
• Content change
• Interaction
• Announcement
• Recovery
• Test requirement

=== ACCESSIBILITY REQUIREMENTS ===

• Use semantic HTML.
• Maintain logical heading hierarchy.
• Provide accessible names.
• Support keyboard interaction.
• Preserve visible focus.
• Maintain logical focus order.
• Use sufficient contrast.
• Avoid color-only status communication.
• Use persistent field labels.
• Associate errors with fields.
• Manage modal and drawer focus.
• Provide responsive reflow.
• Support browser zoom.
• Respect reduced-motion preferences.
• Provide drag-and-drop alternatives.
• Use sufficient touch-target sizes.
• Validate complex widgets with assistive technology.

=== RESPONSIVE REQUIREMENTS ===

Desktop
Persistent shell and full data views.

Tablet
Reduced shell, stacked analysis panels, prioritized columns.

Mobile
Navigation drawer, stacked content, simplified charts, deliberate table transformation, full-width forms, and reduced decorative density.

Responsive Rule
Preserve user tasks, content priority, semantics, keyboard behavior, and status meaning across widths.

=== LOCALIZATION REQUIREMENTS ===

• Allow at least 30% text expansion.
• Avoid fixed-width text regions.
• Support long navigation labels.
• Support long CTA labels.
• Support different date and number formats.
• Prepare mirrored layouts for future RTL.
• Avoid directional icons without RTL adaptation.
• Test German and French expansion.
• Use Unicode-capable licensed fonts.

=== MASTER DESIGN SYSTEM PROMPT ===

Create a complete web UI design system for NovaPilot AI Workspace, a multi-tenant B2B AI automation platform designed for operations managers, marketing teams, customer success teams, agencies, and startup teams.

The system must express these brand attributes: intelligent, calm, precise, premium, trustworthy, and efficient. The visual direction should use dark graphite foundations, deep indigo surfaces, electric-blue primary actions, restrained cyan accents, high-contrast typography, subtle borders, medium radii, limited elevation, and controlled motion.

Define the system in six layers

1. Product and brand principles
2. Foundations and design tokens
3. Layout primitives
4. Reusable components
5. Product patterns
6. Page templates

Create primitive, semantic, and justified component tokens for color, typography, spacing, sizing, borders, radii, elevation, shadows, motion, breakpoints, grids, density, iconography, imagery, and data visualization.

Specify every component with purpose, anatomy, required and optional elements, variants, sizes, states, content rules, keyboard behavior, accessibility, responsive behavior, Figma notes, frontend notes, and tests.

Include the approved component inventory, application shell, workflow builder, human review queue, filter toolbar, bulk actions, activity feed, usage panel, integration status, onboarding checklist, settings, billing selector, permission gate, upgrade flow, dashboards, and landing-page sections.

Use Next.js, React, TypeScript, Tailwind CSS, shadcn/ui, Radix UI, Figma, Storybook, light and dark themes, responsive layouts, future localization, and WCAG 2.2 AA implementation review.

Maintain one coherent design language. Use realistic fictional content. Prefer semantic controls. Favor composition over excessive variants.

Do not copy proprietary design systems, invent licenses, fabricate customer proof, use private data, create inaccessible contrast, rely on color alone, remove keyboard access, hide focus, mix icon families, introduce arbitrary colors, add arbitrary radii, create random shadows, or drift away from the approved visual system.

=== COMPONENT PROMPT ===

Using the approved NovaPilot design system, create a complete specification for the Human Review Queue component.

Define

• Purpose
• Anatomy
• Required elements
• Optional elements
• Variants
• Density modes
• States
• Props
• Content rules
• Interaction behavior
• Keyboard behavior
• Accessibility
• Responsive behavior
• Tokens
• Figma properties
• React implementation notes
• Storybook stories
• Tests
• Anti-patterns
• Acceptance criteria

Do not introduce new visual tokens unless the need is documented and approved. Preserve semantic behavior, non-color status communication, keyboard access, visible focus, and review-risk clarity.

=== SCREEN PROMPT ===

Using the approved NovaPilot design system, create an AI Operations Dashboard for an operations manager focused on monitoring workflow health, investigating failures, and assigning human review.

Use

• Persistent desktop sidebar
• Top utility bar
• Page header
• Four KPI cards
• Workflow performance chart
• Human review queue
• Failed-run queue
• AI confidence panel
• Usage summary
• Integration health
• Recent activity

Include realistic fictional content and explicit loading, empty, error, success, permission, offline, partial-data, and plan-limit states.

Preserve the approved colors, typography, spacing, radii, elevation, iconography, component rules, responsive behavior, and accessibility requirements.

=== AI IMAGE PROMPT ===

Create a premium professional web application UI mockup for NovaPilot, a B2B AI automation SaaS platform.

Use the approved design system: intelligent, calm, precise, premium, trustworthy, and efficient; dark graphite page backgrounds; deep indigo surfaces; electric-blue primary actions; restrained cyan accents; high-contrast typography; medium radii; subtle borders; controlled depth; and minimal glow.

Show an AI operations dashboard with a persistent sidebar, refined top bar, workflow health KPIs, performance chart, human review queue, failed-run queue, AI confidence panel, usage summary, integration health, and recent activity.

Use realistic fictional data, concise labels, reusable components, clear states, precise alignment, and an implementation-believable responsive structure.

Avoid gibberish text, duplicated controls, unapproved colors, random radii, unrelated shadows, malformed tables, impossible charts, distorted icons, broken alignment, excessive glow, fake logos, private data, watermarks, and any styling that conflicts with the approved NovaPilot system. Wide desktop 16:9 composition.

=== NEGATIVE CONSTRAINT LIBRARY ===

• No unapproved colors
• No arbitrary gradients
• No inconsistent radii
• No unrelated shadows
• No mixed icon families
• No random card styles
• No duplicated controls
• No inaccessible contrast
• No color-only status
• No hidden focus
• No illegible microtext
• No gibberish text
• No impossible charts
• No malformed tables
• No fake logos
• No fake testimonials
• No private data
• No watermarks
• No proprietary design-system copying
• No excessive glassmorphism
• No excessive glow
• No broken grids
• No inconsistent perspective

=== FIGMA ARCHITECTURE ===

Pages

• Cover
• Foundations
• Tokens
• Components
• Patterns
• Templates
• Accessibility
• Documentation
• Deprecated

Variable Collections

• Primitive Colors
• Semantic Colors
• Typography
• Spacing
• Sizing
• Radius
• Border
• Elevation
• Motion
• Light Theme
• Dark Theme
• Density

Component Naming
Button / Primary / Medium / Default
Input / Text / Medium / Error
Card / KPI / Default
Modal / Standard / Large

Avoid
Blue Button
Rounded Card
Dark Input

=== FRONTEND ARCHITECTURE ===

Recommended

• React
• Next.js
• TypeScript
• Semantic CSS variables
• Tailwind CSS
• shadcn/ui
• Radix UI
• Storybook
• Testing Library
• Playwright
• Visual regression
• Automated accessibility checks
• Manual accessibility review

Implementation Rules

• Preserve accessible primitive behavior.
• Use semantic token variables.
• Avoid uncontrolled arbitrary values.
• Create composable component APIs.
• Separate loading, error, empty, and permission states.
• Document responsive behavior.
• Test overlays and focus management.
• Align code and Figma naming.

=== STORYBOOK PLAN ===

Every component should include

• Overview
• Default
• Variants
• Sizes
• States
• Light theme
• Dark theme
• Responsive examples
• Long content
• Localization expansion
• Accessibility notes
• Keyboard behavior
• API documentation
• Token references
• Usage examples
• Anti-patterns
• Migration notes

=== TESTING STRATEGY ===

Unit Tests

• Props
• Rendering
• State
• Events
• Content

Interaction Tests

• Keyboard
• Pointer
• Focus
• Overlay dismissal
• Form validation
• Responsive interactions

Accessibility Tests

• Names
• Roles
• Labels
• Relationships
• Focus
• Keyboard
• Contrast review
• Screen-reader review for complex widgets

Visual Regression

• Variants
• States
• Themes
• Breakpoints
• Density
• Localization
• Long content
• Loading
• Error

End-To-End

• Onboarding
• Authentication
• Workflow creation
• Human review
• Settings
• Billing
• Error recovery

=== GOVERNANCE MODEL ===

Contribution Process

1. Define the user problem.
2. Demonstrate repeated need.
3. Identify existing alternatives.
4. Propose anatomy.
5. Define variants and states.
6. Define accessibility.
7. Define responsive behavior.
8. Add tests.
9. Add documentation.
10. Obtain design and engineering approval.

New Component Criteria

• Repeated use
• Shared structure
• Shared behavior
• Shared accessibility requirements
• Clear ownership
• Maintenance justification

=== VERSIONING POLICY ===

Patch
Backward-compatible fixes

Minor
Backward-compatible features and variants

Major
Breaking API, behavior, token, or visual changes

Every release should document

• Added
• Changed
• Fixed
• Deprecated
• Removed
• Migration requirements

=== MIGRATION PLAN ===

Phase 1:
Audit current screens, styles, tokens, and components.

Phase 2:
Map duplicate patterns.

Phase 3:
Approve principles, foundations, and tokens.

Phase 4:
Implement high-frequency controls.

Phase 5:
Implement navigation, forms, feedback, and overlays.

Phase 6:
Implement tables, charts, and product patterns.

Phase 7:
Migrate dashboard and landing-page templates.

Phase 8:
Remove deprecated components.

Phase 9:
Validate responsive behavior, accessibility, and themes.

Phase 10:
Establish governance and release ownership.

=== ACCEPTANCE CRITERIA ===

Theme Consistency

Given either light or dark mode is active,
when any supported component renders,
then it uses approved semantic tokens, preserves hierarchy, maintains visible focus, and communicates state without relying only on color.

Component Consistency

Given a new dashboard screen is generated,
when the screen uses buttons, cards, fields, tables, and alerts,
then every component follows the approved anatomy, variants, states, tokens, spacing, typography, and responsive rules.

Prompt Consistency

Given an AI model generates a new screen from the approved prompt system,
when the output is reviewed,
then it preserves the approved brand attributes, token logic, component language, layout principles, state model, and negative constraints.

Responsive Consistency

Given the viewport changes from desktop to mobile,
when the AI Operations Dashboard reflows,
then navigation becomes accessible, primary tasks remain available, tables use an approved mobile strategy, and content does not create page-level horizontal scrolling.

Accessibility

Given a keyboard user navigates the product,
when focus reaches interactive controls,
then focus remains visible, the order is logical, names are meaningful, overlays manage focus correctly, and status meaning remains understandable without color alone.

=== QA CHECKLIST ===

Brand

• Verify attributes.
• Verify visual direction.
• Verify avoided styles.
• Verify product and marketing consistency.

Tokens

• Verify primitive tokens.
• Verify semantic tokens.
• Verify component-token necessity.
• Verify theme mapping.
• Verify contrast.

Components

• Verify anatomy.
• Verify variants.
• Verify states.
• Verify content rules.
• Verify responsive behavior.
• Verify accessibility.
• Verify tests.

Prompts

• Verify product context.
• Verify user role.
• Verify screen purpose.
• Verify layout.
• Verify components.
• Verify states.
• Verify negative constraints.
• Verify output format.

Figma

• Verify variables.
• Verify component names.
• Verify variants.
• Verify Auto Layout.
• Verify documentation.
• Verify deprecated components.

Frontend

• Verify semantic tokens.
• Verify component APIs.
• Verify responsive rules.
• Verify focus management.
• Verify Storybook.
• Verify tests.

=== KNOWN LIMITATIONS ===

• AI outputs may still drift and require review.
• Final Figma components must be constructed and validated.
• Final source code requires engineering review.
• Accessibility requires implementation testing.
• Browser and framework compatibility require validation.
• Package and asset licensing require independent verification.
• Migration effort depends on the existing system.
• The design system does not guarantee complete adoption, faster delivery, lower cost, or commercial success.

=== FINAL PROFESSIONAL NOTE ===

Validate component behavior, accessibility, licensing, browser support, framework compatibility, performance, and product-specific requirements before production release.

Verify the licenses and usage rights of all fonts, icons, illustrations, UI libraries, code packages, and third-party assets before distribution or commercial use.