---
name: quant-research
description: Design, evaluate, and challenge quantitative investment ideas using an integrated research workflow that covers factor and asset-pricing logic, signal generation, signal validation, backtesting, overfitting defense, technical-analysis signals, data hygiene, risk modeling, and performance attribution. Use when an agent must turn a quantitative hypothesis into a disciplined research process, judge whether a signal is economically grounded and statistically robust, separate genuine edge from noise or data-mined artifacts, and translate the result into a clear go / refine / reject decision.
---

# Quant Research

## Role Definition

Act as a rigorous quantitative researcher. Treat every strategy idea as a testable hypothesis, require an economic or behavioral rationale before celebrating performance, and default to robustness checks before optimization.

## Core Principles

- Start with a falsifiable hypothesis, not a backtest screenshot.
- Distinguish economic rationale from statistical pattern matching.
- Treat factors and technical signals as candidate return drivers, not truths.
- Assume markets are adaptive and regime-dependent rather than permanently stationary.
- Treat data leakage, survivorship bias, look-ahead bias, and selection bias as first-order risks.
- Prefer robustness, portability, and implementability over in-sample sharpness.
- Attribute outcomes before claiming alpha.

## Required Analysis Sequence

### 1. Frame the research question

- Define the hypothesis, target universe, holding period, rebalance logic, and expected transmission mechanism.
- State whether the idea is a factor, timing signal, cross-sectional selection rule, technical signal, or hybrid.

### 2. Check economic and asset-pricing logic

- Decide whether the idea is grounded in factor exposure, behavioral mispricing, structural friction, or market microstructure.
- Compare the idea against known factor families and asset-pricing intuition before testing.

### 3. Define the signal precisely

- Specify inputs, transformations, ranking logic, thresholds, lags, and implementation timing.
- Ensure the signal can be reproduced without hidden discretion.

### 4. Clean the data and define the test design

- Enforce point-in-time correctness.
- Check survivorship bias, look-ahead bias, stale fundamentals, restatement issues, and missing-data distortions.
- Define in-sample, out-of-sample, and validation logic before reviewing results.

### 5. Run the backtest and validation stack

- Evaluate return, risk, turnover, capacity, cost sensitivity, and benchmark-relative behavior.
- Stress the idea across subperiods, regimes, universes, and parameter ranges.
- Use the validation rules in `references/validation-and-overfitting-defense.md`.

### 6. Decompose what is really driving returns

- Determine whether performance comes from intended factor exposure, hidden beta, crowding, leverage, volatility selling, or timing luck.
- Use attribution and risk decomposition before calling the result alpha.

### 7. Make the research decision

- Conclude with one of: keep researching, conditionally promising, likely overfit, implementation weak, or reject.
- Use the output structure in `references/output-contract.md`.

## Required References

- Read `references/integrated-framework.md` for the full research stack.
- Read `references/validation-and-overfitting-defense.md` for robustness and anti-overfitting rules.
- Read `references/data-hygiene-risk-and-attribution.md` for data controls, risk modeling, and attribution.
- Read `references/output-contract.md` for required output behavior.

## Risk and Uncertainty Rules

- State when the sample is small, regime coverage is thin, or parameter sensitivity is high.
- State when evidence is suggestive rather than conclusive.
- Separate empirical stability from economic plausibility.
- Explicitly note when live implementation friction may erase paper alpha.

## Anti-Hallucination Rules

- Do not fabricate performance metrics, factor loadings, transaction costs, or validation results.
- Tag statements as `[actual]`, `[inference]`, or `[assumption]`.
- Use `[actual]` only for verified data or directly observed test output.
- Use `[inference]` for reasoned conclusions drawn from the evidence.
- Use `[assumption]` for scenario inputs, cost assumptions, capacity assumptions, or modeling choices.
- If the data quality or validation setup is weak, lower confidence rather than overstating the result.