Introduction

This book explains what dont is, why it exists, and where the authoritative project sources live.

dont is a proposed command-line tool for autonomous LLM harnesses.

Its job is narrow and opinionated: stop an agent from turning ungrounded text into asserted project truth.

In the surrounding tool ecology (these auxiliary tracking tools are used in this repo, but aren’t prerequisites for understanding dont):

• wai helps track workflow and design intent
• bd tracks concrete work
• dont governs epistemic discipline

This book is the reader-friendly front door for the project. It does not replace the fuller OpenSpec decomposition or the archived monolithic draft in wai research. Instead, it explains the problem the tool is meant to solve and points to the deeper source material in the repository, especially the tracked research notes under .wai/projects/dont/research/. These notes are part of the project’s workflow and research record managed with wai.

Read this book if you want to know

• what dont is for
• why ordinary “please double-check yourself” prompting is not enough
• how the project’s research maps onto the proposed tool

Key sources

(Note: External links point to the main branch of the repository.)

• OpenSpec change specs (openspec/changes/*/specs/)
• Research: forcing doubt in minds and machines
• Research: designing doubt into AI interaction
• Repository README

Why dont exists

The problem

Large language models are good at producing fluent answers, but fluency is not the same thing as epistemic discipline.

Once a model has started down a line of reasoning, it often tends to elaborate on that line instead of questioning it. In practice, this means an autonomous agent can:

• state a claim too early
• defend the claim after weak checking
• fold the claim into project memory or downstream actions
• create a trail of confident but poorly grounded work

The core idea behind dont is that this failure mode should not be handled as a style problem. It should be handled as a tooling problem.

The research-backed claim

Takeaway: Asking an LLM to reconsider is usually weaker than forcing it through an external verification path.

The research corpus in this repository points to a consistent conclusion:

1. LLMs do not reliably self-correct just because they are asked to reconsider.
2. Better results usually come from external checks such as retrieval, tests, verifiers, or independent critics.
3. Durable human institutions solve similar problems by separating assertion from evaluation.

So the design stance of dont is simple:

Do not let an agent assert what it has not yet grounded.

What dont does

Takeaway: dont turns epistemic caution into explicit tool-mediated state transitions.

dont is a forcing function for autonomous LLM harnesses.

It gives the model a mechanical path between “I want to say this” and “this is now grounded enough to keep.”

Instead of letting every plausible sentence become accepted project state, dont introduces explicit transitions such as:

• conclude a claim
• define a term
• trust with a reason
• dismiss with evidence
• move entities through statuses like unverified, doubted, verified, or locked

The point is not to make the model sound cautious. The point is to make the workflow itself require justification.

Why a tool instead of a prompt

Prompting alone is weak because the same model that produced the claim is often asked to judge its own claim in the same context.

The draft spec and research notes both argue for the opposite pattern:

• make claims explicit
• record state changes
• surface unmet conditions as actionable refusals
• use fresh-context verification paths when independence matters

That is why dont is proposed as a peer CLI tool, not just a prompt template.

The role of dont in a harness

These companion tools reflect the surrounding workflow used in this repository; they are helpful context, not prerequisites for understanding dont.

A harness can use three different kinds of support:

• memory tools to remember what happened
• workflow tools to know what stage of work is happening
• epistemic tools to control what is allowed to count as grounded

dont is the third category.

It is meant to sit beside workflow and memory tools, but remain independent from them. Its concern is narrower: claims, terms, evidence, rules, and the right to assert.

Non-goals

dont is not meant to be:

• a general ontology editor
• a replacement for external validators or retrieval systems
• a memory system
• a workflow planner
• a magical truth machine

It is a guardrail and protocol layer.

A short example

An agent concludes: “The API rate limit is 500 requests per minute.”

dont should not let that sentence quietly become accepted project state just because it sounds plausible.

Instead, the tool can force a better path:

1. the agent uses conclude and the claim is recorded as unverified
2. the agent is refused when it tries to promote or rely on that claim without support
3. the refusal tells the agent to gather evidence, use dismiss with evidence, or request independent verification
4. only after that grounding step can the claim earn a more trusted state

That is the point of dont: not better-sounding caution, but enforced epistemic process.

Read next

• Research basis

Research basis

• LLMs do not reliably self-correct in the same context that produced a claim.
• External signals such as evidence, tests, and independent critics are stronger.
• dont translates those conclusions into an explicit claim-handling protocol.

This page explains which research conclusions most directly shaped the proposed design.

The documentation site is grounded in two main source categories in this repository:

• the OpenSpec change specs under openspec/changes/*/specs/, together with the archived monolithic draft preserved in wai research
• the tracked research artifacts under .wai/projects/dont/research/, especially the long-form syntheses on why LLMs defend prior outputs and how institutions force better verification

Main conclusions carried into the tool design

1. In-context self-correction is weak

The research summary argues that models often rationalize earlier answers instead of reliably inspecting them. Asking the same model, in the same context, to “be more critical” often produces better-sounding prose rather than better epistemic behavior.^{1 2}

This motivates dont’s refusal-oriented design: the system should block or route unsupported assertions instead of merely asking for a nicer explanation.

2. External signals are stronger than introspection

The strongest correction patterns in the cited literature depend on something outside the initial generation stream.¹

• retrieved evidence
• tests or executable checks
• trained verifiers
• independent critics or clean-context retries

This is why the spec emphasizes evidence, explicit remediation, and spawn-style verification requests instead of plain self-reflection.

3. Institutions solve this with structure

The research notes compare LLM verification failures to long-studied human failures in science, law, medicine, and engineering. Across those domains, reliability improves when systems enforce the following patterns^{1 2}:

• separation between generator and evaluator
• explicit burden of proof
• auditable state transitions
• procedures for challenge, review, and lock-in

dont translates that pattern into a CLI protocol for agents.

How this maps into the spec set

The current OpenSpec decomposition turns those conclusions into concrete design choices:

• a forcing-function CLI with a narrow role
• append-only history instead of silent rewrite
• explicit claim and term entities
• status transitions rather than implicit confidence
• refusal messages that tell the agent what to do next
• clean-context verification hooks when independent checking matters

Traceability

For deeper reading, start here:

• OpenSpec change specs (openspec/changes/*/specs/)
• Research: forcing doubt in minds and machines
• Research: designing doubt into AI interaction

Limits of this page

This page is a synthesis, not the full literature review. It is meant to explain why the project exists, not to replace the source documents.

1. Research: forcing doubt in minds and machines ↩ ↩2 ↩3

2. Research: designing doubt into AI interaction ↩ ↩2

Sources and status

This documentation site is an overview, not the project’s only source of truth.

What each source is for

• This mdBook (docs/) gives a reader-friendly explanation of the project’s purpose and research basis.
• The OpenSpec change specs are the main detailed design documents for the proposed tool as it is currently decomposed.
• Tracked research notes capture the reasoning and source synthesis behind the project’s design, including the archived monolithic draft.
• OpenSpec is the structured specification workspace where the monolithic draft is being decomposed into capability-focused specifications.

Current project status

dont is still a specification-first project. The repository contains design drafts, capability splits, and research artifacts, not a released implementation.

That means this book should be read as:

• an introduction to the project
• a guide to why the tool is designed this way
• a pointer to the more detailed project artifacts

How to read the project

If you are new here, read in this order:

1. this book for the overview
2. openspec/changes/*/specs/ for the detailed capability-by-capability design
3. .wai/projects/dont/research/ for the justification, research trail, and archived monolithic draft
4. openspec/ for the broader structured specification workspace

Important distinction

The mdBook explains the project in narrative form.

The OpenSpec change specs and related artifacts define the project more precisely.

The .wai research artifacts explain why those design choices were made.