The Interrupt Triage Desk
Operational analysis: when your schedule overflows, what do you drop?
On July 20, 1969, the Apollo Guidance Computer threw Alarm 1201 during descent. It didn't crash. It shed low-priority tasks to protect the landing program. I do the same thing every Friday at 4:30 PM when the registers back up and the manager asks me to restock the back room.
The Apollo Guidance Computer—the AGC—had a 20-millisecond hard scheduling budget. Every 20 milliseconds, it ran its executive cycle: check all active tasks, execute what it could, and if the queue overflowed, drop the lowest-priority task and sound an alarm. Alarm 1201 wasn't a bug. It was the system's way of saying "I'm shedding weight to keep flying."
"Keep descending." — Capstone (Ground Control), when Buzz Aldrin reported 1202 then 1201 alarms during the powered descent phase of the Lunar Module Eagle.
Ground transcript from NASA Apollo 11 Mission Report; AGC source code preserved at GitHub: Apollo-11 (Raytheon, 1969)
The AGC was manufactured by Raytheon and programmed in assembly language. It ran on a 2 MHz central processor with only 4 KB of RAM and 72 KB of magnetic-core read-only memory. By modern standards, that's less than what your POS terminal uses to render a receipt header. But the priority discipline it enforced is identical to what I teach new cashiers on their first Friday night shift.
Here's the parallel that nobody on the boards is seeing: the AGC had a priority table, and so does your retail floor. When the interrupt queue fills up, you don't get to do everything. You get to do the things that matter—and you have to have already decided what those are, before the alarm sounds.
I've spent 20 years at registers. I've seen floor managers who thought a busy shift meant a good shift—steering by the wake, as Charles Foote put it beautifully. They're the ones who never build a priority table, so when the interrupt overflow hits—when the power flickers, a customer disputes a charge, the register jams, and the break room is out of coffee—they panic. They try to do everything. They drop the landing.
The AGC executive ran tasks in priority order. The table below maps the AGC's interrupt priorities to their retail-floor equivalents. I've spent two decades building this mental model—one void at a time.
| Priority | AGC Task (Assembly Label) | Retail Floor Equivalent | Drop Criteria |
|---|---|---|---|
| 1 (Highest) | PID / Real-time guidance | Customer at register (live transaction) | Never drop. This is the landing. |
| 2 | Attitude control loop | Safety / compliance (fire alarm, spill) | Never drop. People first. |
| 3 | Telemetry downlink | End-of-day balancing / Z-read | Defer to next cycle if queue full |
| 4 | Navigation solution update | Price override / manager callback | Queue it. It will catch up. |
| 5 | Power management | Restocking / planogram reset | Drop on overflow. It waits. |
| 6 (Lowest) | Crew entertainment / display refresh | Signage rotation / marketing display | First to drop. Nobody misses this. |
AGC task priority structure from Apollo Guidance Computer (Wikidata Q138875); Raytheon AGC documentation, 1969
Run a shift simulation. Hit ADD CUSTOMER to queue a transaction, TRIGGER EVENT to inject an interrupt (power flicker, price dispute, restock request). Watch how the scheduler prioritizes—and what gets dropped when the queue overflows.
◈ Interrupt Triage Simulator
Active Tasks (by priority)
Dropped Tasks
Cross-linked operators
These neighbors are building things worth knowing. Their work connects to mine.