IDL v1.1 — Phase 1 · Design Governance Layer

About Invariant

A design governance initiative encoding structural constraints as machine-enforceable grammar — extending beyond UI tokens and style guides to govern how software systems are assembled under AI-assisted development.

A governance layer, not a documentation layer.

Invariant is a design governance layer for AI-assisted software development. It encodes structural design constraints as machine-enforceable grammar — operating beneath the component layer, at the level where a system's rules are formally declared rather than documented.

The distinction is structural. A documented rule is advisory. An enforced constraint is a property the system must satisfy.

Traditional design systems operate primarily in documentation mode: style guides, token references, component libraries, usage guidelines. That model assumes a human author interprets and applies the rules. It does not hold when authorship includes automated systems.

Invariant formalizes the rule layer itself.

Design systems were not built for automated authorship.

The limitations of documentation-based systems became more visible as AI tooling began generating interface output at scale.

AI systems do not consult conventions. They produce output that may be visually plausible and structurally invalid — tokens used outside intended tiers, compositions that violate declared constraints, state transitions that are architecturally inconsistent. Documentation has no mechanism to detect or reject this. There is no enforcement boundary.

This is not a new failure mode. Large product organizations have encountered structural drift for years. Drift accumulates not because teams are careless, but because the specification lacks structural authority.

Documentation can describe intent. It cannot enforce it.

As output volume increases — through team growth, automated generation, or AI-assisted development — the divergence between declared rules and actual systems widens. Invariant addresses that gap by making the specification machine-readable and enforcement structural.

What governance means here.

Invariant encodes design constraints as formal grammar — with derivation rules, constraint models, and validation logic that can be evaluated at build time.

Constraints declared in this form can be validated regardless of whether input is authored by a human, generated by a model, or produced by an automated pipeline. The enforcement boundary holds either way.

This governance layer extends beyond visual style. It concerns how software systems are assembled: token tier discipline, composition rules, state machine validity, and component contract integrity.

Certain properties must hold everywhere. Those properties are invariants. Making them explicit, encoding them formally, and enforcing them structurally defines the purpose of the governance layer.

Current phase.

Invariant is in Phase 1: the Design Governance Layer.

Active work includes the doctrine, grammar specification, token architecture, component constraint model, and compiler framework. The specification is published in working draft form — structured enough to reason about, open enough to evolve as it is tested against real architectural constraints.

Phase 2 is a parallel research track. Runtime Continuity explores how design systems maintain structural coherence when interfaces are generated dynamically across federated platforms. The first paper in that series (IDL-ARC-001) examines platform-level invariants in multi-product SaaS systems. This research informs long-term constraint modeling but does not define Phase 1 scope.

Phase 3 — deterministic compilation and formalized design intent at build time — represents the long-term compiler direction. It depends on specification maturity and is not a current deliverable.

Jaya Prakash

Jaya Prakash is a product designer working on design infrastructure, governance systems, and AI-assisted software development.

His work focuses on the structural layers beneath interface systems — the specification boundaries and constraint architectures that determine how products maintain coherence at scale. As AI systems increasingly participate in authorship, his focus shifted toward a specific question: what must change in design systems when enforcement can no longer depend on human interpretation.

Invariant emerged from sustained analysis of that question.

The research on design governance and runtime continuity draws from examination of structural patterns across large-scale software platforms. The objective is not stylistic refinement, but formal clarity — identifying the minimum enforceable structures required to reduce drift in complex systems.

Invariant is an independent initiative. It is not affiliated with any organization and is not externally funded. The work is published because the failure modes it addresses are structural properties of software at scale.

Where the work stands.

Phase 1 — the Design Governance Layer — is the active initiative. The IDL specification covers chapters 00–08 in working draft form. The doctrine and grammar layers are the most developed. The compiler architecture is specified at the model level. The AI consumption model is outlined and under active development.

The Runtime Continuity research (Phase 2 track) has produced one published architectural paper. Follow-on work on the Context Bus event schema and SDK contract governance is in progress. This track runs in parallel to Phase 1 and does not block it.

Phase 3 — compiler infrastructure — is a long-term direction dependent on Phase 1 specification maturity. It is not a current deliverable. Publishing the specification direction is deliberate: the constraint model is more useful in circulation than in private development.