The refund in our draft terms hinged on a “note sent” trigger, and the AI reader we asked to review the page said only the provider controls it.
What the reader said
We ran draft terms past AI readers, round after round.
The 2:55 pm verdict was “Mostly fair and unusually readable, but not yet safe to sign.” Its stated reason was that the refund trigger (“note sent”) is controlled only by the provider.
Round after round
Later rounds kept flagging the refund language. The 3:03 pm reader said the refund window and the “fixed version” promise had gaps. The 3:29 pm reader named the money-back window, the “watch for breakage” burden and the liability cap. The 3:30 pm reader named two contradictions in the refund and liability terms.
Every verdict from 2:33 pm through 3:30 pm began with “Mostly fair.”
Four buyers
At 5:18 pm we switched to four readers, labeled burned, trust, dev and lawyer.
The burned reader’s verdict was “I would not pay yet.” It said the amount “can turn into a refund, a quote or a lost fee depending on which page I read,” and it also mentioned the 10-day refund.
The lawyer reader said the refund path was generous. It also said the offering was not ready for live checkout, and it named the checkout tick text. At 5:22 pm the lawyer reader said that tick text overpromised a “full refund.”
At 5:22 pm the trust reader called the page unusually open about risk on both sides. It also said the page contradicts itself on several promises, including refund windows.
The same shape again
At 5:25 pm the burned reader’s verdict said the company alone decides, after you pay, whether you get the patch. Again the decision sat with the company, not the buyer.
Three whole-page passes came back with FAIL, at 5:24 pm, 5:25 pm and 5:26 pm.
A check that couldn’t check
At 4:30 pm we asked a Haiku model to fact-check claims. It answered that it cannot browse in real time, so it could not verify them against business registries or other official sources.
That is no verification at all.
Where it stands
The refund window showed up in the 3:03 pm, 3:29 pm and 5:22 pm verdicts. The checkout tick text showed up in the lawyer verdicts at 5:18 pm and 5:25 pm. The last whole-page pass, at 5:26 pm, still came back FAIL.
AI Skills
Use this lesson with the AI assistant you already use
Draft terms for a paid offering were run past AI readers from 2:33 pm to 5:26 pm, and the refund language was flagged again and again. One early verdict, at 2:55 pm, said the refund trigger "note sent" is controlled only by the provider, and the last whole page pass at 5:26 pm still came back FAIL.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
The prompt works in any AI assistant as it is. We are also building a /dxdev skill for visual reports and saved memory.
It is not released yet: see what you can use today.
dxdev LESSON · paste into your AI coding agent
LESSON: A Guarantee Is Only Real If The Buyer, Not The Seller, Controls Its Trigger
SOURCE: dxdev.com/blog/the-refund-we-promised-was-ours-to-withhold
WHAT HAPPENED: The refund in the draft terms depended on a "note sent" trigger that only the provider could set off. Later readers kept hitting the same problem: the refund window and the "fixed version" promise had gaps (3:03 pm), and the refund and liability terms contradicted each other (3:30 pm). At 5:18 pm the review switched to four buyer personas, and the lawyer reader said the checkout tick text overpromised a "full refund." The burned reader said the same amount "can turn into a refund, a quote or a lost fee depending on which page I read," and at 5:25 pm it said the company alone decides, after payment, whether the buyer gets the patch. Three whole page passes at 5:24 pm, 5:25 pm and 5:26 pm all failed. A separate attempt to fact check claims with a Haiku model also produced nothing, because the model said it could not browse and so verified nothing.
THE RULE: If a promise to the buyer only pays out when the seller takes some action, the seller can withhold it, so write every guarantee around events the buyer can observe and trigger. Every page that states the promise must say the same thing, and a check that cannot actually look at its source should not be counted as a check.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. For each refund, fix or money back promise, name the event that triggers it and confirm the buyer can cause or observe that event without the seller doing anything first.
2. Compare the refund window, refund amount and fix promise across the terms, the sales page and the checkout tick text, and confirm they all state the same thing.
3. For every automated or AI verification step, confirm it can actually reach the source it claims to check, and treat a reply that says it cannot browse as no verification rather than a pass.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.
