Your support automation closes forty tickets today. Zero errors. The dashboard is green top to bottom. You glance at it once during lunch, see no red, and go back to actual work.
Two weeks later, a customer forwards you one of the “resolved” tickets. The refund had processed. The dollar amount was right. But the message that went out reads like it was written by someone who’d never spoken to a human being: clipped, robotic, closing with “Your request has been processed. Have a nice day.” To a customer who’d just described losing a family photo when your product corrupted their file.
Nothing broke. Nothing errored. The green checkmark was telling the truth the whole time. It just wasn’t asking the question that actually mattered.
A green checkmark only proves the code ran without crashing. It’s telling you the plumbing worked, not that the water coming out of it is safe to drink. Most automations bundle several different outcomes into one pass or fail. Some of those outcomes are plain facts a computer can check in a fraction of a second: did the status change, did the number match. Others are judgment calls no true-or-false check can capture: does this read as caring, does this sound like a business you’d trust. When you check the whole bundle with one glance, the fact-based parts pass, and they drag the judgment-call parts across the finish line with them, unchecked.
The Fix: The Confidence Audit Prompt
You don’t need to rebuild the automation from scratch. You need to make it confess, in writing, which parts of “it worked” it can actually prove and which parts it’s just assuming. This prompt takes an automation you’ve already built, or are about to ship, and pulls every outcome apart into its own claim, each with its own verification method, so a judgment call can’t hide behind a fact’s checkmark.
How to Use It
Copy the prompt block below.
Paste it into your AI assistant (ChatGPT, Claude, etc.).
Describe the automation as it currently runs, including however you currently confirm it “worked.”
Let it split every outcome apart and assign each one an honest verification method.
You are a Confidence Auditor. Your job is to find every place I’m trusting a judgment call because a fact-based check happened to pass at the same time.
I will describe an automation or AI workflow I’ve already built, along with however I currently confirm it “worked.” Do not assume my current check is sufficient. Interview me instead.
List Every Outcome: Break down everything this automation is supposed to produce or change, not just the main one. Include side effects like messages sent, records updated, or notifications triggered.
Split Bundled Outcomes: If one “it worked” check is actually covering multiple outcomes, separate them into individual claims. Do not let a fact-based outcome (like a status change) vouch for a judgment-based outcome (like tone or quality) riding along with it.
Assign a Verification Method to Each Claim, using:
System Check: A strict, definitive check a computer can run (e.g., “record status equals ‘Closed’”).
AI Judgment: The outcome requires interpretation and should be scored by review, not assumed.
Human Eyes: A person must actually look at this before it counts as done.
Flag Any Outcome Currently Being “Checked” by a glance, a vibe, or the absence of an error message. Name it explicitly as unverified.
Do not close the interview until every outcome has an honest verification method attached, even if that method is “nobody’s checking this yet.”
The Plain-English Translation
If you’re wondering how this connects to what we cover more technically over at The Expression Layer: this is the same idea behind Grader Types from last time, taken one level deeper. Instead of assigning one verification method to a whole scenario, you assign one to every individual outcome inside it. A single automation might produce three outcomes that each deserve a different confidence level: one checked by code, one checked by a model, one that still needs a human. Bundling them into a single green checkmark is exactly the mistake this deeper split exists to catch.
Why This Works
What you used to trust: “No errors, dashboard’s green, must be fine.” What the Confidence Audit forces you to say: Outcome 1, status changed to Closed, System Check, passing. Outcome 2, tone of the closing message, AI Judgment, never actually scored. Why it prevents failure: Separates the fact you verified from the judgment call you assumed. One can no longer vouch for the other.
What you used to trust: “I read a few of them and they looked okay.” What the Confidence Audit forces you to say: Human Eyes assigned deliberately to the outcomes that actually need it, tracked as a real step, not a habit. Why it prevents failure: Turns an accidental spot-check into a verification step you can point to and repeat.
The Bottom Line
“It ran” is a fact about your code. “It worked” is a claim about your business, and it usually has more than one part hiding inside it. Split the claim before you trust the checkmark, and you’ll catch the version of “almost working” that never throws an error at all.
If you would like a Skill version of this, share and comment, and I’ll add it to the backlog of Skills I’m working on.