A business process automation example, shown as the 14-entry decision log one Monday run writes to disk.
Every SERP result draws BPA as a four-box pipeline. Receive, validate, match, pay. A clean left-to-right arrow with no pauses and no questions. Real automations fork. The forks are the story.
This page shows one real Monday 08:00 invoicing ritual across 8 consulting clients. It runs 7 minutes 41 seconds. It writes 14 lines to a markdown file at ~/.clone/memory/logs/. Three of those lines are operator questions. One is a deliberate skip. Seven are staged invoice drafts. The log is the uncopyable artifact.
The diagram every article draws.
Open the top five search results for “business process automation example”. Every one of them shows a pipeline that looks like this: boxes connected by arrows, left to right, with no branches.
This is a useful abstraction. It is also a lie. A real invoicing run for a consulting business has a client with zero hours, a client on a sub-project with no defined rate, a client using Google Sheets instead of QuickBooks, and a running variance against last week that you would like to eyeball before anything ships. The pipeline diagram has no vocabulary for any of these moments.
Happy-path diagram vs. real decision log
The top 5 articles all draw the same four-box diagram. Receive. Validate. Match. Pay. A clean left-to-right pipeline, no pauses, no questions, no edge cases.
- No branch where hours are missing
- No branch where a rate is undefined
- No operator intervention, ever
- No artifact you can read after the run
The anchor fact: a file on disk.
For every ritual run, Clone writes a markdown file to ~/.clone/memory/logs/. The filename is the date and the ritual name. The contents are one line per branch point, timestamped to the second. Every read, decide, fork, ask, reply, skip, draft, and write is a line you can grep.
anchor fact
One Monday 08:00 invoicing run across 8 clients produces a 14-entry markdown log at ~/.clone/memory/logs/2026-04-20-invoicing.md. Three of those entries are operator-intervention pairs. One is a skip. Seven are staged drafts. The file is the uncopyable part of the workflow.
What each kind of line means.
The log grammar is small on purpose. Eight verbs cover every line any ritual will ever write. You do not need a dashboard to understand a run. You need to read the file.
read lines
Everything the ritual observed before making any decision. Timely hours, rate map entries, apps_this_month mapping. These are the inputs.
decide lines
Automatic decisions Clone made without asking. One per client per branch that the rule map could resolve on its own.
fork lines
Points where Clone could not resolve the decision itself. A fork line is always paired with a following ask line.
ask + reply pairs
The human-in-the-loop moments. The operator sees the question in chat, types a short answer, and Clone records both. Three pairs this run.
skip lines
A deferred client. The skip is written with its next_run date so a future grep can surface everyone who got deferred.
draft + write lines
Outputs. Each draft captures the draft_id inside the vendor tool (QuickBooks draft, Clio bill, Gmail draft). The final write posts links to chat.
What the run produced.
Total wall-clock time from the first read at 0:00:02 to the last chat post at 08:07:41: 7 minutes 39 seconds. Of that, about 80 seconds is Clone driving vendor apps (opening QuickBooks, typing line items, saving drafts). The remainder is the operator reading the asks and typing a reply.
The operator's view: chat transcript.
While the decision log is written to disk, the operator sees a pared-down version in Clone's chat window. The info lines surface asks, the command lines are the operator's typed replies, the success lines confirm each draft. Nothing ships without a final “yes”.
Eight clients, one ritual, eight outcomes.
The ritual fans out across the 8 clients in scope, touches whichever invoicing app each one uses this month, and returns either a draft_id or a deferred line. One client (nexora) ends up on the right side of this diagram as “deferred” because the operator chose to skip rather than draft a zero-dollar note.
monday 08:00 invoicing fan-out
Zoom in on one fork: the nexora skip.
The richest moment of the run is the 19 seconds between Clone noticing nexora has zero hours and the operator typing “skip nexora” in chat. Six internal stages. One decision. Two log lines.
fork + ask + reply, six stages
read timely
hours for nexora since last monday
detect zero
0h, last_seen 11 days ago
write fork
new log line: fork nexora
ask operator
chat question with the two defaults
wait reply
no timeout, ritual holds
log decision
reply appended to log, run continues
nexora fork, actor sequence
The full timeline in order.
Every log entry has a timestamp. Read the run in order and the rhythm is: two clean drafts, a fork, a reply, another decision, another clean draft, another fork. Happy paths and branches alternate the whole way through.
08:00:02 read ritual
Planner loads memory/rituals/invoicing.md and the rate map.
08:00:11 decide acme
apps_this_month map says quickbooks_desktop. Open QB, find client ledger.
08:00:47 draft acme
Invoice #2041 drafted. 12.0h at $225. draft_id captured.
08:01:14 decide holloway
apps_this_month says clio, matter #241. Open Clio bills tab.
08:02:21 fork nexora
Timely reports 0 hours this week for nexora. Operator decision required.
08:02:22 ask operator
“nexora has 0 hours this week. skip, or draft a $0 status note?”
08:02:41 reply operator
skip nexora
08:02:43 decide mckinsey
No QB connection, no Clio. Fallback to google_sheets invoice template.
08:03:51 fork baymont
rate_map is missing a price for a newly added sub-project. Operator resolves.
08:03:52 ask operator
“baymont has phase_2 hours at no rate. use default $225 or quote new?”
08:04:09 reply operator
use default
08:04:41 draft kaplan, vecturo, orion
Three happy-path drafts across FreshBooks, QuickBooks, Clio.
08:06:22 fork total
Variance vs last week flagged. Operator confirms before chat post.
08:06:23 ask operator
“7 drafts ready. post links to chat? (yes/review)”
08:07:38 reply operator
yes
08:07:41 write chat
7 draft links posted, 1 skip summary, deferred list saved for next week.
“I thought I wanted a dashboard. What I actually wanted was a file I could grep. The decision log replaced three tabs in my browser.”
Early Clone operator, year-4 solo consultant
Clone decision log vs. a vendor run history
Zapier, Make, and most workflow tools give you a dashboard row per execution. Clone gives you a markdown file with one line per branch.
| Feature | Zapier-style history | Clone |
|---|---|---|
| Per-run visibility | Dashboard row with success or fail | Markdown file with one line per branch, read in any editor |
| How to handle a fork | Pre-configure a branch step in the visual builder | Clone pauses, asks in chat, appends the reply to the log |
| Deferred work | Failed step, usually marked red | skip line with next_run date, tracked as first-class state |
| Audit trail | Proprietary run history inside the vendor UI | Plain markdown in ~/.clone/memory/logs/, git-committable |
| Replay a past run | Re-trigger the Zap, hope the inputs are the same | cat the log, read what happened, re-run from any branch point |
| Bulk grep across history | Not possible; export CSV and filter in a spreadsheet | grep skipped ~/.clone/memory/logs/*.md |
Why a log file beats a dashboard.
A dashboard is read-only and vendor-owned. A log is grep-able, diff-able, and lives in a folder you control. A few things this unlocks over time.
- History audit.
grep skipped ~/.clone/memory/logs/*.mdreturns every client you deferred across every ritual, ever. Who did you skip six weeks ago? One command. - Week-over-week diff.
diff 2026-04-13-invoicing.md 2026-04-20-invoicing.mdshows which clients moved apps, which hours changed, which forks are new this week. - Replay from a branch point. Every draft line carries a draft_id. If you decide you do want to invoice nexora after all, you pass the fork timestamp to Clone and it picks up the run from that line forward.
- Private git history. Put
~/.clone/memory/in a private repo. One commit per Monday. A year later, you have 52 log files and a full audit trail of every decision your automations asked you to make.
“The day I realized the log was the product, not the automation, was the day I stopped opening Zapier. I want to read what happened, not watch a green check mark flash.”
Bring one recurring ritual. Leave with a log file.
On a 30-minute call we pick one recurring automation you run today (invoicing, onboarding, status, closeout) and write the ritual live. By the end of the call, Clone has produced the first log file for that ritual on your Mac. You keep the file.
Book a 30-minute callA 14-entry decision log on your disk. We open yours together.
Twenty minutes together. We run one Monday ritual and read the ~/.clone/logs/ file it writes, entry by entry, so you see the mechanism.
Frequently asked questions
Where exactly does Clone save the decision log?
Under ~/.clone/memory/logs/, one file per ritual run, named YYYY-MM-DD-<ritual-name>.md. The Monday invoicing ritual on 2026-04-20 writes to memory/logs/2026-04-20-invoicing.md. It is plain markdown. You open it in any editor, grep it from the terminal, and commit it to a private git repo if you want a cross-week history.
Why 14 entries for an 8-client ritual? Shouldn't it be 8?
8 clients produce 8 decisions, but not all are clean happy paths. This run has 1 read line (what Timely returned), 8 client decisions (7 drafted, 1 skipped), 3 operator-intervention pairs (one for missing hours, one for a missing rate, one for the final chat post confirmation), and 1 final write line. 1 + 8 + 3 + 1 plus the fork line that preceded each ask. The total comes to 14 visible lines in the example log shown on this page. Every one of them is a thing you could grep for later.
What is the difference between a 'fork' line and an 'ask' line?
A fork line is Clone saying 'I hit a decision I cannot make alone.' An ask line is the chat message to the operator. Fork logs the state of the branch (e.g., nexora has 0 hours). Ask logs the question posed. They are separate because you might want to grep every fork that required operator input versus every question ever asked.
What happens if the operator ignores the ask line?
The ritual holds. There is no timeout. The entire run pauses at the fork waiting for a reply. This is intentional. An ignored ask will not silently skip the client or silently auto-decide. When the operator eventually replies (5 minutes or 5 hours later), the ritual picks up from the fork and continues. The timestamp gap is visible in the log.
Can I replay a past run from the log?
Yes. Every draft line records the draft_id of the artifact it created (qbo_9f2a, clio_a81b, fb_318, sheet_row_44). Clone can re-read the log, verify the drafts still exist in the vendor tools, and either skip the ones that shipped or redo the ones that were discarded. The log is the source of truth for 'what did Monday actually do.'
How does this compare to Zapier's run history?
Zapier's run history is a dashboard row per execution: green for success, red for fail. It captures start time, end time, and the output of each step. It does not capture operator decisions, because Zapier does not pause for them. Clone's log is shaped around the forks, not the success path. The skipped, the asked, and the deferred are first-class lines.
Does the log contain sensitive client data?
The log contains client names, hours, invoice numbers, draft IDs, and rate decisions. It does not contain full invoice PDFs, payment details, or bank information. If you commit the log to a git repo, it should be a private one. The log's job is to be a running record, not a production artifact.
What if two rituals run back-to-back on the same Monday?
Each ritual writes to its own log file. memory/logs/2026-04-20-invoicing.md is the 08:00 run. If you also have a Monday 08:15 status-update ritual, that writes to memory/logs/2026-04-20-status.md. Grep across both with a glob pattern: memory/logs/2026-04-20-*.md gives you your whole Monday.
Can I turn off the operator asks and have Clone auto-decide every fork?
Yes, but you have to explicitly set defaults in the ritual file for every branch that could arise. For the invoicing ritual, that means a zero-hours default ('skip' or 'status_note') and a missing-rate default ('use_default' or 'quote_new'). Once those are set, Clone stops asking and records the default taken. The operator-in-the-loop behavior is opt-out, not opt-in.
Is this specific to invoicing, or does every ritual produce a log?
Every ritual produces one. The shape is the same: read, decide, fork, ask, reply, skip, draft, write. A Friday 16:00 status ritual writes a status log with the same grammar. A quarterly tax ritual writes a tax log. If you run 30 rituals a month, you get 30 log files, all in the same shape, all grep-able with the same patterns.
One BPA example, 14 log lines, $49/mo. The file lives on your Mac, not in a vendor dashboard.
Book a call