---
name: co-fita-research-operations
type: analysis
title: "Co-Fita Research Operations"
description: "How research is conducted: the AutoResearch protocol for long-horizon autonomous tasks, the web research pipeline (SearXNG + Crawl4AI), the Hyper Harness orchestrator, and the operational methodology."
tags: [research, operations, auto-research, orchestrator, harness, long-horizon, autonomous, web-research, searxng, crawl4ai]
timestamp: "2026-07-21"
---

# Co-Fita Research Operations

How research is conducted within the Co-Fita ecosystem. Three layers: the AutoResearch protocol for autonomous long-horizon tasks, the web research pipeline (SearXNG + Crawl4AI) for information gathering, and the Hyper Harness orchestrator that ties everything together.

The methodology is shaped by a core observation: long-running code agents fail not from insufficient model capability, but from missing engineering scaffolding. Cognitive loops, stalls, and runtime fragility are engineering problems with engineering solutions.

See also: [[co-fita-infrastructure]] | [[unit-distance-methodology]] | [[co-fita-pam-setup]]

---

## 1. The Three Layers

```
┌─────────────────────────────────────────────────┐
│           Layer 3: AutoResearch Protocol          │
│  (Long-horizon task execution, stall detection)  │
├─────────────────────────────────────────────────┤
│           Layer 2: Hyper Harness Orchestrator     │
│  (Phase loop, governance, red team, elo arena)   │
├─────────────────────────────────────────────────┤
│           Layer 1: Web Research Pipeline          │
│  (SearXNG search + Crawl4AI deep reading)        │
└─────────────────────────────────────────────────┘
```

Each layer operates independently and can be used without the others. AutoResearch works on any task. The Harness orchestrates multi-step research. The Pipeline provides raw information.

---

## 2. AutoResearch Protocol (Deli_AutoResearch)

A protocol framework for long-horizon autonomous tasks (days to weeks). Ships no executable code -- it prescribes conventions for state management, stall detection, guardian layering, and behavioral constraints.

### The Three Failure Modes

| Failure Mode | Description | Frequency |
|---|---|---|
| **Cognitive loop** | Successive iterations try similar directions with diminishing returns; unable to escape a local optimum | Common |
| **Stalling** | Agent finishes work, outputs summary, waits for user feedback. Session looks alive, but work has stopped | More common than crashes |
| **Runtime fragility** | Context compaction silently breaks the loop; closing a session takes down parasitic timers | Rare but catastrophic |

The common cause: missing engineering scaffolding, not insufficient model capability.

### Behavioral Constraints (Non-Negotiable)

1. **Zero interaction** -- no prompting the user during a run. No Plan Mode, no question tool, no ending on a question. Continue working until the user stops you. Resolve ambiguity yourself and write the reasoning to the log.

2. **Ready means execute** -- the most common hidden violation: finishing all preparation and then asking "should I submit?". The purpose of preparation is execution.

3. **Callback means report-alive** -- after context compaction the loop dies silently. The first action of every callback updates its own `last_seen`, then checks liveness; on detecting failure it restarts immediately.

4. **Persist state to files** -- all progress is written to `state/` files, not conversation memory. Each iteration starts a fresh session, injecting only curated state; never use resume.

5. **Guardian / worker separation** -- a heartbeat patrol may take only three actions on tasks that are not its own: liveness-check, restart, nudge. It does not read their data, modify their state files, or report to the user on their behalf.

### State File Structure

```
{task}/state/
├── task_spec.md           # goal / milestones / success criteria
├── progress.json          # {iteration, total_findings, status, stale_count}
├── findings.jsonl         # accumulated findings (append-only)
├── directions_tried.json  # directions already tried
└── iteration_log.jsonl    # per-iteration summary

{task}/logs/
├── work.jsonl             # written by work agent
├── orchestrator.jsonl     # written by orchestrator
└── heartbeat.jsonl        # written by heartbeat watchdog
```

### Stall Detection and Pivoting

| Mechanism | Rule |
|---|---|
| Stall detection | An iteration with 0 new findings or a metric drop increments `stale_count` |
| Forced pivot | `stale_count >= 2` -- change a structural constraint, not tactical parameters |
| Direction diversity | A new direction must differ from every tried one |
| Round cap | A single work session caps at 15 rounds or 30 minutes |

The key insight: **"Pivot structure, not tactics."** When a task stalls repeatedly within a frame, the gain usually comes from correcting the environment or structural constraint, not from tuning strategy parameters harder inside the existing frame.

### Heartbeat Watchdog (Three-Layer V3)

| Layer | Form | Depends on | Role |
|---|---|---|---|
| L0 | Resident shell guard | No session | Heartbeat stale > 2h -- spin up emergency patrol via headless agent |
| L1 | Durable cron, hourly | A living interactive session | Check each loop's `last_seen`, restart timed-out loops, detect stalling |
| L2 | Business loop | Each its own session | First line of each callback updates its own `last_seen` |

Any one layer dying can be detected and recovered by another. This is defense in depth for agent reliability.

### Subagent Scheduling Patterns

| Pattern | Use | Key Idea |
|---|---|---|
| A Goal-driven | Research iteration | Inject tried directions, require verifiable findings, write back to `findings.jsonl` |
| B Parallel exploration | Complex sub-problems | Fire multiple agents in one message: investigation, refutation, cross-domain analogy |
| C Experiment run | Long compute jobs | Start minute-level polling right after submit: auto-diagnose errors, fix, resubmit |
| D Verification | Post-iteration QA | An independent subagent audits the evidence chain of findings |

### Validated Output

The framework has been validated on academic paper writing:

| Paper | Pages | Citations | Self-rated |
|---|---|---|---|
| Autonomous Research Agents | 59 | 228 | 8.0/10 |
| Continual Learning | 65 | 326 | 8.0/10 |
| Long-Horizon Decision-Making | 55 | 384 | 8.0/10 |
| Self-Play (285B RL experiment) | 75 | 217 | 8.6/10 |

The longest continuous run on record: 72 hours, 6 directional human inputs, zero operational intervention.

---

## 3. Hyper Harness Orchestrator (v3.0)

The orchestrator manages multi-phase research cycles. Each phase maps to a specific type of work.

### The Five Phases

```
I.   Ideation    -- SearXNG + Crawl4AI + OpenCode generate hypotheses
II.  Execution   -- OpenCode executes the best approach
III. Audit       -- Red Team adversarial verification
IV.  Fixation    -- HashMath cryptographic anchoring
V.   Governance  -- Proposals from failures, Congress every N=3 iterations,
                     Kanban escalation, Telegram notifications,
                     wiki export (wiki, elo-arena, failure-tree)
```

### Module Registry

The orchestrator integrates these modules:

| Module | Purpose |
|---|---|
| **Plugin Registry** | Open-Closed extension system |
| **ACP Client** | Single model gateway (OpenCode) |
| **SearXNG** | Privacy-respecting web search |
| **Crawl4AI** | Deep reading and page extraction |
| **Failure Tree** | Branch/fail/explore tracking |
| **Reflector** | Verbal reinforcement for improving outputs |
| **Elo Consolidator** | Tournament-style ranking of findings |
| **Red Team Arena** | Adversarial audit of results |
| **HashMath** | Cryptographic anchoring of findings |
| **Telegram Gateway** | Outer loop notifications |
| **Watchdog** | Stall detection and recovery |
| **Governance** | Phase V -- Centralismo Democratico |

### Architecture Principle

All model inference flows through a single path:

```
Orchestrator → ACP Client → OpenCode → mlx-lm / vllm-mlx (localhost:8080)
```

The harness orchestrates **WHAT** to ask, not **HOW** to serve. This separation means the entire serving layer can be swapped without changing orchestration logic.

---

## 4. Web Research Pipeline

The information gathering layer, combining SearXNG for broad search with Crawl4AI for deep reading.

### SearXNG

A privacy-respecting metasearch engine running locally in Docker. It aggregates results from multiple search engines without forwarding user data.

- **Endpoint:** `http://searxng:8080` (within Docker) or `localhost:8080` (from host)
- **Configuration:** Environment variable `SEARXNG_INSTANCE`
- **Use case:** Broad hypothesis generation, finding relevant papers, discovering infrastructure details

### Crawl4AI

A web scraping tool designed for AI research pipelines. It extracts clean, readable content from web pages.

- **Use case:** Deep reading of papers, documentation, and technical articles discovered by SearXNG
- **Integration:** Called by the orchestrator during Phase I (Ideation)

### Pipeline Flow

```
Research Question
    → SearXNG (broad search, multiple engines)
    → Crawl4AI (deep read top results)
    → OpenCode (analyze and synthesize)
    → Findings (appended to findings.jsonl)
```

---

## 5. Elo Arena and Failure Tree

Two tracking mechanisms that provide quantitative feedback on research quality.

### Elo Arena

A tournament-style ranking system for hypotheses, findings, and approaches. Each finding competes against others; the Elo rating reflects its quality relative to the corpus.

**Use in practice:** The ClickFix investigation used Elo ratings to track the quality of different forensic analyses and infrastructure assessments. The unit distance research used Elo to rank hypotheses (H4 at Elo 1500, H15 at Elo 2200, H16 at Elo 2350).

### Failure Tree

A structured tracking system for failed approaches. Each failure is categorized, and the tree accumulates patterns that inform future pivots.

**Categories:**
- `methodological` -- wrong approach, insufficient data
- `technical` -- implementation bugs, environment issues
- `conceptual` -- flawed assumptions, misunderstanding of the problem

The failure tree prevents the cognitive loop failure mode by forcing the system to recognize when a direction has been exhausted.

---

## 6. Operational Methodology

### How a Research Session Works

1. **Initialization** -- the user provides a research question or task specification
2. **State setup** -- `state/task_spec.md` is written with goals, milestones, and success criteria
3. **Orchestrator starts** -- the phase loop begins, running Ideation → Execution → Audit → Fixation → Governance
4. **Work agents are spawned** -- each iteration starts a fresh session with injected state (never resume)
5. **Stall detection** -- the watchdog monitors progress; if `stale_count >= 2`, a structural pivot is forced
6. **Results are anchored** -- HashMath provides cryptographic fixation of findings
7. **Governance** -- every N=3 iterations, a Congress reviews accumulated findings and proposes direction changes
8. **Wiki export** -- findings are published to the wikifita knowledge base

### Anti-Contamination Protocol

For sensitive research (like the unit distance conjecture), additional constraints apply:

- No access to external solutions or benchmarks
- Web searches are blocked for specific values or papers
- Findings are validated against the original source materials only
- Enforcement via PreToolUse hooks on WebSearch and Bash tools

### Quality Standards

- All scripts: `#!/bin/bash` with `set -euo pipefail`
- State persisted to files, not conversation memory
- Fresh sessions over resume (context accumulation causes cognitive loops)
- Citation-like content verified every 20 entries, never batched
- Unresolvable external-dependency failures escalate; never abandon silently

---

## 7. Connection to Other Co-Fita Components

| Component | Relationship |
|---|---|
| [[co-fita-infrastructure]] | The infrastructure layer provides the Docker stack, dashboard, and LLM backend that the research operations run on |
| [[co-fita-pam-setup]] | PAM setup ensures Touch ID works in all terminal contexts, including the tmux sessions where long-running agents operate |
| [[co-fita-clickfix-vaccine]] | The ClickFix investigation was one of the first operational uses of the research pipeline (SearXNG for infrastructure analysis, Crawl4AI for deep reading of blockchain explorers) |
| [[clickfix-handoff]] | The ClickFix handoff document uses the same IOC tracking and timeline reconstruction patterns established in the research operations |
| [[unit-distance-methodology]] | The unit distance research used the AutoResearch protocol's stall detection and direction diversity mechanisms to navigate 16 hypotheses |

---

## 8. Design Principles

1. **Fresh session over resume** -- context accumulation is the primary cause of cognitive loops. Each iteration starts fresh; state is injected via files.

2. **Separate execution from evaluation** -- the agent doing the work does not judge its own progress. Stall determination is made by the orchestration layer based on quantitative metrics.

3. **Enforced direction diversity** -- before each iteration, the system reads the list of tried directions; a new direction must differ from all history. This prevents the cognitive loop.

4. **Zero interaction during runs** -- the system resolves ambiguity internally and writes reasoning to logs. The human provides direction, not micromanagement.

5. **Defense in depth for reliability** -- three independent watchdog layers ensure that no single point of failure can kill a long-running research session.

6. **Local-first everything** -- search, inference, vector storage, and orchestration all run on the local machine. No cloud dependencies for core functionality.