Heuristic:Diagram of thought Diagram of thought Strict Vs Flexible Critic Rigor
| Knowledge Sources | |
|---|---|
| Domains | LLMs, Prompt_Engineering |
| Last Updated | 2026-02-14 04:30 GMT |
Overview
Decision framework for configuring critic rigor level: strict mode (mandatory `@status` records) for formal tasks vs. flexible mode (softer critiques) for creative tasks.
Description
The DoT framework supports two distinct modes of critic behavior that fundamentally affect reasoning quality and auditability. Strict mode requires the critic to always emit a `@status target= mark={validated|invalidated}` record for every proposition it evaluates, producing a formally verifiable reasoning trace. Flexible mode allows softer, narrative critiques without mandatory status records, which is better suited for open-ended or creative tasks where binary validation is too constraining. Choosing the wrong mode can lead to either over-constrained creative reasoning or under-verified formal reasoning.
Usage
Apply this heuristic when configuring the DoT prompt for a specific task domain. The decision should be made at Step 1 (Define Task Requirements) of the DoT_Prompt_Customization workflow, before selecting or customizing the prompt template. Use strict mode for mathematics, logic, code verification, and any task where correctness is binary. Use flexible mode for brainstorming, creative writing, open-ended analysis, and tasks where multiple valid answers exist.
The Insight (Rule of Thumb)
- Action: Choose the critic rigor level based on the task domain before configuring the prompt.
- Value:
- Strict mode: Instruct the `<critic>` to always emit `@status target= mark={validated|invalidated}` for every proposition. Add the instruction: "You MUST emit a @status record for every proposition you evaluate."
- Flexible mode: Allow the `<critic>` to provide narrative feedback without mandatory `@status` records. The critic may still emit them but is not required to.
- Trade-off: Strict mode produces formally verifiable traces but may constrain the model on creative tasks. Flexible mode allows richer exploration but loses the formal auditability guarantees.
- Decision Rule: If the task has a single correct answer or requires formal verification, use strict. If the task is exploratory or creative, use flexible.
Reasoning
The DoT framework derives its formal guarantees (colimit construction, acyclic verification) from the typed serialization protocol. These guarantees only hold when every proposition receives an explicit validation status. Without `@status` records, the summarizer cannot reliably distinguish validated from invalidated branches, weakening the formal properties.
However, forcing binary validation on creative or open-ended tasks creates artificial constraints. A critic forced to mark a brainstorming idea as "validated" or "invalidated" loses the nuance of "interesting but needs refinement." The flexible mode preserves the propose-critique-summarize structure while allowing richer feedback.
Code evidence from `README.md:L99-103`:
Tips for Effective Use:
* 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.
Code evidence from `README.md:L61`:
The typed records (@node, @edge, etc.) are optional for basic use but are
essential for enabling the formal guarantees and auditable extraction.