Introduction
PRIZM is a DSTA design system. One coherent foundation, several distinct product surfaces. This page covers where the name comes from, what changed in PRIZM 4.0, and what we're building next.
Why “PRIZM”
When light enters a prism it doesn’t stop being light. It splits — fanning into red, orange, green, blue — and each colour continues on a different path. The source is one. The outputs are many.
PRIZM works the same way. One design system. One set of primitives. One coherent visual language. But the surfaces it shapes — a tactical operator station, a customer-facing portal, an internal admin tool — each find their own path, with their own density, their own tone, their own audience. Same DNA, different colours.
The “Z” isn’t a typo. It’s the system’s reminder to itself that the goal isn’t to copy what other design systems already do — it’s to anticipate where they’re going.
PRIZM 4.0
PRIZM 4.0 is rebuilt from the ground up. It is not an incremental update to PRIZM 1, 2, or 3 — it is a reimagination of what a DSTA design system can be.
The earlier versions served us well. They standardised UI across DSTA products through years of steady, additive iteration. But the surrounding landscape has moved on: component primitives have matured (we now build on Base UI’s accessible foundations rather than maintaining our own), CSS has matured (Tailwind v4’s token system replaces hand-rolled CSS), and — most consequentially — the way teams build software is changing. AI is part of how interfaces get designed and shipped now. A design system built only for human consumption is leaving capability on the table.
Built for both developers and AI
Components are documented for developers, and the same documentation is structured so an AI assistant can read it, understand it, and ship correct UI on a team’s behalf. Every component ships with a TypeScript surface, a usage example, a per-component LLM context file, and props encoded in a machine-readable spec. See using PRIZM with AI for how teams adopt this in practice.
Every component carefully crafted
The 44 stable primitives in the baseline are not auto-generated wrappers — each one has been considered individually. Variants are chosen, not enumerated. Keyboard paths are explicit. Focus management is deliberate. The four-variant token system means a single component renders correctly in C3-light, C3-dark, Enterprise-light, and Enterprise-dark with no branching at the call site. The result is a small set of well-shaped parts that compose into much larger surfaces without losing coherence.
A custom Liquid Glass surface treatment
On the visual side, we’ve layered a custom Liquid Glass treatment over Base UI’s primitives — a translucent surface system designed for C3 operator displays, where panels need to sit over a map or feed without blocking spatial context. Two tiers, both light and dark, all baked into the system.
What’s next
PRIZM 4.0 is in active preview. The 44-component stable baseline covers a large surface area, but it isn’t complete — six more components are already on the roadmap (Accordion, Date Picker, Tree, Toggle Group, Number Input, Scroll Area), with further additions to follow as templates pull them in.
We will also expand the template library, building out the six planned C3 app templates and adding the Enterprise template set.
Beyond the current two product families, we’re exploring a third — Info systems — for products that sit between C3 and Enterprise: dashboards, briefing surfaces, and analytical tools where information density matters but the audience isn’t purely operator-trained.