Principle:Spcl Graph of thoughts Thought State Management

Knowledge Sources	Graph of Thoughts: Solving Elaborate Problems with Large Language Models Graph of Thoughts
Domains	Graph_Reasoning, State_Management
Last Updated	2026-02-14 12:00 GMT

Overview

Data management pattern that encapsulates LLM reasoning state as mutable thought objects flowing through a graph of operations.

Description

In the Graph of Thoughts framework, all reasoning state flows through Thought objects. A Thought is the fundamental unit of data in the graph -- it represents a single reasoning state at a particular point in the execution pipeline.

Each Thought carries two categories of information:

1. Problem-specific state (the state dict):

The state dictionary holds domain-specific data that varies by use case. For example:

• In a sorting task: {"original": [3,1,2], "current": [1,2,3], "phase": 1}
• In a keyword counting task: {"original": "text...", "current": "word1, word2", "count": 5}
• In a document merging task: {"original": "doc...", "current": "summary...", "part": 2}

The state dict is defined by the Prompter (which reads state to generate prompts) and the Parser (which writes state from LLM responses). The framework itself is agnostic to the state schema -- this is where domain-specific logic lives.

2. Metadata flags and values:

Every Thought carries standardized metadata that the framework's operations read and write:

• scored (bool) -- Whether this thought has been evaluated by a Score operation
• score (float) -- The numerical score assigned by a Score operation
• validated (bool) -- Whether this thought has been checked by a ValidateState operation
• valid (bool) -- Whether the thought passed validation
• compared_to_ground_truth (bool) -- Whether this thought has been evaluated against a known answer
• solved (bool) -- Whether the thought's state matches the ground truth

Thought lifecycle:

1. Creation: Thoughts are created by Generate operations. The initial thought's state is populated from the problem_parameters dict passed to the Controller.
2. Cloning: When operations like Score or KeepBestN need to propagate thoughts forward, they use from_thought() to create a copy that inherits the original's state and metadata.
3. Flow: Thoughts flow from operation to operation through predecessor-successor links in the Graph of Operations. An operation receives the thoughts produced by its predecessors and produces new thoughts for its successors.
4. Transformation: Generate operations create new thoughts with LLM-modified state. Score operations set the score flag. KeepBestN filters thoughts by score. Aggregate merges thoughts from multiple predecessors.

Usage

Use this principle when designing the state schema for a new GoT use case. The key decisions are:

• What keys should the state dict contain? Define the data your Prompter needs to read and your Parser needs to write.
• How does state evolve through the graph? Map out how each operation transforms the state (e.g., a Generate changes current, a Score sets score).
• What constitutes ground truth? Define the solved condition for your domain.

A well-designed state schema keeps all problem-specific data in the state dict and relies on the framework's metadata flags for operation-level coordination.

Theoretical Basis

Thought as a Unit of Reasoning State

In the GoT formalism, a Thought is a node in the Graph Reasoning State (GRS). The GRS is the runtime counterpart of the Graph of Operations (GoO): while the GoO defines what operations to perform, the GRS records what thoughts were produced.

Each thought is effectively an immutable snapshot of reasoning state at a particular point in the graph, with the following properties:

• Identity: Each thought has a unique auto-incrementing ID, enabling tracing and debugging.
• State: The problem-specific dictionary is the thought's payload. It captures the LLM's reasoning output in a structured form.
• Metadata: The scored/validated/compared flags act as a type-state system, indicating which framework operations have processed this thought.

The separation between state (problem-specific) and metadata (framework-level) is a key design decision. It means:

• The framework operations (Score, KeepBestN, GroundTruth) can work generically across all use cases by reading metadata flags.
• The domain-specific logic (Prompter, Parser) can focus solely on the state dict without worrying about framework coordination.

State flow through operations:

# Pseudocode illustrating thought flow
# Generate: creates new thoughts from LLM output
thought = Thought(state={"current": llm_response})

# Score: marks the thought as scored
thought.score = scoring_function(thought.state)  # sets scored=True

# KeepBestN: filters by score, passes best thoughts forward
best = sorted(thoughts, key=lambda t: t.score, reverse=True)[:n]

# GroundTruth: compares to known answer
thought.solved = (thought.state["current"] == ground_truth)  # sets compared_to_ground_truth=True

Related Pages

• Implementation:Spcl_Graph_of_thoughts_Thought