Co-Fita Hyper-Harness

What Is Co-Fita

Co-Fita is a self-evolving AI agent orchestration system that combines autonomous research loops with adversarial verification, cryptographic anchoring, and democratic governance. It is designed so that AI agents can propose, debate, vote on, and implement improvements to the very system that orchestrates them — a system that evolves through its own operation.

The system is built by Alefita (Lider Suprema) and operates on a philosophy of Centralismo Democratico — agents observe failures, propose improvements, deliberate collectively, and the human principal retains final approval authority (chancela).

Core design principle: The harness orchestrates what to ask, not how to serve models. All LLM inference flows through a single gateway (OpenCode via ACP), which handles model routing internally.

The Three Pillars

1. Hyper-Harness Core

The orchestration engine at harness_core/. Implements a 5-phase autonomous research loop:

Ideation — Search (SearXNG) + deep reading (Crawl4AI) + LLM hypothesis generation
Execution — Model executes the best approach via ACP
Audit — Red Team adversarial verification (steganography detection, reward hacking prevention)
Fixation — HashMath cryptographic anchoring (SHA-256 chain)
Governance — Proposals from failures, Congress deliberation, Kanban escalation, wiki export

The loop runs continuously via a background daemon thread (bg_monitor.py) in the Odysseus dashboard. A Watchdog monitors for stalls and triggers recovery.

2. Odysseus Dashboard

A forked web workspace (dashboard/) providing:

Chat sessions with model routing (local Gemma 4 12B, remote DeepSeek V4)
Governance Kanban board (7 columns, drag-and-drop)
Task scheduler with background monitor
FastAPI backend + SQLAlchemy database
MCP server integration

The dashboard runs at localhost:7000 and serves as both the operational UI and the data backend for the harness.

3. Democratic Centralism (Centralismo Democratico)

A governance layer inspired by deliberative democratic systems, where:

Worker agents generate proposals from direct observation (especially failures)
National Congress convenes periodically for collective deliberation
Elo Tournament provides pairwise debate scoring
Lider Suprema (Alefita) gives final chancela via Telegram or web
Strategy Deliberation happens after chancela, before implementation
Promotion deploys artifacts to .agents/skills/ or .agents/rules/

The governance is not theoretical — it is isomorphic to GRPO (Group Relative Policy Optimization): proposals are policy samples, Elo debates are reward scoring, chancela is RLHF.

Architecture

graph TB
    subgraph Dashboard["Odysseus Dashboard (Web UI)"]
        UI["Chat + Model Routing"]
        KB["Kanban Board (7 cols)"]
        BG["bg_monitor.py (daemon)"]
        API["FastAPI + SQLAlchemy"]
    end

    subgraph Core["Hyper-Harness Core"]
        ORC["UnifiedHyperHarness<br/>5-Phase Loop"]
        SEARX["SearXNG<br/>localhost:8888"]
        CRAWL["Crawl4AI<br/>localhost:11235"]
        RED["Red Team Auditor"]
        HASH["HashMath Verifier"]
        TREE["Failure Tree"]
        ELO["Elo Consolidator"]
        REF["Reflector"]
        GOV["Governance Engine"]
    end

    subgraph Outer["Outer Loop"]
        TG["Telegram Bot"]
        WIKI["Wiki Sync"]
        WD["Watchdog (3-layer)"]
        MCP_SVR["MCP Server"]
    end

    BG -->|"daemon thread"| ORC
    ORC --> SEARX
    ORC --> CRAWL
    ORC --> RED
    ORC --> HASH
    ORC --> TREE
    ORC --> REF
    ORC --> ELO
    ORC --> GOV
    GOV --> KB
    TG -->|"chancela"| GOV
    WD -->|"stall detection"| BG
    ORC -->|"wiki export"| WIKI
    MCP_SVR --> GOV
    MCP_SVR --> RED
    MCP_SVR --> ELO

Key Design Decisions

Single Model Gateway

All model inference flows through ACPClient -> Odysseus llm_core.py. The harness never selects models directly. This means:

Models configured in the dashboard are automatically available
The harness focuses on orchestration logic, not serving infrastructure
Swapping models (local to remote, one provider to another) requires zero harness changes

File-Based Persistence

All state is persisted to JSONL files and JSON state files. This is deliberate:

Survives context compaction in long-running sessions
Audit trail is append-only
Human-readable and git-friendly
No external database dependency for the harness core (dashboard uses SQLAlchemy)

Open-Closed Plugin Architecture

Plugins are registered via typed registries (registry.py) using the Open-Closed principle:

Registry	Interface	Implementations
`SearchProviderRegistry`	`SearchProvider`	SearXNG
`WebCrawlerRegistry`	`WebCrawler`	Crawl4AI
`GatewayRegistry`	`NotificationGateway`	Telegram
`ModelProviderRegistry`	`ModelProvider`	OpenCode/ACP
`VerificationRegistry`	`VerificationLayer`	Red Team, HashMath
`LearningRegistry`	`LearningBackend`	Placeholder

Adding a new search provider, crawler, or notification channel requires only implementing the interface and decorating with @Registry.register("name").

Technology Stack

Layer	Technology	Purpose
Package Manager	uv (PEP 723)	Dependency management, script execution
Python	3.13+	Runtime
Web Framework	FastAPI	Dashboard API
Database	SQLAlchemy + SQLite	Dashboard persistence
Search	SearXNG (Docker)	Meta-search across 70+ engines
Crawling	Crawl4AI (Docker)	Deep page extraction, markdown
MCP	FastMCP	Model Context Protocol server
Telegram	Bot API (long-polling)	Mobile governance, notifications
Cryptography	SHA-256 (stdlib)	Hash chain anchoring

Repository Structure

co-fita/
├── pyproject.toml              # Root workspace (uv monorepo)
├── dashboard/                  # Odysseus Web Dashboard (inner git repo)
│   ├── app.py                  # FastAPI application
│   ├── core/database.py        # SQLAlchemy models
│   ├── routes/governance_routes.py
│   ├── src/governance_engine.py
│   ├── src/bg_monitor.py       # Background orchestrator daemon
│   ├── src/llm_core.py         # LLM abstraction
│   └── static/                 # Frontend (Vanilla JS)
│
├── harness_core/               # Hyper-Harness Orchestration Engine
│   ├── orchestrator.py         # Main 5-phase loop
│   ├── red_team.py             # Adversarial auditor
│   ├── hash_math.py            # Cryptographic verifier
│   ├── failure_tree.py         # Branch/fail/explore tree
│   ├── consolidator.py         # Elo tournament ranking
│   ├── reflector.py            # Verbal reinforcement
│   ├── governance.py           # Proposal lifecycle
│   ├── committee.py            # Central Committee & Congress
│   ├── telegram_governance.py  # Telegram slash commands
│   ├── watchdog.py             # Stall detection
│   ├── wiki_sync.py            # Auto wiki population
│   ├── plugins.py              # SearXNG, Crawl4AI, Telegram impls
│   ├── registry.py             # Typed plugin registries
│   ├── acp_client.py           # Model gateway adapter
│   ├── state_manager.py        # State persistence
│   └── harness_mcp_server.py   # MCP server implementation
│
├── .agents/skills/             # Agent Skills
│   ├── Deli_AutoResearch/      # Long-horizon autonomous protocol
│   ├── telegram_notify/        # Telegram notification skill
│   └── web_research_pipeline/  # SearXNG + Crawl4AI pipeline
│
└── unified-harness-wiki/       # Auto-populated knowledge base

Relationship to Other Projects

Co-Fita builds on and integrates with several other research streams in the Alefita ecosystem:

unit-distance-methodology — The research protocol (generate, debate, evolve) that Co-Fita operationalizes at system level. The Elo tournament in Co-Fita is directly inspired by the Elo ranking system used in the unit distance research.
co-scientist — Google DeepMind's Co-Scientist architecture (Nature 2026) informed the multi-agent swarm model. Co-Fita's Central Committee and Congress protocol are the governance layer that Co-Scientist lacked.
red-team-arena — The adversarial verification concept from the unit distance project's safety framework. Co-Fita's RedTeamAuditor is the concrete implementation, checking for reward hacking, steganography, and metric manipulation.
unit-distance-elo-ranking — The Elo calibration scale that the EloConsolidator extends. In Co-Fita, Elo is used not just for research hypotheses but for skills, rules, workflows, and governance proposals.

Quick Start

# Clone and install
git clone https://github.com/your-org/co-fita.git
cd co-fita
uv sync --all-packages

# Initialize dashboard database
cd dashboard && uv run python setup.py && cd ..

# Start dashboard (includes background orchestrator)
cd dashboard && uv run python app.py
# Dashboard: http://localhost:7000

# Optionally start search/crawl services
docker compose -f dashboard/docker-compose.yml up -d searxng crawl4ai

# Configure Telegram governance
mkdir -p ~/.hermes
cat > ~/.hermes/.env << 'EOF'
TELEGRAM_BOT_TOKEN=your_bot_token
TELEGRAM_HOME_CHANNEL=your_chat_id
EOF

Version History

Version	Date	Milestone
0.1.0	2026-06-17	Initial implementation: basic loop, failure tree, reflector, Elo consolidator
1.0.0	2026-06-18	Full governance system, Odysseus integration, Telegram bot, uv workspace, 5 critical bug fixes

Key Metrics

5-phase loop with cryptographic chain integrity
7-column Kanban for governance proposals
6 typed plugin registries (Open-Closed architecture)
3-layer watchdog for stall detection
32 K-factor Elo for tournament ranking (standard chess Elo)
SHA-256 hash chain for discovery anchoring
129 packages resolved in unified lockfile