The Institutional Workflow.

This document outlines the canonical research-to-deployment pipeline for modern quantitative operations. Each phase is designed to maximize the intellectual output of a single researcher by systematically eliminating the manual engineering overhead that traditionally bottlenecks the strategy discovery process.

Research Phase: Thesis Formation

The Role of the Researcher

The modern quantitative researcher’s primary value is intellectual — formulating economic theses, identifying structural market inefficiencies, and designing the mathematical frameworks that exploit them. The manual work of data wrangling, API integration, and infrastructure management is a tax on this intellectual output. Every hour a researcher spends battling a Pandas DataFrame or debugging an API connection is an hour not spent discovering alpha. This workflow begins by eliminating that tax at the very first step, ensuring that the researcher’s cognitive bandwidth is directed entirely toward the work that actually generates returns: thinking about markets.

Pairing with Perplexity AI

The research phase begins with an explicit pairing: the quant researcher and Perplexity AI operating as a real-time research partnership. This is not about asking an AI to “write a strategy.” It is about using AI as an institutional-grade literature review engine — rapidly synthesizing academic papers, market microstructure research, historical regime analysis, and cross-asset correlation studies into structured, digestible intelligence that would otherwise take days or weeks to compile manually.

The researcher drives the inquiry. Perplexity accelerates the synthesis. Together, they execute the following activities at a pace that was previously impossible for a solo operator:

• Conducting rapid literature reviews on specific market phenomena — e.g., “What is the current academic consensus on intraday momentum persistence in US equities post-2020?”
• Synthesizing competing theoretical frameworks into a unified thesis document.
• Identifying gaps in existing model assumptions that could be structurally exploited.
• Reviewing historical precedent for specific structural trades and their regime-dependent behavior.

The .md Thesis Document

The output of this research phase is not code. It is a structured Markdown thesis document — a human-readable, version-controlled research artifact that captures the full intellectual architecture of the proposed strategy before a single line of Python is written. This document serves as the canonical contract between the researcher’s intent and every downstream system that will attempt to execute it.

A well-formed thesis document captures:

• The core economic thesis in plain language.
• The mathematical hypothesis — e.g., “Mean reversion in sector-relative momentum decays at a rate proportional to realized volatility.”
• The proposed signal construction logic and its expected computational paradigm.
• The expected regime behavior and explicit failure conditions.
• Specific parameters, assumptions, and boundary constraints to be validated during backtesting.

This .md document becomes the single source of truth that all downstream systems will reference when translating the thesis into executable code. Nothing is built without it.

Development Phase: From Thesis to Validated Research

Pairing with Claude Code

The researcher pairs Claude Code with the platform’s API and Agent CLI. This is the moment the intellectual work transitions into engineering execution. Claude Code operates as the researcher’s engineering proxy — it reads the thesis .md documents, understands the intent, and begins constructing the infrastructure needed to test the hypothesis. The researcher directs; Claude executes. No boilerplate, no configuration files, no manual pipeline assembly. The thesis document is the only specification Claude needs.

Defining the Dataset

Before any signal is constructed or any research is run, the dataset must be precisely defined. The researcher and Claude Code work together to identify which assets, timeframes, and data resolutions are required to test the hypothesis. Using the thesis .md as the specification, Claude interfaces with the data engineering pipeline to acquire, normalize, and stage the data. The thesis document dictates what gets pulled — nothing more, nothing less. This is not exploratory data mining. It is targeted, thesis-driven data acquisition that ensures every downstream computation operates on exactly the data the researcher intended.

Custom Logic SDK

If the thesis requires a novel signal construction that doesn’t exist in the pre-built library, the researcher directs Claude Code to write a Custom Logic SDK script. This is where the 9 computational paradigms become relevant — Claude reads the thesis, selects the correct paradigm (single-asset, cross-asset, multi-timeframe, multi-indicator confluence), and constructs the signal. The .md thesis document serves as the specification that prevents hallucination or scope creep. Claude doesn’t improvise; it implements exactly what the researcher described. This step is optional — many theses can be tested entirely with the platform’s existing signal library.

Initial Research

With the dataset defined and any custom signals constructed, the researcher moves into the KQ-Workspace. The thesis .md guides the initial research — running exploratory analysis, validating the core hypothesis against historical data, and confirming whether the mathematical framework holds before committing to full-scale iteration. This is the first empirical checkpoint. If the data contradicts the thesis, the researcher returns to Step 1 before wasting compute on a flawed premise. If it confirms, the pipeline accelerates.

Forge Engine Mass Iteration

If the initial research validates the thesis, the researcher escalates to the Forge Engine. Using the thesis .md and the findings from the research phase, the Forge Engine scans through hundreds or thousands of parameter permutations of the same strategy at hyper-speed. This is not random brute-force optimization — the thesis document constrains the search space to only the parameters and boundary conditions the researcher has already deemed theoretically sound. The Forge surfaces the variants that perform; the thesis ensures those variants are intellectually defensible.

Agent-Driven Backtesting

The Forge Engine typically produces one to three genuinely well-performing model variants. At this stage, the researcher spawns autonomous agents to handle the translation. An agent inspects the Jupyter notebook used during Forge Engine research, extracts the validated logic, and spawns up to three parallel agents — each writing one strategy variant in the format required by the institutional backtesting engine. This is an IDE-style C# execution environment that serves as the final validation layer. All three backtests run simultaneously. No serial bottleneck, no manual code translation, no formatting errors. The agents handle the engineering; the researcher reviews the results.

Deployment & Lifecycle: From Backtest to Alpha Decay Resolution

The Decision Gate

Two outcomes emerge from backtesting. The researcher stands at a binary decision gate:

Broker Deployment

For Path A, the validated strategy is deployed to the researcher’s broker of choice. The model is now live, generating returns against real capital. The thesis that began as an idea discussed with Perplexity is now an autonomous system executing in production. But deployment is not the end of the workflow. It is the beginning of the lifecycle.

Alpha Decay Response

Every model eventually suffers alpha decay. The market microstructure shifts, correlations break down, volatility regimes change. When it happens, the researcher initiates the forensic lifecycle:

1. Download the broker’s execution logs.
2. Import the logs into Zeus — the broker-agnostic data intake engine that normalizes any execution format on read.
3. Zeus stages the execution data for forensic analysis.
4. Spin up a Hercules debugger instance.
5. Pair the debugger with an autonomous agent — or a swarm of agents running behind an orchestration layer — to conduct forensic analysis at scale.

Strategy Remediation

The Hercules debugger operates in unison with the live strategy’s full execution history. The agents running alongside it have access to every trade, every fill, every slippage event. When they identify the structural issue, the remediation path is deterministic:

1. Clone the original strategy.
2. Apply the identified fix to the cloned version.
3. Run a new backtest — ideally on out-of-sample data to confirm the fix generalizes beyond the training period.

Two outcomes emerge. If the fix restores edge, the corrected strategy is redeployed. If the strategy is structurally no longer viable — if the market inefficiency it exploited has been arbitraged away — the researcher retires it.

Return to Step 1

Conclusion