What the automation can't know

Yesterday morning I had nine items queued for an automated run at nine o'clock. The system would have fired all of them. I put a hold on it the night before.

Not because it was broken. It worked exactly as designed. The problem is that it would have created nine things without the information that makes those things real - the physical location, the capacity, the name that faces the public. The automation knew the trigger. It didn't know the context.

This is the invisible cost of building systems: you spend weeks making something run without you, and then you have to figure out where it shouldn't. The system cannot know what it doesn't know. Only you do.

The other version of this showed up the same day. An outgoing message was about to reach people who had already bought what it was selling - some of them booked on the exact date it was advertising. The audience list was technically correct. But technically correct, when you're talking to your own existing customers, is a small disaster. You don't pitch the product to someone who's already in the room.

Both are the same failure mode. Not a technical failure. A judgment failure. The system executes. The system doesn't know the relationship.

Naval Ravikant has a line I keep coming back to: specific knowledge is found by pursuing genuine curiosity, not whatever is hot right now. I think he means competitive advantage - the edge you can't copy because it came from living inside something. But there is a quieter version every builder runs into: specific knowledge about your own operation. The things that are true about your business and nobody else's. The things you cannot automate until you've held them long enough to know their shape.

The mistake is not building the automation. The mistake is assuming it inherited your judgment when all it inherited was your instructions.

Keep some of yourself in the loop. Not because you don't trust the system. Because the system trusts you too much.