So, the phrase I keep coming back to is “empty cart management system”. It is wonderfully unglamorous and it explains why the project is more useful than the usual story about flying suitcases... Sure, the visible job was moving bags, but the real hard job was continually putting spare capacity in the right place before demand arrived. Once that failed, every loading point became a queue whose failure could spread elsewhere. That pattern turns up whenever automation removes local slack. A human with a tug can improvise, wait, reroute or prioritise. Denver Airport replaced much of that discretion with a network whose physical state, database state and schedule assumptions all had to agree in real time. Lose a barcode association, misplace an empty cart or take a corner too fast, and the software’s model of the airport starts drifting away from the airport itself. The system then spends its effort recovering from yesterday’s mistakes while new bags keep arriving. This showed that the machinery could perform its tricks, while neatly avoiding the shared-resource problem that defined production. That is a familiar way to prove the easy part and call it validation. Denver’s later fallback, belts and human-driven tugs squeezed through tunnels with railway-style signalling, looks primitive only until you notice that it actually opened the airport.

The image that sticks is that memory as something literally moving! Its bits racing through mercury as sound, twisting around coils of wire, circling on magnetic drums. We now talk about memory as though it were a place, an addressable landscape of neat little cells. Much of its history looks more like choreography. So that changes how I read the article’s argument about Babbage; programmability is intellectually glamorous because it sounds like software, yet working memory sounds like plumbing. But once computation becomes complicated, retaining an intermediate result and getting it back to the right place quickly is what lets complexity accumulate rather than collapse under its own mechanics. The bizarre hardware here was solving that coordination problem with whatever physics happened to be affordable. The continuity with DRAM is especially good. A modern capacitor cell is vastly removed from a rotating drum of mechanically switched capacitors, yet both accept impermanence as an engineering bargain: make storage cheap and dense, then spend effort continually rescuing the data before physics erases it. Bottom line; computer architecture has repeatedly advanced by finding tolerable ways to make unreliable or awkward physical phenomena behave like dependable abstractions, but memory only looks passive after an extraordinary amount of machinery has made us forget what it is doing.

Luther Stickell is useful because he speaks sparingly; he has context, but more importantly he has judgement about interruption. That turns Audio AR from a speech-interface problem into an attention-allocation problem. Drew’s three product patterns expose a useful gradient. VoiceMap works because the route already encodes intent. Apple Fitness works because starting a workout creates a bounded session. Meta’s pull model works because the user chooses the moment. Each product gets better as it reduces uncertainty about whether an interruption is welcome. The more ambient the system becomes, the less certainty it has and the more damage a badly timed cue can do. That makes the call for richer context necessary and slightly dangerous from a product-design perspective. More signals may improve relevance, but they don’t automatically produce judgement. A model can know my location, calendar and messages and still be annoyingly literal. The hard engineering target is probably not maximal context. It is confidence calibration: know enough to help, and be conservative enough to stay silent when uncertain. An assistant that occasionally misses a useful cue is tolerable. One that keeps guessing wrong becomes something you switch off.

The part I’d keep is the open gradebook, because it shows how a “transparent” interface can quietly redesign the system around it. A grade used to arrive at intervals. Make it continuously visible and it becomes a live metric, which invites continuous checking, parental escalation and optimisation by everyone being measured. Johnson’s 50-to-80-times-a-day figure is methodologically thin, but the mechanism deserves attention. That is more interesting than another argument about whether AI will replace teachers. The useful distinction is who retains discretion when software enters the loop. A photocopier speeds up production without deciding what deserves copying. An open gradebook exposes a metric and changes behaviour. AI can go further by generating material, sequencing work and recommending interventions, so the design question is not simply whether a teacher remains physically present. Once a proxy becomes constantly observable, people start managing the proxy. Schools are hardly unique there. Anyone who has watched a dashboard KPI become a target should recognise the smell.

Cook’s claim that complex systems “run as broken systems” is quite true! So it is a useful corrective to the tidy picture produced by dashboards and postmortems. A service can be green because the machinery is healthy, or because people are quietly rerouting traffic, restarting jobs, carrying tribal knowledge and compensating for defects. The observable outcome is the same until those compensations stop lining up. For engineering leaders, that makes uneventful operation ambiguous evidence. If reliability depends on expert improvisation, absence of incidents may conceal fragility rather than demonstrate it. Cook’s “proto-accidents” are therefore more interesting than the final outage: the near miss, manual recovery or weird alert that disappeared after someone nudged a system back into shape. Those moments expose the operating envelope while everyone still remembers what they did. Waiting for catastrophe selects only the rare combinations that escaped every defence, then tempts us to narrate them backwards into inevitability. A system’s resilience may be most visible on the days when nothing officially happened.