# Floor Plan to Seating Chart: What AI Should Never Decide

> A vision model can propose intent from a floor plan, but it shouldn't emit final coordinates. The eval-first split between AI and deterministic geometry.

**HTML version:** https://www.paiteq.com/blog/ai-event-seating-chart/
**Published:** 2026-08-11T06:25:57.060Z
**Author:** Navin Sharma, Founder · AI Engineering Lead
**Reading time:** ~14 min


---

> [!NOTE] (rich block: pullQuote)

fragments, including the awkward curved and tiered cases that defeat naive heuristics. That is not the hard part. It should not be trusted to decide whether that row overlaps a
> stage, violates a chart invariant, or is safe to publish.

## The tempting demo

Give a vision-language model a floor-plan image and ask for an event seating chart. The output looks promising: a stage, two sections, a few rows, labels that resemble the source. A product review calls it “mostly right.”
That isn't a production evaluation. In our experience it's the exact moment a project commits to the wrong architecture — the demo is convincing enough that nobody asks what “mostly” costs at the point of sale.
An interactive chart is a contract. Not a picture. Seat labels must be unique. No exceptions. Rows cannot overlap the stage. A table needs a valid occupancy rule. A floor needs a coherent hierarchy. Categories and prices need to map to sellable meaning. A buyer needs geometry that is usable at several zoom levels. An agent can help infer intent from an imperfect reference. It should not invent final coordinates and quietly publish them.
We treat an AI event seating chart as a staged authoring workflow, not a generated image with a publish button.
The architecture we keep coming back to separates **probabilistic interpretation** from **deterministic chart compilation and validation**.

## The split that makes the system reviewable

This split also makes debugging possible. When a chart is wrong, the team can ask whether the model misread the reference, the semantic proposal was ambiguous, the compiler rejected a valid intent, or the validator caught a structural defect.

## The reference-to-chart pipeline

### 1. Ingest the reference with provenance

The input might be a private raster floor plan, a bounded SVG, or an existing venue document. Store where it came from, who authorised it, and which chart revision it belongs to. A reference without provenance becomes impossible to explain when the venue changes the room layout later.
The model should see only the reference and task scope it needs. It should not receive account keys, unrelated workspaces, buyer records, or billing context.

### 2. Ask for semantic observations, not final points

A useful proposal says:
The numbers above are illustrative. They are not coordinates and the confidence value is not a publication score. The point is to preserve uncertainty rather than force a model to sound certain about a blurred line.

### 3. Compile meaning into geometry

The deterministic layer can then create a section, generate rows, apply spacing, assign labels, and attach categories under the chart engine's rules. It can reject an impossible request without asking the model to “try again with better coordinates.”
This is where a reusable venue chart becomes more valuable than an image overlay. The chart can be published once, pinned to events, rendered in a buyer surface, and revised through an explicit workflow.
The [SeatLayer Venue Designer](https://seatlayer.io/venue-designer/) is the relevant product surface for that reusable chart. What matters is where the authoring boundary sits — a polished screenshot of a generated chart proves nothing about extraction accuracy.

### 4. Validate as an executable specification

At minimum, a chart validator should be able to report issues such as:
- duplicate or missing seat labels;
- unknown categories or invalid sellable meaning;
- empty or malformed rows;
- overlapping objects or rows crossing protected shapes;
- table/GA occupancy outside the declared rule;
- objects outside a floor or section boundary;
- accessibility or navigation objects that conflict with the chart's own constraints;
- stale revision or publish conflicts.
The exact validator names and behavior must come from the current public contract. Do not inflate the list for a more impressive article. A shorter list with reproducible failures is better than a catalogue of hypothetical checks.

## Build the evaluation set before writing the conclusion

The smallest useful evaluation set is not a gallery of perfect floor plans. It is a collection of cases that make the boundary fail in observable ways.
For this draft, prepare 8–12 synthetic or permission-cleared fragments:
So we score separate things separately:
1. **Extraction:** did the proposal identify the expected semantic objects?
1. **Compilation:** did the deterministic engine produce the intended chart structure?
1. **Validation:** did invalid geometry receive a clear failure rather than a plausible publish?
1. **Review:** could a human understand uncertainty and correct the exact revision?
Do not collapse those into one “AI accuracy” percentage. A model can recognise 95% of labels and still produce a chart that is unsafe to sell if one overlap is missed.

### What the ten-case fixture actually measured

Our evaluation set is deliberately small. It contains ten synthetic reference intents: straight rows, a curved row, mixed tables and seats, an occluded aisle, low-resolution text, duplicate-looking row labels, a stage overlap, a multi-floor hierarchy, an ambiguous symbol, and a deliberately empty row. No venue or customer plan appears in it.
The semantic proposals are manually authored teaching fixtures. That matters. The exercise measures whether the evaluation architecture keeps interpretation, abstention, compilation, and validation separate; it does **not** measure a named vision model. Calling the result “model accuracy” would be false.
These ratios are reproducible from the retained JSON and scoring script. They are not evidence that a production model will achieve the same result, and they are too small to support any safety, speed, or cost claim. Their value is methodological: a team can swap in a named model, preserve the same target schema, and see exactly which layer regressed.

### Turn the fixture into an engineering evaluation

For a real model comparison, freeze the source set and semantic target before running candidates. Record the model identifier, provider, inference settings, prompt/instruction version, and the hash of every input. Run each candidate without editing its proposal, then score object identity and required abstentions against the same annotations. Feed the proposal into the same compiler and validator versions. Only after scoring should a reviewer correct the chart.
Separate three reports. The **raw proposal report** shows what the model recognized or missed. The **compiled report** shows which intentions the deterministic layer could represent. The **reviewed report** shows the final human-corrected artifact and the work needed to reach it. Publishing only the reviewed chart makes every model appear perfect; publishing only raw extraction error ignores the protection supplied by validation.
Add cases when production reveals a new failure, but never delete a difficult case because a newer model scores worse on it. Version the dataset when venue semantics genuinely change. Keep a small locked regression set out of prompt tuning so that prompt improvements are not evaluated on the same examples used to create them.
The release decision should use category-specific gates, not one aggregate percentage. Missing an ornamental label and inventing an accessibility designation are not equivalent errors. A team might permit a low-risk text miss to enter human review while setting zero tolerance for unconfirmed seat identity, capacity, accessibility, price, or protected-boundary violations. Those thresholds belong to the venue and product risk owner, not to the model vendor. Record those thresholds before comparing candidates so the winning rule cannot be rewritten after the results are visible.

### Make the schema carry uncertainty

The proposal schema should distinguish an observation from an instruction. `observed_text` can be “A12?” while `normalized_label` remains empty; `confidence` can be recorded for triage without becoming an automatic publish threshold. Keep `source_region` or another reference pointer on each object so a reviewer can jump from a warning to the pixels that caused it. When the model cannot resolve a symbol, use `unresolved` and a question rather than a guessed object type.
This prevents a subtle evaluation error: scoring a guessed answer as correct because the final chart happened to look tidy. A tidy chart with the wrong section meaning is still a failed chart. Evaluate the semantic proposal before compilation, then evaluate the compiled artifact against its rules. Store both artifacts so regressions can be located instead of hidden behind a single score.

### Use a fixed review rubric

Use pass/fail plus a short note. This creates a useful engineering dataset without inventing a precision claim that the sample cannot support.

## The failure gallery is the proof

The most valuable examples are not the clean outputs. They are the cases a reviewer would catch:

### Visually plausible, structurally invalid

The rows look aligned in the image, but two generated labels collide after the compiler applies spacing. The validator should reject the revision and show the conflicting objects.

### Semantically uncertain, incorrectly forced

The model calls a rectangle “tables” because that is common in venue plans. The source does not show occupancy marks. The correct behavior is an unresolved question, not a confident table conversion.

### Correct object, wrong scope

An external stage or floor is mistaken for a sellable section. A chart-scoped tool should keep the proposal inside the authorised chart and ask for clarification when the reference extends beyond it.

### Good revision, stale publish

A human corrects the row shape while another editor publishes a newer revision. The system must reject stale writes or require an explicit review of the current revision. “The model finished” is not a concurrency policy.
Annotate each failure with the layer that should own the fix. A recognition error belongs in the prompt, model, or source-image handling. A duplicate label belongs in the compiler or validator. A stale revision belongs in authorization and write semantics. This ownership tag keeps teams from trying to solve every defect with a larger model.

### One case, examined end to end

Case 07 is the one we point at most. It begins with a synthetic stage rectangle and two intended rows. The semantic proposal gets the object types right, so it earns credit at the extraction layer. The compiled second row crosses the protected stage boundary. A screenshot of that chart can still look plausible at article size; the overlap is narrow and the labels remain aligned.
The deterministic result is `protected_shape_overlap`. The revision is rejected before publication. The human decision is not “approve because extraction was correct”; it is “revise the row bounds, compile again, then review the new revision.” The case therefore records one extraction success and one geometry failure. A blended score would erase the most useful fact.
Case 05 demonstrates the opposite boundary. A low-resolution label cannot be resolved. There is no geometry invariant to catch because the proposal correctly leaves the identity unresolved. That is still a successful control behavior: the review packet must ask for a clearer source or an authoritative label list. Deterministic validation cannot prove a fact that never entered the chart.

## Where MCP fits

SeatLayer's public MCP is a chart-scoped Designer authoring surface. A compatible client can ask for capabilities, read an authorised reference, propose semantic edits, invoke deterministic chart tools, validate, and continue through the documented revision/review workflow.
That is different from giving an agent broad access to a ticketing account. The chart scope and authorization boundary should be visible in the architecture:
The [Designer MCP workflow](https://docs.seatlayer.io/agents/designer-mcp/) should be the source for current capabilities, authorization, and revision behavior. Refresh it immediately before publication; an old tool list is not evidence.
SeatLayer does not host the model in this flow. The agent supplies reasoning. The chart engine supplies deterministic geometry and validation. The operator supplies the final approval.
The safe interaction is revision-oriented: read the permitted chart revision, propose one bounded change, run validation, and present the diff for approval. Do not let a conversational retry silently expand scope from one section to an entire venue. If the user asks for a second change, create a new proposal against the current revision and show what changed between revisions. The exact transport, tool names, and approval mechanics must be copied from the current public MCP documentation at publication time; explain the control model rather than freeze an unverified API surface.
For enterprise governance, log the reference hash, model/provider version, instruction-set version, proposal payload, validator version, reviewer, and published revision. That record answers “what did the system know when it made this suggestion?” without placing private venue files or credentials in a model transcript.
The current preview contract makes several controls concrete. A compatible host negotiates capabilities instead of assuming yesterday's tool list. OAuth authorizes one chart-scoped session; the token cannot enumerate unrelated charts, events, members, buyers, billing, or API keys. Large semantic region sets are split into bounded, disjoint changes. Mutations use the newest expected revision timestamp, and the merged canonical state is read back before the next change.
Publication is narrower still. A review packet is bound to the current immutable chart hash. If any change occurs after approval, the approval no longer applies. A session with publication authority may publish only the approved, unchanged revision. That is the difference between “a human clicked approve somewhere in the conversation” and an approval an auditor can attach to an artifact.
Machine validation remains necessary rather than sufficient. A chart can pass structural checks and still contain an authoritative mistake: the wrong seat count, an accessibility designation inferred from a symbol, or a price copied from an old plan. Those facts require venue or commercial confirmation. The agent can surface the question and carry the answer into a bounded revision; it cannot promote pixels into commercial truth.

## Build, buy, or keep it manual

An agent-assisted chart workflow is not automatically the right investment.
Keep the process manual when:
- the venue has a handful of stable layouts;
- reference documents are already structured;
- a designer can finish corrections faster than a team can maintain the pipeline;
- the cost of a wrong chart is high and event volume is low.
We build or integrate the full workflow only when all of the following hold, and we say no to the engagement when they don't, because a pipeline that cannot be evaluated is a liability we would be handing to someone else's operations team:
- the organisation receives many layout variants or poor-quality references;
- a reusable chart becomes an operational asset across events;
- the review team needs a repeatable provenance and validation trail;
- deterministic chart tools already expose the right semantics;
- the organisation can maintain evaluation cases as the venue model evolves.
The output is not “AI generated seating.” It is a reviewed, versioned chart whose uncertain parts were surfaced and whose structural rules were enforced by software.

### Explicit no-go rules

Stop automation and return to manual authoring when any of these conditions holds:
- the source owner cannot confirm that the plan may be processed;
- physical scale is unknown and the requested geometry depends on it;
- dense labels remain unreadable after the required detail inspection;
- accessibility, capacity, price, or sellable identity exists only as a visual guess;
- the importer cannot represent a venue object without arbitrary coordinate invention;
- the current chart revision changed while the proposal was being reviewed;
- the evaluator has no retained failure cases for the object types entering production.
These are control thresholds, not admissions that the model is weak. They prevent the pipeline from creating certainty where the source contains none. A senior review should reward abstention at these boundaries.

## A production review gate

Before publishing any assisted chart, require:
- input provenance and permission;
- exact chart/workspace scope;
- semantic proposal with unresolved questions;
- deterministic compilation result;
- validation report with failures and warnings;
- visual comparison to the reference;
- human reviewer and decision;
- exact revision identifier;
- audit trail for corrections and publication.
That gate is slower than a one-shot demo. It is also what makes the system defensible when a venue manager asks why a row moved, a category changed, or an inaccessible path disappeared.

## The point of the architecture

AI is useful at the fuzzy edge of venue mapping: reading references, surfacing likely meaning, asking questions, and reducing repetitive authoring. Deterministic geometry is useful at the hard edge: compiling legal structures, rejecting overlaps, preserving identity, and making revisions reviewable.
We treat those as different jobs. That separation is the whole design, and it is what lets a reviewer sign off on a chart without having to trust the model that proposed it. The result is less magical than a one-prompt demo and much closer to something an enterprise team can operate.

### Evidence note

Every result we report above is measured from our synthetic fixture; the interpretation proposals are simulated. The Designer MCP claims were checked against its public preview contract on 11 August 2026 — that contract is still moving, so recheck it before you build against these numbers. No fixed tool count, model-success rate, or production metric is asserted here.

---

## About Paiteq

Enterprise AI engineering — production agents, RAG, LLM apps, automation, generative AI. Eval-first, senior-led, fixed-scope engagements.

- **Site index for agents:** https://www.paiteq.com/llms.txt
- **Full content for agents:** https://www.paiteq.com/llms-full.txt
- **Book a call:** https://www.paiteq.com/contact/