During a large batch update, I realized the process had been designed with a beginning and an end, but almost nothing in between.
It knew when to start. It knew what work to perform, and it knew what completion looked like. Once it began, however, there was no meaningful point where it had to stop, show what had happened, and return the next decision to a person.
The process was not ignoring its instructions. It was following them exactly, and that made me uneasy.
When a system fails loudly, the problem is easier to recognize. An error appears, a job stops, or an alert fires, and someone begins investigating. This situation was different because the workflow did not need to fail in order to go too far. It could continue operating exactly as designed.
I kept thinking about the approval that allowed the update to begin. We had made that decision before execution, using the information available at the time: the intended scope, the expected volume, and the logic of the operation.
What that approval did not answer was how long the decision should remain valid.
Approval to begin the update was not necessarily approval to complete every remaining record under every condition the process might encounter. Those decisions can look identical when the workflow is designed, but they are not identical once the work begins.
Execution reveals information that planning cannot always provide. The actual volume may differ from the estimate. Failures may cluster around one part of the data. The affected records may not look the way they did during testing. An operation can remain technically correct while producing a result that deserves another look.
In this workflow, none of that new information created another decision. The original approval remained open for the entire run, even though the context supporting that approval could change while the process continued.
That was the design gap I had missed.
I did not want someone reviewing every record. That would have made the automation harder to use without adding meaningful judgment. Over time, it could also train people to approve each step mechanically just to keep the process moving.
What I wanted was a deliberate return point.
The process could complete a bounded amount of work, preserve its state, and then present what had happened so far. A reviewer could see how many records were examined, how many changed, what was skipped, and what failed.
From there, the reviewer should be able to continue, change the remaining scope, or stop the process.
Without those choices, the checkpoint is only a report.
The next decision should be based on evidence from the run rather than only on assumptions made before it started.
That is where the idea of an action budget became useful to me.
We usually think of a budget as money, but an automated process can consume many things. It can consume time, compute, retries, API calls, messages, or record changes. The unit depends on the system and on the consequence of the action.
For a batch update, the budget may be the number of records the process can change before it must pause. In another workflow, the budget may be a retry count, a time limit, a spend threshold, or a defined number of external actions.
An action budget is different from an estimate. An estimate describes how much work we expect. A budget defines how much work the system may complete before another decision is required.
That difference matters because estimates can be wrong. A system should not treat an incorrect estimate as permission to continue without limit.
The obvious response is to divide the work into smaller batches. Smaller units can make failures easier to isolate, reduce the work tied to one execution, and make recovery more manageable.
But smaller batches do not automatically create oversight.
If one batch finishes and the next begins immediately, the workflow still has an uninterrupted path from the first record to the last. The work has been divided into smaller pieces, but the authority granted at the beginning remains open across all of them.
The same distinction applies to logging. Logs help us understand what the process did, identify failed records, and support recovery. They do not create a point where someone can decide whether the process should continue.
A checkpoint uses operational evidence while there is still time to make a different decision.
That is the difference between observing an automated process and governing one.
The checkpoint also has to be part of the workflow rather than an approval button added at the end. The process needs a safe waiting state where it can preserve completed work, present the evidence clearly, record the decision, and resume without repeating what has already finished.
I would not add this control to every batch process. Human review introduces delay, and the waiting state creates another path the workflow has to handle. The checkpoint becomes worthwhile when the cumulative consequence can grow beyond what someone could reasonably assess before execution.
That tradeoff matters because the goal is not to place a person in every step. The goal is to introduce judgment before the cost of being wrong becomes difficult to contain.
The large batch update changed the questions I ask when I review automated actions.
What is the unit of authority?
When does that authority expire?
What evidence must the system return before it continues?
I still ask what a process is allowed to do and which systems or records it can reach. Now I also ask how much work that permission covers before the process has to return with evidence.
Once I started asking that question, the design changed. It separates approval to begin from permission to continue indefinitely.
An automated process does not need human approval for every action. It does need a point where the authority granted at the beginning expires.
At that point, the system should pause, show what it has done, and earn the next step.