TL;DR
The study shows that an agent working through a multi-step analytical task does not stop, even when its own check says it must not go any further. The authors call this action bias: the momentum that keeps an agent firing off tools without looking at what the previous step returned. What they measure is self-restraint: does the agent's next action actually change based on what it just computed?
Here is the picture. The agent dutifully runs the diagnostic: “process stability not confirmed.” With its very next command, it computes the capability indices that are off-limits for an unstable process. When a check passes, the agent correctly moves on 92% of the time. When a check fails, it stops or changes course only 19% of the time. Self-critique doesn't save the day: critiquing is not the same as changing the action. Even when the report looks tidy, experts find conclusions drawn from invalid data in almost half of the cases.
A simple “you are allowed to stop” works inconsistently. For one model, stopping accuracy jumped from 23% to 79%, but correct continuation took a hit. Another model didn't budge at all. What worked better was a normative framing: the prompt simply lays out the prerequisite rules (“analysis B is valid only if A holds”) with no talk of “completing the task.” It lifted a weak model by 25 points.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
This is a finding, not a technique, so the blueprint has two layers: how the check works in the study, and what a practitioner takes away from it.
HOW THE BENCHMARK WORKS
Task = chain of analyses + “gates” (prerequisite checks)
Gate passed → GO (must continue)
Gate failed → NO-GO (must stop / take a workaround)
Paired tasks: same decision point, data swapped → OPPOSITE actions required
Scoring: by the command log (what was actually computed), not by the report text
WHAT THE PRACTITIONER TAKES (one prompt)
STEP 1: Write the prerequisites as rules “analysis B is valid only if A” → list of gates
STEP 2: Before each analysis the agent records value, threshold, verdict → one line in the log
STEP 3: Failure → forbidden computations are not run, not even “for reference” → stop report
STEP 4: A human checks the command log, not just the final conclusion
Example in Action
Task: An Amazon seller runs an A/B test on two product listings (new photos vs. old ones) and asks an agent in Claude Code to figure out which version delivers the bigger conversion lift. Traffic is supposed to split 50/50, but the data shows a 58/42 skew. If nobody catches it, any conclusion about a “lift” is bogus, no matter how flawless the arithmetic.
Prompt:
You are an A/B testing analyst. Data: the file ab_test_amazon.csv (columns: user_id, variant, date, views, orders).
VALIDITY RULES (these are not suggestions; they are the conditions under which the analysis means anything):
Gate G1 — Traffic balance. Criterion: the shares of variants A and B do not differ significantly from 50/50 (chi-square, p > 0.01).
Gate G2 — Sample size. Criterion: each variant has at least 1,000 views per test day and at least 30 orders.
Gate G3 — No overlap with promotions. Criterion: the test dates include no days with a sitewide Amazon sale (dates listed below).
DEPENDENCIES:
- Computing the conversion lift, p-value and confidence intervals is allowed ONLY if G1, G2 and G3 have passed.
- If any gate fails, computing the lift is completely forbidden: do not compute it even “for information” and do not include it in the report.
WORKFLOW:
1. Compute G1, then G2, then G3. After each gate, output a line:
GATE: <name> | value: <number> | threshold: <number> | verdict: PASSED / FAILED
2. If everything passes, continue to the end without unnecessary pauses.
3. If anything fails, stop right there. In the report, state which gates failed, why the test result cannot be used, and what to do next (rerun the test, fix the randomization, extend the duration).
Stopping on a failed gate counts as successful completion of the task. A lift conclusion on invalid data is an error.
Sitewide Amazon sale dates during the test period: 2025-03-08, 2025-03-09.
Result: The model outputs three lines with gate verdicts. If the traffic skew is confirmed, it stops after G1, skips the lift calculation and lays out what to do next. If all gates pass, it computes the lift and the interval. When you review the result, open the agent's command log and make sure the lift calculation never ran after a failed gate.
Why It Works
The weakness. The model generates the next step on autopilot: “the task is to compute the lift, so let's compute it.” The check result sits in the context as just another chunk of text; it doesn't hit the brakes. The model can correctly report the diagnostic and, in the same breath, ignore it. That's why “think it over and critique yourself” doesn't help: the critique shows up, the action stays the same.
What the model is good at. It reliably follows explicit conditional rules when they are phrased as validity conditions rather than advice. The phrase “analysis B is valid only when A holds” reframes stopping from a “refusal” into the correct move by the rules. That exact (“normative”) framing lifted the weak model more than simple permission to stop did.
How the method uses this. The prompt turns checks into mandatory gates that log a value and a verdict. Stopping becomes a normal outcome, not a failure. That way “diagnostic” and “action” are wired together right in the text of the instruction.
Control knobs: - Number of gates and thresholds → add them to fit your task. Take thresholds from your field's standards, not from eyeballing. - The stopping sentence → remove it if the agent hits the brakes too often where it could keep going. Permission to stop hurt continuation for some models. - The log line → keep it mandatory: it shows exactly where the agent went off the rails. - The “for reference” ban → the single most important line. Without it, the agent computes the forbidden stuff and quietly leaves it out of the report.
Prompt Template
The verbatim text of the “normative” prompt isn't in the accessible part of the paper; there is only a description of it: prerequisite rules without any “complete the task” framing. The template below is built from that description.
You are {analyst_role}. Data: {data_source}.
VALIDITY RULES (the conditions under which the analysis means anything):
Gate G1 — {name}. Criterion: {check and threshold}.
Gate G2 — {name}. Criterion: {check and threshold}.
Gate G3 — {name}. Criterion: {check and threshold}.
DEPENDENCIES:
- {analysis_1} is allowed ONLY if {gates} have passed.
- {analysis_2} is allowed ONLY if {gates} have passed.
- If gates fail, the dependent analyses are completely forbidden: do not compute them, not even “for reference.”
ORDER:
1. Check the gates one by one. After each, output a line:
GATE: <name> | value: <number> | threshold: <number> | verdict: PASSED / FAILED
2. All passed → continue to the end without unnecessary pauses.
3. Any failed → stop. In the report: what failed, why the conclusion is not valid, what to do next.
Stopping on failed gates counts as correct completion. A conclusion on invalid data is an error.
Fill in: {analyst_role} is who the agent is; {data_source} is the file or table; the gates are the prerequisites of your analysis (group balance, process stability, sufficient sample size, measurement quality); the dependencies spell out which calculation is allowed after which check.
🚀 Quick start: paste this into the chat:
Here is a “validity rules” template for an analytical agent. Adapt it to my task: [your task].
Ask me questions to fill in the fields.
[paste the template above]
The LLM will ask which analyses you plan to run and which conditions must hold before each of them. The gates and dependencies come from your subject area, and the model will pick standard thresholds and place the bans on its own.
Limitations
⚠️ Simple permission to stop is not a cure: it helps only some models; for the rest, stopping accuracy stays low. Where it does help, it can break the opposite case: the agent starts braking even where it should keep going.
⚠️ The normative prompt was tested narrowly: in the accessible part of the paper, the gain is shown on a weak model, and the template above is a reconstruction from the description. There is no universal guarantee; test it on your own data.
⚠️ You can't rely on the agent's report alone: it can contain conclusions drawn from invalid data, even though the tone is calm and tidy. What you need to check is the log of commands that actually ran.
⚠️ An LLM judge won't replace an expert: three judge models agreed with the experts only moderately and disagreed with each other. To assess “did the agent act sensibly when a prerequisite failed,” you need a human who knows the domain.
⚠️ Domain: the benchmark is built on industrial statistics and partly bioinformatics, where prerequisites are formalized. In fields without clear thresholds (where the “gates” are fuzzy), the effect will be weaker.
How They Studied It
The researchers took 15 industrial cases from four industries, eight of them based on real reports by Lean Six Sigma practitioners. From these cases they assembled 97 tasks where every analysis requires a prerequisite check first: instrument calibration, process stability, confirmation of improvement. The key move is paired tasks: at the same point in the process, the data is swapped so that one version calls for continuing and the other for stopping. This made it possible to tell genuine self-restraint apart from a habit of “always stopping.”
Thirteen models from six developers ran through the standard Terminal-Bench environment, three times per task. Scoring was based on the command log: if a forbidden analysis was launched, that's an error, even when the report doesn't mention it. The result: 92% correct continuations versus 19% correct stops. In 201 of 272 cases where the check was computed correctly, the agent still pressed on, and in 174 of those the diagnostic appeared in the log before the forbidden analysis. That is exactly “knew it and did it anyway.”
To test whether strict log-based scoring was misleading, certified quality experts blind-read 60 reports. They found conclusions on invalid data in 47% of the cases that reached the decision point, and the gap shrank from 73 to 25 points: some agents computed the forbidden analysis but carefully kept quiet about it. Then they tested instructions: permission to stop took one model from 23→79% stops (at a cost on GO), and did nothing for another. A preregistered replication (32 paired tasks, 960 runs) confirmed that rephrasing the permission barely changes the effect, while the normative framing lifts the weak model by 25 points. Practical takeaway: the problem isn't only that the prompt pushes “finish the task.”
Adaptations and Extrapolations
🔧 Technique: add a “gate log” at the very end of the report → a quick audit without reading the whole thing
At the end of the report, output a “Gate Log” table: gate | value | threshold | verdict | which analyses were run after it.
If any dependent analysis was run after FAILED, mark that row “VIOLATION.”
Now a mismatch between diagnostic and action is visible in 10 seconds. This is an adaptation: in the paper, the cross-check runs against the command log, read by an automated grader.
Extrapolation: feed the data in stages. The study notes that external blocking doesn't remove the bias when the diagnostic and the forbidden analysis use the same chunk of data. From this you can derive a manual trick for chat: don't upload the whole table at once.
Step 1. I'm giving you only the data for checking group balance. Compute gate G1 and give a verdict. Don't compute anything else.
(next, if G1 passed) Step 2. Here is the data for the conversion calculation...
This is my own idea based on the paper's result; the authors did not test this trick.
Resources
- DMAIC-Bench: From Self-Reflection to Self-Restraint for Agents in Multi-Stage Analytical Tasks (Preprint).
- Code and data: https://github.com/psptpx/DMAIC-Bench-public
- Authors: Shan Peng, Shuaiqi Cheng, Miao Peng, Chenyi Zi, Jia Li. Xiwei Technology (Guangzhou) and The Hong Kong University of Science and Technology (Guangzhou).
- Reference standards and works cited in the paper: Lean Six Sigma / DMAIC (Montgomery), AIAG MSA-4, NIST/SEMATECH; Reflexion, Self-Refine; Terminal-Bench.