Skip to content

07-intelligence.md

Latest commit

 

History

History
128 lines (89 loc) · 4.01 KB

07-intelligence.md

File metadata and controls

128 lines (89 loc) · 4.01 KB
Raw

SPEC-07: Intelligence Enhancements

Overview

This specification defines capabilities for enhancing RLM reasoning quality through Tree of Thoughts integration, compute-optimal allocation, and formal verification.

Research Basis:

Dependencies

SPEC-07 (Intelligence) ───► SPEC-01 (REPL Functions)
SPEC-07 (Intelligence) ───► SPEC-05 (Budget Tracking)

7.1 Tree of Thoughts Integration

Requirements

[SPEC-07.01] The system SHALL implement ThoughtNode with:

  • thought: str
  • state: dict[str, Any]
  • children: list[ThoughtNode]
  • value_estimate: float
  • is_terminal: bool

[SPEC-07.02] The system SHALL support thought branching via branch(thoughts: list[str]) -> list[ThoughtNode].

[SPEC-07.03] The system SHALL support state evaluation via evaluate_state(node: ThoughtNode) -> float.

[SPEC-07.04] The system SHALL support backtracking via backtrack(to_node: ThoughtNode).

[SPEC-07.05] The ToT integration SHALL preserve REPL state at each branch point for backtracking.

[SPEC-07.06] The system SHALL support configurable search strategies:

  • BFS (breadth-first)
  • DFS (depth-first)
  • Best-first (by value estimate)

[SPEC-07.07] The system SHALL support configurable:

  • max_branches (default: 3)
  • max_depth (default: 4)
  • pruning_threshold (default: 0.3)

Acceptance Criteria

  • ThoughtNode correctly tracks state
  • Branching generates valid alternative thoughts
  • Backtracking restores REPL state correctly
  • Search strategies implemented and selectable
  • ToT improves success rate on multi-step reasoning tasks

7.2 Compute-Optimal Allocation

Requirements

[SPEC-07.10] The system SHALL allocate compute dynamically based on query difficulty.

[SPEC-07.11] ComputeAllocation SHALL include:

  • depth_budget: int
  • model_tier: ModelTier
  • parallel_calls: int
  • timeout_ms: int
  • estimated_cost: float

[SPEC-07.12] The allocator SHALL estimate difficulty using existing complexity_classifier signals plus:

  • Historical performance on similar queries
  • Context complexity (files, modules)
  • Task type (code, debug, analysis, question)

[SPEC-07.13] The allocator SHALL support total_budget constraint.

[SPEC-07.14] The allocator SHALL consider model+depth tradeoffs:

  • Haiku with depth=3 vs Opus with depth=1
  • Cost vs quality optimization

[SPEC-07.15] The allocator SHALL emit allocation reasoning for transparency.

Acceptance Criteria

  • Compute allocation varies appropriately with query difficulty
  • Budget constraints are respected
  • Allocation improves cost-efficiency by 2x+ vs static allocation
  • Allocation reasoning is logged

7.3 Formal Verification Integration

Requirements

[SPEC-07.20] The system SHALL support verification chains for code tasks.

[SPEC-07.21] VerificationChain SHALL support:

  • generate_preconditions(change: CodeChange) -> list[Constraint]
  • generate_postconditions(change: CodeChange) -> list[Constraint]
  • verify(constraints, code) -> VerificationResult

[SPEC-07.22] The system SHALL support constraint types:

  • Type constraints (via type checker)
  • Behavioral constraints (via CPMpy)
  • Test constraints (via test execution)

[SPEC-07.23] For refactoring tasks, the system SHALL automatically generate:

  • "All call sites still type-check"
  • "All tests still pass"
  • "No new imports introduced" (if requested)

[SPEC-07.24] Verification SHALL be integrated with recursive decomposition:

  • Spawn verification sub-queries for each postcondition
  • Aggregate verification results

[SPEC-07.25] Verification failures SHALL trigger automatic correction attempts.

Acceptance Criteria

  • Preconditions and postconditions generate correctly
  • Type checking integration works
  • Test execution integration works
  • Verification improves code change correctness
  • Correction attempts reduce verification failures