Skip to content

Strategy Methodology

This is the full technical reference for QuantAscent's strategy-testing machinery — the data foundation, signal measurement, the non-adjustable rulebook, and the walk-forward protocol behind the Adaptive Strategy Builder and the Sweep Explorer. The in-app summary (the "How is this tested?" links inside the Adaptive Builder and Sweep Explorer) covers the same machinery at a high level; this page is the in-the-weeds version — the actual algorithm, with the math.

The division of labor is fixed and worth stating up front: you author the strategy; the software executes your rules and scores the result. Nothing is pre-selected in your name: the first time you compose, the fill rule and the universe-floor setting start blank and wait for your choice; after that the Builder remembers your choices as your defaults. The tilt templates are QuantAscent starting designs — we set their cluster weights in our own research; edit any of them. What the software does control — and never lets you adjust — is the honesty machinery: point-in-time data, economic direction priors, the stability gates, the sealed holdout, and the luck accounting described below.

(The Library's ETF tab is a separate, simpler thing: passive single-ETF index trackers with historical tracking records. They carry no methodology beyond historical index tracking and none of what follows applies to them.)

1. Data foundation

Everything operates on a point-in-time metrics matrix: one row per (company, as-of date), where every metric value is computed strictly from information that had been filed and public on that date. Fundamentals are stamped by filing date, not fiscal-period end, so a process evaluated "as of" March 2021 can only see statements companies had actually filed by March 2021.

  • Rebalance grid: as-of dates are spaced 90 calendar days apart. All scoring, testing, and record-keeping happens on this quarterly grid.
  • Forward returns: each row carries the company's total return over the 90 days following the as-of date, computed from dividend- and split-adjusted prices.
  • Survivorship: the database includes delisted companies (sourced from exchange delisting filings), so processes are scored against the universe as it actually existed — including the companies that later disappeared.
  • Outlier control: forward returns are clipped to ±100% per quarter before any averaging, for your process and its random benchmarks alike, so a single data artifact or extreme micro-cap move cannot dominate a record.

2. The universe you author

A process draws from a universe you define: sectors (or the whole market), a market-cap range, and a share-price range. One screen applies uniformly on top of whatever you choose:

Screen Rule Rationale
Freshness Latest filing ≤ 135 days old One quarter plus normal filing lag; stale books aren't comparable books

The freshness screen is deliberately universal and disclosed once — the algorithm is barred from learning recency-based filters, a class of screen that historically exploited data artifacts rather than economics.

There is no market-cap floor gate: universes reaching below $300M run, and carry a factual liquidity disclosure (spreads and thin trading are not modeled in walk-forward records — $300M is the envelope the testing machinery was validated on).

3. Signal measurement: the Information Coefficient

The basic question — "does this metric predict returns in this universe?" — is answered with the Information Coefficient (IC): the average of per-date cross-sectional Spearman rank correlations between metric values and subsequent 90-day returns.

For each as-of date \(t\) with companies \(i\) in the universe:

\[ \mathrm{IC}_t = \rho_{\text{Spearman}}\big(\, m_{i,t},\; r_{i,\,t \to t+90d} \,\big) \qquad\qquad \mathrm{IC} = \frac{1}{T}\sum_{t=1}^{T} \mathrm{IC}_t \]

where \(m_{i,t}\) is the metric value and \(r_{i,\,t\to t+90d}\) the clipped forward return. Rank correlation is used because metric scales are arbitrary; per-date computation prevents one unusual period from dominating.

4. The rulebook: what you set, what you can't

4.1 Direction priors — labels win (never adjustable)

Every metric carries one allowed direction, fixed by its economic meaning: higher return-on-capital is good (desc), heavier leverage is bad (asc), and so on. If the data says a metric "works" in the opposite direction, that metric is dropped for that quarter — never flipped. A Financial Strength slot is structurally incapable of preferring the most-levered companies, no matter what a backtest suggests.

A small set of metrics is excluded from recipes entirely: short-horizon reversal instruments, economically ambiguous measures, and aliases of other metrics (so the same ratio can't enter twice under two names).

4.2 Structure — clusters and slots (you author, within the taxonomy)

A process's structure is a weighted set of slots, each naming a cluster of closely related metrics (all the margin measures form one cluster, all the leverage ratios another; the cluster taxonomy itself is fixed). You compose the slots yourself — starting from one or more tilt templates (several blend with equal mass per template, merging same-cluster slots) or as a custom composition with your weights totaling 100%.

Each slot carries a fill rule you choose: strongest qualifying signal (largest mean absolute IC among the slot's qualifiers), most consistent across halves, or a pinned metric of your naming. A pinned metric always keeps its economic prior's direction, and in any quarter it fails the qualification gates its weight redistributes pro-rata for that quarter. Because each cluster contributes at most one metric, a composite can never quietly become one bet counted several times. Holdings count: 5–15.

4.3 The stability gate

A metric qualifies for a slot only if, on the training window split into two halves at its midpoint:

  1. Sign stability: its IC has the same sign in both halves,
  2. Prior agreement: that sign matches the metric's direction prior,
  3. Magnitude: the mean \(\tfrac{1}{2}|\mathrm{IC}_{H1} + \mathrm{IC}_{H2}|\) clears your minimum-signal dial (0.005–0.050; the shipped default is 0.02 — signal strength runs on different scales in different universes, so a live preview under the dials shows how many stable metrics clear your floor in the universe you chose),
  4. Coverage: at least 500 valid (metric, return) pairs in each half.

If fewer than two slots fill in a quarter, no portfolio is generated for that quarter — the process stands aside (section 6).

4.4 The remaining dials

Training window (expanding from the record's start, or trailing 12/16/20/24 quarters), stability gate (standard or strict), re-learn cadence (every quarter, or at ~2-year boundaries), the defensive universe floor on/off, a floor stability gate, and fresh-filings-only training. Every dial is bounded; nothing outside the bounds runs.

5. Universe floors

A process may carry one hard floor — a screen that removes the unfavorable half of the universe before scoring (e.g., "above-median interest coverage only"). Floors are chosen from a small curated pool of economically sensible candidates (volatility measures, balance-sheet strength, earnings quality) — never mined from the full metric library.

Selection uses per-date median-split lift. For each training date, the universe is split at the metric's median; the lift is the difference in mean forward return between halves, averaged across dates:

\[ \mathrm{lift} = \frac{1}{D}\sum_{d=1}^{D}\Big( \bar r_{\text{above-median},\,d} - \bar r_{\text{below-median},\,d}\Big) \]

A date only counts if it has ≥ 40 valid pairs and ≥ 15 companies in each half; at least 8 such dates are required. The learned favorable side must match the metric's direction prior (the drop-don't-flip rule extends to floors), and the qualifying metric with the largest absolute lift is selected. A floor is never forced: if no candidate clears the gates — its learned direction contradicts its prior, or the pool's metrics are too sparse in that universe — the process simply runs without one. With the floor-stability dial on, the floor must additionally keep its prior-consistent sign in both halves of the training window.

6. Portfolio construction

At each rebalance date the process scores its screened universe with a weighted percentile composite. Each recipe metric contributes its cross-sectional percentile rank (direction-adjusted, so "better" is always higher), weighted by its slot weight:

\[ \mathrm{score}_i = \sum_{k} w_k \cdot \mathrm{pctrank}_k(i) \]

The process holds the top-scored names at your holdings count, equally weighted, for the following 90 days, then re-derives and re-scores.

A quarter where fewer than two slots qualify — or the screened universe is empty — is recorded as stood aside: the process holds cash at 0% while the benchmark return still compounds. Standing aside can never flatter the record; hiding those quarters would understate the benchmark a real adopter was trailing.

7. The walk-forward protocol

The record on every card is produced by walk-forward testing with periodic re-learning — the strictest of the standard backtest designs, because it tests the process, not one frozen recipe. At each 90-day date past the minimum history, the process re-derives its slot picks by your rules using only data available before that date, holds one quarter, and chains the returns. Single-sector universes benchmark against their sector ETF (XLK for Technology, XLV for Healthcare, and so on); anything broader against SPY; a universe-equal-weight comparator is computed alongside.

Two spans keep the test honest:

  • The design span — everything you tune against.
  • The sealed holdout — roughly the most recent two years, computed but never displayed during design. Locking a process is permanent: the holdout is computed once, drawn onto the record, and stamped. Editing a locked process seeds a new, unlocked process — the stamped record never changes.

8. Luck accounting

Every candidate reports, factually and without a pass/fail badge:

  • its record's percentile against 500 random portfolios drawn from the same universe at the same holdings count and the same dates, scored identically (stood-aside quarters excluded on both sides) — in a universe where everything went up, beating the benchmark is not evidence of skill;
  • weight robustness — the record recomputed with slot weights deformed to their square roots and their squares (renormalized); results that collapse under small weight changes are curve-fit artifacts;
  • the luck bar, when the candidate was selected out of a field. A record picked out of a sweep is graded against a bar set by that sweep's size, because the best of more tries is expected to look better: under the null, the number of records clearing a fixed bar grows with the size of the search, while an N/(N+1) bar holds the expected number of lucky-looking results at about one however large the sweep. A record you authored by hand was selected out of nothing and carries no bar; its percentile is reported as a plain fact. "None beat the benchmark" is a designed, normal outcome.

Why these are records, not forecasts

Before release, a pre-registered study asked: do candidates that stand above the random-portfolio bar keep outperforming on data they never saw? The answer was no — clearing the luck bar did not predict holdout performance, while risk characteristics (volatility, drawdown) did persist. That finding shapes the product: the luck accounting can reject a result as explainable by chance, it never endorses one; the default orderings are risk-first; and every record sentence ends the same way — a historical record, not a prediction of future performance.

9. The Sweep Explorer

The Sweep Explorer runs the same machinery at scale. You author a design space instead of a single process — one fixed universe, the structures you allow, and ranges for the dials and holdings — and the engine fills it with draws sampled mechanically from that space. It never optimizes, never steers toward good-looking results, and never uses values you didn't allow: a search that chased winners would quietly hand authorship back to the software and corrupt the luck accounting.

Every draw is a complete walk-forward record (design span only — the holdout stays sealed), and every draw is accounted for: completed records, draws your own rules refused, and duplicates collapsed — nothing is dropped silently.

The bar a candidate must clear is set by the size of its own sweep — N/(N+1) over the records that sweep completed — and is stated before you run. Nothing outside the sweep moves it: a sweep is one experiment, and it is graded as the search it actually was. Refused and errored draws produced no candidate to select and are excluded from N; a sweep you stop early is graded on what completed, and resuming it raises the bar again, because you have now looked at more. The map grades each draw against its own universe's random-portfolio cloud; a result inside the cloud is one luck alone manufactures at this sweep's size. Opening a candidate computes its full record and saves it into Your Records — tagged with how large the field was when you picked it — where the ordinary Lock & Reveal and adoption path applies unchanged.

What the bar does not do. It corrects for the candidates inside one sweep, not for how many sweeps you have run. Twenty separate 25-draw sweeps over the same universe each carry the bar of a 25-candidate search, even though you have in truth looked at 500 designs and are free to keep the best one you saw anywhere. No number in the app prices that, deliberately: the alternative we tried — a running per-universe tally — was defeated by changing a single universe filter, and it made every sweep's standing drift as unrelated work happened elsewhere. Your Records instead lists every sweep you have run, so the size of your real search is visible in the record rather than compressed into one dot's brightness. Reading it is your job, and it is the strongest reason to treat a bright dot as a reason to test rather than a result.

10. Adoption and deployment

Only a locked process can be adopted. Adoption creates a scoring system that runs your process's derivation against current data at every rebalance. A derivation matching the rules you already run simply confirms them; a changed derivation becomes a pending proposal — the rebalance keeps trading the rules you last accepted, and nothing changes until you review the proposal (accept or decline) in the Strategy Manager. Accepting each proposal as it arrives keeps the deployed behavior identical to the recorded process; declining departs from it, and the record no longer describes what you run. The rebalance preview shows the recipe in force (each slot's metric and weight, the floor, and the derivation date) and flags any pending proposal, and every trade list is preview-and-confirm. If the process cannot derive picks (wrong data basis, missing or stale matrix), list generation stops and says why; a one-time explicit override can deploy the last-derived picks with the stale date disclosed.

11. Limitations

Honest reading of the records requires knowing what they do not include:

  • Trading costs. Walk-forward records are computed from market returns gross of commissions, spreads, and slippage. Quarterly-rebalanced portfolios trade little, but the drag is not zero.
  • Hypothetical performance. No capital tracked these records when they were generated. Fills at the rebalance price are assumed.
  • Sample size. Even the longest records span ~10 years of quarterly data — ~40 observations. The random-portfolio comparison exists precisely because records this short are easy to luck into.
  • Narrow universes. Your universes are your own, so a record's sample can be far narrower than a sector's — the luck accounting exists precisely because short records over narrow universes are easy to luck into.
  • Search across sweeps. The luck bar accounts for the candidates in one sweep, never for your search history as a whole. If you run sweep after sweep and keep the best result you have ever seen, no figure in the app corrects for that — the honest accounting for it is the list of sweeps in Your Records, and your own memory of how hard you looked.
  • Benchmark choice. Sector ETFs are investable, dividend-inclusive comparators, but any single benchmark is a simplification.

The process end to end — a replication checklist

Everything above, restated as the sequence of steps the machinery takes for one process. Someone with a point-in-time dataset could follow this list and reproduce the test; each step names the section that specifies it fully.

  1. Take the authored process (§2, §4): the universe, the slot composition with weights and fill rules, and the dial settings.
  2. Walk the quarterly grid (§7). At each 90-day date past the minimum history, restrict to data available before that date.
  3. Screen the universe (§2, §5): the authored sector/cap/price bounds, the 135-day freshness screen, and the floor if one qualifies.
  4. Qualify and fill each slot (§3, §4.3): split the training window in half; keep metrics whose IC carries the same prior-consistent sign in both halves, clears the signal floor, and has at least 500 valid pairs per half; fill each slot by its fill rule.
  5. Score and hold (§6): if at least two slots filled, hold the top-scored names equally weighted for 90 days and record the clipped return; otherwise record a stood-aside quarter at 0% while the benchmark compounds.
  6. Seal the holdout (§7): grade and display only the design span; compute the final ~two years once, at lock, and stamp it.
  7. Account for luck (§8): report the record's percentile against 500 random same-universe portfolios over the same dates, its weight robustness, and — when it was selected out of a sweep — the size of the field it was picked from.

QuantAscent provides research and analysis tools, not investment recommendations. Backtested and walk-forward results are hypothetical, have inherent limitations, and are not a guarantee of future performance. See the full Disclosures.