Implementation:Diagram of thought Diagram of thought Rigor Protocol Configuration

Overview

Rigor Protocol Configuration is a concrete pattern for configuring the rigor level (strict / flexible) and typed protocol inclusion when customizing a Diagram of Thought (DoT) prompt for a specific task domain.

Description

This is a configuration decision pattern where users select parameters based on task domain characteristics. The two primary configuration axes are:

• rigor_level — determines how strictly the <critic> role evaluates propositions ("strict" or "flexible")
• typed_protocol — determines whether the @node/@edge/@status typed serialization records are included in the prompt (True or False)

These parameters directly control the structure and formal properties of the resulting reasoning trace.

Usage

This configuration pattern is applied before customizing a DoT prompt for a specific domain. It is the concrete realization of the Task Requirements Definition principle.

Code Reference

Source: README.md:L99-103

The configuration pattern is derived from the "Tips for Effective Use" section of the DoT repository:

• Be Strict: For mathematics, logic, or code-related tasks, instruct the <critic> to be rigorous and always emit a @status record.
• Be Flexible: For open-ended or creative tasks, allow for softer critiques, but still encourage the model to make an explicit validation decision.

Signature:

from dataclasses import dataclass
from typing import Literal

@dataclass
class DoTConfig:
    """Configuration for Diagram of Thought prompt customization."""
    rigor_level: Literal["strict", "flexible"]
    typed_protocol: bool
    domain: str
    critic_mandate: str

Import: No import required — this is a configuration pattern, not a library dependency. The dataclass above is illustrative; any dictionary or structured object may be used.

I/O Contract

Inputs

Parameter	Type	Description
Task domain description	str	A natural-language description of the target task domain (e.g., "mathematical proof", "creative writing", "code review")
Desired auditability level	str	Whether the user requires formal, extractable reasoning traces or accepts narrative-only output

Outputs

Parameter	Type	Description
rigor_level	"flexible"	The selected rigor mode for the <critic> role
typed_protocol	bool	Whether to include @node/@edge/@status typed records in the prompt
domain	str	The target task domain identifier
critic_mandate	str	A natural-language instruction appended to the <critic> role definition

Usage Examples

The following examples demonstrate how to configure DoT for different task domains:

Strict Mode for Mathematical Reasoning

# Strict mode for mathematical reasoning
config = {
    "rigor_level": "strict",
    "typed_protocol": True,
    "domain": "mathematics",
    "critic_mandate": "must emit @status for every proposition"
}

In this configuration, the <critic> is required to emit a @status record for every proposition, ensuring that every reasoning step is formally validated or invalidated. The typed protocol enables post-hoc DAG extraction and acyclicity verification.

Flexible Mode for Creative Writing

# Flexible mode for creative writing
config = {
    "rigor_level": "flexible",
    "typed_protocol": False,
    "domain": "creative_writing",
    "critic_mandate": "provide qualitative feedback"
}

Here, the <critic> provides qualitative feedback rather than binary validation. The typed protocol is omitted to reduce prompt overhead and allow the model to focus on creative generation rather than formal bookkeeping.

Strict Mode with Protocol for Code Review

# Strict with protocol for code review
config = {
    "rigor_level": "strict",
    "typed_protocol": True,
    "domain": "code_review",
    "critic_mandate": "must emit @status, check for bugs and logic errors"
}

For code review, strict mode ensures that every proposed code change or reasoning step is rigorously evaluated. The typed protocol creates an auditable trail of which code aspects were validated and which were flagged, enabling traceability in safety-critical software development.

Configuration Decision Guide

Quick Reference

Question	If Yes	If No
Does the task require formal correctness?	rigor_level = "strict"	rigor_level = "flexible"
Do you need to extract the reasoning DAG?	typed_protocol = True	typed_protocol = False
Is post-hoc verification required?	typed_protocol = True	typed_protocol = False
Is the task open-ended or exploratory?	rigor_level = "flexible"	rigor_level = "strict"

Related Pages

Implements Principle

• Principle:Diagram_of_thought_Diagram_of_thought_Task_Requirements_Definition

Uses Heuristic

• Heuristic:Diagram_of_thought_Diagram_of_thought_Strict_Vs_Flexible_Critic_Rigor