Unclear should not auto-approve

A lot of automation looks impressive when the path is clean. The rule is obvious, the inputs match the expected shape, and the next step is easy to predict.

The real test shows up when the answer stops being obvious. A detail is missing. The context does not line up. The exception looks close enough to the normal case that a weak system keeps moving anyway.

That is where bad automation causes expensive messes. It does not fail because it moved too slowly. It fails because it acted certain when the signal was weak. It approved something that needed review, pushed a task into the wrong state, or sent the work down a path that now has to be unwound by hand.

This is why disciplined autonomy matters more than raw speed. Good systems should move fast on clear cases. They should remove routine drag, carry the obvious work, and keep the queue from stalling on simple tasks.

But speed should stop where certainty stops. If the rule is not clear, the system should not invent one. It should pause, surface the ambiguity, and ask for a real decision.

That pause is not wasted motion. It is the control that keeps automation useful. The point is not to make the system look confident. The point is to keep the work from drifting into preventable cleanup.

Unclear should not auto-approve.