Before an AI workflow goes to production, write it out in four lines: source, logic, eval and destination. Then ask one question of each line. It takes about fifteen minutes for one workflow, and it shows which steps the model should own, which belong in code, and whether you're ready to launch.
What is the four-line test?
The four-line test is a one-page way to check an AI workflow before launch. You describe the workflow in four lines (where inputs come from, what happens to them, how you know the output is right, and where it goes), then ask whether a wrong answer on each line would look like a right one.
It comes from how we scope every build. Our forward-deployed engineers call it the anatomy of a task. The four-line version is the short form, meant for an operator, a product owner or a finance lead, not just an engineer. You don't need to know how the model works to fill it in. You need to know the workflow.
Line 1: Source
Where does the information come from, and how messy is it? Name the actual systems and formats: an inbox, SharePoint, a data room, an API, a scanned PDF. Messy inputs are fine. Reading them is what the model is good at.
A good answer is specific: "vendor invoices, PDFs and scans, arriving in a shared inbox in many layouts." A red flag is a vague one, like "our data". If you can't say where the inputs come from, the workflow isn't defined yet.
Line 2: Logic
What has to happen to the inputs, and does it have to come out the same every time? If it does, such as a calculation, a match against a policy or a threshold, it belongs in code, not in the prompt.
This is the line where most scoping mistakes happen. Teams describe the logic and hand all of it to the model. Split it instead. Reading and judgment can stay with the model. Rules, arithmetic and anything an auditor would ask about go into code that sits inside the workflow.
Line 3: Eval
How would you know the output is wrong? Name the check that runs on every output, not the test you ran once before launch. If you can't fill in this line, the workflow isn't ready for production.
Good evals are concrete: totals reconcile to the source, required fields are present, figures match the system of record, confidence is logged and low-confidence records go to a person. "Someone will review it" is only an eval if that person has the time and the criteria to catch a plausible error.
This is the gap we see most often, and it's the cheapest one to fix before launch. After launch, the missing eval shows up as a customer finding the mistake for you.
Line 4: Destination
Where does the result go, and who acts on it? An ERP, a queue, a deck, a report, a customer. The more consequential the destination, the stronger the check in front of it needs to be.
A draft that a person edits before sending can tolerate more error than a record posted straight to the ledger. Name the destination and the person who acts on it, and you'll know how much checking the line above it needs.
A worked example
Here is the test filled in for an accounts payable workflow that matches vendor invoices to purchase orders. The model owns only the first line. Code owns the logic and the eval, and a person handles exceptions.
The one question to ask of every line
Would a wrong answer here look exactly like a right one? If yes, that step belongs in code or behind a check. If no, the model can own it, because people will catch visible errors before they spread.
A garbled extraction from a scanned invoice usually looks garbled. Someone notices. A match that's off by one line item, posted with confidence, looks like every other match. Nobody notices until the month-end close doesn't tie out. The test is designed to find the second kind of step before it ships.
Run the test on one workflow this week. If you want the reasoning behind it, read Why AI Agents Fail in Production, and if your plan includes retrieval, check Do You Need RAG? first.