The judgment line, applied to a whole process
· Prabhu Eshwarla
Some months ago I wrote about the judgment line, the boundary between work a machine may finish on its own and work a person has to finish. The argument was that most AI projects ask can AI do this work and stop there, when the question that actually decides the outcome is may the machine do this work alone. Technology answers the first. Accountability answers the second.
I still think that is right. What I have learned since is that it was incomplete, and in a specific way. The judgment line is a task-level tool, and businesses do not have tasks. They have processes. Applying the line to one task at a time produces a set of locally sensible decisions that leave the process exactly as slow as it was.
So this is the method extended: how to pick which processes to work on at all, how to break one into steps, and how to decide, step by step, what should run it and who should finish it.
Start from the process, not from the tool
The usual sequence is that somebody buys or builds an AI capability and then looks for places to apply it. That order guarantees a poor fit, because the capability was chosen before anyone knew what the work needed.
Reversing it costs nothing. List your processes first. Not your tasks, your processes: a trigger, a sequence, and an outcome somebody outside the process cares about. Vendor onboarding. Invoice approval. Claim intake. Contract review. Recruitment screening. Month-end close. Most companies can write this list in an afternoon, and most have never written it down at all.
Shortlist on evidence, not on enthusiasm
Two patterns make a process worth the effort, and one of them gets overlooked almost every time.
The first is high volume and repetition. The same shape of work arriving often, handled essentially the same way. This is the familiar target, it is easy to justify, and everybody starts here.
The second is low volume with a long cycle time caused by people. Only a handful of instances a month, but each one takes days or weeks, because it passes through several people and each of them has a queue. Nobody is being slow. The work is simply waiting.
To tell them apart, measure two numbers for each process: touch time, the minutes of actual hands-on work, and elapsed time, the days from trigger to outcome.
A process that takes nine days end to end and forty minutes of work does not have a work problem. It has a waiting problem. And this is where a lot of AI spending quietly fails to show up in any business measure, because halving forty minutes of work inside a nine-day process changes nothing anyone can feel. What changes it is removing handoffs, so that steps run when they are ready rather than when somebody gets to them.
That is worth stating plainly, because it cuts against the instinct to go where the volume is: the highest-volume process is not always the one where automation returns the most. A low-volume process with six handoffs can be the better target, and it will never surface if the shortlist is built on transaction counts.
Break the process into steps, and record the waiting
For each step, write down what comes in, what is done, what goes out, who does it today, how long the work takes, and how long the step waits before it starts.
Most process maps capture the first four and skip the last two. The last two are where the answer is.
Four things can execute a step
This is the part of the model that has changed most in my own thinking. A business process is not a choice between "a person does it" and "AI does it". There are four executors, and each step gets exactly one.
Rules. Deterministic logic, no model involved. Thresholds, routing, validation, status changes. Instant, auditable, and free to run.
Programs. Real computation over your own logic — a matching routine, a calculation, a reconciliation, a risk model. Deterministic and repeatable, and the logic stays yours.
AI. A model call. Reading a document, pulling fields out of unstructured text, classifying a message, drafting a summary. Capable and fast, and probabilistic, which is the property that decides everything downstream.
People. Judgment, relationship, accountability. Slow and expensive, and irreplaceable exactly where those three things are what the step is for.
The selection rule is short. Choose the most deterministic executor that can do the job. Determinism costs nothing at run time, gives the same answer twice, and is what makes a process explainable afterwards.
Which leads to the sentence I would most want a reader to keep:
Reach for AI where the input defeats a rule, not where the work is merely tedious.
Tedious and structured is a rules problem. Solving it with a model makes it slower, more expensive, harder to explain and less reliable, and it is the most common misallocation I see. The invoice arrives as a PDF, so reading it is an AI step. Comparing the total to the purchase order is arithmetic, and arithmetic should never be done by a language model when a program will do it exactly and for nothing.
Then draw the judgment line, one step at a time
Now the original six questions apply, per step rather than per project.
Can the machine do it? Has this been done a hundred times in essentially the same way, can someone check the output faster than they could have produced it, and is everything the step requires written down somewhere.
May it act alone? When this goes wrong, does someone outside the company expect a named person to answer for it, and does the value of the step depend on a person doing it.
How bad is wrong? If a bad output reaches the outside world and nobody catches it, what breaks. One sentence.
Each step then lands in one of three places. The machine finishes, and people audit a sample on a schedule instead of reviewing everything. Or the machine prepares and a person finishes, performing the accountable act of signing, sending or approving. Or the person does the work and the machine briefs them beforehand.
The two axes are not the same axis, and conflating them is the mistake. The executor answers what does the work. The destination answers who completes it. A step can be executed entirely by AI and still require a human signature, and a step executed by a person can still have most of its preparation done by a machine.
A few rules fall out of putting them together. Rules and program steps satisfy the first three questions by construction, so they finish on their own unless accountability or consequence puts a signature on them. AI steps need a confident yes on verifiability before finishing alone is even worth discussing, because if checking the output takes as long as doing the work then the honest destination is that a person finishes. And for human steps, the interesting question stops being whether to automate and becomes how much can be prepared in advance.
What it looks like on a real process
Vendor invoice approval, six steps.
The invoice arrives and is routed, which is a rule, and it finishes on its own. The supplier, purchase order number, amounts, tax and dates are read out of the document, which is AI, and a person confirms the fields because checking them takes seconds. The invoice is matched to the purchase order, which is a program, and it finishes on its own. Differences above tolerance are flagged, which is a rule. Payment is approved, which is a person, because a supplier expects a named human to answer for what was paid. The posting to the ledger is deterministic and finishes on its own.
All four executors, and the judgment line falls in exactly one place. Every other step runs without waiting for anybody, which is where the nine days go.
Where the software comes in
A method is worth something on its own, and this one is vendor-neutral. You can run it with a whiteboard and it will still tell you which processes to work on and where your judgment line sits.
What software decides is whether the design you drew survives. A process where a rule, a program, an AI step and a human approval are all first-class, each recorded with who or what advanced it, is a different thing from a process held together by people remembering to do the next bit.
Learn more at forgeprivate.com, or contact us.
