What does an approval gate actually do?
An approval gate on ftes.ai holds a piece of work between the moment a Digital FTE finishes it and the moment it takes effect, and releases it only on a human decision. The work waits with its evidence attached, the decision is recorded in the audit trail, and a send-back returns it with a reason. Nothing about the gate slows the role's production; it slows the release. That distinction matters for the model, because the role keeps working while items wait.
The gate is the mechanism behind every honest claim ftes.ai makes about control, which is why it is the last thing removed rather than the first.
The cost is delay, and cadence sets it
An item's wait is the time from finishing to the next time a human reviews, plus the review itself. Since a review takes a few minutes and a cadence is measured in hours or days, cadence dominates entirely. A manager reviewing once each morning gives items an average wait of roughly half a day; a manager reviewing twice a week gives an average wait of nearly two days. Making each review faster barely moves either figure.
The consequence is counterintuitive and useful: the way to reduce delay is to review more often, not to review more quickly.
Batching: interruption traded away for wait
Reviewing in one daily batch protects the manager's attention: one context switch instead of twenty, and the items can be read in a consistent frame, which tends to make the decisions more consistent too. The cost is that every item waits for the batch. Reviewing continuously reverses both. Neither is correct in general, and the right choice depends on whether the work is time-sensitive: a published article can wait until morning, a customer reply usually cannot.
Mixed roles are best split by class, with time-sensitive classes reviewed continuously and the rest batched. The Approvals surface supports that because items carry their class.
The benefit is bounded exposure
With a gate in place, the set of things that can reach a customer, a ledger or a public page without human sign-off is empty. That is a categorical statement rather than a probabilistic one, and it is the reason a gate is worth its delay on anything outward-facing or irreversible. Without a gate, the exposure is whatever the role can do between acting and being noticed, which depends on how often the record is read.
A worked comparison is unnecessary here, because the two sides are different in kind. One is a delay measured in hours; the other is a class of outcome that either can or cannot occur.
The three conditions: bounded, logged, reversible
First, the class must be bounded: a manager can write in one sentence what the role may do alone, with a threshold and a scope. Second, it must be logged: every action taken without approval appears in the audit trail with its inputs, so the record can be read later. Third, it must be reversible: there is a specific, cheap action that undoes an item, and the manager is willing to take it. A class that fails any one of the three keeps its gate regardless of how clean its approval record looks.
The ftes.ai autonomy ladder encodes exactly these conditions, which is why promotion is per class and never per role.
- Bounded: the permission fits in one sentence with a threshold and a scope
- Logged: every unapproved action lands in the audit trail with its inputs
- Reversible: a specific, cheap undo exists and the manager will use it
Why is reversibility the condition most often missed?
Because it is the only one that cannot be satisfied by configuration. Bounds can be written and logging is automatic, but reversibility is a property of the action in the world: an unsent email is reversible, a sent one is not; a draft page is reversible, an indexed one is partly so; a posted ledger entry is reversible only if the accounting process allows a correcting entry. Teams tend to promote a class because its record is clean and discover afterwards that the undo they assumed does not exist.
The test is to name the undo before promoting, in the review note, in one sentence. A class whose undo cannot be named in a sentence is not reversible enough to promote.
When should a gate be put back?
At the first substantive send-back on a promoted class — meaning a correction about a fact, a rule, or a judgement rather than about tone. Stepping back is a routine operation on ftes.ai and is meant to be cheap and unremarkable, so that promoting is also cheap. A team that treats a step-back as a failure will promote too slowly at first and then too reluctantly reverse, which is the worse of the two errors.
Recording the step-back with its reason is what makes the next promotion decision better, so the reason matters more than the reversal itself.