A running record of what each design could not survive — kept because naming the failure boundary is part of the engineering, not an apology for it.

The Failure Wall

Seven ways to lose a 72-hour event. These are synthetic teaching cases written for this course: they are not incident reports, not anonymised real runs, and not anyone’s dispatch log. Each names a decision that was defensible when it was made. Nobody on this list did anything stupid.

Hour 8
Ran a perfect first day and never looked at the forecast for the third.
Hour 19
Charged the battery during the only windy hour of the event, because the price was low.
Hour 31
Held the reserve back to save fuel, then needed ninety minutes it did not have.
Hour 44
Shed industry first because it was the largest block, and lost the argument afterwards.
Hour 52
Imported to the cap for two days, then discovered the neighbour was in the same weather.
Hour 61
Protected EV charging over water treatment, and then had to explain why.
Hour 70
Survived, with eleven minutes of margin, and could not say which decision had saved it.

The last one is on the list because a system you cannot explain is not a system you can repeat.

Why the course keeps one

Every design in this course is asked for two statements: the event it survives, and the event that defeats it. This page is where the second statement lives.

It is not a wall of shame, and it is not encouragement. It is a register. A design whose limits are written down can be checked, compared and improved by someone who was not in the room. A design that claims to survive everything has either not been tested or is not telling you about the case it fails.

Three things follow from keeping the record in public:

  1. A boundary becomes falsifiable. “This system survives the reference event but not one arriving with storage already depleted” is a claim someone can test. “This system is robust” is not.
  2. Comparison becomes possible. Two portfolios that both survive the reference event are not equivalent if one fails at 70 hours and the other at 140.
  3. The incentive changes. When the failure boundary is the marked output, there is nothing to gain from hiding it.

How the wall is added to

Entries arrive from the weekly studio sessions, and from Design for the Worst Week, where stating the defeating event is the primary requirement rather than a caveat attached to one. Each records the hour a run became unavoidable, the decision that caused it, and what it cost.

Week 11 argues that the cause of a failure is partly a choice about where the system’s edge was drawn, so an entry that does not say where the boundary sits has not finished describing the failure.

These seven are worked examples, not a record. Your wall opens empty in Week 1.