kimasplund Reasoning Handover Protocol
Purpose: Standardized protocol for preserving and transferring cognitive state between reasoning patterns during complex analysis sessions. Enables seamless handovers between ToT, BoT, SRC, HE, AR, DR, AT, RTR, and NDF patterns while maintaining evidence chains, confidence scores, and exploration history.
When to Use This Protocol
Use the Reasoning Handover Protocol when:
- IR-v2 orchestrator transitions between patterns mid-session
- Parallel reasoning branches need to merge results
- Long-running analysis requires checkpointing
- Multiple patterns collaborate on the same problem
- Sessions need to be paused and resumed
- Post-hoc audit of reasoning process is required
Do not use when:
- Single-pattern analysis is sufficient
- Analysis completes within one interaction
- No state preservation needed
Part 1: Directory Structure Specification
1.1 Root Directory: .reasoning/
The .reasoning/ directory serves as the persistent workspace for cognitive reasoning sessions. It maintains session state, handover files, and evidence chains across pattern transitions.
.reasoning/
├── sessions/
│ └── session-{uuid}/
│ ├── manifest.json # Session metadata and state
│ ├── pattern-state/ # Per-pattern working state
│ │ ├── tot/
│ │ │ ├── state.json # ToT-specific state
│ │ │ └── branches/ # Branch exploration data
│ │ ├── bot/
│ │ │ ├── state.json # BoT-specific state
│ │ │ └── approaches/ # Approach exploration data
│ │ ├── he/
│ │ │ ├── state.json # HE-specific state
│ │ │ └── hypotheses/ # Hypothesis tracking
│ │ └── {pattern}/ # Other patterns follow same structure
│ ├── handovers/ # Pattern-to-pattern handover records
│ │ └── {sequence}-{from}-to-{to}.json
│ ├── checkpoints/ # Mid-reasoning save points
│ │ └── checkpoint-{timestamp}.json
│ ├── evidence/ # Shared evidence repository
│ │ ├── gathered/ # Evidence files
│ │ └── index.json # Evidence registry
│ └── synthesis/ # Final outputs
│ └── conclusion-{timestamp}.json
├── templates/ # Reusable handover templates
│ └── {pattern}-handover-template.json
└── config.json # Global configuration
1.2 Session Directory: session-{uuid}/
Each reasoning session gets a unique directory identified by UUID.
Session UUID Format: YYYYMMDD-HHMMSS-{random8}
Example: 20260118-143052-a7b3c9d2
Directory Lifecycle:
- Created: When IR-v2 orchestrator initiates multi-pattern analysis
- Active: During reasoning (state updated continuously)
- Completed: When synthesis finalized
- Archived: After 30 days (move to
.reasoning/archive/)
1.3 Manifest File: manifest.json
The manifest tracks session-level metadata and current state.
{
"session_id": "20260118-143052-a7b3c9d2",
"created_at": "2026-01-18T14:30:52Z",
"last_updated": "2026-01-18T15:45:23Z",
"status": "active|completed|paused|failed",
"problem": {
"statement": "Design authentication system for multi-tenant SaaS",
"constraints": ["SOC2 compliance", "< 100ms latency", "10M users"],
"success_criteria": ["Security validated", "Performance tested", "Cost acceptable"]
},
"orchestration": {
"strategy": "sequential|parallel|nested",
"planned_patterns": ["BoT", "ToT", "AR"],
"current_pattern": "ToT",
"pattern_history": [
{"pattern": "BoT", "started": "...", "completed": "...", "handover_to": "ToT"}
]
},
"dimensions": {
"sequential_dependencies": 2,
"criteria_clarity": 4,
"solution_space_known": 3,
"single_answer_needed": 4,
"evidence_available": 3,
"opposing_valid_views": 3,
"problem_novelty": 3,
"robustness_required": 5,
"solution_exists": 2,
"time_pressure": 2,
"stakeholder_complexity": 2
},
"confidence": {
"overall": 0.72,
"by_pattern": {
"BoT": 0.75,
"ToT": 0.78
}
},
"checkpoints": ["checkpoint-20260118-150000.json"],
"active_handover": null
}
Part 2: Handover Schema Specification
2.1 Universal Handover Format
All pattern-to-pattern handovers follow this base schema:
{
"$schema": "reasoning-handover-v1",
"handover_id": "003-bot-to-tot",
"timestamp": "2026-01-18T15:00:00Z",
"source_pattern": {
"name": "BoT",
"version": "1.0",
"session_state_path": "./pattern-state/bot/state.json"
},
"target_pattern": {
"name": "ToT",
"version": "1.0",
"recommended_entry_point": "step-3-evaluation"
},
"context_transfer": {
"problem_understanding": "...",
"constraints_identified": ["..."],
"assumptions_made": ["..."]
},
"deliverables": {
"type": "approaches|branches|hypotheses|synthesis",
"items": [],
"confidence_scores": {}
},
"evidence_chain": {
"sources_used": ["..."],
"key_findings": ["..."],
"reference_paths": ["./evidence/gathered/..."]
},
"recommendations": {
"focus_areas": ["..."],
"avoid_areas": ["..."],
"open_questions": ["..."]
},
"metadata": {
"duration_minutes": 25,
"branches_explored": 8,
"branches_retained": 5,
"confidence_at_handover": 0.75
}
}
2.2 Pattern-Specific Handover Extensions
BoT (Breadth of Thought) Handover
When BoT hands off to another pattern:
{
"bot_specific": {
"exploration_summary": {
"level_0_approaches": 8,
"level_1_subapproaches": 32,
"total_explored": 40,
"retained_above_40pct": 18
},
"approach_registry": [
{
"id": "approach-1",
"name": "Write-through caching",
"level": 0,
"confidence": 0.72,
"status": "retained",
"strengths": ["..."],
"weaknesses": ["..."],
"best_for": "Strong consistency requirements",
"subapproaches": ["1.1", "1.2", "1.3"]
}
],
"pruned_approaches": [
{
"id": "approach-6",
"name": "Blockchain-based cache",
"pruned_reason": "Complexity exceeds benefit, confidence 28%",
"pruned_at": "level-0"
}
],
"top_5_viable": ["approach-2", "approach-1", "approach-4", "approach-3", "approach-7"],
"handover_recommendation": {
"to_tot": "Evaluate top 3 approaches against defined criteria",
"to_he": "If problem is diagnosis, use approaches as hypothesis set",
"to_ar": "Validate top approach before implementation"
}
}
}
ToT (Tree of Thoughts) Handover
When ToT hands off to another pattern:
{
"tot_specific": {
"tree_structure": {
"total_levels": 4,
"branches_per_level": [5, 5, 5, 5],
"winning_path": ["branch-2", "branch-2.3", "branch-2.3.4", "branch-2.3.4.2"]
},
"branch_scores": {
"branch-2": {
"novelty": 18,
"feasibility": 19,
"completeness": 17,
"confidence": 18,
"alignment": 19,
"total": 91
}
},
"winning_solution": {
"path": "L0:Eventual-consistency > L1:CRDTs > L2:OR-Set > L3:Tombstone-compaction",
"final_score": 91,
"confidence": 0.88,
"key_insight": "CRDTs provide eventual consistency without coordination overhead"
},
"alternatives_considered": [
{
"path": "L0:Write-through > L1:Redis-cluster",
"final_score": 78,
"why_not_selected": "Latency requirements not met under load"
}
],
"handover_recommendation": {
"to_ar": "Validate CRDT approach against adversarial scenarios",
"to_src": "Trace implementation steps for CRDT integration",
"to_he": "If issues arise, use pruned branches as hypothesis set"
}
}
}
HE (Hypothesis-Elimination) Handover
When HE hands off to another pattern:
{
"he_specific": {
"hypothesis_registry": [
{
"id": "H1",
"name": "Memory leak in connection pool",
"initial_probability": 0.3,
"current_probability": 0.05,
"status": "eliminated",
"eliminated_by": "evidence-003",
"elimination_reason": "Memory stable at 2GB, no growth over 4 hours"
},
{
"id": "H3",
"name": "Slow external API response",
"initial_probability": 0.2,
"current_probability": 0.85,
"status": "confirmed",
"confirmed_by": ["evidence-005", "evidence-007"],
"mechanism": "Payment gateway P99 latency increased from 50ms to 800ms"
}
],
"evidence_chain": [
{
"id": "evidence-001",
"type": "log_analysis",
"source": "application-logs",
"finding": "No OOM errors in last 24h",
"hypotheses_affected": {
"H1": "eliminated",
"H2": "unchanged"
}
}
],
"elimination_path": {
"started_with": 12,
"remaining": 1,
"elimination_sequence": ["H1", "H5", "H2", "H8", "H4", "H6", "H7", "H9", "H10", "H11", "H12"]
},
"root_cause": {
"hypothesis": "H3",
"confidence": 0.85,
"mechanism": "External payment API degradation causing request queuing",
"confirmation_test": "Timeout reduction test showed immediate improvement"
},
"handover_recommendation": {
"to_tot": "Evaluate mitigation options for external API dependency",
"to_ar": "Stress-test proposed timeout configuration",
"to_src": "Trace exact failure path through code"
}
}
}
SRC (Self-Reflecting Chain) Handover
When SRC hands off to another pattern:
{
"src_specific": {
"chain_trace": [
{
"step": 1,
"action": "Trace user click to event handler",
"result": "Event handler found in UserSubmit.tsx:45",
"confidence": 0.92,
"dependencies": [],
"backtracked": false
},
{
"step": 2,
"action": "Analyze event handler logic",
"result": "Handler calls validateForm() then submitToAPI()",
"confidence": 0.88,
"dependencies": ["step-1"],
"backtracked": false
},
{
"step": 3,
"action": "Check validateForm() return value",
"result": "Validation passes, returns true",
"confidence": 0.45,
"dependencies": ["step-2"],
"backtracked": true,
"backtrack_reason": "Assumption about validation logic was wrong"
},
{
"step": "3-revised",
"action": "Re-examine validateForm() with edge case inputs",
"result": "Validation fails silently on special characters",
"confidence": 0.82,
"dependencies": ["step-2"],
"backtracked": false
}
],
"chain_confidence": {
"overall": 0.82,
"weakest_link": "step-3-revised",
"strongest_link": "step-1"
},
"backtrack_log": [
{
"from_step": 3,
"to_step": 3,
"reason": "Logic error - assumed validation was comprehensive",
"resolution": "Re-examined with edge cases"
}
],
"handover_recommendation": {
"to_he": "If bug persists, generate hypotheses from chain findings",
"to_tot": "Evaluate fix approaches for validation issue",
"to_ar": "Test fix against adversarial inputs"
}
}
}
AR (Adversarial Reasoning) Handover
When AR hands off to another pattern:
{
"ar_specific": {
"threat_model_summary": {
"target": "JWT authentication system",
"attack_categories_analyzed": ["Spoofing", "Tampering", "Information Disclosure", "Elevation"],
"total_attacks_identified": 24,
"critical": 2,
"high": 5,
"medium": 10,
"low": 7
},
"critical_attacks": [
{
"id": "ATK-001",
"name": "JWT algorithm confusion",
"category": "Spoofing",
"impact": 5,
"feasibility": 4,
"risk_score": 20,
"description": "Attacker changes alg header from RS256 to HS256, signs with public key",
"current_mitigation": "None",
"recommended_mitigation": "Explicitly validate algorithm server-side",
"status": "unmitigated"
}
],
"edge_cases_identified": [
{
"id": "EDGE-001",
"category": "Timing",
"scenario": "Token expiry during long request",
"potential_failure": "Request fails midway through multi-step process",
"test_case": "Submit 5-minute workflow with token expiring at minute 3"
}
],
"residual_risk": {
"score": 0.25,
"description": "After mitigations, supply chain and social engineering remain",
"accepted_risks": ["Insider threat with DB access"],
"deferred_risks": ["Nation-state level attacks"]
},
"handover_recommendation": {
"to_tot": "Evaluate mitigation implementation approaches",
"to_he": "If breach occurs, use attack paths as hypothesis starting point",
"to_src": "Trace attack path through code for fix verification"
}
}
}
2.3 Confidence Score Transfer
Confidence scores must be recalibrated during handover:
{
"confidence_transfer": {
"source_confidence": {
"pattern": "BoT",
"score": 0.75,
"basis": "18 of 40 approaches retained above 40% threshold"
},
"transfer_adjustments": {
"scope_change": -0.05,
"information_loss": -0.03,
"pattern_alignment": +0.02
},
"target_starting_confidence": {
"pattern": "ToT",
"score": 0.69,
"rationale": "Starting ToT with pre-filtered approaches, slight uncertainty from scope narrowing"
},
"shared_assumption_discount": {
"applied": true,
"discount": -0.05,
"reason": "Same LLM, same problem framing, potential shared blind spots"
}
}
}
Cycle Detection
Max Handover Chain Length: 5 (prevents runaway chains)
Cycle Detection Rules:
- Track all (from_pattern, to_pattern) pairs in manifest
- If any pair repeats -> BLOCK handover
- If chain length exceeds 5 -> BLOCK and synthesize current state
Example Blocked Cycles:
- AR -> BoT -> ToT -> AR (AR repeated)
- BoT -> ToT -> BoT (BoT repeated)
Part 3: Integration Points
3.1 IR-v2 Orchestrator Integration
The IR-v2 orchestrator manages handovers through these integration points:
Orchestrator State Machine
+------------------+
| Problem Input |
+--------+---------+
|
v
+--------+---------+
| IR-v2 Scoring |
| (11 dimensions) |
+--------+---------+
|
+--------------+---------------+
| |
v v
+--------+--------+ +--------+--------+
| Single Pattern | | Multi-Pattern |
| Execution | | Orchestration |
+--------+--------+ +--------+--------+
| |
v +---------+---------+
+--------+--------+ | |
| Result | v v
+--------+--------+ +--------+--------+ +--------+--------+
| | Sequential | | Parallel |
v | Orchestration | | Orchestration |
+--------+--------+ +--------+--------+ +--------+--------+
| Synthesis | | |
+-----------------+ v v
+--------+--------+ +--------+--------+
| Handover | | Branch Merge |
| Protocol | | Protocol |
+--------+--------+ +--------+--------+
| |
v v
+--------+-------------------+--------+
| 15-min Checkpoint |
+-----------------+-------------------+
|
v
+-----------------+-------------------+
| Synthesis |
+------------------------------------+
Orchestrator Handover Commands
# Pseudo-code for IR-v2 orchestrator integration
class ReasoningOrchestrator:
def initiate_handover(self, from_pattern: str, to_pattern: str):
"""
Trigger handover from one pattern to another.
"""
# 1. Signal current pattern to prepare handover
handover_data = self.active_pattern.prepare_handover()
# 2. Write handover file
handover_path = self.write_handover(
from_pattern=from_pattern,
to_pattern=to_pattern,
data=handover_data
)
# 3. Update manifest
self.manifest.pattern_history.append({
"pattern": from_pattern,
"completed": timestamp(),
"handover_to": to_pattern,
"handover_file": handover_path
})
# 4. Initialize target pattern with handover context
self.active_pattern = self.load_pattern(to_pattern)
self.active_pattern.load_handover(handover_path)
# 5. Set checkpoint
self.create_checkpoint()
def merge_parallel_branches(self, branch_results: list):
"""
Merge results from parallel pattern executions.
"""
# 1. Validate all branches completed
for branch in branch_results:
if branch.status != "completed":
raise IncompleteHandoverError(branch.id)
# 2. Apply agreement analysis (from IR-v2)
agreement = self.analyze_agreement(branch_results)
# 3. Calculate merged confidence
if agreement.type == "FULL_AGREEMENT":
merged_confidence = max(b.confidence for b in branch_results) + 0.05
elif agreement.type == "PARTIAL_AGREEMENT":
agreeing = [b for b in branch_results if b.conclusion == agreement.majority]
merged_confidence = (avg(b.confidence for b in agreeing) * 0.7 +
avg(b.confidence for b in disagreeing) * 0.15)
else:
merged_confidence = min(b.confidence for b in branch_results) - 0.10
# 4. Create merge record
merge_record = self.write_merge_record(
branches=branch_results,
agreement_type=agreement.type,
merged_confidence=min(merged_confidence, 0.95)
)
return merge_record
def checkpoint(self, reason: str = "scheduled"):
"""
Create checkpoint for session recovery.
"""
checkpoint = {
"timestamp": timestamp(),
"reason": reason,
"manifest_snapshot": self.manifest.to_dict(),
"active_pattern_state": self.active_pattern.get_state(),
"evidence_index": self.evidence_repository.get_index(),
"recovery_instructions": self.generate_recovery_instructions()
}
checkpoint_path = f"checkpoints/checkpoint-{timestamp()}.json"
self.write_json(checkpoint_path, checkpoint)
self.manifest.checkpoints.append(checkpoint_path)
3.2 Parallel Branch Merge Protocol
When patterns run in parallel (AT + BoT, for example), results must merge:
{
"$schema": "parallel-merge-v1",
"merge_id": "merge-001",
"timestamp": "2026-01-18T16:30:00Z",
"branches": [
{
"pattern": "AT",
"branch_id": "at-001",
"conclusion": "Use microservices with event sourcing (analogous to banking ledgers)",
"confidence": 0.72,
"key_insight": "Financial audit trails provide proven pattern for event logs"
},
{
"pattern": "BoT",
"branch_id": "bot-001",
"conclusion": "Top 3: Event sourcing (0.78), CQRS (0.71), Saga pattern (0.68)",
"confidence": 0.78,
"key_insight": "Event sourcing emerged as top approach from 8 explored"
}
],
"agreement_analysis": {
"type": "FULL_AGREEMENT",
"agreeing_on": "Event sourcing architecture",
"confidence_boost": "+5%"
},
"merged_result": {
"conclusion": "Event sourcing architecture (validated by both exploration and analogy)",
"confidence": 0.83,
"confidence_calculation": "max(0.72, 0.78) + 0.05 = 0.83",
"synthesis": "Both analytical and analogical approaches converged on event sourcing. AT found banking analogy, BoT found it as top approach from systematic exploration."
},
"next_step": {
"pattern": "AR",
"rationale": "High-confidence solution needs adversarial validation before implementation"
}
}
3.3 Checkpoint Protocol
Checkpoints enable session recovery and mid-reasoning pauses:
{
"$schema": "checkpoint-v1",
"checkpoint_id": "checkpoint-20260118-150000",
"created_at": "2026-01-18T15:00:00Z",
"trigger": "scheduled|manual|error|handover",
"session_state": {
"session_id": "20260118-143052-a7b3c9d2",
"active_pattern": "ToT",
"pattern_phase": "step-3-evaluation",
"elapsed_minutes": 30,
"patterns_completed": ["BoT"],
"patterns_pending": ["AR"]
},
"pattern_snapshot": {
"pattern": "ToT",
"current_level": 2,
"branches_at_current_level": 5,
"winning_branch_so_far": "branch-2.3",
"confidence_so_far": 0.78,
"work_remaining": "Levels 3-4 exploration, final synthesis"
},
"evidence_snapshot": {
"evidence_count": 12,
"evidence_index_path": "./evidence/index.json",
"key_evidence": ["evidence-003", "evidence-007", "evidence-011"]
},
"recovery_instructions": {
"to_resume": [
"1. Load manifest from ./manifest.json",
"2. Restore ToT state from ./pattern-state/tot/state.json",
"3. Resume at Level 2, branch-2.3 expansion",
"4. Continue ToT methodology step 4 (recursive depth)"
],
"expected_time_to_complete": "20-30 minutes",
"dependencies": "None - can resume independently"
},
"integrity_check": {
"manifest_hash": "sha256:abc123...",
"pattern_state_hash": "sha256:def456...",
"evidence_hash": "sha256:ghi789..."
}
}
Part 4: Pattern-Specific State Formats
4.1 ToT State Format (pattern-state/tot/state.json)
{
"pattern": "ToT",
"version": "1.0",
"started_at": "2026-01-18T15:00:00Z",
"current_phase": "step-4-recursive-depth",
"tree": {
"root": {
"problem": "Design distributed caching system",
"evaluation_criteria": ["latency", "consistency", "cost", "scalability"]
},
"levels": [
{
"level": 0,
"branches": [
{
"id": "branch-1",
"name": "Write-through caching",
"analysis": "...",
"self_reflection": {
"confidence": 75,
"strengths": ["Strong consistency"],
"weaknesses": ["Higher latency"],
"recommendation": "Continue if consistency is priority"
},
"scores": {
"novelty": 12,
"feasibility": 18,
"completeness": 17,
"confidence": 15,
"alignment": 16,
"total": 78
},
"status": "explored",
"selected_for_depth": false
}
],
"winner": "branch-2",
"winner_score": 85
}
],
"current_level": 2,
"winning_path": ["branch-2", "branch-2.3"]
},
"exploration_stats": {
"total_branches_explored": 15,
"total_time_minutes": 25,
"average_branch_confidence": 72
}
}
4.2 BoT State Format (pattern-state/bot/state.json)
{
"pattern": "BoT",
"version": "1.0",
"started_at": "2026-01-18T14:30:00Z",
"current_phase": "step-3-conservative-pruning",
"exploration": {
"problem": "Identify all viable data pipeline architectures",
"level_0": {
"approaches_generated": 8,
"approaches": [
{
"id": "approach-1",
"name": "Batch processing (ETL)",
"overview": "Traditional extract-transform-load...",
"strengths": ["Mature tooling", "Cost-effective for large batches"],
"weaknesses": ["High latency", "Not real-time"],
"feasibility": {
"technical": "High",
"operational": "Medium",
"business": "High"
},
"confidence": 68,
"status": "retained"
}
],
"pruned": ["approach-6", "approach-8"],
"retained": 6
},
"level_1": {
"expanded_from": ["approach-1", "approach-2", "approach-3", "approach-4", "approach-5", "approach-7"],
"total_subapproaches": 30,
"retained_above_40pct": 18
}
},
"top_5_solutions": [
{
"path": "approach-2 > approach-2.3",
"name": "Kafka + Flink streaming",
"confidence": 78,
"best_for": "Real-time analytics with exactly-once semantics"
}
],
"exploration_stats": {
"total_branches_explored": 38,
"pruned_count": 20,
"retained_count": 18,
"diversity_score": 0.85
}
}
4.3 HE State Format (pattern-state/he/state.json)
{
"pattern": "HE",
"version": "2.0",
"started_at": "2026-01-18T14:00:00Z",
"current_phase": "phase-4-confirmation",
"symptom": "API returning 500 errors intermittently since 14:00",
"hypotheses": [
{
"id": "H1",
"name": "Memory exhaustion",
"mechanism": "Container OOM causing crashes",
"initial_probability": 0.25,
"current_probability": 0.02,
"status": "eliminated",
"evidence_trail": [
{"evidence": "E001", "impact": "eliminated", "timestamp": "14:15"}
]
},
{
"id": "H3",
"name": "External API timeout",
"mechanism": "Payment gateway slow, causing request backup",
"initial_probability": 0.20,
"current_probability": 0.88,
"status": "leading",
"evidence_trail": [
{"evidence": "E003", "impact": "strengthened", "timestamp": "14:25"},
{"evidence": "E007", "impact": "strengthened", "timestamp": "14:40"}
]
}
],
"evidence_hierarchy": [
{
"id": "E001",
"source": "Container metrics",
"discrimination_power": 4,
"acquisition_cost": 2,
"priority_score": 2.0,
"finding": "Memory stable at 2GB, no OOM events",
"gathered_at": "14:15"
}
],
"elimination_progress": {
"started_with": 10,
"eliminated": 9,
"remaining": 1,
"elimination_sequence": ["H1", "H5", "H2", "H8", "H4", "H6", "H7", "H9", "H10"]
},
"confirmation_status": {
"hypothesis": "H3",
"prediction": "Reducing timeout from 30s to 5s will reduce 500 errors",
"test_result": "500 errors dropped 95% after timeout change",
"confidence": 0.88
}
}
Part 5: Evidence Repository
5.1 Evidence Index (evidence/index.json)
{
"session_id": "20260118-143052-a7b3c9d2",
"evidence_count": 15,
"last_updated": "2026-01-18T15:30:00Z",
"evidence": [
{
"id": "E001",
"type": "metric",
"source": "prometheus:container_memory",
"gathered_at": "2026-01-18T14:15:00Z",
"gathered_by_pattern": "HE",
"file_path": "./gathered/E001-memory-metrics.json",
"summary": "Container memory stable at 2GB, no OOM events",
"used_by_patterns": ["HE"],
"hypotheses_affected": ["H1:eliminated", "H2:unchanged"]
},
{
"id": "E003",
"type": "log_analysis",
"source": "application:logs:error",
"gathered_at": "2026-01-18T14:25:00Z",
"gathered_by_pattern": "HE",
"file_path": "./gathered/E003-error-logs.txt",
"summary": "Timeout errors spike at 14:02, correlates with payment gateway",
"used_by_patterns": ["HE", "SRC"],
"hypotheses_affected": ["H3:strengthened"]
}
],
"evidence_by_type": {
"metric": ["E001", "E005", "E009"],
"log_analysis": ["E002", "E003", "E006"],
"code_analysis": ["E004", "E007"],
"external_status": ["E008"],
"reproduction": ["E010"]
}
}
Part 6: Usage Examples
6.1 Sequential Orchestration: BoT to ToT to AR
## Session: Design authentication system
## Strategy: Sequential (BoT -> ToT -> AR)
### Phase 1: BoT Exploration
**Started**: 2026-01-18T14:30:00Z
**Duration**: 25 minutes
BoT explored 8 authentication approaches:
1. JWT with refresh tokens
2. Session-based with Redis
3. OAuth2 with external provider
4. Passwordless (magic links)
5. WebAuthn/FIDO2
6. Certificate-based (mTLS)
7. API keys with HMAC
8. Blockchain identity
**Retained (>40%)**: Approaches 1, 2, 3, 5, 6 (5 retained)
**Pruned (<40%)**: Approaches 4, 7, 8
**Handover to ToT**: ./handovers/001-bot-to-tot.json
**Deliverable**: Top 5 approaches for evaluation
---
### Phase 2: ToT Optimization
**Started**: 2026-01-18T14:55:00Z
**Duration**: 30 minutes
ToT evaluated top 3 approaches through 4 levels:
Level 0: JWT vs Session vs OAuth2
Winner: JWT (Score: 85/100)
Level 1: JWT variants
- Asymmetric (RS256) vs Symmetric (HS256) vs EdDSA
Winner: RS256 (Score: 88/100)
Level 2: RS256 implementation
- Self-signed vs CA-signed vs JWKS rotation
Winner: JWKS rotation (Score: 91/100)
Level 3: JWKS rotation strategy
- Manual vs Automated vs Vault-managed
Winner: Vault-managed (Score: 93/100)
**Winning Path**: JWT > RS256 > JWKS rotation > Vault-managed
**Confidence**: 88%
**Handover to AR**: ./handovers/002-tot-to-ar.json
**Deliverable**: Optimal solution for validation
---
### Phase 3: AR Validation
**Started**: 2026-01-18T15:25:00Z
**Duration**: 20 minutes
AR attacked JWT/RS256/JWKS/Vault solution:
**Critical Attacks Found**: 2
- ATK-001: Algorithm confusion (RS256->HS256)
- ATK-002: JWKS endpoint poisoning
**Mitigations Designed**: 2
- Explicit algorithm validation server-side
- JWKS endpoint pinning with certificate validation
**Edge Cases Found**: 4
- Token expiry during long requests
- Clock skew between services
- Key rotation during request processing
- Vault unavailable scenario
**Residual Risk**: 15% (acceptable)
**Final Confidence**: 85% (reduced from 88% due to attack findings)
---
### Synthesis
**Session Complete**: 2026-01-18T15:45:00Z
**Total Duration**: 75 minutes
**Patterns Used**: BoT -> ToT -> AR
**Final Recommendation**:
Implement JWT with RS256 algorithm, JWKS rotation managed by HashiCorp Vault.
Include algorithm validation middleware and JWKS endpoint pinning.
**Confidence**: 85%
**Handovers Created**: 2
**Evidence Items**: 15
**Checkpoints**: 3
6.2 Parallel Orchestration: AT + BoT Merge
## Session: Design data platform architecture
## Strategy: Parallel (AT || BoT -> Merge -> ToT)
### Phase 1: Parallel Exploration
**AT Branch** (Analogical Transfer):
- Problem: Novel data platform for real-time analytics
- Analogy found: Stock exchange trading systems
- Insight: Event-driven architecture with in-memory state
- Confidence: 0.72
**BoT Branch** (Breadth of Thought):
- Explored 8 architectures
- Top 3: Event sourcing (0.78), Lambda (0.71), Lakehouse (0.68)
- Insight: Event sourcing emerged as highest-confidence approach
- Confidence: 0.78
### Phase 2: Merge
**Agreement Type**: FULL_AGREEMENT
- Both patterns converged on event-driven/event-sourcing architecture
- AT found it via stock exchange analogy
- BoT found it via systematic exploration
**Merged Confidence**: 0.83 (max + 5%)
**Synthesis**: Event sourcing architecture validated by both analytical and analogical approaches. Stock exchange systems provide proven pattern for high-throughput event processing with strong consistency guarantees.
### Phase 3: ToT Optimization (on merged result)
[Continue with ToT to optimize event sourcing implementation details...]
Part 7: Implementation Checklist
For IR-v2 Orchestrator Developers
- Implement session directory creation with UUID generation
- Implement manifest file management (create, update, validate)
- Implement handover file writing with schema validation
- Implement checkpoint creation at 15-minute intervals
- Implement checkpoint recovery (session resume)
- Implement parallel branch merge with agreement analysis
- Implement evidence repository indexing
- Add hooks for pattern-specific state serialization
For Pattern Implementers
- Implement
prepare_handover()method returning pattern-specific data - Implement
load_handover()method accepting incoming handover data - Implement
get_state()method for checkpoint serialization - Implement
restore_state()method for checkpoint recovery - Add evidence registration to evidence repository during gathering
- Update confidence scores according to transfer protocol
For Session Recovery
- Validate checkpoint integrity hashes before restore
- Log recovery operations for audit trail
- Handle partial state gracefully (continue from last valid checkpoint)
- Notify user of any state loss during recovery
Part 8: Configuration
Global Configuration (.reasoning/config.json)
{
"version": "1.0",
"session_defaults": {
"checkpoint_interval_minutes": 15,
"auto_checkpoint_on_handover": true,
"max_session_duration_hours": 4,
"archive_after_days": 30
},
"handover_settings": {
"validate_schema": true,
"require_confidence_transfer": true,
"shared_assumption_discount": 0.05
},
"evidence_settings": {
"max_evidence_file_size_mb": 10,
"index_update_on_gather": true
},
"parallel_settings": {
"max_parallel_branches": 5,
"merge_timeout_minutes": 30
},
"logging": {
"log_level": "INFO",
"log_handovers": true,
"log_checkpoints": true,
"log_pattern_transitions": true
}
}
Summary
The Reasoning Handover Protocol provides:
Standardized Directory Structure:
.reasoning/session-{uuid}/with clear organization for pattern state, handovers, evidence, and checkpointsUniversal Handover Schema: Base format plus pattern-specific extensions for ToT, BoT, HE, SRC, AR, DR, AT, RTR, and NDF
Confidence Transfer: Calibrated confidence scores with adjustments for scope changes and shared assumptions
IR-v2 Integration: State machine for orchestration, commands for handover initiation, and parallel merge protocol
Checkpoint Protocol: Mid-reasoning save points with integrity validation and recovery instructions
Evidence Repository: Shared evidence storage with cross-pattern indexing
Use this protocol whenever multi-pattern reasoning requires state preservation, pattern transitions, or audit trails.