Every automation pitch eventually arrives at the same sentence: “and then a human reviews it.” That sentence is doing more work than the rest of the proposal, and it is almost never designed.

A gate that everyone clicks through is not a gate. It is latency with a paper trail.

What a reviewer is actually deciding

A reviewer is not checking the model’s work. They do not have time, and if they did, the automation has not saved anything.

They are deciding one thing: whether to accept the consequence. So the gate has to show the consequence, not the reasoning.

Three facts do it. What changed. What it costs if this is wrong. What the system would have done unattended.

The third one is the surprising one, and it is the one most gates omit. A reviewer who can see what would have happened without them learns, over a few weeks, exactly where their attention is worth spending. That is how a gate narrows over time instead of calcifying.

Where to put it

At the last reversible moment.

Not at the first uncertain step, which is where teams instinctively put it. A gate placed early forces the human to evaluate a plan, and evaluating a plan is harder than evaluating an outcome. It also fires on every run, including the ones that would have been fine.

Money moving. A date being promised. A document leaving the building. A record of truth being written. Those are the moments worth stopping. Everything before them can be retried at no cost, and should be.

The failure mode nobody plans for

The gate approves everything for three months, so someone widens it. Then it approves everything for another three months, so someone removes it.

That is not a discipline problem. It is an instrumentation problem: nobody recorded how often a reviewer changed anything, so the only available evidence was that nothing had gone wrong yet.

Record the override rate from day one, per field, per workflow. The thresholds are worth stating plainly as assumptions rather than findings. The working numbers: a gate running near 2 percent has probably earned the right to narrow, and one running near 40 percent is telling you the step before it is not ready. Neither figure has been tested across enough deployments to defend as a rule.

What does not depend on where the line sits is the direction of the inference. A gate that is rarely overridden is measuring a step that works. A gate that is frequently overridden is measuring a step that does not, and widening it would have shipped that unreadiness straight to a customer. You cannot tell those two situations apart without the number, which is the actual argument for recording it.

Why this is the product

Owner-operators do not withhold work from automation because they doubt the model. They withhold it because delegation without visibility is indistinguishable from loss of control.

The gate is where that is settled. Build it first, instrument it properly, and the rest of the workflow gets adopted almost by default.

每一份自動化提案最後都會走到同一句話：「然後由人審核。」這句話承擔的份量比提案其 餘部分都重，而它幾乎從來沒有被設計過。

一道大家都直接按過去的關卡不是關卡，那只是有紀錄的延遲。

審核者實際在決定什麼

審核者不是在檢查模型的作業。他沒有時間；而如果他有時間，這段自動化就沒有省下任何 東西。

他在決定的只有一件事：要不要承受這個後果。所以關卡要呈現的是後果，不是推理過程。

三項事實就夠了。改了什麼。如果這是錯的，代價是多少。以及——如果沒有人看，系統原 本會怎麼做。

第三項最出人意料，也是最多關卡漏掉的。看得到「沒有我會發生什麼」的審核者，幾週之 內就會學到自己的注意力值得花在哪裡。關卡因此會隨時間收窄，而不是僵化。

該放在哪裡

放在最後一個還可以反悔的時刻。

不是放在第一個不確定的步驟——那是團隊直覺會放的位置。關卡放太早，等於逼人去評估 一個計畫，而評估計畫比評估結果難得多。而且它每一次執行都會觸發，包括那些本來就不 會出事的。

錢要動、日期要承諾、文件要寄出去、真實紀錄要被寫入——這些才是值得停下來的時刻。 在這之前的每一步都可以零成本重跑，也應該重跑。

沒人事先規劃的失效模式

關卡連續三個月什麼都放行，於是有人把它放寬。再三個月什麼都放行，於是有人把它拿 掉。

這不是紀律問題，是儀器問題：沒有人記錄審核者到底改過幾次，所以唯一拿得出來的證 據，就是「目前還沒出事」。

從第一天就記錄覆寫率，逐欄位、逐流程地記。覆寫率百分之二的關卡，有資格被收窄。覆 寫率百分之四十的關卡，是在告訴你它前面那一步還沒準備好；把它放寬，等於把這份沒準 備好直接送到客戶面前。

為什麼這才是產品

老闆不把工作交給自動化，不是因為懷疑模型。是因為沒有可見度的授權，跟失去控制沒有 分別。

關卡就是這件事被解決的地方。先把它做好、把它量好，流程的其餘部分幾乎會自動被接 受。