> For the complete documentation index, see [llms.txt](https://quandora.gitbook.io/quandora-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://quandora.gitbook.io/quandora-docs/understanding-quandora/quandora-workflow.md). # Quandora Workflow Quandora turns AI-generated market ideas into tested research artifacts, then uses monitoring to decide whether the research loop should restart. This is the main idea: Quandora is not just a one-time backtest. It is a research loop that can keep improving when performance decays. ``` +----------------------+ | factor mining |<----------------+ +----------------------+ | | | v | +----------------------+ | | factor evaluation | | +----------------------+ | | | v | +----------------------+ | | factor / strategy | | | card | | +----------------------+ | | | | | | | performance decay | | restarts mining | | v | +----------------------+ | | strategy | | | construction | | +----------------------+ | | | v | +----------------------+ | | strategy evaluation | | +----------------------+ | | | v | +----------------------+ | | paper trading / |-----------------+ | monitoring | +----------------------+ | | stable | v +----------------------+ | supervised | | deployment | +----------------------+ | v +----------------------+ | optional live | | trading | +----------------------+ ``` *** ### Step 1: Factor Mining Factor mining is where the system searches for candidate market signals. The user or agent starts from a [research task](/quandora-docs/understanding-quandora/research-tasks.md). The task gives the agent a focused behavior to investigate. Inside factor mining, the agent: * reads the research task * checks the [task card](/quandora-docs/understanding-quandora/task-card.md) * reviews allowed [data headers](/quandora-docs/understanding-quandora/our-data.md) * checks memory for duplicates or similar ideas * generates [`plugin.py`](/quandora-docs/understanding-quandora/plugin.py.md) * writes a human-readable formula The output of factor mining is a factor artifact: ``` plugin.py + formula ``` `plugin.py` is the executable factor logic. The formula explains the same idea in readable form. Factor mining answers: ``` What signal should we test? ``` ### Step 2: Factor Evaluation Factor evaluation tests whether the mined factor has evidence. The factor artifact is submitted to Quandora. Quandora validates the artifact, binds supported market data server-side, and runs the backtest / evaluation. The full changing market data is bound by Quandora during evaluation. Factor evaluation may include: * Sharpe * RankIC / IC * ICIR * IC win rate * autocorrelation * return * max drawdown * turnover * cost viability Factor evaluation answers: ``` Did this factor show useful evidence under the test conditions? ``` It does not answer: ``` Will this make money in the future? ``` Backtests are evidence, not promises. See [How Factors Are Judged](/quandora-docs/understanding-quandora/how-factors-are-judged.md) for the exact checks behind every verdict. ### Step 3: Factor / Strategy Card After evaluation, Quandora returns a [factor / strategy card](/quandora-docs/understanding-quandora/factor-card.md). The card is the trust artifact. It turns the raw evaluation into something a human and an AI agent can review. A card may include: * verdict * factor idea * formula * data used * key metrics * assumptions * caveats * reason for rejection, if rejected * suggested next experiment Possible states include: ``` accepted rejected duplicate needs repair failed evaluation ``` The card answers: ``` What did we test, what happened, and what should happen next? ``` If the factor is weak, duplicated, invalid, or too costly, the workflow can stop or return to factor mining. If the factor is promising, it can move into strategy construction. ### Step 4: Strategy Construction Strategy construction turns a promising factor into a testable trading workflow. A factor is only a signal. A strategy defines how that signal would actually be used. Strategy construction should specify: * market or universe * entry logic * exit logic * ranking or selection method * position sizing * rebalance frequency * cost assumptions * liquidity filters * risk limits * deployment target Strategy construction answers: ``` How would this factor become an operating strategy? ``` This step matters because a good-looking factor can still fail when turned into a real workflow with sizing, costs, rebalancing, and risk rules. ### Step 5: Strategy Evaluation Strategy evaluation tests the full strategy, not just the raw factor. This step asks whether the strategy still works after adding trading rules, costs, position sizing, liquidity assumptions, and risk constraints. Strategy evaluation may check: * return * Sharpe * drawdown * volatility * win rate * turnover * cost viability * liquidity limits * regime sensitivity * correlation to other strategies Strategy evaluation answers: ``` Does the complete strategy survive more realistic testing? ``` If the strategy fails, it can go back to strategy construction or all the way back to factor mining. If it passes, it can move into paper trading / monitoring. ### Step 6: Paper Trading / Monitoring Paper trading / monitoring is where the strategy is watched forward without risking real money. This step tracks whether the strategy behaves like the backtest suggested it should. Monitoring may include: * simulated orders * forward performance * PnL and equity curve * drawdown * turnover * cost drift * regime changes * signal decay * alerts * trade-log memory Paper trading / monitoring answers: ``` Does the strategy keep working after the backtest? ``` This is the main decision point in the workflow. ### Step 7A: If Performance Decays, Restart Factor Mining If performance decays, the workflow loops back to factor mining. Decay can mean: * performance weakens * drawdown becomes larger than expected * turnover or costs increase * the market regime changes * the signal stops behaving like it did in the backtest Quandora should not treat a decaying strategy as permanently valid. The old result becomes memory, and the agent receives a refreshed research task. The loop becomes: ``` paper trading / monitoring detects decay -> factor mining restarts -> new candidate factors are generated -> new factors are evaluated -> the strategy is repaired, replaced, or retired ``` This is what makes Quandora a living research loop instead of a static backtest report. ### Step 7B: If Stable, Move To Supervised Deployment If the strategy stays stable through paper trading / monitoring, it may move toward supervised deployment. Supervised deployment means the user stays in control. The system packages the strategy, prepares configuration, and supports monitoring — and real-money deployment requires your approval and risk controls. Execution follows the strategy you approved, not the system's own judgment. Supervised deployment may include: * export package * execution configuration * risk limits * position limits * human approval * monitoring * logs * kill switch Supervised deployment answers: ``` Is this strategy ready to be used under human-controlled conditions? ``` ### Step 8: Live Trading Live trading is the final stage, not the default product promise. It should only happen after research, evaluation, strategy construction, strategy evaluation, paper trading, and supervised deployment controls. Live trading executes the strategy you approved, and requires: * human approval * strict limits * monitoring * logs * risk controls * ability to stop execution Live trading answers: ``` Can this supervised strategy be allowed to trade under controlled limits? ``` The product principle remains: ``` report rails, not direct trade calls ``` Quandora never decides what to trade on its own — it executes your strategy, within your limits. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://quandora.gitbook.io/quandora-docs/understanding-quandora/quandora-workflow.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.