The early comparisons gave us a visual direction. Typography, icons, and a button helped us see what Lattice by Tegis could feel like. A design system, though, has to make those decisions repeatable when another screen or application is built.
In part one, I described the first choices. In part two, I showed how we tested them in representative interfaces. This article covers what we have documented and implemented now, including the decisions that are still open.
Record the rule and its status
The foundation work lives in the repository as a decision register, token files, and a browsable reference site. We use Paper boards for exploration and alignment. The repository records implementation values and the reasoning that engineers need when using them. Each foundation separates confirmed decisions from proposals and open questions. This prevents an attractive specimen from quietly becoming a product-wide rule.
Typography and icons are among the confirmed foundations. IBM Plex Sans handles headings, body copy, labels, and controls; Geist handles numeric content. Fluent UI System Icons Regular is the icon baseline. The standard button’s 5px radius, 14/20 type, 1px border, 16px icon, and spacing rules are also confirmed.
The broader system covers color, spacing and alignment, geometry, layout, motion, and validation screens. For example, the spacing guidance establishes 8px between a visible form label and its control and 24px between complete fields or groups. Text inputs use a 36px height and 7px inset. Marketing layout has audited container widths and an 80px section rhythm. These values provide a shared starting point, with optical adjustments documented where equal measurements do not look equal.
Make tokens describe purpose
Color is a good example of why the documentation needs more than swatches. Purple came from product design; I did not select the brand color. The system work translates that direction into roles such as action-primary, text-default, bg-surface, and border-focus so components can use a purpose rather than a raw hex value.
The proposed palette includes neutral and Tegis purple ramps, light and dark mappings, and status roles. The repository records contrast checks for 17 foreground and background pairs. Those tested pairs pass their applicable thresholds, but the palette mapping still needs approval. Selection, overlays, skeletons, data visualization, and some action roles remain open. Calling that out is part of making the system useful: engineers should know which decisions are stable and which need review.
Geometry follows a similar pattern. The control radius is 5px. Smaller surface and dialog radii are documented as proposed roles. Borders provide the usual separation; shadows are reserved for actual elevation changes. This keeps a dense product screen from turning every grouping into a floating card.
Document components as behavior, not just appearance
We started the component reference with a small set of reusable primitives: Button, Input/control, Icon Button, Surface, and Status. Dialog and Select are supporting examples of how the foundations compose. The live button uses Base UI behavior with shared tokens for variants and sizing; the documentation also records hover, pressed, focus, disabled, and loading states.
The component rules include details that a screenshot cannot show. An icon-only button needs an accessible name and, for unfamiliar actions, a visible tooltip. A form label stays visible instead of being replaced by placeholder text. An invalid field gets focused and receives its own corrective guidance; a toast is for a completed action or an app-wide result. Status uses text alongside color. These rules help the interface remain understandable when it is used with a keyboard, assistive technology, or a different theme.
The platform defaults are recorded too: Next.js for new web applications and official sites, Tailwind CSS with shared semantic tokens, owned React components using shadcn/ui and Base UI, Fluent icons, and Motion for designed movement. Native scrolling remains the product default. The point of listing these choices is to give teams a consistent path while leaving room for a justified application-specific exception.
Where the system stands
This is a foundation draft with several confirmed parts, not a claim that every Tegis screen has already been migrated. The repository has a decision register, token source, component examples, searchable documentation, and dashboard and settings specimens for validation. There is no shared token package or registry yet. The next important test is to apply the foundations to a real Lattice workflow, record exceptions, and settle the remaining palette and layout questions before declaring a stable internal baseline.
That progression—from paper sketches to controlled comparisons, then to tokens, components, and documentation—has made the system easier to explain and easier to challenge. Every choice now has a place where its purpose, value, and current status can be checked before it spreads into another application.