The first answer to Pasha's request for "a graph of the flow of work".

• The biggest problem: it did not model cooking at all. Nothing showed how the food gets cooked.
• A literal copy of the physical restaurant: the dining room and the kitchen kept apart, as they are in the room.
• It did not work visually, and Pasha asked straight away for something else.

Thrown away.

Pasha described three sections, and we built them as a board of cards.

• Actors are defined, but not shown: each table has its people, but you cannot see them.
• No arrows: you have to assume the flow goes from left to right.
• The kitchen is hidden inside one state: nothing says that "waiting for food" is the kitchen's own state machine, so it does not look expandable.
• Cooking is one monolithic step, drastically simplified: no way to show that some dishes are made in sequence and some in parallel.
• It stood still, and work could not be seen at the tables.

Thrown away: basically unusable.

Things start on the left and complete on the right, with nothing tied to the room. Much better than before: it shows clearly which actor is on which task.

• No equipment: no stoves, no pizza oven, no coffee machine. People are allocated to tasks, but resources are not.
• It does not scale the same way: a cook also has to be allocated to an oven, and there was nowhere to show that.
• The cook never puts the food anywhere: it should go into a queue.
• A queue drawn as a step: "food to pass" was shown as a state of the table, not as a queue.

Thrown away: nice, but very limited in what it could show.

Pasha pushed the workflow further, to see whether it could bring the resources in as well, with the things that wait drawn differently from the things that happen.

• Incomprehensible: the result was so hard to read that it could not even be evaluated.
• The queues were not things of their own: the two real queues, tickets and food, needed to be modelled explicitly.
• Still, a good idea in it: the states of the party through the restaurant, which became the foundation of the next version.

Thrown away.

The party's states as the foundation, with the two key queues, the order rail and the pass, as things of their own. This was what Pasha was looking for.

• The visitor's state machine at the top, with the cook's state machine below it as a sub-machine.
• Where the staff are: an area for free waiters and cooks, and where they go when deployed.
• Parties move: each party is a coloured circle that clearly moves from state to state through its state machine.
• Tickets do the same for the kitchen, and the two state machines connect.

Kept: something that could be improved step by step, and good enough to take forward.

The four other views were deleted, and the rest of Episode 2 went into the one that was kept.

• The more Pasha used it, the more intuitive and informative it felt: the flow from left to right, parties and tickets moving as tokens, waiters and cooks going from the free area to the equipment they work at. A real, process-oriented picture of a restaurant's work.
• Everything can be selected, here and on the floor.
• Every object has a card and metrics, with a target and two charts.
• Waiters and cooks can be added and taken away while it runs.
• The tables came in too, each showing its state, for more information in the same space.

We decided to keep working with it. It worked, and it was accepted. It was also still a picture of this one restaurant: its boxes, its two queues, its kitchen.

Okay, so tell me in this three ways methods you proposed, what is the visitor, what is a stove, is a standard notation in terms of terminology that should be used in modeling across these three things and methodologies.Pasha, to Gemini

A fair answer to the question, and still in the formalisms' own words: tokens, places, entities, channels.

Every word of the answer was right, and Pasha knew it: the mathematics of all three methods was familiar to him. That was not the difficulty.

The difficulty was who the video is for. Cyber Kitchen is meant to introduce the running of a restaurant to a business major, and someone with a bachelor's degree in business does not know these methods.

• To follow the answer you need places and transitions, markings, Markov chains, semaphores and Python generators.
• None of that is taught on a business course, so none of it could go into the video as it stood.
• So the question stayed open: how do you help a business major model what happens in a restaurant?

Mathematically correct advice, and not applicable to the people it had to reach.

To be widely used, it needed to be a much simpler model.

We knew the method and the terminology by now. It still took three iterations to get it right.

• Three lanes: visitors, waiters and cooks, each task in the lane of whoever does it.
• Tables and kitchen equipment as boxes underneath.

What is wrong with it:

• The key error: all the food is cooked in sequence, not in parallel.
• Too rigid: each actor is confined to his swim lane. Letting a waiter make the coffee should not need a new diagram of the operations.

The second was built from scratch from the decisions borrowed from the studies. It came out as a flowchart.

• A flowchart, not DES: a flowchart-style diagram, so it was rejected right away.
• Flowchart shapes: ovals to create and dispose, diamonds to separate and match, boxes for queues and delays.
• Two paths: the party's, and its order ticket's through the kitchen.
• Still, a good idea in it: resource pools. Tables at the top, cooks and stove burners at the bottom, each a pool of units. The final version has them too.

The third was a whole new view, built on a real event engine, with the guests as actors.

• No flow: neither left to right nor top to bottom, so it was difficult to follow. What reads naturally is work beginning on the left and outcomes on the right.
• Too busy: stations, actors, resources and objectives all on one screen. It had to be decomposed.
• Still, good ideas in it: outcomes. Happy visit, unhappy visit and turned away, each its own end.
• And fork and join: planning an order forks it into its parts, and plating joins them again.

After three that were not kept, this is the basic DES model that was. It had very good, solid foundations:

• One engine, from Gemini's requirements at turn 8.
• Every queue has a box, in front of the task it feeds.
• The kitchen is not a sequence: the parts of an order cook in parallel and meet at plating.

But it had a few weaknesses:

• Metrics in the flow: a bar on top for busy tables, boxes for free waiters and cooks.
• Aggregate metrics along the bottom: λ, W, L and a row of totals.
• Two ends only: why a party left is not shown.

The metrics do not belong in a process flow. The next iteration moved them elsewhere and decluttered.

The first view was functionally correct but not yet usable. Phase 2 made it a clean interface in three moves, each borrowing a concept from a rejected attempt.

• Actors were introduced. Parties, waiters and cooks sit along the top beside the resources they use. Each one is a box of squares, one square per unit: the resource pools of attempt 2.
• Outcomes were introduced. Every way a visit can end has its own box along the bottom, as in attempt 3: turned away, left because of a slow waiter or a slow kitchen, dined.
• Queues were folded into the tasks. A queue is no longer a box of its own but an optional part of a task, a dashed waiting area on its left, as each task had in attempt 1.

The process map itself stayed clean from the first step. What this phase added was a natural way to explore it, with a lot of nuance behind it.

• Select and inspect any element, in any view, or pick it by name.
• Zoom in and out, with the buttons or two fingers on the trackpad, and focus on one portion of the process.
• The same object is selected in every view, so a table picked on the floor plan is the same table on the process map.
• The side panel follows the selection. About says what the object is and what it is for, in the same form for every kind of object.

The other polish: instead of looking at the whole thing, you can focus on any one element of the model.

• Anything can be pinned: a task, a resource, one cook, one table, one party. It moves to the middle and only its own arrows remain.
• A pinned task shows what feeds it on the left, what follows on the right, what it needs on top and how it can end below.
• The side panel follows the selection. About says what the thing is, Metrics shows its charts and targets, Actions lists what can be done to it.

The side panel's Metrics tab is where each object is measured against what it is for.

• Each object has an objective, said in plain words: what a good job looks like for this thing.
• And metrics for it: charts over time, a target, and a colour for whether it is being met.
• All the way down: the waiters together and each specific waiter, every piece of equipment, every table, every party, every task and every outcome.

Each object also carries the actions that make sense for it. This is very powerful: it lets you control scenarios dynamically, while the restaurant runs.

• A person gets sick: call a specific cook or waiter in sick, and back to work.
• A machine breaks down: break a stove, the pizza oven or the coffee machine, and fix it.
• A table closes, and opens again. Waiters and cooks can be added or taken away.
• From the side panel or by right-click on the object, in any view. Only the actions that apply to that object are offered.
• The engine reacts at once: a red diagonal marks what is out of service, and queues build up.

The purpose of the Scorecard is to level up: from the metrics of each component of the process map to the actual business metrics, the ones that cut across all of them.

• Nine tiles: arrivals, parties in the building, time per visit, the wait for food, happy visits, each coloured by whether it meets its target.
• Real time, with history, derived automatically: the system is highly formalized, so every number comes almost for free. Select a tile for its charts.
• Little's Law in plain words, as a footnote: how many are inside equals arrivals times time spent.

This is just the beginning of the high-level business metrics. Episode 3 will build them out toward the owner's actual objectives.

Deployed as a single HTML page with everything bundled in. No third-party libraries: everything was built and tested from scratch. Built by Pasha by voice: the keyboard was not touched through any of it.

This is probably not something a business major could do, even with the same AI tools. Better left for a professional software engineer.