Ten artworks and one sentence in, a walkable exhibition out — AI-curated rooms, wall labels, a guided tour with spoken narration, and a one-click export that gives the artist a gallery they actually own.
IBM watsonx.ai · Llama vision + text models · Three.js · Zod validation · BYOK · Static-site export
Openhall, 2026
TypeScript, Three.js, watsonx.ai, and one Cloudflare Worker · Open source · Artist-owned edition
Room 1The Problem
Independent artists and art students make work worth exhibiting, but exhibitions stay gatekept. A physical show means renting a space, and the usual online alternatives treat artwork as content: a square in a feed, a page in a PDF. What disappears is exactly the thing a show is for — walking through rooms someone composed, seeing works in deliberate company, reading a label written with intent.
Virtual-gallery platforms exist, but they mostly hand the artist a 3D editor and a subscription: hours of manual placement, then a gallery that lives on someone else's servers for a monthly fee. The two questions behind Openhall were simple: what if curation took one sentence instead of one editor — and what if the result belonged to the artist, full stop?
Room 2The Show
The two-minute pitch shows the whole arc — upload, one-sentence brief, generation, and the walkable result.
The generated exhibition behaves like a real one. You walk it in first person (WASD and mouse), click any work to step close and inspect it, or press Tour and let the gallery guide you piece by piece — with an opt-in audio guide that speaks each narration aloud. An "About the Artist" wall, generated from the artist's name, statement, and links, greets visitors the way a title wall does in a physical show.
And then the part that defines the product: Export. One click produces a zip that is a complete, self-contained static website — viewer, tour, narration, everything. Drop it on any free static host and the exhibition is live at the artist's own URL, with no Openhall account, dependency, or fee. The tool forgets you; the show is yours.
Room 3Behind the Walls
The generation pipeline is a six-station line. The core idea: language models are good at judgment and terrible at geometry, so every station does only what its worker is reliably good at — AI decides what belongs together and what to say; deterministic code decides where every wall, doorway, and picture hook goes.
Up to ten works, resized in the browser. Nothing leaves the artist's machine except the AI calls they configure.
A vision model notes every piece's style, palette, subject, and mood — the curator walking the studio, taking notes.
A language model reads all the notes plus the artist's one-sentence brief, then decides rooms, groupings, hanging walls, and the visitor's route. It chooses; it never measures.
A deterministic assembler turns the plan into geometry — room dimensions, doorways, exact placements, collision bounds. Pure math, correct every time.
Placard labels and a spoken docent narration for every work, in the voice the artist's brief set. Validated batch by batch.
Three.js renders the walkable gallery; the exporter packs it into a static site that runs anywhere, forever.
Why the gate matters: an AI answer is "probably right", never "guaranteed right". A model can format perfect JSON and still assign eight artworks out of ten, or invent ids that don't exist. Every structured AI response is checked against what was actually asked for — before anything downstream trusts it.
Room 4Curatorial Decisions
Early versions let the model emit gallery geometry freeform. The result was walkable but incoherent — tour paths through walls, backtracking routes. Splitting judgment from geometry fixed it permanently: the model was never asked to do math again.
When validation fails, the pipeline retries once with the errors attached, then stops and tells the artist. I rejected auto-repairing bad AI output — a gallery silently missing three works is worse than an honest error screen that keeps the artist's inputs intact.
API keys live in the artist's browser; the export is a complete site with zero Openhall dependency. I rejected the standard SaaS shape — hosting users' galleries — because ownership was the point. The one exception is a tiny stateless relay the IBM route needs.
An 11B vision model reads one artwork at a time — an easy task, done sixteen times cheaply. Curation, which must track ten ids across rooms, placements, and tour order without dropping one, gets a 70B model. Right-sizing beat using one big model for everything.
Room 5Restoration Notes
Every fix below is visible in the repo's history — the project keeps its debugging honest instead of pretending the pipeline worked on the first try.
Symptom: generation failed at the same JSON position on every retry. Root cause: the model was asked to emit the entire gallery — geometry, labels, everything — and hit its output-length ceiling; retrying couldn't fix truncation. Fix: this failure produced the architecture — the deterministic assembler took geometry away from the model entirely, and output shrank to what a model can reliably say.
Symptom: with ten artworks, curation failed validation on every run — ids dropped, duplicated, or invented. Root cause: exact bookkeeping across a long answer is precisely what small models are worst at, and near-zero temperature meant the retry repeated the same mistake. Fix: swapped the 8B curation model for a 70B one and verified it against the exact failing scenario — first-attempt pass, twice in a row.
Symptom: watsonx calls that worked in scripts died in the browser. Root cause: IBM's auth and ML endpoints send no CORS headers — they assume you have a backend, and Openhall deliberately has none. Fix: a minimal stateless Cloudflare Worker that exchanges the token and relays the calls — the smallest possible backend, built only because the browser wasn't allowed to do it alone.
Room 6Visitor's Book
Openhall was built in collaboration with AI; the design decisions, content, and direction are mine. I did not write this project line by line — and being precise about that split is part of the work I want to show.
The most useful thing this project taught me about AI engineering is that a model isn't "good" or "bad" — it's good at a shape of task. The same 8B model that analysed artworks flawlessly failed curation every single time, because analysing one image is easy and tracking ten ids through an interlocking plan is hard. Once I saw capability as task-shaped, the design followed: shrink each AI task until it fits the model reliably, give everything else to deterministic code, and put a validator at every seam. That principle — not any single feature — is what I'd carry to the next product.
Walk the live demo gallery, watch the pitch, or read the source — the repo includes the full build history, the AI session prompts that directed it, and the debugging notes.