# MosAIc: a reconfigurable surface where an LLM emits a layout, not just text > Source: > Published: 2026-06-21 09:44:47+00:00 I’ve been exploring an alternative to linear chat: instead of a transcript, the model emits a small JSON overlay that re-configures the UI, and the surface lays it out. The interesting parts are the mechanism and the contract and would love some technical feedback (or thrown spears). The core mechanism is a couple dozen lines. A surface holds views that lay out “tesserae” (typed tiles: markdown / code / table / diagram / note / tasks). An overlay is a surface-shaped patch, merged over a base by view id: effective(base) = base merged with overlay, and the entire render path reads only from effective(), so one overlay reshapes the sidebar and the tiles, no imperative DOM code. The schema is deliberately tiny and it’s meant as a render target any producer (model, agent, IDE) can write to SCHEMA.md It evolves, not regenerates (a bit simplistic right now tbh). Successive tasks are sent the current surface and emit a patch while composeOverlay() folds each into the accumulated overlay with the same id-merge, so “add a PKCE section” extends the surface instead of starting over. (Composing a patch into the accumulator yields the same result as applying it to the rendered surface, so the accumulator stays one overlay.) Architecture is viewer-billed with no back end. Static Space, pure HTML/ES-modules, no build. The model path is BYO LLM: client side HF OAuth with Inference Providers billed to the signed-in viewer and the token never leaves the browser (no server, no owner key). The OAuth app is provisioned just from hf_oauth in the README. Robustness. Every overlay (model or hand-edited) passes a validator that normalizes and degrades a bad emit to a message instead of breaking the render; the model path uses json_object, a balanced-brace extractor, and one corrective retry. The model is also told it has no file access, which curbs it from confidently inventing specifics about content it can’t see (though YMMV). Open question I’d like input on: the wire format. It’s JSON today (precise, trivially validated, but models fumble escaping/brackets and it can’t stream). I wrote up the tradeoff matrix (JSON vs YAML block scalars vs markdown vs XML tags vs tool calls/json_schema) in ROADMAP.md. What have people found most reliable for getting structured UI out of a model? MIT Licensed code and docs are in the Space tree. No signin demo via the examples: [MosAIc - a Hugging Face Space by vonargo](https://huggingface.co/spaces/vonargo/mosAIc)