Implementation:Diagram of thought Diagram of thought Proposer Critic XML Cycle

Overview

This page describes the concrete pattern for implementing the iterative propose-critique reasoning cycle using XML tags and typed serialization records in the Diagram of Thought (DoT) framework. Users apply this pattern directly in their prompts to enable a single LLM to construct a self-correcting reasoning DAG with auditable, machine-parseable structure.

Description

The DoT propose-critique cycle is structured using two XML tags that serve as role delimiters:

• <proposer> -- Encloses an atomic reasoning step proposed by the model. The proposer generates a clear, concrete proposition that advances the solution, building on previously validated nodes.
• <critic> -- Encloses an evaluation of the preceding proposition. The critic assesses logical consistency, accuracy, and soundness, then issues a validation verdict.

Each block is annotated with typed serialization records that formally encode the DAG structure:

Record	Syntax	Purpose
@node	critic}	Declares a new node in the reasoning DAG with a unique monotonically increasing integer ID and its role.
@edge	critique|refine}	Declares a directed edge from node i to node n. The constraint i < n enforces acyclicity. Edge kinds: use (builds upon), critique (evaluates), refine (corrects after invalidation).
@status	invalidated}	The critic's verdict on a target proposition node. validated means the proposition is sound; invalidated means it contains a flaw.

The interleaving of <proposer> and <critic> blocks, each annotated with these records, produces an incrementally growing DAG that is both human-readable (natural language reasoning) and machine-parseable (typed records).

Usage

Use this pattern within a DoT-configured LLM session after the problem node has been established (i.e., after a <problem> block with @node id=1 role=problem has been emitted). The propose-critique cycle then begins at node id=2 and alternates until sufficient validated evidence is accumulated for the summarizer to synthesize the final answer.

Code Reference

Source

• prompts/iterative-reasoner.md:L12-26 -- Role definitions for proposer, critic, and summarizer.
• README.md:L68-71 -- Typed record format specification (@node, @edge, @status).
• README.md:L77-92 -- Propose-critique example with typed records.

Signature

The XML tag pattern with typed records follows this structure:

<proposer>
[Atomic reasoning step in natural language]
@node id=<n> role=proposer
@edge src=<i> dst=<n> kind={use|refine}
</proposer>

<critic>
[Evaluation of the preceding proposition in natural language]
@node id=<n+1> role=critic
@edge src=<n> dst=<n+1> kind=critique
@status target=<n> mark={validated|invalidated}
</critic>

Key constraints:

• Node IDs are monotonically increasing positive integers.
• Every @edge must satisfy src < dst (enforces DAG acyclicity).
• A critic block targeting a proposer node must include exactly one @status record for that node.
• After an invalidated verdict, the next proposer should use kind=refine to indicate it is correcting the flawed step.

Import

No import required. This is a prompt pattern -- it is applied by including the role tokens and typed record format in the system prompt or instruction given to the LLM.

I/O Contract

Inputs

• Problem node: A previously established <problem> block (typically from the Problem Formulation step) declared as @node id=1 role=problem.
• Prior proposer/critic nodes: Any previously emitted proposer and critic nodes in the current reasoning session. The proposer may reference any prior validated node via @edge kind=use.

Outputs

A sequence of interleaved <proposer> and <critic> blocks, each annotated with @node, @edge, and @status records, forming an incrementally growing DAG. Specifically:

• Each <proposer> block produces one new node with at least one inbound @edge (either use or refine).
• Each <critic> block produces one new node with a critique edge to the proposition it evaluates, plus a @status record marking the target as validated or invalidated.
• The sequence terminates when sufficient validated evidence exists for a <summarizer> block to synthesize the final answer.

Usage Examples

The following example demonstrates a multi-turn propose-critique cycle for the task of counting the letter "r" in the word "strawberry". The problem node (id=1) has already been established.

<proposer>
The word "strawberry" has three syllables: straw-ber-ry. Let me count the letter "r" in each syllable.
@node id=2 role=proposer
@edge src=1 dst=2 kind=use
</proposer>

<critic>
The proposer correctly identifies three syllables. Counting: "straw" has 1 "r", "ber" has 1 "r", "ry" has 1 "r". Total = 3 "r"s. This is correct.
@node id=3 role=critic
@edge src=2 dst=3 kind=critique
@status target=2 mark=validated
</critic>

Below is an extended example showing what happens when a proposition is invalidated and the proposer must refine its reasoning:

<proposer>
To compare 9.11 and 9.9, I note that 9.11 has more decimal digits, so 9.11 > 9.9.
@node id=2 role=proposer
@edge src=1 dst=2 kind=use
</proposer>

<critic>
The proposer's reasoning is flawed. The number of decimal digits does not determine magnitude. Comparing digit by digit after the decimal point: 9.11 has "1" in the tenths place, while 9.9 has "9" in the tenths place. Since 1 < 9, we have 9.11 < 9.9. The proposition is incorrect.
@node id=3 role=critic
@edge src=2 dst=3 kind=critique
@status target=2 mark=invalidated
</critic>

<proposer>
Correcting my approach: to compare 9.11 and 9.9, I align the decimal places. 9.11 = 9.11 and 9.9 = 9.90. Comparing tenths: 1 < 9, so 9.11 < 9.90. Therefore 9.11 < 9.9.
@node id=4 role=proposer
@edge src=2 dst=4 kind=refine
</proposer>

<critic>
The refined proposition correctly aligns decimal places and compares digit by digit. The conclusion 9.11 < 9.9 is correct.
@node id=5 role=critic
@edge src=4 dst=5 kind=critique
@status target=4 mark=validated
</critic>

In this example, node 2 was invalidated by the critic at node 3. The proposer then issued a refinement at node 4 (indicated by @edge src=2 dst=4 kind=refine), which was subsequently validated at node 5. The summarizer would later draw only from validated nodes (node 4) when constructing the final answer.

Related Pages

• Principle:Diagram_of_thought_Diagram_of_thought_Iterative_Propose_and_Critique -- Theoretical principle underlying this implementation pattern.