Sometimes the kitchen catches fire mid-recipe
The chef is cooking one instruction at a time. Trigger an emergency, watch the chef save exactly where they stopped, handle it, and pick the recipe back up without ever starting over.
Why the emergency recipe actually works as a model
An interrupt is a signal that tells the CPU to stop what it's doing and handle something more urgent right now — a key pressed, a network packet arriving, a disk finishing a read. Without interrupts, a CPU would have to constantly ask "has anything happened yet?" in a loop, wasting cycles. Instead, the CPU just keeps working, and hardware taps it on the shoulder only when something actually needs attention.
That's exactly the role of the Clock and Interrupt Controller in this kitchen. The chef never stops mid-chop to wonder if the stove is on fire — the Clock checks in only after each instruction finishes, and the Interrupt Controller is the thing that actually raises the alarm when it finds something waiting. Different interrupts carry different priorities for the same reason a fire alarm outranks a new delivery of vegetables: the CPU services the most urgent request first, exactly as this simulation's priority levels demonstrate.
The single most important idea here is the save and restore cycle. Before the chef touches the emergency recipe, they write down precisely which step they were on, what was on the kitchen table, and what they were about to do — that's the CPU pushing its registers onto the stack. The Emergency Recipe Book is the Interrupt Service Routine (ISR): a small, separate program written specifically to handle one kind of event, nothing more.
Once the ISR finishes, the chef doesn't start the original recipe over — they retrieve the Saved Kitchen State and resume from the exact instruction they'd stopped at. That's what makes interrupts transparent to the running program: from the recipe's point of view, no time ever passed. It has no idea it was interrupted at all.