Intents

Overview

Most design systems begin with tokens that give way to components. Our intention is that HashDS will begin with intents — descriptions of the goal underlying the use of a component (or set of components).

Agents emit intents, which are then translated into components via an intermediate representation we call (UI‑IR) to produce generative user interfaces (GenUI).

Each intent has a canonical form — Verb(Params) — and a declared-intent slug (kebab-case) that gates component capabilities, including access to trust tokens and sensitive operations (e.g. the ability to read or write sensitive personally-identifiable information).

Temporal aspects — when something should happen — are handled by dedicated scheduling and time intents. These let users specify a future time, a recurrence, or a reminder for an action. Temporal intents often compose with others in a series (e.g. schedule a message for later, or confirm a future booking). The UI‑IR can represent "when" explicitly so that agents and validators can enforce constraints (e.g. no scheduling without user-confirmed time, clear display of timezone).

Components declare the intent they serve, and their output schemas additionally specify events as intents, creating a closed, typed loop between what the user sees and what the system does.

Why intents?

A model could describe what a component should do in other ways — free-form natural language, direct component names, or low-level UI specs. We use intents because they give a stable, verifiable layer between agent output and the design system.

• Stable vocabulary: Intents are a fixed set of canonical goals (Verb(Params)). The system can validate that agent output maps to real intents and that components actually implement them. There are no hallucinated "components" or ambiguous phrases; every emitted intent either resolves to a permitted component or is rejected.
• Goal, not implementation: The model describes what the user needs (e.g. "confirm before proceeding", "pick one option") rather than how it should look. The design system chooses the right component(s) and keeps UX consistent while implementation can evolve. The same intent can be fulfilled by different components in different contexts without the agent needing to know the difference.
• Composability and validation: Intents chain in well-defined series. The system can enforce valid sequences (e.g. ConfirmDestructiveAction before Delete) and reject invalid ones. Free-form descriptions don't provide a contract for ordering or for what "counts" as a valid flow.
• Trust and capability gating: Because intents are typed and declared, the system can enforce which components may touch sensitive data or destructive actions. Capabilities like "Reads PII" or "Trust: confirmation dialogue" are attached to intents, so the renderer can allow or deny access. You cannot get that from a vague natural-language description like "a form" or "a button".
• Consistency and linting: Natural language is underspecified: "let the user pick one" could be a dropdown, radio group, or list. Intents like SelectOne(options) resolve to the right component and keep agent output deterministic. That makes UI‑IR lintable, diff-friendly, and reproducible for the same user need.

Together, intents give agents a bounded, typed language for describing component behavior — one that the system can validate, gate, and translate into components without relying on the model to name specific components or to stay within safe patterns on its own.

Read more

• Intent series — chaining intents for larger objectives
• Intent library — draft catalog of proposed intents by category
• UI‑IR — draft intermediate representation that turns intents into rendered interfaces