Records, not just renders

Last reviewed: July 2026. Comparison against A2UI v0.9.x; we will update this page as that specification evolves toward v1.0.

The idea that an AI agent should emit UI as declarative data, rendered natively from a catalog of trusted components, is now mainstream. Google's A2UI standardises exactly that: agents stream declarative JSON "UI intent", clients render it from a pre-approved component catalog, and incremental updates mutate what is already on screen. Production server-driven UI systems (Airbnb's is the best-documented) established the underlying pattern years earlier. We think this consensus is correct – and Fuaran shares all of it.

The difference is in what the data is once it exists.

A rendering-instruction protocol answers: "what should the client draw next?" The JSON is transport – consumed by the renderer, then gone. That is a perfectly good design centre for agent chat surfaces, and A2UI executes it well, with real ecosystem reach.

Fuaran treats the emitted tree as a durable, verifiable artefact. That single decision cascades into properties a rendering stream does not have:

• One canonical serialisation. Ordinal-sorted keys, canonical number layout, omit-when-absent – so the same tree is the same bytes from every conformant host, certified by a shared, executable conformance corpus. As of v0.9.x, the A2UI specification does not define a canonical byte encoding or publish a cross-implementation conformance suite; without canonical bytes, the properties below are unbuildable. (See Canonical bytes.)
• Strict decoding with typed refusals. Undeclared keys are refused, not ignored; every error carries a stable code and path, in a deterministic order every host reproduces. (See Default-deny by shape.)
• History as a first-class object. Edits are typed tree operations in a hash-chained op stream – replayable, forkable, mergeable with a real structural three-way merge, and checkable against corruption or casual alteration. The chain is unkeyed, so that is corruption detection and not tamper evidence; authenticity against a writer who can rewrite the store needs signing, a separate seam that is not shipped. (See The interface as a value.)
• A typed answer channel. When an agent needs a human decision, the question is a live form with a declared answer contract, and the reply is validated typed data – never prose to re-parse. (See Typed questions, typed answers.)

A fair scorecard runs the other way too: A2UI ships with Google's ecosystem gravity, first-class integrations into the agent-protocol landscape, and a deliberately simple flat component list that is easy for any third-party agent to emit. Fuaran's richer typed tree asks more of the emitting model – which is why the reference hosts pair the format with schema lookup and a typed repair loop, so a wrong emission is a correctable error rather than a silent guess.

The one-line version: if you only need to render, a rendering protocol is enough; if you need to trust, audit, replay, merge or move what was rendered, the UI has to be a record – and a record needs canonical bytes, strict decoding and provenance. Fuaran is built for the second case, and the first comes free with it.