Signal & Factor Construction and Evaluation

Learning objectives

By the end you can:

1. Define what a cross-sectional signal (or factor) actually is (one score per company per period, meaningful only in comparison to the other scores in the same period) and explain why factor construction is fundamentally a cross-sectional, not a time-series, discipline.
2. Construct a value signal (an earnings-yield ratio) from bundled fundamentals and price data in code, including the explicit per-share-versus-aggregate simplification this module states and flags rather than hides.
3. Construct a momentum signal (12-month-minus-1-month price momentum) from a price panel in code, and explain (from a named, real finding in the literature) why the most recent month is deliberately skipped.
4. Construct a quality signal (a profitability, leverage, and earnings-stability composite) from fundamentals data in code.
5. Construct a low-volatility signal (inverted trailing realized volatility) from a price panel in code.
6. Cross-sectionally standardize (z-score) and winsorize a raw signal, separately in every period, so that raw units, scale, and outliers never contaminate a comparison across companies or across the India and US markets.
7. Compute the Information Coefficient (Pearson and rank/Spearman) between a factor score and the forward return it is supposed to predict, period by period, and summarize an IC series into an Information Ratio, and use both, together, to tell a real signal from a plausible-looking one.
8. Measure a factor's decay across forward-return horizons and its portfolio turnover, and connect both numbers to the practical cost of actually trading the signal.
9. Diagnose double-counting between two signals via their pairwise correlation and an orthogonalized residual IC, so that "combining factors" does not silently re-weight the same underlying bet under two different names.
10. (Productivity objective: R10 duality.) Use an AI coding assistant to accelerate signal-construction boilerplate under the Copilot Discipline, understand the by-hand version yourself first, then accelerate, then always review every line and run the hidden tests, because a hallucinated column name or a silently backwards sign reads exactly as fluent as a correct one.

The duality, stated once (R10). Objectives 1–9 are the understanding objective: the gate rewards being able to derive a signal, standardize it, and evaluate it honestly, by hand and in code, on data the exercise has never shown you before. Objective 10 is the productivity objective riding on top of it: a working quant developer absolutely uses an AI assistant to draft the tenth nearly-identical factor pipeline of the week, but only after they could have written the first one alone, and only with every line reviewed against the same hidden tests that grade you here.

Prerequisites & connections

Builds on. QD1.01 (Market & Fundamental Data Pipelines) owns the data layer this module simply assumes: corporate-action adjustment, and (critically) point-in-time, survivorship-controlled panels. Every fundamentals figure this module uses is treated as available only from its stated filed_date onward, never earlier; that discipline is QD1.01's to teach in full, and this module inherits it rather than re-deriving it (R1). DA1.01 (NumPy) and DA1.02/DA1.03 (pandas) teach the general-purpose array and dataframe mechanics (groupby, rolling windows, vectorized arithmetic) that make this module's constructions fast and idiomatic in real quant work; they are a strong, advisory companion, not a hard gate, because cross-branch prerequisites in this program are recommendations, never locks (this module's own code pack is written in plain Python precisely so that a QD-track learner who has not yet taken the DA branch is never blocked). QM1.01 (Probability, Distributions & Estimation) already defined covariance and correlation, ρ(X, Y) = Cov(X, Y) / (σ_X · σ_Y), and QM1.02 (Hypothesis Testing, Correlation & Regression) already taught you to test whether a sample correlation is distinguishable from zero. This module does not re-derive either. It assumes you hold both as working tools and spends its own time on the part that is genuinely this branch's job under the program's binding boundary: **C-3: G1's QM branch owns the statistics and ML concepts (intuition, math, failure modes); this branch owns ML in code: implementation, validation, pipelines, and evaluation.** Every time this module computes a correlation, it is applying QM1.01's formula, not reinventing it; every time it discusses whether an IC is "real," it is one concrete, repeatable instance of QM1.02's hypothesis-testing habit of mind, applied at production scale across dozens of periods rather than once by hand.