Invariant Design Language

IDL — Phase 1 · Design Governance Layer

Invariant Design
Language

A Design Governance Layer for AI-Assisted Software Development.

Invariant encodes structural design constraints as machine-enforceable grammar. It operates below the component layer — governing the rules by which design decisions are declared, validated, and enforced across automated pipelines and AI-generated output.

Structural constraints.
Machine-enforceable.

Automated tooling accelerates interface generation. It does not produce governance. Design systems without enforceable structure degrade to informal convention — undeclared, unenforced, and untranslatable across system and team boundaries.

Invariant is a design governance layer. It encodes the rules a design system must uphold as machine-readable grammar — structural constraints that hold regardless of whether output is authored by a human or generated by an AI system.

AI Tooling
Interface Output
Without Governance
Convention Drift
With IDL Governance
Coherent System

Foundation

01AxiomsFoundational truths. Non-negotiable.
02InvariantsProperties that must hold everywhere.
03ConstraintsDeclared in schema. Enforced at compile time.

Doctrine Before Implementation

IDL begins with axioms — formal constraints that govern what the system is and what it cannot become. Invariants define properties that must hold across all versions, platforms, and contexts.

Constraints are not suggestions. They are declared in schema, evaluated at compile time, and surfaced as hard errors. No implementation is valid unless it derives from the doctrine layer.

01 — Foundation →

Grammar, Not Guidelines

The token system defines three tiers: primitive, semantic, and component. Each tier has derivation rules. Lower tiers may not reference higher tiers. Violations are compile-time errors, not style warnings.

The component system extends this model. Components declare props, slots, variants, and state machines. Composition is explicit. Inheritance is prohibited. Every structure is traceable to a token, and every token resolves to a primitive.

04–05 — System Grammar →

Token Tiers

tier.01Primitivecolor.blue.500 · spacing.4
tier.02Semanticcolor.background.surface
tier.03Componentbutton.background.default
Lower tiers may not reference higher tiers.

Compiler Phases

01ParseSource → AST
ERROR
02TransformResolve · Validate · Analyze
ERRORWARN
03EmitCSS · JSON · TS · Figma
INFO

Enforcement, Not Convention

The IDL compiler specification operates in three phases: parse, transform, and emit. The parse phase converts source to AST. The transform phase resolves references, evaluates constraints, and validates state machines.

Structural violations are not flagged after the fact. They are rejected at build time. The compiler is the enforcement boundary. Documentation describes the system. Enforced grammar governs it. This is the distinction between a style guide and a governance layer.

07 — Compiler Architecture →

Three Layers. Active Governance.

Layer III
Compiler + Runtime
Parse · Transform · Emit · Platform Targets · Validation
Layer II
Grammar
Token Tiers · Component System · State Machines · Composition Rules
Layer I
Doctrine
Axioms · Invariants · Constraints · Visual Grammar · Scope

Each layer depends only on layers beneath it. Layer I (Doctrine) is the active governance phase. Layers II and III are specified and under active development.

Runtime Continuity

A parallel research track — distinct from Phase 1 governance work — examining how design systems maintain structural coherence when interface output is partially or fully generated by automated systems. Covers schema contracts, prompt primitives, and the role of compiler-enforced constraints as a validation boundary at the runtime layer.

Document ID
RC-01
Classification
Architectural Research — Phase 2 Track
Status
Ongoing — Parallel to Phase 1
Read Research →

Runtime Continuity Model

InputDesign System
Also InputAI-Generated Output
BoundaryIDL CompilerValidation · Schema Contract
OutputRuntime ArtifactCoherent · Structurally validated

Development Phases

Phase 1 — Current
Design Governance Layer
AI-aware grammar · Structural constraints beyond UI tokens · Drift reduction in AI-assisted pipelines · Machine-enforceable invariants
Phase 2 — Parallel
Runtime Research
Runtime Continuity · Platform-level invariants · Structural coherence under AI-generated output · Research track, not Phase 1 dependency
Phase 3 — Future
Design → Compiler Infrastructure
Deterministic compilation · Formalized design intent · Full constraint enforcement at build time · Dependent on Phase 1 specification maturity

Phase 1 is the active governance initiative. Phase 2 is parallel research that informs but does not block Phase 1 progress. Phase 3 represents a long-term compiler direction dependent on specification completeness.

About Invariant

Invariant is a design governance initiative developing the specification and enforcement layer for AI-era design systems. It focuses on encoding structural constraints as machine-enforceable grammar — extending governance beyond style tokens and UI guidelines to influence how software systems are assembled under AI-assisted development.

Founded by Jaya Prakash, a product-focused platform designer working at the intersection of design infrastructure, systems architecture, and AI-era software development.