Introduction

IDL — the Invariant Design Language — is a formal specification language for design systems. It defines the primitives, grammar, and enforcement mechanisms used to propagate design intent across surfaces, platforms, and automated pipelines without loss of fidelity.

A conventional design system communicates intent through documentation, convention, and shared tooling. These mechanisms depend on human interpretation at every step. When a designer commits a token value and an engineer implements it on a different platform, fidelity is preserved only by agreement, not by enforcement. IDL replaces that agreement with a compiler.

What Problem IDL Solves

Design systems at scale encounter a consistent failure mode: the further a design decision travels from its origin — through handoff, implementation, platform translation, and versioning — the more it diverges from intent. IDL treats this as a pipeline problem. Design intent is encoded as structured data, validated at authoring time, transformed deterministically, and emitted as platform-appropriate artifacts. The compiler is the integrity layer across the entire chain.

Scope of This Specification

• The IDL grammar and syntax rules for expressing design intent as source files.
• The token system — Primitive, Semantic, and Component tiers — and its derivation rules.
• The component model: props, slots, states, variants, and composition constraints.
• The motion subsystem: named duration and easing tokens, choreography models.
• The three-phase compiler pipeline: Parse, Transform, and Emit.
• The plugin interface for extending each compiler phase.
• AI consumption contracts: serialisation formats, prompt primitives, and validation gates.
• Platform integration contracts for web, native, design tools, and CI/CD.
• Governance: RFC process, versioning policy, deprecation protocol, and changelog.

What IDL Does Not Govern

IDL does not govern pixel-level rendering, accessibility implementation details, platform interaction patterns, or the visual aesthetics of any specific design system instance. These concerns are delegated to platform integration layers or to the consuming design system's own governance process. Clarity about scope is itself a systems practice.