How EventBlok started: from live event chaos to an AWS-supported proof of concept

I have been calling shows since 1996. Different countries, different scales, different clients — and the same twenty minutes of avoidable panic, somewhere around the middle of day one.

It is never the thing you rehearsed. The keynote lands. The VT rolls. What goes wrong is smaller and duller than that: a speaker arrives at the wrong room because the pack they were sent was built a fortnight before the programme changed. The signage outside Hall 2 still says a session that moved on Tuesday. Someone on comms is reading from a printout, and the printout is one revision behind the sheet, which is itself one revision behind the decision the client made in an email nobody forwarded.

Every one of those is the same failure wearing a different coat. Not a scheduling failure — a propagation failure. The decision was made correctly and communicated to some of the places it needed to reach.

Sit down and count where the programme actually lives on a mid-sized conference, and you will get to five without trying.

None of these were created by careless people. Each one exists because a real person had a real job to do and the existing artefact did not fit it. The spreadsheet is the planning tool. The website needs marketing copy and images. Speakers need a document that answers their questions and not everyone else’s. The showflow needs cue numbers and department tags no attendee should ever see. The script is the words in the room.

The first version of this idea was not a product. It was an argument I wanted to test: if the event were held as one structured record instead of five documents, how much of the day-one panic simply stops happening?

With support from AWS we built a proof of concept to find out. It did the obvious things — one programme, several generated views — and it did one less obvious thing, which turned out to be the important part. It could read an unstructured brief and propose a structured event: sessions, rooms, speakers, durations, the lot.

That worked far better than I expected. It also failed in a way I did not expect at all.

The model was good at structure and confidently wrong about judgement. It would produce a clean, plausible running order that no experienced producer would ever run.

It scheduled a heavy technical session directly after lunch. It gave a nervous first-time speaker the graveyard slot. It compressed a turnaround to eight minutes because eight minutes is arithmetically sufficient to move four chairs, and it is, and anyone who has actually done it knows you will lose the top of the next session every time.

None of that is a model failure in the technical sense. Those decisions depend on things that were never in the input: the room’s mood, the client’s politics, which speaker needs holding, how far the walk is when it rains.

So we drew a line and built the product on the correct side of it. Event Brain proposes; a person decides. Nothing it suggests enters the event until someone with the room in their head approves it. That is not caution about the technology — it is an accurate description of where the useful information lives.

One event spine, and many live views of it. The programme is built once. The audience portal, the speaker pages, the showflow, the prompter and the signage are all reads of that same record, not copies of it.

Move a session at five to doors and every one of those surfaces is already correct, because there was never a second version to update. That is the entire proposition. Everything else in the product is a consequence of it.

The rest of this journal is mostly the specifics — why one source of truth matters, what a showflow does that a spreadsheet cannot, and how the sync layer actually works.