Principle:Diagram of thought Diagram of thought Task Requirements Definition
Overview
Task Requirements Definition is the principle of selecting the appropriate rigor level and protocol configuration for a structured reasoning task based on domain characteristics. This principle is library-agnostic and applies to any adaptation of the Diagram of Thought (DoT) framework regardless of the underlying LLM or deployment environment.
Description
Before customizing a reasoning prompt, practitioners must decide on two key parameters:
- Rigor level — strict vs. flexible
- Typed serialization protocol — whether to include the
@node/@edge/@statustyped record system
Strict mode is appropriate for tasks requiring formal verification, such as:
- Mathematics and formal proofs
- Logic puzzles and constraint satisfaction
- Code generation, review, and debugging
In strict mode, the <critic> role is instructed to be rigorous and must always emit a @status record for every proposition it evaluates.
Flexible mode suits open-ended or creative tasks where softer critiques are acceptable. The critic still makes an explicit validation decision, but the judgment may be qualitative rather than binary.
The typed protocol (@node/@edge/@status) enables formal guarantees and auditability—including deterministic DAG extraction and acyclicity checking—but adds overhead to the prompt and the model's generation. Practitioners must weigh this tradeoff based on whether post-hoc verification is required for their use case.
Usage
Task Requirements Definition is applied before prompt customization, as the first step in adapting the DoT framework to a specific domain. The decisions made at this stage determine the structure and constraints of all subsequent prompt engineering.
| Domain Type | Rigor Level | Typed Protocol | Rationale |
|---|---|---|---|
| Mathematics, Logic | Strict | Recommended | Formal verification requires binary validation and auditable traces |
| Code Generation/Review | Strict | Recommended | Bug detection and correctness checking demand rigorous critique |
| Creative Writing | Flexible | Optional | Qualitative feedback is more appropriate than binary judgments |
| Open-ended Exploration | Flexible | Optional | Soft critiques encourage broader ideation without premature pruning |
| Scientific Analysis | Strict | Recommended | Reproducibility and auditability are critical for scientific claims |
Theoretical Basis
Task requirements definition maps to choosing the appropriate logical framework for the reasoning task.
- Strict mode corresponds to classical logic (bivalent: validated / invalidated). Every proposition receives a definitive truth value, and the reasoning DAG maintains strict formal properties. The critic operates as a classical judge—each step is either accepted or rejected with no intermediate state.
- Flexible mode allows for graded judgments. The critic may provide qualitative assessments that do not map cleanly to a binary validated/invalidated distinction. This relaxation trades formal guarantees for broader applicability in domains where binary judgments would be reductive.
The typed protocol decision affects whether formal verification (DAG extraction, acyclicity checking) is possible. Without the @node/@edge/@status annotations, the reasoning trace remains a natural-language narrative that cannot be deterministically parsed into a graph structure. With the protocol enabled, an online validator can enforce structural invariants (e.g., edge sources must have smaller IDs than destinations) during generation.
From the perspective of topos theory (as described in the DoT paper), the typed protocol is what enables the interpretation of validated propositions as subobjects in a slice topos and the final summary as a colimit—a universal construction that optimally synthesizes all validated evidence.