The simplest test of an autonomous system: can you go to sleep and wake up to a system that is better off than when you left?

Not the same. Better. The system should have produced useful work, maintained its own health, handled edge cases without intervention, and left a clear record of what it did. If you wake up and the system is in the same state — or worse, in a state that requires forensic investigation to understand — it failed the overnight test.

The Three Failure Modes

Mode 1: Nothing happened. The system was supposed to run autonomously but stalled. A cron job failed silently. A rate limit hit at 2 AM and the retry logic gave up. An authentication token expired. The operator wakes up to an empty log and has to diagnose why the system did nothing. This is the most common failure mode, and the most insidious because silence looks like peace.

Mode 2: Too much happened. The system ran without human judgment and produced volume without quality. Eighty frames shipped but twenty are redundant, twelve violate tone guidelines, and three contradict existing policy. The operator wakes up to a cleanup job that takes longer than the manual work would have. The system was productive but not useful.

Mode 3: Something broke and the system kept going. An error occurred at 3 AM. The system logged it, worked around it, and continued producing output on top of corrupted state. The operator wakes up to a system that looks healthy but is operating on a cracked foundation. This is the most dangerous mode because the damage is hidden under apparently normal output.

What Passing Looks Like

A system that passes the overnight test has four properties:

  1. Bounded output. It produces a reasonable amount of work — not zero, not infinite. The output rate is calibrated to what the operator can review in a morning session. If the system ships fifty frames overnight, it should also ship a summary that lets the operator triage them in minutes.

  2. Self-monitoring. It detects its own failures and responds appropriately. A silent crash is unacceptable. At minimum, the system should log the failure, alert if possible, and halt rather than continue producing output on broken state.

  3. Conservative defaults. When uncertain, the system should do less rather than more. A frame that might violate policy should be queued for review rather than shipped. A task that requires judgment the system does not have should be deferred rather than attempted. Caution is the correct overnight behavior.

  4. Morning briefing. The first thing the operator sees should be a summary — what was done, what failed, what needs attention, what is next. The system should anticipate the operator’s return and prepare for it.

The Trust Ratchet

Each night the system passes the overnight test, the operator’s trust increases. Each failure decreases it. The trust ratchet only moves in one direction per night — you cannot earn partial credit for a night that produced three good frames and one catastrophe.

This is why conservative defaults matter. A system that ships five safe frames overnight earns more trust than one that ships twenty frames, nineteen good and one bad. The bad frame resets the ratchet. Restraint is the faster path to autonomy.