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.