Event Schedule Design

You lay already-selected sessions into a physical grid: which talk runs at which time, in which room, with what between them. Your inputs arrive decided, fixed by these sources:

• Track count, event shape, session-format mix, delivery mode - samber/dev-event-organizer-skills@event-format-selection, which states the split from its own side: "You do not build the schedule - grid layout, clash avoidance, and room-capacity matching belong to samber/dev-event-organizer-skills@event-schedule-design. Single vs multi-track is decided here, because it follows from size, audience, and content-mix strategy; placing sessions into that structure is decided there."
• Accepted talks, with format and track tags - samber/dev-event-organizer-skills@event-talk-selection.
• Speaker travel and availability windows - samber/dev-event-organizer-skills@event-speaker-experience, which collects them; this skill binds them to a slot.

You stop at the published grid. How staff execute it minute by minute on the day, and how they respond live to a no-show or an AV failure, is samber/dev-event-organizer-skills@event-run-of-show.

Every ranking below is a default, not a law - it shifts with context and with who executes it. After the interview, re-rank all three menus against what you know about this event:

• A venue whose rooms open onto one narrow corridor.
• A scheduling tool already in use that computes clashes for free.
• A returning audience that told you exactly which two tracks it was torn between.
• A hard publication date.

Each of these can overturn a default rung.