Fifty thousand tickets. Twelve gates. Seven hours. One screen.
Concept demonstration — modeled against the operating model of a 50,000-capacity recurring event.
Hero visual placeholder · EventOS
Challenge
Event operations is a Frankenstein.
A ticketing provider that talks to a different access-control vendor. An ops radio stack the dashboard cannot hear. A vendor coordination thread on WhatsApp. A medical incident form on paper. A merch sales count that lives on a spreadsheet someone keeps refreshing.
The night runs anyway — because the humans are excellent. But the cost is invisible: every event commander we have talked to spends the first three hours of show day stitching tools together that should have already been one tool.
We wanted to see what happens when the stitching is gone.
System
We built EventOS.
An operating layer for a single event. It is one screen for the commander on show day and one back-end the rest of the studio sees from anywhere.
The ticket engine is native: seat maps, dynamic pricing, group bundles, refunds, cap controls. It writes directly to the access layer, so a refund at 6:40pm closes the gate ticket at 6:40pm.
Access control is native: QR scan, capacity throttling, anti-flooding, lane reassignment. Twelve gates feed one live density model and one staffing recommendation.
The ops radio integrates: incidents create themselves from a flagged word in the channel, find the right team, and reopen until the commander confirms resolved.
Vendor coordination integrates: the catering window, the AV cue, the medical readiness, the cleaning rotation all live on the same timeline. A change in one ripples to the people who need to know, and only the people who need to know.
The commander screen shows the show. Footfall by gate, revenue by hour, queue dynamics, open incidents, vendor status, weather signal. Three big numbers, one big timeline, one big map. Nothing else.
Outcome
We modeled the system against the operating profile of a real 50,000-capacity recurring event and replayed three of its show days at minute resolution.
On the modeled days, EventOS would have eliminated the first 2 hours 40 minutes of commander stitching time entirely, surfaced the gate-three crush twenty-six minutes earlier than the live system did, and closed eleven of the fourteen post-event vendor reconciliation tickets automatically.
The concept is now in conversation with two production houses about scoping a real deployment as a Discovery Sprint.
By the numbers
Modeled: 2h 40m
commander stitching time eliminated
Modeled: −26m
earlier gate crush detection vs status quo
Modeled: 11/14
vendor reconciliations auto-closed
Target: 50k
capacity supported per event
Target: 12
gates coordinated in one density model
Concept
discovery sprint pending
Concept demonstration. Modeled values were produced by replaying the operating profile of a real 50,000-capacity recurring event at minute resolution. Real-deployment performance will depend on the venue, the ticketing model, and the operating culture of the production team.
Tech stack
Ticket engine
Native to EventOS. Seat maps, group bundles, dynamic pricing, capacity controls. PostgreSQL primary with Drizzle ORM and write-through to the access layer.
Access control
QR validation in under 200ms per scan. Edge units per gate with offline-tolerant queuing for poor connectivity moments.
Density model
Reuses CrowdFlow's forecasting layer. Per-gate occupancy + venue-aware redistribution suggestions.
Incident graph
Radio transcription via on-prem Whisper, flagged-word incident creation, routing to the right team, auto-reopen until commander confirms resolution.
Vendor coordination
A shared timeline with permissioned slices per vendor. Changes propagate only to the people who need to know.
Commander screen
Three numbers, one timeline, one map. Built for ambient awareness, not data exploration. Next.js 16 + Supabase Realtime + Mapbox.
Weather signal
Pulls from Sirius Weather Intelligence when the venue is exposed. Green / amber / red windows for outdoor calls.
Timeline
Concept build: four weeks. Real deployment scopes at eight to twelve weeks per event series, then operate-phase retainer.
Team and credits
Humans
- Concept direction[Founder]
- Engineering lead[Name]
- Operations consultant[Name]
- Venue advisor[Partner]
Agents
- Sirius ConductorDesigned the commander screen interaction model and the incident-graph state machine.
- Sirius BuilderBuilt the ticket engine, the access edge, and the realtime backplane.
- Sirius ComposerDesigned the commander visual language and the vendor timeline UI.
- Sirius ObservatorySourced the operating profile of the modeled event and built the replay corpus.
- Sirius VoiceComposed the showcase narrative.