A live 86 hits mid-service. The signed private-event BEO can't move — who tells the table?

Say the private dining room already has its BEO. It was finalized three days ago, signed by the host, and handed to the floor at pre-shift. Forty-five minutes into service, the kitchen runs out of the halibut the BEO names by course and by table. The BEO does not change. Nobody reprints it, and nobody should expect it to say anything different than it said this morning.

That is not a gap in the software. It is the design. A finalized document is a record of what was agreed and handed out — it stays exactly as signed so the room and the kitchen keep working from the page they studied ahead of time. The real question is not why the BEO holds still. It is what carries the 86 to the table instead, since the signed page will not.

Does the pre-shift note update when an item gets 86'd mid-shift?

No. The pre-shift note is drafted from the 86 list and the finalized BEO as they stand before service starts. It is not redrafted mid-shift when a new item runs out later in the night. A note built before doors reflects the kitchen's reality at that hour — an 86 that happens three courses in is simply after the note existed. Treating the note as a live feed asks it to do a job it is not built for. It is a briefing, read once, before the floor starts.

So what actually carries a mid-shift 86 to the private event's table?

Someone has to say it, in the room, to the people serving that table. Industry guidance on restaurant communication treats an item running out mid-shift as an urgent, real-time problem, not a written one — the moment calls for someone saying the words out loud, the same way a kitchen calls out that it is 86'd on an item, rather than a document being quietly amended somewhere no one is checking. For a private event this means whoever is captaining the room hears it from the kitchen the moment the item is gone, and relays it directly to every server working that function before the next course goes out. There is no written record this lives in during the moment it matters. It is a sentence, said once, to the right people, fast.

Why doesn't the BEO just get corrected in place?

Because a finalized BEO is immutable by design. Finalizing a document marks it final and points it at a frozen record of exactly what was on the page at that moment. A document that already carries a signature will not be quietly re-finalized under that signature — a genuine change means publishing a new version, which is visible, not editing the one everyone already has. An 86 during service is not that kind of change. It is not a contract term. It is a kitchen running out of something, and it gets handled the way kitchens have always handled that: a word to the captain, a word to the servers.

What if the 86'd item is the thing named on the BEO's run of show?

Same answer, with more urgency. The BEO's run of show still says halibut, and it will keep saying halibut, because that is what was agreed and signed. But the captain, told directly by the kitchen, has to relay the substitution to every server at that table before the course fires — not after a guest asks why their plate looks different than what the host described weeks ago. The signed page and the actual plate are allowed to diverge for one night. What is not allowed is the server hearing it from the guest instead of from the kitchen.

Does writing the 86 down anywhere help at all?

It helps the next shift, not tonight's floor. Standard pre-shift content is built around which items are 86'd or running low, delivered verbally before service starts, and a shift log is best kept updated in real time as things happen rather than left until the end of the night. What that written record does not do is reach a server's ear during tonight's service on its own. A list sitting by the pass only helps the people who happen to walk past and read it during a rush. Writing something down and a person hearing it in time are two different jobs, and only one of them is guaranteed before the next table's course fires. There is a real liability angle here too: a restaurant can be held responsible if a dish's makeup changes and nobody tells the servers, which is exactly the failure a verbal relay exists to prevent.

What is the sequence, start to finish?

Plainly, in order:

• The BEO was finalized and signed days ago. It stays exactly as signed, tonight and after.
• The pre-shift note was drafted before service from the 86 list and the finalized BEO as they stood at that hour. It does not get redrafted when the 86 list changes mid-shift.
• The kitchen 86s an item mid-service. A written log can capture it for tomorrow's note, but that entry does not reach tonight's floor by itself.
• A person — a manager, an expo, a captain — says the words to the servers working that table, before the next course.
• If the 86'd item is named on the signed BEO, that document still says what it said. The gap between the page and the plate is carried by a person, not a record.

This is the same boundary that shows up across private dining software for groups: some records are built to hold still, and some information is built to move fast through a person's voice, and the two do not swap places on their own. For how the pre-shift note itself is drafted — what it pulls in from the 86 list and the finalized BEO, and what it leaves out rather than invent — see how pre-shift notes draft. And for the general sorting logic behind day-of changes beyond just an 86, the post on which channel carries each day-of change walks through it directly.

In plain terms

A finalized, signed BEO does not move once an event is underway. The pre-shift note is a once-a-shift snapshot of the menu, the 86 list, and that BEO — not a running feed. When the 86 list changes mid-service, the only thing that reliably reaches the server in time is a person telling them, directly, before the next course. No document closes that gap tonight. A manager's voice does.