AI advice becomes risky when it sounds confident but cannot show its evidence. The fix is not asking a smarter model the same loose question. The fix is forcing the work through evidence, critique, traceability, and a decision memo before anyone acts.<\/p>\n
The real decision is whether AI should be treated as a fast answer machine or as a reviewable decision system. For casual drafting, speed may be enough. For pricing, hiring, product, finance, strategy, compliance-sensitive messaging, technical changes, or customer-impacting actions, speed without traceability is a liability.<\/p>\n
Agentic AI makes this sharper because some systems can now coordinate steps, call tools, produce artifacts, and review parts of their own work. Anthropic’s Claude Science announcement<\/a> is a useful signal: it describes a scientific workbench where outputs can carry an auditable history, figures can be traced to code and environment, and a reviewer agent can check citations, calculations, untraceable numbers, and mismatches between figures and underlying code.<\/p>\n A business team does not need a scientific workbench to borrow the operating lesson. If an AI-supported recommendation cannot be traced back to documents, code, data, assumptions, or a named judgment call, it should not drive a serious decision. This is the practical edge of AI in Practice<\/a>: the model is useful only when the surrounding workflow makes the answer inspectable.<\/p>\n Most teams do not have an AI intelligence problem. They have an approval problem. They let a fluent answer move too close to action before anyone checks the evidence behind it.<\/p>\n This is the lowest-friction mode. A founder asks, Is this offer strong?<\/em> A marketer asks, Does this campaign make sense?<\/em> The AI often responds inside the user’s frame. It may improve the wording, organize the argument, and make the idea sound cleaner than it is.<\/p>\n Use agreement mode for brainstorming, first drafts, and low-stakes wording. Do not use it for decisions where the output might be acted on without a separate review.<\/p>\n Expert mode asks the model to respond as a strategist, CFO, CTO, analyst, or reviewer. This can improve structure and force a more useful lens. It still does not create evidence by itself.<\/p>\n The failure is subtle: the role sounds authoritative even when the inputs are thin. A costume is not a control. Use expert mode when you need better structure, not final approval.<\/p>\n Truth Mode changes the job. The model must separate facts from assumptions, challenge the user’s preferred answer, list failure modes, and produce a decision memo with a confidence level.<\/p>\n This is slower than a simple prompt. That is the point. Use Truth Mode when the cost of being confidently wrong is higher than the cost of review: money, customers, staff decisions, public claims, technical changes, or operational systems.<\/p>\n Use Truth Mode for any AI-supported recommendation that another person might act on without reading the raw inputs. That includes internal plans, executive summaries, customer-facing claims, campaign strategy, automation design, vendor comparisons, technical changes, and analysis from exported data.<\/p>\n The mechanism is simple: one answer is not enough. You want five jobs performed in sequence. First, the AI builds an evidence ledger. Second, it checks assumptions. Third, it argues against the recommendation. Fourth, it finds failure modes. Fifth, it writes a decision memo that separates what is known, what is inferred, and what still requires human judgment.<\/p>\n Use the prompt below as one block. It is for founders, operators, marketers, consultants, analysts, and technical leads reviewing a real business decision. Bring source documents, notes, meeting transcripts, campaign data, code snippets, customer feedback, CRM exports, or a proposal that needs pressure before approval. Do not paste confidential, regulated, or private customer data into any AI tool unless your company policy and permissions allow it. Minimize sensitive data, remove unnecessary identifiers, restrict access, and keep human approval for high-risk outputs.<\/p>\n <\/p>\n The expected output is not a prettier answer. It is a decision packet. A manager should be able to scan it and see where the recommendation stands, where it is weak, and what must be checked before action.<\/p>\n For example, imagine a team preparing to approve a new onboarding email sequence. In agreement mode, AI may improve the subject lines and explain why the flow is persuasive. In Truth Mode, it should check whether the sequence matches real customer objections, which claims are supported by product facts, where personalization could create risk, and what needs approval before sending. That changes the work from copy polishing to decision control.<\/p>\n The main risk with Truth Mode is that teams make it ceremonial. They paste a prompt, get a critical-looking answer, and treat that as governance. That is not enough. A review workflow only works if someone owns the inputs, someone checks the evidence, and someone has authority to stop the decision.<\/p>\n The second risk is over-correction. Some operators hear critique and assume every AI answer must become a courtroom process. That is wasteful. A low-stakes caption, rough outline, or internal draft does not need a decision memo. Truth Mode belongs where the output may trigger action, spend, public claims, customer impact, or technical change.<\/p>\n The third risk is data exposure. Evidence-led work often tempts teams to upload CRM exports, customer tickets, contracts, analytics, inbox threads, or internal documents. The operating rule is conservative: use the minimum data needed, strip sensitive identifiers when possible, restrict access, and follow company policy before using private material in any AI system. For automation and connected workflows, access control belongs inside Business Systems & Operations<\/a>, not just the prompt window.<\/p>\n The fourth risk is fake traceability. A model can produce references and confident labels that look like proof. The reviewer must still inspect whether the cited input actually supports the claim. If the evidence ledger points to a document but the document does not say what the memo claims, the workflow failed.<\/p>\n Use this checklist before approving any AI-supported recommendation that affects customers, money, systems, public claims, or staff decisions.<\/p>\n If three or more items fail, do not approve the decision from the AI output. Return to the inputs, narrow the decision, or ask a human domain owner to review the evidence.<\/p>\n Start with one live decision this week. Run the normal prompt first, then run Truth Mode against the same inputs and compare what changes. If the second answer exposes missing evidence, weak assumptions, or a better reason to pause, keep the workflow and assign an owner for it.<\/p>\n Before you bolt on another tool, it is worth knowing whether your business runs on systems or on you. I put together a free 2-minute assessment that gives you a straight read on exactly that, and the first thing to fix. Take the free assessment<\/a>.<\/p>\nThree operating modes<\/h2>\n
Agreement mode<\/h3>\n
Expert mode<\/h3>\n
Truth Mode<\/h3>\n
Use Truth Mode when<\/h2>\n
TRUTH MODE DECISION REVIEW
Role: You are a decision review system, not an agreement assistant. Your job is to protect the user from confident but weak recommendations.
Decision to review:
- [Describe the decision, recommendation, campaign, technical change, vendor choice, pricing move, hiring plan, or operational change.]
Available inputs:
- [Paste or summarize the approved documents, data, notes, code, customer feedback, assumptions, constraints, and source links available for this review.]
Business context:
- Company or team: [brief context]
- Goal: [what success means]
- Constraints: [budget, time, policy, people, technology, customer risk]
- Decision owner: [who approves]
- Deadline: [when a decision is needed]
Rules:
1. Do not flatter my preferred answer.
2. Separate evidence from interpretation.
3. If a claim is not supported by the inputs, label it as unsupported.
4. Trace important claims back to the document, data point, code section, or user-provided input where possible.
5. Do not invent statistics, customer proof, legal conclusions, technical guarantees, or financial outcomes.
6. Ask for missing inputs only if they are necessary for the decision. Otherwise proceed with clear caveats.
Step 1: Evidence ledger
Create a ledger with: claim, supporting input, strength of evidence, and what would make the claim stronger.
Step 2: Assumption check
List the assumptions behind the recommendation. Mark each as safe, uncertain, or dangerous. Explain why.
Step 3: Adversarial review
Argue against the recommendation as a skeptical operator. Identify the best reason not to proceed.
Step 4: Failure-mode finder
List the most likely ways this decision could fail in execution. Include operational, customer, technical, financial, and reputational risks where relevant.
Step 5: Decision memo
Write a final memo with these headings:
- Recommendation
- Confidence level: high, medium, or low
- What the evidence supports
- What remains unproven
- Risks to control before approval
- Decision owner's next action
- Human review required before action: yes or no, with reason
Quality check before final answer:
Review your own memo and flag any sentence that sounds more certain than the evidence allows.<\/code><\/pre>\nRisks to control<\/h2>\n
Approval checklist<\/h2>\n
\n
\nWhere does your business actually stand?<\/h3>\n