# How an AI Agent Turns a Market Hypothesis into a Tested Signal

> The agent can propose and implement a predictor. What makes it a tested signal is the experiment it survives—and the history of how that experiment was used.

Published: 2026-10-09 · Lumisonde (https://lumisonde.com/reports/agent-hypothesis-to-signal/)
Citations JSON (per-claim receipts): https://lumisonde.com/reports/agent-hypothesis-to-signal/citations.json
Continues: https://lumisonde.com/reports/tradingagents-decision-path/

## The brief

**Question:** How does an AI agent turn a market idea into a tested predictive signal?

**Stake:** A convincing explanation and a promising historical score can draw attention and resources to a candidate. Researchers need to know what those results actually establish before relying on them.

**Answer:** An agent can specify a prediction, implement a candidate and help evaluate it. [3, 27] To call it tested, freeze the candidate and require it to meet a declared criterion against a meaningful comparison, with information access, selection history and uncertainty accounted for. Historical scores already used to guide revisions are search feedback, not untouched confirmation. Keep failed and inconclusive results: correct code can still predict poorly, and insufficient evidence leaves a candidate unconfirmed. Trading usefulness needs a separate test of feasible net outcomes, while the agent's research contribution needs comparison with other ways of doing the work.

A market hypothesis begins as an expectation: unusual trading activity might contain information about what prices do next. An AI agent can make that expectation computable, write its implementation, inspect failures and propose revisions. [3, 27] The difficult transition comes after the code runs. A promising historical result may reflect useful information, a familiar exposure, or the search process learning the peculiarities of its evaluation sample.

Turning the idea into a tested signal requires different achievements: specify a prediction, construct a faithful candidate, measure it against a meaningful alternative, and decide what the surviving evidence warrants. Agents can assist specification, implementation and evaluation. [3, 27] Calling their output a tested signal requires an explicit account of information access, selection and uncertainty. Reading the implementation makes these boundaries concrete: it shows what the agent changes, what the evaluator measures, and which measurements become the next proposal's input.

## Specify what the market idea predicts

A hypothesis, a feature and a signal answer different questions. The hypothesis describes an expected relationship. A feature is an observable representation of it. A signal is the score or prediction used to distinguish future outcomes; a feature can serve directly as that score, or several features can feed a learned model. A trading strategy adds rules for positions and transactions. Qlib's staged research architecture separates these objects, although an end-to-end decision model need not expose the same modules. [1]

The representation need not be a price-volume formula. LLMFactor uses supplied prompt stages to identify company relationships, extract textual drivers from news, and combine them with historical price-movement text to predict direction. [2] That is a text-to-prediction route rather than generated factor code. RD-Agent-Quant describes factor-only, model-only and joint optimization, while a cryptocurrency study constrains agent proposals to executable recipes assessed by a deterministic engine. [3, 4] These designs allocate different parts of the experiment to the agent.

Consider an illustrative hypothesis, not an established result: a recent price rise accompanied by unusually high volume is more likely to continue than a comparable rise on ordinary volume. To contradict it, first decide which assets are eligible, when the score becomes available, what “continue” means, and what comparison isolates the extra volume claim. One possible experiment scores a historically defined equity universe after the close and predicts five-session relative returns beginning at the next open. Its comparator is a plain recent-return score, evaluated on the same eligible observations.

A deliberately simple candidate multiplies the past five-session return by the logarithm of today's volume divided by the previous twenty sessions' average volume. Those windows are illustrative assumptions, not recommended parameters. On schematic inputs, a 5% rise with twice the usual volume gives a score of about 0.0347; the same rise with ordinary volume gives zero. This shows how the formula represents the proposed interaction. It also reveals an additional choice: below-normal volume makes a rising asset's score negative. The researcher must decide whether that behavior belongs to the hypothesis before rewarding the formula for its historical score.

The target's exact alignment matters as much as its verbal horizon. RD-Agent's inspected baseline template contains this label expression: [6]

```yaml
                            - ["Ref($close, -2)/Ref($close, -1) - 1"]
```

In the separately inspected Qlib operator, a negative `Ref` offset selects future observations. [14] Thus, for a row indexed at session *t*, this expression represents the close return from *t+1* to *t+2*. [6, 14] It is a legitimate future label, but differs from the RD-Agent-Quant v2 appendix's simplified *t*-to-*t+1* close-return equation. [3, 6, 14] Neither convention is intrinsically wrong; substituting one for the other changes what prediction is being tested.

Before interpreting any result, record the universe, usable-input timestamps, target interval, comparator, missing-value handling and preprocessing fit bounds. This is a proposed specification discipline, drawn from the different task and configuration interfaces—not a claim that one framework automatically audits all of them. Future returns belong in the evaluation label; they must not enter the predictor's decision-time inputs.

## Follow the candidate through implementation and measurement

In [RD-Agent](https://github.com/microsoft/RD-Agent), a proposal becomes a task rather than an immediate market conclusion. The factor converter parses a model response into a description, formulation and variables, then constructs a `FactorTask`. [7] Those fields preserve the proposed computation for the next consumer, the coder. The supplied scenario and templates provide the surrounding data and output interfaces. [33, 41]

The joint loop makes the division of labor explicit. `QuantRDLoop` dispatches factor or model proposals to the corresponding converter, coder, runner and feedback generator. [5, 8] A factor runner processes generated factor data, conditionally combines it with prior factors, and evaluates it with a baseline model or a prior selected model. [9] A model runner provides the alternative route for changing the predictor. [34] These are supported source paths, not evidence that every branch succeeded in a published experiment.

For the volume example, the changing artifact would be the specified formula and its implementation; its output would be an asset-date feature panel. The runner consumes that panel inside a configured prediction experiment. [9, 42, 43] If a learned model uses the new feature alongside existing ones, the measured result belongs to the combined feature-model system. An improvement cannot automatically be assigned to the standalone formula or to the economic explanation behind it.

Implementation feedback asks whether there is a usable computation. The configured factor coder selects an evaluator to check the implementation: the coder resolves to `FactorCoSTEER`, whose constructor selects `FactorEvaluatorForCoder`. [5, 32, 10] That evaluator executes the workspace and gathers value checks; it does not merely read the generated code's explanation. [35] The selected value evaluator checks matters such as infinities, format and daily indexing. [36] With a reference implementation, it also compares rows, indexes, missingness, value agreement and correlation. [36] Some findings are feedback rather than unconditional vetoes; when the value checks do not settle the decision, a code critic and final language-model evaluator judge the implementation. [35, 36]

A reference helps, but the meaning of its comparison must remain clear. High correlation with reference outputs does not establish pointwise equality. Without a trustworthy reference, execution plus model-judged alignment leaves semantic fidelity less certain. RD2Bench supplies a concrete older-generation counterexample: an implementation used volume where the task requested volatility, and a more detailed specification repaired the case. [11] That example demonstrates the distinction, not the current code's error rate.

Use hand-worked miniature cases to check the intended relationship, then test rolling windows, instrument grouping, time alignment and missing values. For the schematic volume formula, check both rising and falling prices and both high and low volume. These are proposed correctness checks. They can justify “this computes the specified candidate”; they cannot justify “this predicts the market.” A shape repair makes measurement possible, while a correctly implemented candidate can still fail its predictive comparison.

Market measurement is a separate operation. The RD-Agent workspace runs the configured Qlib experiment, exports recorder metrics through a result-reading script, and reads the resulting series back into the experiment. [12, 37] A missing usable result can produce an experiment failure rather than a predictor score. [9, 12] The cryptocurrency design offers a different selection mechanism: fixed training-window admission gates and an append-only trace retain both successful and failed recipes. [4] Its validation diagnostics and later tuning still have to be distinguished from final unseen assessment. [4]

## Separate search feedback from confirmation

Search improves a candidate by responding to observations. That same responsiveness changes what those observations can establish. If differences between candidates' historical scores mainly reflect sample noise rather than genuine differences in predictive usefulness, choosing the maximum risks selecting an optimistically estimated candidate; designing the next candidate after seeing earlier scores also lets sample-specific patterns influence the search. [19, 20] Adaptive-analysis research explains this second problem, while investment-specific backtest research shows why selecting among configurations requires trial accounting. [19, 20]

The factor-specific RD-Agent path shows where this happens. The template configures which observations to test and sets matching backtest bounds; with the separately inspected Qlib prediction model (`LGBModel`), the recorder (`SignalRecord`) records predictions from that named test segment. [6, 15, 44] The workspace's reader exports the latest recorder's metrics, and `QlibFactorExperiment2Feedback` compares the new result with the prior selected result. [37, 13]

Here IC (information coefficient) is the correlation between predictions and future labels, computed by date. [16] Excess return compares the portfolio's gross return with the benchmark; the with-cost version subtracts the separately recorded modeled trading costs. [39, 15, 45] The metric filter is exact source code: [13]

```python
IMPORTANT_METRICS = [
    "IC",
    "1day.excess_return_with_cost.annualized_return",
    "1day.excess_return_with_cost.max_drawdown",
]
```

The comparison becomes a model-facing request, alongside the hypothesis and implementation details. [13] The response supplies observations, a proposed new hypothesis and a replacement decision. [13] Separately, `QlibFactorHypothesisGen.prepare_context` renders prior and latest experiment-feedback history for subsequent proposals; its templates expose IC and pre-cost annualized excess return and drawdown. [7, 38] The feedback comparison and proposal history therefore expose related, but not identical, metric views.

Following the handoff matters more than reading a segment name: configured test/backtest metrics enter the search. In this source path they are research feedback, not untouched confirmation of the selected output. This finding does not establish the exact environment or access history of a paper's run, nor rule out a later protected assessment. It establishes the visible route by which measurements can influence the next candidate.

A practical design should declare which evidence fits the model, which evidence steers selection, and which evidence assesses the resulting frozen choice. One defensible route is a genuinely unconsulted chronological or forward assessment after fixing the computation and selection rule. Check actual information availability, including preprocessing fit dates, historical universe membership and revised values. If target intervals straddle a split, account for the shared future observations. A short forward period can remain too imprecise or unrepresentative to settle the claim.

Pretraining creates a further boundary: an agent may possess historical facts that never appear as future-price columns. [22] Financial-LLM temporal-provenance studies investigate this route, but rationale-based audits cannot prove hidden knowledge is absent. [22] Treat it as an access question to examine, not as an accusation that every historical agent result is contaminated.

Protecting evidence does not require a universal “use a holdout only once” rule. Thresholdout and Generic Holdout offer conditional alternatives. Their guarantees depend on stated sampling and testing assumptions, including independent samples; neither is an off-the-shelf correction for arbitrary dependent, changing market returns. [19, 21] Thresholdout controls disclosure by comparing training and holdout means: sufficiently close queries receive the training mean; discrepancies receive a noisy holdout mean and consume an overfitting budget. [19] Generic Holdout instead releases only binary test outcomes and stops under declared acceptance or test budgets. [21]

Rolling or nested temporal evaluation can also assess a predeclared refitting or search procedure. The essential question remains what its outer results are allowed to change. As a proposed safeguard, if those results alter the procedure itself, treat them as consumed selection evidence and seek renewed confirmation. The date partition and the agent's tool permissions must describe the same boundary.

## Decide what the candidate actually survived

Once the assessment boundary is defensible, the next question is what the candidate must outperform. A candidate should earn its place against a credible existing prediction, not just against zero correlation. In the illustrative experiment, compare the plain trend score with the volume augmentation, then compare the existing model with and without the new feature under the same target, fitting choices and eligible observations. Declare the meaningful improvement and uncertainty method before confirmation; calibrate that method to the experiment's dependence and selection history.

Structural novelty is a different measurement. AlphaAgent's originality checks compare expression trees, while its alignment checks use model judgments of hypothesis-description-expression agreement. [23] RD-Agent's factor runner filters highly correlated new columns against prior features. [9] These can organize a search and reduce obvious duplication, but neither establishes additional predictive information conditional on the current system.

FactorEngine v3 gives a concrete contribution comparison: generated factors are added to Alpha158, the baseline feature set, and passed through the same LightGBM prediction model and portfolio pipeline. [24] Its reported CSI300 comparison includes additions that do worse than Alpha158 alone as well as additions that improve it. [24] Adding searched features is therefore something to test, not an automatic benefit. These are author-reported comparisons under that study's conditions, not a matched reproduction of every original agent system.

For the volume hypothesis, a failure to improve the trend comparator can reject the extra-volume claim while leaving trend prediction useful. Before final assessment, define robustness probes that test rival explanations—concentration in a narrow universe, a familiar exposure, or sensitivity to arbitrary windows. Repeatedly adding exceptions after inspecting final results would create another selection process. Even a surviving forecast increment establishes conditional predictive usefulness, not the hypothesized economic cause.

The following disposition rule is a proposed synthesis of these mechanisms and evaluation principles, not a universally validated agent protocol. It makes the different outcomes explicit:

| What the evidence shows | Candidate disposition |
|---|---|
| The computation fails, or does not represent the specification | Record an implementation or semantic failure; revise on exploratory evidence and version the repair. |
| Valid, sufficiently informative assessment contradicts the declared prediction or comparator requirement | Reject that tested claim; retain the result and any useful baseline. |
| Fidelity, timing, assessment independence or precision remains unresolved | Leave the candidate unconfirmed, even if its selected historical score is attractive. |
| The frozen version meets an applicable, declared predictive criterion against its comparator | Retain it as a tested predictive signal under the named conditions, with uncertainty and selection history. |

If protected evidence prompts another revision, the revision is a new candidate. Obtain renewed evidence, use a genuinely applicable controlled-reuse method, or leave it unconfirmed. Stop at the declared evidence or resource boundary; insufficient confirmation is a legitimate result, not an instruction to keep adjusting until a favorable score appears.

The proposed handoff should bind three groups of information:

- **Candidate identity:** the hypothesis and computation, code/configuration hashes, data versions and timestamps, and frozen date.
- **Information and evaluation boundary:** target alignment, comparator, fitting/selection/assessment windows, and uncertainty.
- **Search history:** every failure and revision, released feedback, and selection decisions.

Qlib's prediction/label records and the cryptocurrency trace provide concrete recording surfaces; this fuller record is a proposed requirement, not a claim that every system already stores it. [4, 15] “Tested” should identify the version and tests survived, rather than erase the route by which it was chosen.

## Give trading usefulness a separate test

Prediction and trading evaluate different objects. Qlib computes Pearson information coefficient between predictions and labels by date, and Spearman rank IC for their ordering. [16] Neither is a return on filled positions. A ranking strategy can use scores whose numerical scale is not an expected return; a position optimizer may need calibration as well as risk and constraint information. [17]

The inspected TopkDropout consumer makes the conversion concrete. It retrieves the previous trading bar's score, combines current holdings with highly ranked unheld candidates, and—under its default bottom-selling rule—selects held names among the combined low ranks for replacement. [18, 40] Holding-age requirements, tradability and cash can change the resulting orders. [18] It selectively updates holdings rather than liquidating everything each day. [18] The calendar's positive shift verifies the previous-bar relation, not every upstream input's historical availability. [40]

A schematic two-holding example shows the operation: suppose A and B are held, C is unheld, and the scores rank A above C above B. With a two-name target and one-name dropout, the unconstrained default ranking logic replaces B with C and retains A. This is an illustration of the inspected rule, not an executed backtest. If B cannot be sold or C cannot be bought, the realized holdings need not match that intended replacement.

Costs enter another downstream calculation. Qlib's portfolio recorder evaluates net benchmark-excess returns using this exact expression: [15]

```python
                analysis["excess_return_with_cost"] = risk_analysis(
                    report_normal["return"] - report_normal["bench"] - report_normal["cost"], freq=_analysis_freq
                )
```

Here `return` is the portfolio's gross return series, `bench` the benchmark return and `cost` the separately recorded modeled trading-cost fraction. [39, 15, 45] Reading the gross column as already net changes the conclusion. The exchange is configurable: volume clipping needs a supplied rule, and its impact-cost parameter defaults to zero. [25] A simulated fee schedule alone does not establish liquidity or capacity at the intended capital size.

For a declared use, specify when scores arrive, when orders can be submitted, executable prices, position rules, benchmark, risk objective, turnover, costs, liquidity and any shorting requirement. Preserve intended and filled orders. Reject a trading use if feasible net outcomes fail its objective, without automatically rejecting the signal's forecasting usefulness. Leave trading utility unconfirmed if execution or scale assumptions remain unresolved.

Costs do not necessarily destroy every opportunity. The September 2015 Frazzini–Israel–Moskowitz study uses one institutional manager's live trading data across 21 developed equity markets in 1998–2013 and finds that size, value and momentum survive costs at the studied scale; cost-aware portfolio changes can preserve exposure while improving net implementation. [26] It does not supply the cost model or capacity for a newly generated signal.

Reported returns also need an identifiable policy. RD-Agent-Quant v2's appendix describes selling all holdings alongside retaining highly ranked names, and next-open action alongside closing-price fills. [3] The separately inspected Qlib implementation does not attest which effective configuration produced the paper's returns. [18] Those statements need experiment-specific reconciliation before attributing the headline result to one reproduced trading procedure.

## Measure the agent's contribution, not just its winner

A useful predictive or trading result does not by itself establish the agent's marginal research contribution. An agent can add value through faithful implementation, better proposal choices, or more completed experiments for a resource budget. Compare those achievements separately. To measure coding assistance, hold task specifications fixed and count faithfully completed implementations, retries, human corrections, time and cost. QRAFTI's coding-only, full-tool and reflection comparisons illustrate this fixed-task approach; their reference-panel similarity measures workflow reproduction, not fresh predictive information. [27]

To measure discovery, hold the data, target and evaluator compatible and compare a human-designed baseline, conventional automated search and agent-assisted search. AutoAlpha's hierarchical evolutionary search is a substantive non-LLM alternative, not merely a theoretical objection to language-guided proposals. [28] Its original scores cannot be placed beside another paper's returns as though they came from a matched experiment.

Budget matching changes the question. Equal evaluator calls tests proposal quality per measured candidate. Equal total spend or elapsed time tests useful research per available resource. RD-Agent-Quant v1's o3-mini scheduler comparison gives each controller twelve hours, yet reports 33 loops for random and LLM scheduling versus 44 for bandit scheduling. [29] That is an equal-time system comparison; different trial and implementation opportunities prevent interpreting it as pure idea quality per evaluation.

Count local search inside each proposal, too. FactorEngine reports twenty Bayesian parameter trials per macro mutation. [24] Alpha Jungle's MCTS method tests three parameter sets per generated formula and supplies an equal-API-budget comparison against simpler LLM controllers, reporting the highest-IC evaluation interval. [30] That narrows the evidence gap, but matching API spend does not match total computation or independently confirm the selected interval.

A proposed process comparison should repeat the complete search and retain three kinds of accounting:

- **Attempts and evaluations:** preserve failures and duplicates, and record training and parameter-evaluation counts.
- **Resources:** record API costs, hardware, elapsed time, caches and human input.
- **Independent selected-output assessment:** assess selected outputs beyond the search feedback.

Repeating only a baseline's random seeds or averaging successful recorders measures a different uncertainty. Qlib's example collector excludes unfinished or incomplete-metric runs, so its summary cannot stand in for all-attempt search accounting. [31] An agent that reliably implements known ideas can be useful without discovering new market information; a spectacular selected winner alone does not tell us which contribution occurred.

## Conclusion

An AI agent turns a market hypothesis into a candidate by specifying an observable prediction, implementing its representation and submitting it to an evaluator. It turns that candidate into a tested signal only in the qualified sense that a frozen version survives declared comparisons under a defensible information boundary, with selection history and uncertainty intact. Trading usefulness and the agent's marginal research value each require their own comparison. The most useful output is therefore a reproducible computation accompanied by a precise statement of what its evidence establishes.

## Limitations

The implementation account is static inspection of pinned public source, not execution of the software, reproduction of published experiments or verification of deployed behavior. The RD-Agent and Qlib revisions identify separate inspected artifacts; they do not establish that an RD-Agent runtime used that Qlib revision. Complete feedback-object retention semantics, effective paper configurations, point-in-time data provenance and selector access histories remain unresolved.

The proposed specification, confirmation, disposition and accounting procedures combine supported mechanisms with methodological deductions. No source establishes a universal IC, return, significance or drawdown cutoff for agent-generated candidates, and the general holdout-reuse guarantees cannot be transferred to dependent market data without checking their assumptions. The illustrative price-volume formula has no empirical result here. Author-reported comparisons support narrower implementation and search findings, not general superiority over matched human research, a verified economic cause or guaranteed future profit.

## References

[1] Qlib: An AI-oriented Quantitative Investment Platform, v1. Architecture and researcher workflow. — https://arxiv.org/abs/2009.11189v1
[2] LLMFactor: Extracting Profitable Factors through Prompts for Explainable Stock Movement Prediction. Method and prompt stages. — https://aclanthology.org/2024.findings-acl.185.pdf
[3] R&D-Agent-Quant: A Multi-Agent Framework for Data-Centric Factors and Model Joint Optimization, v2. Factor/model design, target equation and trading appendix. — https://arxiv.org/abs/2505.15155v2
[4] From Hypotheses to Factors: Constrained LLM Agents in Cryptocurrency Markets, v1. Recipe evaluation, admission, trace and selection protocol. — https://arxiv.org/html/2604.26747v1
[5] Loop settings and configured components. — https://github.com/microsoft/RD-Agent/blob/32b3d395e73d9db5eee3fe9063d69aec0fdc83bd/rdagent/app/qlib_rd_loop/conf.py
[6] Baseline factor experiment template. — https://github.com/microsoft/RD-Agent/blob/32b3d395e73d9db5eee3fe9063d69aec0fdc83bd/rdagent/scenarios/qlib/experiment/factor_template/conf_baseline.yaml
[7] Factor task conversion and proposal context. — https://github.com/microsoft/RD-Agent/blob/32b3d395e73d9db5eee3fe9063d69aec0fdc83bd/rdagent/scenarios/qlib/proposal/factor_proposal.py
[8] Joint quant loop dispatch. — https://github.com/microsoft/RD-Agent/blob/32b3d395e73d9db5eee3fe9063d69aec0fdc83bd/rdagent/app/qlib_rd_loop/quant.py
[9] Factor runner, combination and redundancy filter. — https://github.com/microsoft/RD-Agent/blob/32b3d395e73d9db5eee3fe9063d69aec0fdc83bd/rdagent/scenarios/qlib/developer/factor_runner.py
[10] FactorCoSTEER constructor. — https://github.com/microsoft/RD-Agent/blob/32b3d395e73d9db5eee3fe9063d69aec0fdc83bd/rdagent/components/coder/factor_coder/__init__.py
[11] RD2Bench: Toward Data-Centric Automatic R&D. Implementation measurements and volume/volatility case study. — https://hytn.github.io/pubs/RD2Bench.pdf
[12] Qlib experiment workspace. — https://github.com/microsoft/RD-Agent/blob/32b3d395e73d9db5eee3fe9063d69aec0fdc83bd/rdagent/scenarios/qlib/experiment/workspace.py
[13] Performance-feedback construction. — https://github.com/microsoft/RD-Agent/blob/32b3d395e73d9db5eee3fe9063d69aec0fdc83bd/rdagent/scenarios/qlib/developer/feedback.py
[14] Expression operators, including Ref. — https://github.com/microsoft/qlib/blob/da920b7f954f48ab1bb64117c976710de198373e/qlib/data/ops.py
[15] Prediction, signal and portfolio records. — https://github.com/microsoft/qlib/blob/da920b7f954f48ab1bb64117c976710de198373e/qlib/workflow/record_temp.py
[16] IC and rank-IC calculation. — https://github.com/microsoft/qlib/blob/da920b7f954f48ab1bb64117c976710de198373e/qlib/contrib/eva/alpha.py
[17] Strategy documentation and score interpretation. — https://github.com/microsoft/qlib/blob/da920b7f954f48ab1bb64117c976710de198373e/docs/component/strategy.rst
[18] Signal strategies and TopkDropout. — https://github.com/microsoft/qlib/blob/da920b7f954f48ab1bb64117c976710de198373e/qlib/contrib/strategy/signal_strategy.py
[19] Generalization in Adaptive Data Analysis and Holdout Reuse, v2. Adaptive analysis and operational Thresholdout method. — https://arxiv.org/abs/1506.02629v2
[20] The Probability of Backtest Overfitting. Investment-selection framework and applicability limits. — https://www.davidhbailey.com/dhbpapers/backtest-prob.pdf
[21] The Generic Holdout: Preventing False-Discoveries in Adaptive Data Science, v1. Binary disclosure and stopping guarantees. — https://arxiv.org/abs/1809.05596v1
[22] All Leaks Count, Some Count More: Interpretable Temporal Contamination Detection in LLM Backtesting, v1. Temporal-provenance stress tests and audit limitations. — https://arxiv.org/html/2602.17234v1
[23] AlphaAgent: LLM-Driven Alpha Mining with Regularized Exploration to Counteract Alpha Decay, v1. Structural originality and semantic alignment. — https://arxiv.org/abs/2502.16789v1
[24] FactorEngine: A Program-level Knowledge-Infused Factor Mining Framework for Quantitative Investment, v3. Baseline-plus-factor comparisons and local parameter-search budget. — https://arxiv.org/html/2603.16365v3
[25] Exchange pricing, volume and impact controls. — https://github.com/microsoft/qlib/blob/da920b7f954f48ab1bb64117c976710de198373e/qlib/backtest/exchange.py
[26] Trading Costs of Asset Pricing Anomalies, September 9, 2015 draft. Live institutional cost evidence for size, value and momentum. — https://spinup-000d1a-wp-offload-media.s3.amazonaws.com/faculty/wp-content/uploads/sites/3/2019/09/TradingCostofAssetPricingAnomalies.pdf
[27] QRAFTI: An Agentic Framework for Empirical Research in Quantitative Finance, v1. Fixed-task tool and planning comparisons. — https://arxiv.org/html/2604.18500v1
[28] AutoAlpha: An Efficient Hierarchical Evolutionary Algorithm for Mining Alpha Factors in Quantitative Investment, v2. Non-LLM search method and experiments. — https://arxiv.org/abs/2002.08245v2
[29] R&D-Agent-Quant, v1. Original o3-mini scheduler ablation and runtime accounting; distinct from v2 cited above. — https://arxiv.org/abs/2505.15155v1
[30] Navigating the Alpha Jungle: An LLM-Powered MCTS Framework for Formulaic Factor Mining, v3. Parameter-set testing and equal-API-cost comparison. — https://arxiv.org/html/2505.11122v3
[31] Repeated-model result collection. — https://github.com/microsoft/qlib/blob/da920b7f954f48ab1bb64117c976710de198373e/examples/run_all_model.py
[32] Configured factor-coder alias. — https://github.com/microsoft/RD-Agent/blob/32b3d395e73d9db5eee3fe9063d69aec0fdc83bd/rdagent/scenarios/qlib/developer/factor_coder.py
[33] Experiment task contract. — https://github.com/microsoft/RD-Agent/blob/32b3d395e73d9db5eee3fe9063d69aec0fdc83bd/rdagent/scenarios/qlib/experiment/prompts.yaml
[34] Model runner. — https://github.com/microsoft/RD-Agent/blob/32b3d395e73d9db5eee3fe9063d69aec0fdc83bd/rdagent/scenarios/qlib/developer/model_runner.py
[35] Selected evaluator and judgment implementation. — https://github.com/microsoft/RD-Agent/blob/32b3d395e73d9db5eee3fe9063d69aec0fdc83bd/rdagent/components/coder/factor_coder/evaluators.py
[36] Value-check and judgment implementation. — https://github.com/microsoft/RD-Agent/blob/32b3d395e73d9db5eee3fe9063d69aec0fdc83bd/rdagent/components/coder/factor_coder/eva_utils.py
[37] Qlib experiment result export. — https://github.com/microsoft/RD-Agent/blob/32b3d395e73d9db5eee3fe9063d69aec0fdc83bd/rdagent/scenarios/qlib/experiment/factor_template/read_exp_res.py
[38] Feedback/history templates. — https://github.com/microsoft/RD-Agent/blob/32b3d395e73d9db5eee3fe9063d69aec0fdc83bd/rdagent/scenarios/qlib/prompts.yaml
[39] Portfolio-account metric construction. — https://github.com/microsoft/qlib/blob/da920b7f954f48ab1bb64117c976710de198373e/qlib/backtest/account.py
[40] Trading-calendar shift. — https://github.com/microsoft/qlib/blob/da920b7f954f48ab1bb64117c976710de198373e/qlib/backtest/utils.py
[41] Factor scenario data, interface and output wiring. — https://github.com/microsoft/RD-Agent/blob/32b3d395e73d9db5eee3fe9063d69aec0fdc83bd/rdagent/scenarios/qlib/experiment/factor_experiment.py
[42] Combined-factor baseline-model configuration and panel loader. — https://github.com/microsoft/RD-Agent/blob/32b3d395e73d9db5eee3fe9063d69aec0fdc83bd/rdagent/scenarios/qlib/experiment/factor_template/conf_combined_factors.yaml
[43] Combined-factor selected-model configuration and panel loader. — https://github.com/microsoft/RD-Agent/blob/32b3d395e73d9db5eee3fe9063d69aec0fdc83bd/rdagent/scenarios/qlib/experiment/factor_template/conf_combined_factors_sota_model.yaml
[44] LightGBM prediction segment default. — https://raw.githubusercontent.com/microsoft/qlib/da920b7f954f48ab1bb64117c976710de198373e/qlib/contrib/model/gbdt.py
[45] Portfolio report fields and benchmark construction. — https://raw.githubusercontent.com/microsoft/qlib/da920b7f954f48ab1bb64117c976710de198373e/qlib/backtest/report.py

---
Every [N] marker above is verifiable: fetch the citations JSON, match the marker id, and check the extraction (summary and key facts) plus placements against the source URL. Verification guide: https://lumisonde.com/for-agents/