The research daemon

The research daemon is Forven's autonomous background loop. While Forven is running, it invents new strategy hypotheses, drives candidates through the gauntlet, retires the ones that fail, and surfaces a shortlist of survivors for you to review. It is the engine behind hands-off research.

This is an operator surface. The daemon does real work — spawning hypotheses, running backtests, promoting and archiving strategies — so it is governed by autonomy modes, the scheduler, and operator approval gates. Nothing it produces reaches real capital without surviving the full pipeline and a human approval.

Forven is a research tool. The daemon evaluates strategies against historical and live data; survival in the gauntlet is not a prediction of future results, and nothing here is financial advice.

What the daemon is

"Daemon" covers two cooperating things in Forven. Keep them distinct:

• The research loop — the autonomous discovery-and-testing engine that this page is about. It is a set of scheduled jobs (crucible discovery, the planner, the evolution testing step, paper graduation, learning, and maintenance) that move strategies along the pipeline without you clicking anything.
• The process daemon (daemon.py) — the long-running async loop that keeps live state alive: streaming prices, enforcing hard risk controls, and reconciling exchange positions. It runs whether or not autonomous research is enabled. The research loop rides on top of it.

The research loop never trades. It only researches: it proposes ideas, tests them, and changes a strategy's lifecycle stage. Live execution is a separate concern handled by the scanner, which this page contrasts below.

How it differs from the live scanner

This is the most common point of confusion, so it is worth stating plainly.

The daemon's job ends when a strategy graduates to paper and, eventually, live. From there the scanner takes over live signalling. Think of the daemon as the laboratory and the scanner as the trading floor.

The research loop, stage by stage

The daemon drives the real pipeline:

researching → backtesting → quick_screen → gauntlet → paper → live_graduated → retired

The public site simplifies these to screen → gauntlet → candidate → live, where candidate is the paper stage. The app uses the real names; you will see them in the strategy event log.

1. Ideation. When the active research pool runs dry, the planner emits a propose_crucible task. A crucible is a market thesis — indicators, regime, timeframe, assets, and a claimed edge. Crucibles can be invented by an agent (origin=agent), harvested from external sources, or seeded by you.
2. Refine and develop. The planner dispatches refine_crucible to detail the thesis, then develop_candidate to spawn child strategies under it. Each crucible has spawn limits and a 3-strike retry cap so a bad idea cannot churn forever.
3. Quick screen. Every candidate hits the quick_screen gate first. Terminal failures (duplicate, overfit, or too few trades with an undefined Sharpe) auto-archive the strategy with no re-queue. Non-terminal holds — like a data-quality issue — are re-queued.
4. Gauntlet. Survivors enter the gauntlet, where the daemon auto-runs the readiness steps: timeframe sweep, optimization, apply-best-params, confirmation backtest, and the validation suite (walk-forward analysis, Monte-Carlo, parameter jitter, cost stress, and regime split). The output is a composite robustness score. See the gauntlet for the battery in detail.
5. Promotion to paper. When all gates pass, the daemon queues a promotion. By default this requires an operator approval; with auto_approve_promotions enabled it proceeds automatically. Paper is local-simulation only — no real capital.
6. Paper graduation. After 7+ days in paper, the paper-graduation job checks the strict paper-to-live gates (duration, trades, return, drawdown). If they pass, the strategy promotes to live_graduated.
7. Retirement. Strategies that decay — fitness below the floor or drawdown over the ceiling — are archived with a reason. Their linked quant skills take a confidence hit, closing the learning loop.

Illustrative promotion gates from the evolution policy include fitness 60+, walk-forward degradation under 30%, profit factor over 1.5, and max drawdown under 15%. These are tunable in configuration; treat the numbers here as illustrative, not guarantees.

Relation to the brain and agents

The daemon does not think for itself. The brain is the sole orchestrator: it evaluates quality gates, decides lifecycle transitions, and dispatches work to specialized agents (strategy-developer, simulation-agent, risk-manager, execution-trader). The daemon's scheduled jobs are the heartbeat that triggers the brain to act on schedule.

• The planner decides what research to do next and queues tasks.
• Agents carry out those tasks — writing strategy code, running backtests — and return results to the brain.
• The brain judges the results against the gates, records the outcome, and updates its memory and lessons.

Agents never task each other and never place trades. Every capital-consuming transition the daemon proposes flows through the approval queue unless you have explicitly relaxed the policy.

Controlling the daemon

The daemon's aggressiveness is set by your autonomy mode, not by a single on/off switch. See autonomy modes for the full model:

• Manual (safe default) — autonomous research jobs are frozen. The daemon keeps the process loop alive (prices, risk, reconciliation) but does not invent or promote on its own.
• Semi-auto — hardening is allowed (the daemon can run the gauntlet and recalibrate), but new research generation is blocked.
• Auto — the full loop runs: ideation, testing, promotion, and learning.

Autonomous discovery has its own switches, independent of the mode:

// research settings (config.json / Settings → Lab)
{
  "autonomous_discovery": {
    "enabled": false,               // default: discovery is off
    "mode": "operator_approves",    // or "autonomous"
    "max_open_discovery_tasks": 1   // cap on concurrent harvests
  }
}

With enabled: false (the default) the daemon never harvests external ideas on its own — you trigger discovery manually. With mode: "operator_approves", harvested crucibles land as proposed in the Hypothesis Manager for your review before they advance.

Steps — turn on autonomous research

1. Open /ops and confirm the system is running (not paused).
2. Set the pipeline autonomy mode to semi-auto or auto on the ops dashboard. Manual freezes the research loop.
3. (Optional) Open Settings → Lab and enable autonomous_discovery if you want the daemon to harvest fresh ideas, not just test the ones already in the pool.
4. Confirm the relevant scheduler jobs (promotion loop, verdict loop, paper graduation, daily learning) are enabled.
5. Leave the app running. The daemon works on its scheduled cadence.

What you'll see: new strategies appear in the strategy list with quick_screen and gauntlet stages, the activity feed logs planned and assigned task counts, promotions queue up in the approvals page (unless auto-approved), and the Hypothesis Manager fills with crucibles and their verdicts. Survivors surface at the top as the shortlist.

Manual triggers

You do not have to wait for the schedule. The local API exposes manual kicks for each stage of the loop:

# Force a crucible-discovery run, bypassing the enabled flag
curl.exe -X POST "http://127.0.0.1:8003/crucible-discovery/run?force=true"

# Run one planner cycle (up to 3 work items)
curl.exe -X POST "http://127.0.0.1:8003/planner/cycle?limit=3"

Discovery returns { created, task_id?, mode, reason? }; the planner returns { planned, assigned, assigned_task_ids, actions }. Authentication and the full endpoint catalog are in the API reference — these calls assume a local, single-user setup.

The process daemon (daemon.py)

The research loop only runs because the process daemon keeps live state healthy underneath it. Its tick, in brief:

• Price feed — streams HyperLiquid mids over WebSocket, falling back to polling every ~15s, and publishes a shared price snapshot that scanners consume.
• Risk cycle — recomputes account equity against the high-water mark. If drawdown reaches 10% the kill-switch trips, flattening all positions autonomously (no approval) and re-sweeping for residuals. A 5% daily loss triggers a halt.
• Liquidation watch — every ~60s it measures each position's distance to its liquidation price and alerts when it crosses a warning (< 15%) or critical (< 7%) band.
• Reconciliation — roughly every 600s it compares exchange positions against the local books; on a mismatch it blocks new entries and alerts you.
• Heartbeat — every ~5m it logs open/closed trade counts, prices, sentiment, and regime to the activity table, and to Discord if configured.

These controls are hard and autonomous. The kill-switch acts without waiting for you. See risk & safety for how to read and respond to these states.

Caveats

• Paper (optionally on the HyperLiquid testnet) is the supported mode, so the daemon's live_graduated promotions stop short of real-capital execution; live/mainnet is unsupported and at your own risk.
• The crucible planner and the hypothesis promotion loop both dispatch develop_candidate work to the same agent pool; their de-duplication is best-effort, and under heavy load you may see redundant tasks in the queue.
• Autonomous discovery dedup against known crucibles is best-effort — an LLM under load can occasionally re-harvest a near-duplicate thesis.
• Daemon health is visible in health monitoring via the heartbeat; if the heartbeat goes stale, see troubleshooting before assuming the loop has stopped.

Forven is a research tool. The daemon's backtests, robustness scores, and shortlists are illustrative process output, not predictions of profit, and nothing here is financial advice. No strategy the daemon produces touches real capital without surviving the gauntlet and your explicit approval.

Related

• Crucible discovery — how new ideas are invented and harvested
• Hypothesis-driven research — the theses the daemon spawns and judges
• The brain — the orchestrator the daemon's jobs trigger
• Autonomy modes — how to freeze, harden, or fully unleash the loop