An autonomy gate is the rule that decides when a system that can already act is finally allowed to act. Helios, a personal trading system I built for myself, has been running for months and still hasn't cleared mine. It observes, it decides, it writes down what it would have done, and it messages me every morning. It is not allowed to touch anything for real.
Not because it isn't finished. Because it hasn't earned it yet.
Short version: build the full capability, then keep permission behind its own switch. Write the conditions for opening that switch while you still have nothing to gain, make one of them something only time can satisfy, and reset the counter automatically the moment anything breaks.
That constraint turned out to be the most useful thing in the project. It also changed how I ship other people's software, which is why it belongs on a work blog instead of a private notebook.
What is the difference between capability and permission?
Capability is what the code can do. Permission is whether it is allowed to do it right now. Most automation ships with those two welded together. You wire the path end to end, and then you are careful. The system can do the thing, and you simply try not to let it do the wrong thing.
That makes vigilance your safety mechanism. Vigilance runs out. It runs out at the exact moment you need it, which is late at night, when you are tired, and the thing has behaved perfectly for six weeks.
Splitting the switches fixes the order of events. The system is capable of the whole path from day one. Separately, it is permitted to execute only the parts it has already proven it handles correctly. Capability is code. Permission is a gate. Flipping one does not move the other.
The practical effect is that "let it run for real" stops being a mood. It is no longer a decision I make on a Friday when I feel optimistic. It is a set of conditions I wrote down in advance, calm, with no stake in the answer.
Why should you write the gate before you want to pass it?
Because the version of you that wants to pass it will negotiate, and it negotiates well. It knows every excuse you find persuasive.
My criteria live in the project spec: specific conditions, in plain sentences, with numbers where numbers apply. Whether they are the perfect criteria matters less than the fact that they exist and predate my wanting to clear them. A rule I wrote a month ago argues from a position I cannot easily corrupt. My past self had nothing to gain.
Two things I got wrong at first, both worth stealing.
Make one criterion depend on time, not effort. Something like "runs without unexplained failures for N consecutive days." You cannot grind that out over a weekend. It forces the system to sit there and prove itself under conditions you did not stage. For me it has been the only criterion that reliably catches the failures that appear when nobody is watching.
Restarting the clock has to be automatic. When something breaks, the counter goes back to zero and there is no conversation about it. That kills the conversation I would otherwise have with myself, the one that opens with "well, that one doesn't really count." My clock has reset more than once for reasons that had nothing to do with the code. Hardware, mostly. That is not unfair. If the machine it lives on is not stable, the system is not ready, however good the code is.
What does a long observe-only period actually buy you?
It buys you the test suite you cannot write.
Months of recording every decision and executing none of them is not a delay. It surfaces the failures you could never have imagined at design time: the edge case that only shows up on a third Sunday, the time zone assumption that is wrong twice a year, the dependency that behaves differently after an update. Every one of those would have been a live incident. Instead each one was a line in a morning message and a quiet fix that afternoon.
It also gives you an honest record. When the gate finally opens, I will not be deciding on the strength of how confident I feel that week. I will be deciding on months of logged behaviour, including all the days it was wrong, which is the only sample worth anything.
How do you ship an automated feature to a client safely?
Behind a flag, in the mode where it produces real output and sends none of it.
I don't build trading systems for clients and I'm not offering to. But the pattern moved straight into web work. Anything that acts on its own gets the same treatment: a mailing send, a payment path, an automated reply, a bulk update.
It runs in a mode where it produces the exact output it would have sent and shows that output to a human. It stays there until the results are boring, unremarkable, and reviewed often enough that switching it on is uneventful. Then one flag changes and nothing else does. None of this is exotic. It is standard feature toggle practice, and the mechanics are laid out well in Pete Hodgson's feature toggles article on martinfowler.com.
Clients tend to read it as caution, and some of it is. The bigger reason is speed. A version that can be switched on with one flag is a version I can build aggressively, because being wrong stays cheap right up until somebody decides it isn't. Reversible steps let you move faster than careful ones do.
The gate is still shut
So Helios keeps running, keeps deciding, keeps not being allowed. The gate is written down. It is not clear yet. The fact that I want it to be is precisely why I don't get a vote.
If you want to see how this thinking shows up in paid work, the rest of the blog and my recent projects are the long version.
Shipping something that acts on its own, that sends, charges, publishes or replies? I build those with the safety switch built in.