A venue is more than a picture.

A venue operator needs more than an attractive diagram. They need to create a layout, arrange sections, reconcile seat counts, assign prices and decide whether the result is ready to publish. A buyer has a different task: understand where an option is, compare the view and know what selecting or holding it actually means.

SeatMapOS connects those responsibilities through the same underlying venue model. My product design and functional prototyping focused on the transitions between them: an editable chart becomes inventory, a buyer’s visual choice becomes a temporary hold, and a confirmed operation must retain the meaning established in the interface.

The venue-creation flow makes identity, location, dimensions and starting material explicit. A creator can begin from a procedural stadium, arena or theater, a section manifest, or a tracing reference. New measured projects carry a defined physical scale, while existing examples preserve their earlier scale instead of silently changing underneath their author.

These inputs have different authority. A spreadsheet can establish section names, rows, seat counts, capacity and ticket types; it does not establish the building’s real geometry. Imported references support alignment and tracing, while the operator remains responsible for arranging the inferred layout. That distinction prevents a convenient import from being presented as a surveyed reconstruction.

A professional editor can accumulate a large toolbar without making the next action clearer. The interaction model instead uses the selection ladder: selected seats, selected rows, focused sections, or the venue itself. The inspector changes its responsibility with that scope, so pricing a row is distinguishable from configuring a section or reviewing the whole venue.

Drawing and transformation tools connect to the same model. Straight rows, arcs, polygon sections and tables create different structures, while point editing, rotation, curve, stretch and numbering act on an understandable target. The documented gesture behavior separates live previews from the operation committed to undo history. The design question is not simply whether a tool exists, but whether someone can tell what it will change.

The designer uses MapLibre as a vector-rendering engine over venue-local GeoJSON. Seats, sections and artwork are the data on the canvas; a geographic basemap does not sit underneath the seat grid. Location belongs in a separate setup surface. This preserves the distinction between where a venue is and how its inventory is organized.

The product then exposes different views of related geometry: an overview for orientation, detailed rows and seats for editing, a 3D buyer map for comparison and a view-from-section scene for inspection. These views should maintain selection identity rather than behave like disconnected illustrations. The original captures show this product relationship; decorative venue appearance remains distinct from the inventory available to book.

A draft is a place to explore. Publication is a commitment that another surface will consume. The implemented publishing route separates begin, seat chunks, binary blob and finish phases, keeping requests bounded and allowing counts to be checked against stored data. It also checks the publisher’s venue ownership rather than treating a chosen slug as authorization.

This boundary matters to product design because a creator needs to know whether they are still editing, whether publication is incomplete and whether a buyer-facing reference is ready. Changes to generated geometry can replace seat identities and affect overrides, so rebuilding and reviewing a venue cannot be disguised as a purely cosmetic operation. The handoff needs both the visible chart and the meaning of its published state.

A buyer can inspect or select an option before the booking engine has committed anything. The pure seat-state core separates an available seat from a temporary hold, a confirmed seat and a released or expired hold. Holds are all-or-nothing, bound to their owner, and checked for conflicts; the Durable Object wrapper serializes changes and adds persistence, expiry alarms and broadcast updates.

Those commitments need equivalent interface states. A conflict should lead back to a useful alternative; an expired hold should stop looking like a promise; confirmation should not be inferred from a visual selection alone. The existing agentic-booking case explores conversation and allocation intent in more detail. This platform case explains the shared state model that makes web, native and agent surfaces refer to the same operation.

The repository includes a browser booking entry point and a server client for quoting holds, confirming or refunding sales and verifying webhooks. The host can own payment and its surrounding checkout experience. Organization-scoped designer sessions separately define which external user can edit, publish or request AI operations within the host’s context.

That separation is a handoff decision: a visible map, a temporary hold, the host’s payment operation and the final booking record are different responsibilities. A useful integration exposes events such as hold, expiry, release, order and error rather than forcing the host to interpret a screenshot of success. Current route and package implementations take precedence over the initial gap survey in the older SDK plan.

The source design system defines a neutral color ramp, Geist and Geist Mono typography, seven type roles and shared control rules. Neutral interface chrome keeps product content and seat-state signals readable; fill, weight, dash and hatch carry meaning alongside the venue’s own appearance. The design reference is useful to Claude, Codex and human developers when it names existing primitives and the state transition a change must preserve.

A complete handoff also states the boundary of the demonstration. The documented hosted and conversational checkout uses simulated payment, and the renderer-only buyer preview cannot reserve or pay. Stadium presentation includes supplied asset derivatives and browser geometry with explicit rendering limits; it is not a general crowd simulation or proof of architectural parity. These distinctions make the case reviewable without turning implemented features into unsupported commercial or performance claims.