Mission Control Design System¶

Target architecture — not the current operating contract

This page preserves intended product experience. It is not a guide to every component available in the current console; see the current release.

Mission Control uses an operational, evidence-first visual system based on the existing Enkode identity. The interface should feel calm, exact, and trustworthy under dense information: neutral surfaces, clear structure, restrained green accents, explicit status, and evidence close to every consequential action.

Visual principles¶

Control before decoration. Identity, environment, lifecycle, version, owner, policy, health, and consequences are visible before state-changing actions.
Evidence in context. Decisions, approvals, Traces, citations, versions, and Outcomes appear alongside the resource or operation they explain.
Dense, not cramped. Tables and timelines carry operational depth while spacing, hierarchy, alignment, and progressive disclosure preserve scanability.
One semantic meaning per color. A state color never represents a different concept elsewhere, and color is always paired with text, iconography, shape, or position.
Predictable composition. Shared resource anatomy, filters, tables, drawers, cards, timelines, and command patterns behave consistently across modules.
Customer expression without component forks. Theme tokens can carry customer branding while behavior, accessibility, state, and evidence semantics remain shared.

Color tokens¶

Token	Value	Role
`surface.canvas`	`#f7f7f4`	Application background and quiet spatial separation
`surface.panel`	`#ffffff`	Navigation, cards, tables, drawers, dialogs, and focused work surfaces
`text.primary`	`#141715`	Primary copy, headings, identifiers, and high-emphasis labels
`text.muted`	`#656b67`	Secondary metadata, helper text, timestamps, and inactive context
`border.default`	`#d7dcd8`	Dividers, input boundaries, table rules, and neutral component outlines
`accent.primary`	`#00c892`	Enkode brand accent, primary focus detail, active selection, and controlled emphasis
`accent.strong`	`#007f5e`	Accessible accent text, primary action, selected control, and active navigation
`accent.deep`	`#063b31`	High-contrast brand fields, key headers, and dark accent surfaces
`state.info`	`#2d6cdf`	Informational state and neutral operational notice
`state.success`	`#14805c`	Completed, healthy, allowed, approved, and verified states
`state.warning`	`#9b6600`	Degraded, stale, expiring, waiting, attention, and approval-pending states
`state.danger`	`#bd4d4d`	Failed, denied, rejected, unavailable, destructive, and critical incident states

Semantic aliases distinguish labels even when several states share a base token. For example, allowed and approved can both use state.success, but each displays its own text and icon. denied and failed can both use state.danger, but they are never interchangeable in copy, filtering, or evidence.

state.success, state.warning, and state.danger are darkened from their original publication so that each clears WCAG 2.2 AA as text on surface.canvas. The originals — #168a63, #b97900, and #c34f4f — measured 4.03:1, 3.37:1, and 4.30:1 against a 4.5:1 requirement, and all three are used predominantly as text. See decision record 0009.

On tinted backgrounds, implementations derive accessible foreground and surface variants from the semantic token while preserving the token's meaning. Customer themes may change brand accents but cannot remap success, warning, danger, or information semantics.

Typography and identifiers¶

The interface uses a humanist sans-serif family for navigation, headings, controls, tables, explanations, and long-form copy. The initial stack should prefer a locally delivered or system humanist sans serif with robust weights, numerals, and language coverage; no remote font is a runtime dependency.

Monospace typography is reserved for identifiers and machine-shaped evidence: resource IDs, versions, Run and Trace IDs, hashes, idempotency keys, policy paths, schemas, timestamps where alignment matters, and code or manifest fragments. Monospace does not replace readable labels or human explanations.

Style	Use
Display	Product or workspace entry, rare and concise
Page title	Resource or destination name
Section title	Major page region and grouped operational view
Body	Explanations, descriptions, and decision rationale
Label	Field, column, tab, filter, badge, and compact metadata
Identifier	Stable IDs, versions, Trace fields, evidence values, and schema fragments

Use tabular numerals for cost, token, duration, volume, threshold, and capacity comparisons. Text remains selectable, wraps without clipping, and respects browser zoom.

Layout and density¶

The default desktop density is compact but not cramped:

A persistent 240–272 px navigation region can collapse to an icon rail on compact desktop.
Main content uses a readable maximum width for prose and a fluid width for operational tables, Trace trees, designers, and comparisons.
An 8 px base spacing rhythm supports 4 px compact adjustments and 12, 16, 24, 32, and 48 px composition steps.
Standard controls target a 36–40 px visual height on desktop while maintaining at least a 44 px interactive target where touch use is expected.
Tables use aligned columns, sticky headers where useful, visible row focus, and progressive row details rather than shrinking type to fit.
Drawers preserve investigation context; dialogs are reserved for short blocking choices or confirmation, not complex editing.

Hierarchy comes from grouping, spacing, weight, and alignment before color or shadow. Panels use borders and surface contrast; heavy elevation is reserved for overlays.

Core components¶

Component	Required behavior
Application shell	Environment-aware header, grouped navigation, global search or command entry, attention center, account and role context, and responsive workspace
Navigation group	Visible group label, destination label and icon, selected state, badge semantics, keyboard traversal, and hidden or disabled behavior
Resource header	Name, type, stable ID, environment, lifecycle, immutable version, owners, risk, health, module, breadcrumbs, and permissioned actions
Status badge	Text label, semantic icon and shape, accessible name, optional reason, and one state-color role; never color alone
Owner chip	Person or team identity, ownership role, contact path, and overflow behavior without implying access
Metric	Label, value, unit, period, comparison, freshness, source, and status without decorative ambiguity
Data table	Semantic headers, sorting, filters, column priority, selection, keyboard focus, pagination or virtualization, row details, empty and error states
Filter bar	Search, structured filters, saved views, active-filter summary, reset, share scope, and URL or session persistence
Timeline	Causal or chronological events with actor, time, type, state, resource version, links, corrections, and late-event handling
Trace tree	Parent-child spans, duration, status, runtime boundary, model or Connector calls, waits, retries, costs, evidence gaps, and keyboard expansion
Policy decision card	Outcome, reason, policy and version, evaluated input references, matching rules, obligations, approval route, time, and linked execution
Approval card	Request scope, risk and value, requester, resource version, policy reason, route, separation of duties, expiry, rationale, evidence, and allowed actions
Evidence field	Label, typed value or governed reference, provenance, capture and redaction state, retention class, copy behavior, and access explanation
Empty state	Exact scope, why no records appear, whether filters or permissions contribute, and one valid next action when available
Error state	Plain-language failure, typed code or reference, affected scope, preserved state, retry or recovery action, and support or incident link
Command dialog	Searchable permission-aware navigation and actions, environment context, keyboard operation, previewed consequence, and no hidden destructive commands

Components consume canonical resource, policy, approval, Trace, and Evidence contracts. Module-specific views compose these primitives instead of inventing alternate lifecycle, status, owner, or evidence patterns.

State model¶

Every asynchronous or data-backed component defines these states:

State	Required presentation
Loading	Stable skeleton or progress label that preserves layout and communicates the scope being loaded
Empty	Scope, reason, permission or filter influence, and a valid next action without implying an error
Partial	Available data plus a named missing source, affected fields, timestamp, and impact
Stale	Last successful refresh, freshness expectation, operational impact, and refresh or investigation action
Denied	Explicit access or policy outcome, safe reason, relevant resource and operation, and request or review path when policy allows
Approval pending	Policy reason, route, current state, deadline, requester, scope, and non-executed status
Failed	Typed failure, affected step or dependency, preserved durable state, retry eligibility, and exception or incident link
Completed	Completion time, exact version and actor, result or Outcome reference, evidence state, and next valid action

Additional domain states such as degraded, cancelled, expired, changed, suspended, compensated, evidence pending, and recovering follow the same rule: text and icon communicate meaning, the underlying reason is available, and the action set reflects current authority.

Optimistic presentation never implies that an Action executed before the gateway confirms its result and recoverable evidence intent. A client reconnection reads authoritative durable state rather than replaying a mutating request.

Interaction and motion¶

Focus moves in document order and returns to the invoking control when a drawer, dialog, or command surface closes.
State-changing actions name their target, environment, version, effect, and reversal or compensation behavior before confirmation.
Destructive or production actions are visually separated from routine navigation and require policy-appropriate confirmation, rationale, or approval.
Keyboard shortcuts are discoverable, permission-aware, and never the only path.
Motion explains spatial change, progress, expansion, or causal movement; it does not decorate routine status changes.
Reduced-motion preference removes nonessential movement and replaces animated progress with clear static or low-motion feedback.

Accessibility and responsive reflow¶

The target is WCAG 2.2 AA across the application shell, authoring modules, operational views, published AI Applications, and Embed SDK patterns.

Text, icons, controls, focus indicators, and state combinations meet AA contrast against their actual backgrounds.
Every interactive element has a visible focus state, semantic role, accessible name, keyboard path, and sufficiently large target.
Headings, landmarks, labels, table relationships, lists, dialogs, errors, live status, and progress use native semantics before ARIA supplementation.
Status, risk, policy outcome, approval state, health, and severity never rely on color alone.
Screen-reader announcements distinguish loading, updated, denied, approval-pending, failed, and completed state without exposing noisy Trace streams by default.
At 200% zoom and narrow widths, content reflows without loss of controls, policy reasons, version context, evidence fields, or horizontal page scrolling.
Tables prioritize identity and state columns, then move secondary fields into a labeled row-detail view.
Trace trees and timelines retain parentage, event labels, and accessible expansion in compact layouts.
Designers that cannot preserve safe editing on a small screen provide an explicit supported read-only or focused-task experience rather than a broken editor.
User preferences for reduced motion, increased contrast, text size, and platform input methods are respected.

Accessibility is part of component acceptance and journey verification, not a later visual review.

Implemented console tokens¶

The console implements this system directly. Its semantic tokens are defined once in platform/apps/console/src/app/globals.css and exposed as Tailwind utilities; no component holds a colour of its own. Raw palette utilities are rejected by an ESLint rule and by a source scan in token-discipline.test.ts, so a component cannot reintroduce one.

Token	Role
`accent`	Brand fill and tint only — never text, a focus ring, or a border that carries state
`accent-strong`	Accent text, links, state-carrying borders, focus rings
`accent-deep`	The label on an accent fill
`muted`	Eyebrows, helper text, timestamps
`panel` / `line`	Card surfaces and borders
`success`	Completed, healthy, allowed, approved
`warning`	Pending, degraded, expiring, attention
`danger`	Failed, denied, revoked, destructive
`info`	Informational and running states

accent.primary is 2.17:1 against a white panel. It therefore never carries text, a focus ring, or a border that conveys state; accent.strong does that work at 5.00:1, and a label on an accent fill uses accent.deep at 5.77:1. The primary action is an accent fill with an accent.deep label, and its hover darkens the fill and lightens the label together, because accent.deep on accent.strong falls to 2.50:1.

contrast.test.ts asserts WCAG 2.2 AA for every token pair the console renders, so a later palette change cannot quietly fall below it. Adding a colour relationship means adding a row to that test.

A customer-brandable theme is a second set of values behind the same token names; the non-inline @theme block already emits them as custom properties on :root.

Current governance mapping¶

The current source release uses Organizations, Teams, real user/service-account virtual keys and separate human management roles. Agent is managed application content; deployments own secretless execution access and publisher funding. Observe uses Requests, Traces, Sessions and Usage with separate metadata/content/export permissions. Historical identity terms in this target proposal are not the operating contract. See Current release.