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 speccing by vibes.
The Idea
Every automation has the same five parts.
Something starts it. Each step pulls in data, transforms it, and takes an action, and the escalation catches whatever breaks. TRACE walks a process through those five parts and hands you a build spec at the end.
The middle is a chain. Every step in the chain is the same three moves, Retrieve, Apply, Commit, and the Commit of one step kicks off the Retrieve of the next.
Inside every step sits one question that decides the entire build: same input in, same output out, every time? If yes, that step is code. If no, that step gets AI. Run the question on every step and the spec writes itself.
Here is what that produces, for a five step process:
| Step | Retrieve | Apply | Code or AI | Commit | Risky | |
|---|---|---|---|---|---|---|
| 01 | Inquiry email arrives | Message: the inbox | None. The email is the trigger. | — | Hand the body to step 2 | N |
| 02 | Read the inquiry | Message: the email body | Pull dates, party size and room type out of free form text | AI | Save the parsed request | N |
| 03 | Check availability | Database: the property system | Query the dates. One right answer. | Code | Write the open rooms | N |
| 04 | Write the quote | Database: rate rules | Seasonal rate, then 15% off two plus nights | Code | Save the quote | N |
| 05 | Send the reply | Database: the quote and the template | Fill the template. 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 → add the already-done check
Five steps, exactly one of which needs AI, one action flagged as risky, and a rule written down where a judgment call used to hide. That is a build spec, and none of it required knowing which platform you were going to use. The rest of this module is how you fill that table in.
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 Booking Inquiries
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 inquiry 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 need the already-done check, 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.