Production & Hosting
What Every Vendor Needs to Know by 30 Days Out
By thirty days out, every vendor should be working from the same event, not six nearby versions of it.

By thirty days out, every vendor should be working from the same event, not six nearby versions of it.
The date isn’t universally final at that point. It’s a coordination checkpoint: the moment to make sure the high-impact facts are aligned and the remaining uncertainty is visible enough to actually manage.
Publish one shared baseline
Event date, venue, current guest-count range, approved floor plan and timeline versions, access and loading windows, the weather version and who decides it, by when, primary contacts. Every vendor confirms they received it. A distribution list is not a read receipt, no matter how much I would like it to be.
Lock the places where teams overlap
Power needs a name for who provides it, who connects it, who tests it and who stays responsible for it. Loading needs to know what arrives when, and where it waits. Food and bar need their equipment, water and refrigeration confirmed rather than assumed. Sound needs an owner for the microphones and the cutoff. And somebody has to check that the whole path from access to departure is actually complete.
Label the open decisions honestly
Final, provisional, waiting on the client, blocked, conflicting: call it whatever it actually is. “Almost done” hides the only two things worth knowing, which are who is finishing it and what proves it’s finished.
Judge every late change by its real consequence
Which vendors it touches, what it costs, what it does to timing and safety. Then the team can decide honestly whether the benefit is worth reopening the baseline.
Put the final proof points on the calendar
Mockups, tastings, technical tests, cue rehearsals and quantity locks all go on the calendar, each with a name and a clear idea of what counts as done.
Send one real thirty-day update
Current files, open decisions and their owners, changed assumptions, the next irreversible deadlines. Each vendor also needs their own piece of it written as instructions, not as a file dump. Ask every vendor to flag conflicts within a set window, not whenever it occurs to them.
Nobody needs ceremonial finality at thirty days. What you want is the instability showing up while it can still be fixed, instead of in the final week when everyone discovers they were quietly building different events the whole time.
Atmosphere OS · Arc Studio
Every event has a turn. Most plans do not know where theirs is.
Arc Studio places the peak, then arranges load-in, service and the close around it and hands you the run sheet. It is a planning document rather than a venue-compliance one, and it draws that line for you.
The rulebook is public. Every formula it runs on is written down where you can disagree with it.
Field notes and corrections
When a number here turns out to be wrong, you hear about it.
Three things arrive and nothing else. The new field note — bar rates, cover widths, service clearances, the arithmetic worked through on one real evening. A line when a World opens, because a night only goes up once it can actually be thrown. And a correction whenever a rule in the published rulebook changes, or a number the tools rely on turns out to have been wrong. There is no weekly slot, because there is nothing weekly to put in it.
One email per field note or opening, plus corrections when a published figure moves. Unsubscribe from any of them.
Continue through the system
Pretty is still not a plan.
A party gets planned in roughly this order. Pick the chapter where your next problem lives.
What you have to decide next
One decision constrains the next. This is the order they actually happen in.
More in this chapter
See the complete five-chapter Event Design Intelligence map →