What a Quant Engine Actually Computes

Knowledge Bank · Shelf: Financial Analytics

We hold a research house to a simple test: if we publish a number, we should be able to show where it came from, how it was calculated, and what it cannot tell you. This piece tours one piece of our own machinery against that test. It is drawn from the house's "RA Analytical Engine: Master Plan" and its implementation record (26 September 2026), both staged in our corpus.

The engine is called ra-quant, version 0.1.0. It is a standalone TypeScript package that lives inside the Research Analyst repository. It has zero runtime dependencies, carries AGPL-3.0-or-later headers, and is consumed by file path. It holds 63 exported functions. It was built in four parallel tracks, each verified independently — 34/34, 30/30, 29/29 and 53/53 tests — and then merged. On the merged tree, verification showed a strict TypeScript check clean, 125 of 125 tests passing, and a clean build.

That is the whole of what we can state about the package's state; the analyses themselves run in the product, as the limits section states plainly. What it computes, and what it refuses to, is the subject below.

The input, and the line the engine does not cross

The engine takes one thing: a data contract called StatementSeries. That is periods plus aligned arrays of statement lines — revenue, the inputs to margins, cash flow, balance-sheet lines, shares, period-end price — serialized from statements the research pipeline already fetches.

The engine itself does no fetching. It has no network code, no file reads, no clock. It is pure functions over numbers handed to it. Whatever is wrong or missing upstream stays wrong or missing here; the engine does not repair it.

Five design laws

The master plan sets five laws, and the implementation record confirms them:

  1. Pure functions only — no I/O, no network, no clock.
  2. Nulls in, nulls out. Insufficient data returns null rather than throwing or filling. NaN and infinities are treated as missing.
  3. One documented sign convention: cash-flow outflows — capex, buybacks, dividends — are positive magnitudes.
  4. Every exported function documents its formula and its canonical source.
  5. No advice. The engine has no narrative functions at all. It cannot output buy, sell or hold, price targets, or recommendations, because there is no function that produces words.

The fifth law is not a policy bolted on at the end. It is a structural fact about the code.

Trends

The trends module computes compound growth (CAGR), year-over-year growth, and a log-linear trend that returns slope, fit quality and direction. It produces per-share versions of any series, margin trajectories, and a buyback-flattery divergence measure.

DuPont

Per period, the DuPont module reports net margin, asset turnover, leverage and return on equity. It also attributes a change in ROE to the three legs, in percentage points — so a reader can see which leg moved and by how much, rather than only that the total did.

Forensics

This module computes Sloan accruals (Sloan 1996), cash conversion (operating cash flow against net income), Altman Z (Altman 1968, the public-manufacturing model; above 2.99 reads "safe", below 1.81 "distress"), Beneish M (Beneish 1999, eight variables), and working-capital days — DSO, DIO, DPO.

When any input is absent, the score functions return the list of what is missing instead of a score. There is no partial score with holes shown; there is either a complete score or a named gap.

Valuation

The valuation module computes a CAPM cost of equity, and a WACC built up from explicit inputs. It runs a DCF — explicit projected cash flows plus a Gordon-growth terminal value — returning enterprise value with a year-by-year bridge. It runs a reverse DCF that solves by bisection for the growth rate a given price implies. It places a multiple's percentile against the company's own 5-year history, and produces a two-driver sensitivity grid.

Every assumption in that list is an input the caller supplies. The engine does not choose them.

Allocation and expected value

Allocation covers buyback effectiveness (share-count trend; implied average price paid versus current price), dividend profile, debt profile, and incremental return on invested capital.

Expected value covers probability-weighted scenarios, which return null unless the probabilities sum to 1 within a tolerance of 0.01; a tornado ranking of which drivers move the output most; margin of safety, (value − price) / value, after Graham 1949; and break levels — the input values at which a computed value crosses a price.

The module also carries seven mental-model lenses — Graham, Greenblatt, Lynch, Damodaran, Buffett, Dalio and Marks. Each reports its missing inputs and reads neutral when data is missing, rather than throwing.

What the tests assert

Beyond checking outputs, the suite asserts invariants regardless of the data fed in: the three DuPont legs multiply to ROE; a DCF at zero growth equals the perpetuity formula; expected value rejects probabilities summing to 1.2; and a reverse DCF of a DCF output returns approximately the input growth. These are internal consistency claims, and they are the kind of claim a reader can check without trusting us.

Why numbers, never verdicts

"Valuation with every assumption on screen" is what the design laws produce. Missing data stays missing, and is named. Assumptions are inputs, not defaults hidden in the code. And the absence of narrative functions means the engine cannot tell anyone what to do with money — not because we restrain it, but because it has no words to do so with.

The limits, stated plainly

These are the boundaries of what ra-quant v0.1.0 computes and where it stands. We state them here so that any number it eventually surfaces arrives with its provenance and its gaps attached.