In practice
The exception is the job
A worked example runs five clean steps from an enquiry to a quote. Most enquiries do not run that way, and what a system does at the step it cannot complete decides whether it is worth having at all.
The Solutions page carries an illustrative example: an enquiry arrives by email with a specification attached, the item is identified in the ERP, the current cost is checked, a quote is drafted, and a person approves it. Five steps, and the last one is a person. It is an illustration rather than a customer, and so is everything in this piece: Atlas is early and has no deployment to report on.
The example is honest about what it shows and quiet about what it does not. It shows the run where all five steps hold. Anybody who has worked in operations knows how often that is the run you get, which is why the interesting question is the other one. What happens at the step the system cannot complete.
Four ways the same enquiry goes wrong
The failures are not exotic. They are the ordinary texture of the work, and they are the reason the step is done by a person today.
The specification is ambiguous
The attachment describes something in the customer’s vocabulary rather than yours. Two articles in the ERP could be meant. A person resolves this by knowing which one this customer has ordered before, which is knowledge that lives in a person rather than in a field.
The record is stale
The cost in the system was accurate at the last import. Whether that was this morning or last quarter is not visible on the record itself, and a quote built on the second one is wrong in a way nobody notices until margin is counted.
The item is not there at all
It is a variant that has never been quoted, or a configuration assembled from parts. There is no record to identify, so the step does not fail a check so much as find nothing to check.
Two systems disagree
The ERP and the CRM hold different versions of the same fact. Both are internally consistent. Neither is marked as the one that is wrong.
A system that runs the five steps regardless produces a quote in every one of these cases. That is the failure mode worth worrying about, because the output looks exactly like the output of a run that went well.
Stopping is a result, not an error
Forge plans, executes and verifies, and the verification is not a formality at the end. Work is checked against defined rules before it counts as complete, which means a step that cannot be verified does not quietly become a step that passed.
Two different things can stop a step, and they are worth keeping apart. Where the authority behind an action cannot be established, the governance layer refuses: a check that cannot be completed is a refusal rather than a permission. Where the authority is not in question and the work itself is unclear, the check that fails is the quality gate. Identifying an article is not a permission question, and no rule about who may act resolves it.
What the two have in common is the answer they give. Where the item cannot be identified with confidence, the system does not pick the likelier of two articles. It stops at that step and says which two.
Three of the four failures above are caught this way, because each of them shows: two candidates where one was expected, no candidate at all, or two systems holding the same fact differently. A check finds what is absent and what contradicts.
The stale cost is the one it does not catch, and it is worth naming rather than leaving in the list. That record is complete, internally consistent and wrong, and nothing about its shape says so. No quality gate finds it. What closes that gap is not a cleverer check but the source system recording when the figure was last true, and where that is missing the quote was wrong before any system touched it.
This is the opposite of the instinct most automation is built on, which is to produce an output whatever happens, because an output looks like progress. A quote built on a guess has not saved the work. It has moved the error to the person who signs it, at the point where they are least likely to catch it, because everything upstream looks finished.
A step that cannot be finished is a fact about the work, not a fault in the system.
What actually reaches a person
The difference between a system that stops well and one that stops badly is what arrives when it stops.
What arrives is not a failure notice. It is the work up to that point, which in this example is the enquiry read, the customer identified and the four steps that did hold, together with the one question that could not be answered and the evidence behind it: these two articles match the description, here is what each has been quoted at before.
The question is answered in seconds by somebody who knows the customer. That is the step that needed a person, and it is the only one they were asked for.
The job stops. The others do not. One job waiting at a quality gate does not hold up the work beside it, which matters more than it sounds: a queue that blocks is the reason people stop routing work through a system at all.
It stops more often at the start
A system that will not guess stops wherever the information in front of it is genuinely insufficient, and at the beginning that is more places than later. How many is not something we can tell you: Atlas has no deployment to count them in. What can be said in advance is that a system stopping often feels like a system not working, and that the feeling is worth preparing for.
Some of it is the system being appropriately unsure about work it has not seen. Some of it is not about the system at all: an item that cannot be identified is often an item whose record is genuinely incomplete, and a disagreement between two systems was there before anything was automated. The stopping surfaces it rather than causing it.
That distinction matters, because the two have different remedies and only one of them is our problem. What Atlas owes a company here is that the stops are legible: which step, on which record, and what was missing. Whether the answer is to widen the system’s autonomy on that class of step or to fix the data underneath is a judgement the company makes with that in front of it.
Where the exceptions turn out to be useful
An operations team can usually tell you which parts of their data they do not trust. They cannot usually show you, because the knowledge is distributed across the people who work around it every day and has never been written down anywhere.
A system that records where it stopped, and why, writes that down as a by-product of doing the work. Not as an audit finding produced by a project, but continuously, in the course of the ordinary week.
That is the part of this we would defend hardest. The clean path was never the difficult thing to automate. The exceptions are where the work actually lives, they are why the step still belongs to a person today, and a system that treats them as the job rather than as the error case is the only kind that gets to take any of it on.
The product behind it
Plan, execute, verify, and the quality gate this piece turns on: what Forge checks before work counts as complete, and where it stops for a person.