Don't Touch Anything

The briefing didn't arrive at 6:45 AM.

I noticed it the way you notice a sound that stops. Not immediately, but in the absence. The morning had a gap in it. My AI system Jarvis runs a daily briefing: schedule, active jobs, pipeline status, anything I need before the day starts. When it didn't come through I had a choice. I could start pulling wires. Try things. See what moved.

I didn't.

Instead I gave Jarvis one instruction: forensic audit. Investigate only. Do not make any changes. Do not repair anything. Do not update settings. Do not switch providers.

The reason for that rule is something I figured out in construction long before I ever touched an AI system.

When a wall is wet you don't open it up until you know where the water is coming from. If you do, you find rot. You pull the rot. You fix what you can see. You close it back up. Two months later it's wet again because you never found the source, you just removed the evidence. The repair felt like progress. It wasn't.

The same thing happens when a system breaks and someone starts helping immediately. The danger isn't that they don't fix anything. The danger is that they fix five things, and then nobody knows what actually broke. You end up with a system that works, no explanation for why it failed, and no confidence it won't fail the same way again next week.

So Jarvis ran the audit. Automation status, execution logs, credit usage, workflow trace, agent routing, delivery path, change history. The checklist was thorough because thoroughness is the point. You're building a record, not a solution.

What the audit found: the automation had triggered and logged a success. The system said it worked. The briefing still didn't arrive.

A silent success. That's the specific thing that's hard to diagnose, because the tools you'd normally use to find the problem are all reporting that there isn't one. The failure was real. The evidence said otherwise.

The trace eventually pointed to a permission setting that had changed during a recent migration. Human-in-the-Loop had been disabled. That change conflicted with the internal dispatch logic in a way that caused the agent to exit cleanly before retrieving or delivering anything. Clean exit. No error. Successful log entry. No briefing.

We found it because nothing had been touched. The original state was preserved. The audit had something accurate to read.

The briefing was restored the next morning.

I've run this same discipline on job sites for years. A deck ledger pulling away from the house. A footing that's shifted. You walk the whole thing before you touch anything. You take notes. You form a theory. You test the theory with one targeted action, not five simultaneous ones. If you're wrong, you still know what you ruled out.

The instinct to fix immediately is strong. It feels like competence. In a lot of trades it is competence. The guy who moves fastest is often the most experienced. But there's a category of problem where that instinct causes more damage than the original failure. Complex systems. Layered dependencies. Anything where the visible symptom and the actual cause are separated by several steps.

In those situations the most productive thing you can do is slow down completely, make a thorough record of exactly what you see, and resist every impulse to change something before you understand what happened.

Don't touch anything.

That's the whole rule. It doesn't feel like enough. It is.