Skip to content

PRD — UIForge: Specification-Driven UI Composition Platform

Initiative: INIT-UIFORGE-003 Status: Draft Date: 2026-09-10 Home repo: github.com/plexusone/uiforge

Problem

Teams building customizable SaaS products keep reinventing the same UI infrastructure: dashboard builders, admin consoles, agent workspaces, and customer portals each get their own layout engine, component model, configuration format, theming, and permission handling. Commercial platforms (Salesforce Lightning, Splunk Dashboard Studio, Shopify themes) each solved this with proprietary composition engines, but there is no widely adopted, vendor-neutral, specification-driven UI composition platform in open source — nothing that combines a deterministic JSON IR, component contracts, design-system governance, and multiple renderers the way OpenAPI standardized REST API description.

Vision

UIForge is a specification-driven UI composition platform. Its primary artifact is not framework code but UISpec — a deterministic JSON Intermediate Representation (apiVersion ui.plexusone.dev/v1) describing pages, components, layouts, data bindings, and interactions. Go types are the source of truth; JSON Schemas are generated from them; renderers (React today, standard web components via Lit alongside) consume the same IR.

Because the artifact is declarative JSON, UISpec pages can be authored visually, edited as source, generated by AI, validated automatically, version-controlled, reviewed in pull requests, and rendered consistently across runtimes.

Users

User Need
Platform engineers A composition engine to embed in their product instead of building one
Product teams Author pages as specs instead of hand-coding every screen
Admins / advanced customers Configure and compose approved components without writing code
AI agents Generate and modify valid UI specifications rather than framework code

Goals (v0.x)

  1. Stable core IR — PageSpec, ComponentInstance, LayoutSpec, Binding, Interaction, NavigationSpec, ThemeRef, VisibilityRule.
  2. Registry-validated composition — every component referenced by a page resolves to a versioned ComponentSpec manifest (properties schema, data inputs, events, actions, capabilities, layout constraints); pages validate against the registry before rendering.
  3. Experience profiles — dashboard, application, agent, and portal profiles restrict permitted layouts and component namespaces over one shared model.
  4. Multi-renderer — the React renderer and the Lit web-components renderer consume identical PageSpecs and emit an identical data-uiforge-* DOM vocabulary.
  5. Generated, linted schemas — JSON Schemas generated from Go types, camelCase property naming, embedded for runtime validation.

Non-Goals (v0.x)

  • Data-source implementations (connectors, query engines) — hosts supply data via the binding contract.
  • Persistence, multi-tenancy, and auth — host-application concerns.
  • A visual builder application (roadmapped separately).
  • Hosting or serving infrastructure.

Success Criteria

  • A host application can render a PageSpec with either renderer using only this repo's packages.
  • Golden PageSpec fixtures round-trip: validate against generated schemas and the component registry, and render in both renderers.
  • Component namespaces demonstrate three domains out of the box: core.*, analytics.*, assistant.*/agent.*.