delegation that failed, and the salvage that was proved

A wave of work was split across parallel workers so that several implementation tasks would land at once. Both of the slots doing the primary work died on their first steps, having exhausted their working context before producing a change. The report that came back was not a partial success: the primary work was zero, and the only output was a handful of files in a secondary language.

What the programme did next is the part worth recording. It did not restart the same arrangement with more care. The work was rebuilt in a single process, and the salvage from the failed run, some of it carrying defects, was repaired and then re-verified rather than trusted, because a file that arrives out of a process nobody watched is a claim and not a deliverable. Every receipt the workers would have produced was re-derived in the rebuild.

The write-up was appended to the wave's report rather than filed away, and it records the failure mode plainly: not a wrong result, an exhausted one. It also records what the fan-out was for and why it did not pay.

The general lesson is about the cost of coordination, which does not appear in a plan until it is paid. Splitting work multiplies the number of places a state can be lost, and context is a finite resource that a long task can consume before it produces anything at all.

What it proves is that a failed delegation is reported with the same care as a success, and that salvage enters the record only after it is checked.