> 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/how-factors-are-judged.md).

# How Factors Are Judged

Every submitted factor gets the same treatment: Quandora binds market data server-side, runs the backtest, applies a set of gate checks, and returns a grade. The thresholds used for your run are printed in your [factor card](/quandora-docs/understanding-quandora/factor-card.md), so you can always see exactly why a factor landed where it did.

### Evaluation Windows

Factors are not judged on one block of history. The backtest splits time into windows, and the card reports both an **In-Sample** view and an **ALL** view (the full backtest = in-sample + out-of-sample) so you can check consistency:

| Window              | What it is                                                                                   |
| ------------------- | -------------------------------------------------------------------------------------------- |
| In-sample (IS)      | The period the factor is allowed to "learn" from — where the idea gets shaped.               |
| Validation          | Later data the factor has not seen. This is where overfitting shows up.                      |
| Out-of-sample (OOS) | Held-out data folded into the ALL view — the closest thing to "would this have worked live?" |

A factor that shines in-sample but falls apart across the ALL view was likely fitted to noise. The card also reports the validation window's market regime mix (bear / sideways / bull) so you can see what conditions the factor was actually tested in.

### The Gate Checks

| Check                          | Typical threshold     | What it asks                                                     |
| ------------------------------ | --------------------- | ---------------------------------------------------------------- |
| Sharpe (cross-sectional)       | ≥ 0.8                 | Is the risk-adjusted return strong enough to matter?             |
| Rank IC                        | absolute value ≥ 0.01 | Does the factor's ranking actually line up with forward returns? |
| Factor autocorrelation (lag 1) | ≥ 0.4                 | Is the signal stable from bar to bar, or just noise?             |
| Cost viability                 | pass / fail           | Does the edge survive realistic trading costs and turnover?      |
| Duplicate / similarity         | memory check          | Is this genuinely different from factors already tested?         |

Thresholds can vary by task, market, and product stage — the exact values applied to your run are always included in the factor card.

### The Grade

Instead of a pass/fail label, every evaluated factor gets a single grade:

```
SSS, SS, S, A, B, C, D   cleared the gate, strongest to weakest evidence
F                        failed the gate
```

A factor that fails the gate checks above is graded **F**. A factor that clears the gate is ranked from **D** up to **SSS** by how strong and consistent its evidence is. A low grade is not a wasted run — it becomes memory: negative evidence that stops your agent from re-testing the same dead end and points the next attempt somewhere better.

{% hint style="info" %}
A strong grade means the factor showed evidence under test conditions. It does not mean the factor will make money in the future. Backtests are evidence, not promises.
{% endhint %}


---

# 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/how-factors-are-judged.md?ask=<question>&goal=<endgoal>
```

`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.