Framework 04
The TRACE Method
Walk a process through the five parts of an automation and come out holding a build spec: what is code, what is AI, and what happens when it breaks.
The Problem
You’ve picked a process to automate. Now what? Most people jump straight to tooling: which platform, which model, which vendor. The build starts with a subscription instead of a spec, and three weeks in nobody can say what the automation is actually supposed to do when the input is weird or a system is down.
The other failure is quieter. Automation splits into two kinds of work. Deterministic, where the same input always produces the same output and regular software is the right tool. And probabilistic, where the step involves interpretation or open ended output and AI is the right tool. Most builds pick one hammer for the whole process. They bolt AI onto steps a script would do better, cheaper and more reliably, or they try to hard-code judgment calls that no rule can capture. Either way the automation is more expensive and less reliable than it should be.
Without a method, you’re guessing.
The Idea
Every process has the same five.
Something starts it, information gets gathered, that information is read to decide what to do, and then an action is taken. Then if done properly, someone reviews it to ensure it was done correctly.
Every automation has the same five.
Something starts it. Each step pulls the data it needs, works out what to do with it, and takes an action. When a step breaks, the escalation catches it.
A process and an automation have the same shape, so one can be traced onto the other. That is the whole method. Here is what it looks like for a simple customer experience process:
| Step | Retrieve | Apply | Code or AI | Commit | Risky | |
|---|---|---|---|---|---|---|
| 01 | Customer sends a question | Message: the inbox | None. The email is the trigger. | — | Hand the body to step 2 | N |
| 02 | Someone reads it | Message: the email body | Work out what is being asked out of free form text | AI | Save the question and its topic | N |
| 03 | Looks up the answer | Database: the answer library | Pull the entry for that topic. One right answer. | Code | Write the matched entry | N |
| 04 | Writes a reply | Database: the entry and the reply template | Drop the entry into the template. Fixed rule, fixed result. | Code | Save the draft reply | N |
| 05 | Sends the reply | Database: the draft and the sender address | Address it to whoever asked. Fixed rule, fixed result. | Code | Send the email | Y |
The fork
Same input, same output, every time → Code
Messy input or fresh output → AI
A Commit that touches money or customers → ensure it is reviewed by a human
What started out as a slow, repetitive job is now a streamlined automation, and it does the most valuable thing an automation can do. It gives you your time back.
How It Works
Step 1: Break Down the Process
Name the process, then write down what happens today, start to finish, as a numbered list. Don’t automate anything yet. Just get the sequence on paper. If a person does it now, it’s a step. Each step is one action; if you need the word “and” to describe it, split it into two.
Process
Answer Customer Questions
The list is the spec’s skeleton. Everything else hangs on it.
Step 2: T, Determine the Trigger
Look at your first step and ask: what kicks off this process? There are only three answers:
- Event: something notifies you, like a webhook firing or an email arriving.
- Schedule: the automation runs at a specific time, every few minutes or at a set time each day.
- Manual: a person presses a button.
A webhook fires, an email arrives, a file lands. The cleanest trigger when the upstream system offers it.
Runs every few minutes, every hour, or at a set time each day. The fallback when nothing upstream can notify you.
A human decides when it runs. Fine for rare or sensitive processes that shouldn’t fire on their own.
The upstream system usually dictates the answer. If the vendor can notify you, use the event. If they just drop files in a folder, you run on a schedule.
Step 3: E, Determine the Escalation
Before building anything, decide what happens when it breaks. For each step there are three answers:
- Retry: try again automatically, for flaky things that usually work the second time.
- Skip and log: move on but keep a record, for low stakes failures.
- Stop and alert: halt and tell a human, for anything that can’t be wrong quietly.
For flaky things that usually work on the second try, like an API that timed out.
For low stakes failures where one missed run doesn’t matter, as long as someone can see it later.
For anything that can’t be wrong quietly. The automation stops and a person gets pinged.
Anything touching money or customers stops loudly and goes to a person.
The rule of thumb: anything touching money or customers stops loudly and goes to a person. This is your safety net, and you hang it before anyone gets on the trapeze.
Step 4: Run RAC on Each Step
Now go through your list from Step 1, one step at a time, and answer three questions: where does the data come from, what transformation happens, and what action is taken?
The Commit of one step kicks off the Retrieve of the next.
4a. Retrieve: where does the data come from? Every step starts with some piece of information. Name where it lives and how the automation will get to it. Nothing gets decided here; this is just collecting what the step needs.
Info from a local folder, an email attachment, or an upload.
Records the business already keeps: bookings, customers, orders, inventory.
Info pulled from another company’s system, like a booking platform or a payment provider.
Words written by a person: an email, a chat message, a filled out form.
4b. Apply: what transformation happens? This is what determines whether the step is done by regular software or artificial intelligence. Every Apply gets asked the same question: same input in, same output out, every time? If the rule is written down and there’s one right answer, the step is deterministic and it’s code. If the step reads messy input or writes fresh output, it’s probabilistic and it gets AI.
Yes: the rule is written down and there’s one right answer
No: it reads messy input or writes fresh output
Retrieve and Commit are mechanical: no transformation happens in them. The fuzziness can sit at either end. Reading a free form email is probabilistic, and so is writing a fresh reply, even when a fixed rule sits in between. Generative output after a deterministic rule is still AI.
4c. Commit: what action is taken? Something gets written, sent, or updated, and that result kicks off the next step. If the action sends money or reaches a customer, add a check before it fires: has this already been done? That way the same question is never answered twice and the same invoice is never paid twice.
Set a status, save a row, mark it handled. Low risk, easy to undo.
An email, a message, an invoice. A customer sees this, so a wrong one costs trust.
A payment, a refund, an order. The actions that hurt most if they happen twice.
If an action sends money or reaches a customer, check first: has this already been done? That way it can never happen twice.
By the end you have a build spec: one trigger, a chain of steps, exactly which steps get AI, which actions can only be allowed to happen once, and a failure answer for every step.
- 01
One trigger at the front, dictated by the upstream system
Trigger Set
- 02
The process as a chain of steps, each one Retrieve, Apply, Commit
Steps Mapped
- 03
Every Apply sorted: written rule or judgment call
Code vs AI
- 04
Risky Commits flagged so they can never run twice
Commits Hardened
- 05
A failure answer for every step: retry, log, or alert
Errors Captured
Most processes need AI in one or two steps, if at all. TRACE tells you which ones.
Get the Worksheet
The TRACE worksheet is a twelve page PDF. Nine instruction pages walk through the five parts and the fork, then two worksheets do the work: page ten frames the process, with the trigger, the escalation, and the steps as they run today, and page eleven is the RAC table, one row per step. Fill both and you are holding a build spec. It’s free.
Download the worksheet
The TRACE Method
- Nine instruction pages, one per part of the method
- Two blank worksheets: frame the process, then RAC every step
- Where TRACE hands off next
PDF · 12 pages · Free
Working on something like this?
I build full stack AI systems for companies that want to improve how they work or do things that were not possible before. If you are working on this kind of problem, message me on LinkedIn or shoot me an email.
Where It Fits
The TRACE Method is the build layer of the stack. The Business System Blueprint makes the business visible. The Process Map prices every process and ranks the automations. The Process Proposal gets the top automation a yes. TRACE turns that yes into a build spec: what’s code, what’s AI, and what happens when it breaks.
Each tool stands on its own. If you already know what you’re automating, start here.