Stage 2 — Realtime Factor Projections

Realtime Factors is a projection surface, not a claim that every underlying model has been refitted on each tick. A daily factor may still be based on information through the prior close. The current view keeps that state intact and combines it with approved intraday evidence such as price, range, volatility, relative volume, or flow.

The result is a nowcast: a current estimate with an explicit timestamp, freshness, and coverage level.

What the animation shows

The left panel separates the T-1 model state from the records arriving in the current session. That distinction prevents an old fundamental observation from appearing to change simply because the market price moved.

The center panel is the realtime factor projection matrix. Each column is one factor; each row is one eligible security. Updates can change many factor projections at once, but each factor column is normalized independently across stocks. The animation then moves to the aggregation and ranking panel, where a declared consensus method produces a single ordered view.

The final object is a versioned snapshot consumed by web, desktop, or mobile clients. The clients display and sort the same rows. They are not separate calculation engines.

Combining the daily state with live evidence

Let \(d_{i,j,t-1}\) be the last complete daily score and let \(v_{i,j,\tau}\) be the current-session state at intraday time \(\tau\). A general nowcast is

\[\widetilde{s}_{i,j,\tau} = \phi_j\left( d_{i,j,t-1}, v_{i,j,\tau}, \operatorname{freshness}_{j,\tau}, \operatorname{coverage}_{j,\tau} \right).\]

The function \(\phi_j\) is part of the factor version. It may define a direct intraday signal, an end-of-day proxy, or a controlled blend with the prior state. Calling this object a nowcast makes the timing honest: it reflects what can be estimated now, not a return that has already been realized.

Ranking stocks inside each factor

At a given timestamp, collect the valid projections into an \(N_\tau\times K_\tau\) matrix \(P_\tau\). Each factor column is then ranked across the eligible securities:

\[u_{i,j,\tau} = \operatorname{rank\_zscore}_i(P_\tau[:,j]).\]

The direction of this calculation is easy to miss. It compares many stocks for one factor at one timestamp. It does not rank one stock through its own price history.

Looking across factors

For security \(i\), a weighted consensus over its valid factors is

\[c_{i,\tau} = \frac{ \sum_{j\in J_{i,\tau}}a_{j,\tau}u_{i,j,\tau} }{ \sum_{j\in J_{i,\tau}}a_{j,\tau} }.\]

The weights \(a_{j,\tau}\) must have a stated meaning. They may be equal, based on trailing reliability, balanced by factor family, or used in a robust trimmed average. These are alternative views; they should not be mixed without being labeled.

Coverage travels with the score:

\[\operatorname{coverage}_{i,\tau} = \frac{|J_{i,\tau}|}{K_{\mathrm{requested}}}.\]

Two securities can have the same consensus value with very different amounts of supporting evidence. Showing factor count, coverage, and the latest input timestamp makes that difference visible.

What the front end receives

The backend sorts \(c_{i,\tau}\) into positive and negative projections and publishes one snapshot. A useful row includes the symbol, score, rank, side, factor count, tail count, coverage, as-of time, latest input time, weighting method, and normalization method.

The leaderboard and heat map are projections of that contract. They make the cross-section readable without changing the calculation that produced it.