---
title: "Why a standard"
description: "The case for one open format for generative UI - what it gives app developers, model providers, tool builders and end users, and what GistUI Protocol v1 brings to it."
---

> Documentation Index
> Fetch the complete documentation index at: https://gistui.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Why a standard

HTML let any server talk to any browser. Markdown let any tool show any note. Generative UI has no equivalent yet: each library has its own output shape, its own error behaviour and its own idea of what a generated screen may do. This page argues that a shared format is worth having, and that GistUI Protocol v1 is a credible candidate.

## What a shared format gives each party

### App developers

- **No lock-in.** An answer is text in a documented format. Change the renderer, the framework or the library version and stored conversations still render.
- **One safety model.** What a generated UI can and cannot do is written down and testable, not discovered by reading a library's source.
- **Portable catalogs.** A component set is a manifest. The same manifest drives the prompt, the parser and the validator, in any language.

### Model providers and trainers

- **One target.** A model that writes the format well works with every conforming renderer. Fine-tuning or evaluating on it is not a bet on one vendor.
- **Checkable output.** "Valid" has a definition: a conforming processor reports no diagnostic. Benchmarks become comparable.
- **Cheap output.** Fewer tokens for the same screen is lower cost and less waiting, for every user of the model.

### Tool and agent builders

- **Composability.** An MCP server, an agent framework and a chat client can pass a program between them without agreeing on a library.
- **Second implementations.** A parser in Python, Rust or Swift can be written from the specification and proven with the conformance suite.

### End users

- **Interfaces instead of walls of text**, in any app, with the same behaviour: forms that validate, tables that sort, links that cannot do something unexpected.
- **Accessibility as a requirement**, not a feature of one component library.

## What a standard for this has to get right

A format for model-written UI has requirements that a format for human-written UI does not.

| Requirement | Why | In v1 |
|---|---|---|
| **Streamable** | People watch it arrive. Waiting for a closing brace is a blank screen | Line-based; each statement is usable when its line ends; chunking never changes the result |
| **Token-efficient** | Output tokens are the cost and the latency | Positional arguments, bare enums and flags, data written once as tables |
| **Error-tolerant, deterministically** | Models slip. Different recoveries mean different screens | Numbered recovery rules; required diagnostics; same tree in every processor |
| **Safe by construction** | The author is a model that may have read hostile content | No code execution; read and write tools separated; URL policy; limits |
| **Catalog-driven** | Every product has its own components | The catalog is data: one manifest for prompt, parser and validator |
| **Interactive without round trips** | A filter should not cost a model call | Client-side state, expressions and queries, all bounded |
| **Editable** | The second request is usually a small change | Patches, appends and deletes addressed by id |
| **Testable** | A standard nobody can verify is a document | 149 conformance cases, each run whole and one character at a time |
| **Transport-neutral** | Stacks differ | A content format with separate bindings |

## Why this format in particular

**It is measured.** On OpenUI's own generative-UI benchmark (46 screens, 4 runs, the same catalog and model for both), it needs a smaller system prompt and fewer output tokens than OpenUI Lang, more answers are valid as written, and after its code-only repair every screen is valid. Rendering a streaming answer takes 2–6× less main-thread work. The numbers are in [Comparison](/docs/protocol/comparison/).

**It defines recovery.** This is the part other formats leave out. A JSON-based format has one recovery: fail. A DSL without recovery rules has as many as it has implementations. v1 lists each slip, the rule that repairs it and the diagnostic to report.

**It treats the program as untrusted.** Tools that read and tools that write are different things in the format itself. A renderer that conforms cannot be made to change data by showing a program.

**It is small.** The reference processor is about 16 KB gzip with no dependencies, and streams a typical screen in a quarter of a millisecond.

**It does not replace what exists.** It is a content format. It rides on HTTP streams, MCP tool results and AG-UI events, and it maps to A2UI. See [Bindings](/docs/protocol/bindings/).

## What is not done yet

A candid list, because a standard is a promise.

- **One implementation.** The reference processor is the only complete one. A standard needs a second.
- **Working Draft.** Some behaviours were chosen where the implementation was silent; Appendix D of the specification lists them.
- **Media type.** `text/vnd.gistui` is not registered with IANA.
- **Runtime and renderer suites.** Conformance cases cover processors. Runtime and renderer claims are made against the text.
- **Governance.** The specification lives in the GistUI repository under the MIT licence. There is no standards body behind it.
- **Model coverage.** Two models have complete benchmark runs.

## How to take part

- Read [the format](/docs/protocol/format/) and file issues where it is unclear: [github.com/GistUI/GistUI/issues](https://github.com/GistUI/GistUI/issues).
- Write a processor in another language and run the suite: [Implement it](/docs/protocol/implementing/).
- Add a model to the benchmark: [Benchmarks](/docs/reference/benchmarks/#reproduce).

Source: https://gistui.com/docs/protocol/why/index.mdx