Volatility System · Build Status

What is built, and what is not

Trading has not started, so there is no performance to report. What there is instead is an engineering record: every stage of the system with its implementation status, what it does today as distinct from what it is designed to do, its input and output contracts, whatever validation evidence has been published, and the specific test it has to pass before it advances. The system is built in the open under the codename Crack the Sky, which is the repository name behind the GitHub links on this site.

Everything below is generated from one component manifest. The same file renders the status strip on the homepage and the architecture grid on the system overview, so no two pages here can disagree about what is finished.

01 · Architecture

The pipeline, in order

Numbered because it is a sequence: each stage consumes the one above it. Switch between the two views to see the system as it runs today and as it is designed to end up — the difference between them is the honest measure of how far along this is.

View
  1. 01

    Data & cleaning

    Data Operational

    Options chains, trades, day bars, dividends and the Treasury curve land on a schedule under a daily coverage audit.

    Runs today
    End-of-day and intraday options chains, option trades and day bars, underlying prices, dividend schedules and the Treasury curve land on a cron schedule. A daily coverage audit reports on the absence of a job rather than only on its failures, which is how a dataset can otherwise go missing for weeks while every log line looks healthy. Cleaning on the entitled inputs filters by open interest, flags prices that violate static no-arbitrage bounds, and reconstructs the forward from put-call parity rather than trusting a vendor field.
    Designed to
    A point-in-time warehouse in which every field used by a model can be reconstructed as it stood at the decision timestamp, with quote-level hygiene sufficient to trust a fill assumption.
    Blocked by
    Option NBBO is a 403 on the current data tier. There is no bid, ask or mid anywhere in the warehouse, so every price is a traded price — last trade, else day close. Dropping crossed and locked quotes and filtering by spread width are defined in terms of fields this tier does not provide.
    Inputs
    Vendor REST and flat-file feeds; S3 archive; the option-chain snapshot sweep.
    Outputs
    Partitioned Parquet under DATA_ROOT: option_snapshots, option_trades, option_day_bars, option_minute_bars, contracts, dividends, treasury_yields, forwards.
    Validation evidence
    Handbook: ingest
    Next acceptance test
    Publish a dated coverage report showing expected versus observed sessions, missing partitions and the largest inter-sweep gap, generated from the running audit rather than written by hand.
  2. 02

    Pricing & identities

    Data Operational

    Own implied volatility and Greeks, checked every evening against reprice and put-call parity identities.

    Runs today
    Implied volatility is inverted per contract from the traded price: Newton with bounds and a Brent fallback for European contracts, and a Brent inversion of the binomial tree for American-style SPY, so SPY volatility now comes off the same engine that prices it. A price outside the discounted no-arbitrage bounds raises an error rather than returning a NaN, and an American put priced at intrinsic inverts to zero rather than failing, because exercised now it is worth that at every volatility. Greeks are computed from the full named catalogue, European closed-form for SPX and SPXW and a binomial tree for American-style SPY. Vendor implied volatility and Greeks are copied as diagnostics and are never inputs. A daily canary re-checks the stored numbers against three identities on at-the-money names: that the engine reprices its own input, that call and put gamma and vega agree, and that put-call parity holds.
    Designed to
    A pricing layer whose every output can be re-derived from declared inputs and conventions, so that a downstream error is attributable to a model rather than to arithmetic.
    Inputs
    option_snapshots as of a stated instant, the parity forward, and the landed Treasury curve interpolated to each contract's maturity.
    Outputs
    Own IV and Greeks per contract; a daily pass or fail with median reprice error, identity failure counts and the thresholds applied.
    Next acceptance test
    Publish a dated pricing-validation report naming the identities tested, the tolerance for each, the inversion failures, and the Greek conventions in force — vega per 1.00 of volatility, theta per year of calendar time.
  3. 03

    ATM term structure

    Analytics Implemented — under validation

    One row per date, root and expiry over the archive back to 2022-08-31, with the forward recovered from parity.

    Runs today
    Per-contract implied volatilities are reduced to an at-the-money term structure: one row per date, root and expiry, carrying the parity forward, the ATM strike and both leg implied volatilities. It is built from option day bars rather than chain snapshots because day bars reach back to 2022-08-31 while the snapshot sweep only begins in 2026. Pricing is done in the forward measure, which reduces Black-Scholes-Merton to Black-76, because a spot price and a dividend yield are exactly what this tier does not provide. Vol time is a hybrid rather than a flat day count: trading sessions over 252 inside the attested and upcoming exchange calendar, falling back to ACT/365 past the horizon the calendar covers, and stamped per row so a later reader can tell which convention produced a given number rather than having to infer it. The whole archive rebuilds in about seven minutes.
    Designed to
    The level and slope of at-the-money volatility, queryable per root and expiry, as the input a 5-45 day book is actually traded off — and as the baseline any later surface fit must beat.
    Inputs
    option_day_bars, contract terms parsed from the OPRA symbol, and the Treasury curve.
    Outputs
    atm_term_structure — one row per (date, root, expiry).
    Validation evidence
    Handbook: warehouse math
    Next acceptance test
    Publish a diagnostic separating the informative case from the tautological one. When put-call parity selects the same strike as the ATM search, both legs invert to the same volatility by construction and their agreement is evidence of nothing; the acceptance test is a residual distribution computed only over the dates where the two strikes differ, together with the rejected-observation count and the reasons.
  4. 04

    Smile & surface

    Analytics Implemented — under validation

    Raw SVI per expiry over OTM strikes, SPX/SPXW only, with butterfly and calendar arbitrage repaired inside the fit. Runs daily.

    Runs today
    A raw-SVI (Gatheral) smile is fitted per date, root and expiry to total implied variance against log-moneyness, over own-inverted OTM strikes from option day bars — calls above the parity forward, puts below. Butterfly and calendar constraints are repaired inside the fit rather than checked after it, and a slice that cannot be repaired raises rather than writing an arbitrageable smile. The fitted surface evaluates at any strike and maturity, interpolating linearly in total variance between expiries and holding flat outside them. It sits alongside the ATM curve rather than replacing it, and is built from the same chain, the same forward and the same inversion, so agreement between the two at the money is a cross-check between datasets rather than a calibration target. Scheduled daily after the term structure; the archive rebuilds separately.
    Designed to
    A globally consistent, arbitrage-free volatility surface across the whole chain, extended to SSVI, that downstream Greeks and any off-strike valuation can rely on.
    Blocked by
    SPY is refused: its strikes are American and would invert under the wrong exercise boundary in a European fit path. An American inverter exists, so this is follow-up work rather than a structural limit. VIX options sit on the VX future and are a different modelling question.
    Inputs
    option_day_bars via the same chain helpers the ATM curve uses; the parity forward per expiry.
    Outputs
    vol_surface — fitted slice parameters per (date, root, expiry), read back by the surface loader.
    Next acceptance test
    Publish the residuals, the rejected observations and the slices that failed to repair — not a smooth chart. The stage advances to operational when a downstream consumer reads the surface in anger: the daily canary's off-ATM check is the intended first one, and it is not wired yet.
  5. 05

    Volatility forecasting

    Analytics In progress

    A HAR-RV baseline forecast is implemented and tested on a continuous SPY series; it is not yet scheduled or evaluated.

    Runs today
    A HAR cascade in logs — daily, weekly and monthly realised-variance terms — is implemented against a continuous SPY spot series, with its own uncertainty band. The spot series it consumes is built on a schedule; the forecast itself is not, and no out-of-sample evaluation has been run. Fitting is done in logs so the heavy right tail of realised variance does not dominate, and forecasts exponentiate back to variance.
    Designed to
    Realised-volatility estimators that use the full bar — Parkinson, Garman-Klass, Yang-Zhang — rather than close-to-close, feeding HAR-RV and GARCH-family baselines. Learned models are promoted only where they show incremental out-of-sample value over those baselines; a model that fails to beat them is a result, not a defect.
    Inputs
    Underlying minute and day bars; the ATM term structure as the implied-volatility side of the comparison.
    Outputs
    A forecast of realised volatility at a stated horizon, with its baseline comparison and out-of-sample error.
    Validation evidence
    Handbook: target architecture
    Next acceptance test
    Reproduce the baseline forecast evaluation from a frozen dataset and configuration, with a documented target horizon and temporal split, and report the HAR-RV error before any learned model is fitted. Schedule the forecast so it produces a dated series rather than a run.
  6. 06

    Signal & target sizing

    Analytics Planned

    Converts a forecast-versus-implied spread into a target position, subject to Greek budgets.

    Runs today
    Nothing. No signal or sizing code exists.
    Designed to
    The spread between forecast realised and market implied volatility becomes a signal only after it clears modelled costs. Sizing separates direction from conviction by meta-labelling: one model decides whether to act, a second sizes the bet, and the portfolio is constrained by vega, gamma and net-liquidation budgets rather than by notional. This layer proposes a target; it does not authorise one.
    Inputs
    The volatility forecast, the surface, and the modelled cost of the candidate structure.
    Outputs
    A target position per structure, with the budget it consumes.
    Validation evidence
    None published yet.
    Next acceptance test
    Given a frozen forecast and a frozen cost model, produce a target book that is reproducible from those two inputs alone, and show the no-trade gate rejecting the cases where the modelled edge does not clear the modelled cost.
  7. 07

    Risk authorisation & hedging

    Trading control Planned

    The independent authority that can veto a target. Continuous Greek accounting, banded delta hedging, margin modelling.

    Runs today
    Nothing. No risk or hedging code exists.
    Designed to
    Continuous Greek accounting with discrete delta hedging against an explicit rebalancing band, where hedging error is a cost to be optimised rather than a nuisance; scenario and stress grids across spot and volatility shocks; and margin modelling, because a strategy that survives a drawdown on paper can still be closed out by a margin call. This layer is deliberately separate from sizing: it authorises or vetoes the target that analytics proposes, and it can only reduce risk, never raise it.
    Inputs
    The target book from sizing; the current position; the surface; margin rules.
    Outputs
    An authorised book, or a veto with its reason recorded.
    Validation evidence
    None published yet.
    Next acceptance test
    Demonstrate the veto path before the sizing path: a target that breaches a vega, gamma or margin budget must be rejected and logged, with the authorised book never exceeding the proposed one on any constrained dimension.
  8. 08

    Execution

    Trading control Planned

    Fills at achievable prices, legging risk on multi-leg structures, and the SPY assignment hazards of Phase 1.

    Runs today
    Nothing is executed. Interactive Brokers Flex reporting is connected read-only, with no gateway and no trading permission, so executions can be ingested but none can be sent.
    Designed to
    Fills modelled at achievable prices rather than at the mid, because in options the quoted spread is frequently wider than the modelled edge. Multi-leg structures carry legging risk, and index settlement carries hazards of its own — AM-settled SPX expiries print off the opening auction, not the close. Early assignment, stock borrow and share delivery do not apply to SPX and SPXW, which are European-style and cash-settled, but they do apply to SPY, which is American-style and physically settled, and are therefore first-class Phase 1 execution risks.
    Blocked by
    The spread-dependent components of the cost model cannot be calibrated without an option NBBO entitlement. With no bid or ask the crossing cost can be bounded, roughly half the spread in volatility terms, but it cannot be measured or corrected for.
    Inputs
    The authorised book; the live chain; the venue.
    Outputs
    Orders, fills, and the realised cost of each against its model.
    Validation evidence
    Handbook: box operations
    Next acceptance test
    Reconcile a day of Flex-reported executions against the orders the system believed it sent, and report the difference between modelled and realised cost per fill.
  9. 09

    Evaluation

    Evaluation Planned

    Purged and embargoed cross-validation, walk-forward testing, and deflated Sharpe ratios beside raw ones.

    Runs today
    The protocol is written and published, and dated in version control, but nothing has been evaluated under it because nothing produces a result yet. The track-record page's statistics are implemented and withhold every inferential figure below twenty returns.
    Designed to
    Purged and embargoed cross-validation, walk-forward testing as the headline, deflated Sharpe ratios reported alongside raw ones, and an explicit count of every configuration tried so that the probability of backtest overfitting can be estimated rather than ignored.
    Inputs
    Every trial run, with its configuration and its out-of-sample window.
    Outputs
    A judgement under rules fixed before the result existed.
    Validation evidence
    Evaluation protocol, Track record
    Next acceptance test
    Lock the three parameters the protocol currently leaves open — the confidence level, the underperformance window and the cost margin — into a named experiment record before the first evaluation runs, rather than describing them as fixed in advance while they remain unset.
  10. 10

    Operations & logging

    Operations In progress

    Scheduled jobs, structured logs and dead-man alerting run; position and P&L reconciliation does not exist yet.

    Runs today
    The ingest box runs on an installed crontab with a continuous-integration alarm that fires when the running schedule drifts from the one declared in the repository. Every job writes structured JSON lines and pings a dead-man's-switch service, so a job that silently stops running raises an alert rather than going unnoticed. Entitlements are probed rather than assumed, and the probe fails in either direction — a capability gained is as much a change as one lost.
    Designed to
    Structured logs at every stage, daily reconciliation of expected against actual positions and profit and loss, and an alerting layer for silent failures — a stale data feed that produces plausible-looking numbers is far more dangerous than one that crashes.
    Blocked by
    Position and profit-and-loss reconciliation cannot exist before there are positions.
    Inputs
    Every job's exit status, log stream and heartbeat.
    Outputs
    Alerts, audit reports, and the operational record.
    Validation evidence
    Handbook: box operations
    Next acceptance test
    Publish the coverage and canary results as dated artifacts on this site, so that the operational claim is checkable by a reader rather than asserted.

4 of 10 stages run today. Switch to the target system to see the rest.

02 · Evidence

Diagnostic reports

The jobs that produce these run daily on the ingest box. Publishing their output here is a separate decision from running them. A component with a published report links to it; one without shows the test that would make it publishable, rather than a number that does not exist.

Data & cleaning

Coverage audit report

Not yet published

What would make it publishable: Publish a dated coverage report showing expected versus observed sessions, missing partitions and the largest inter-sweep gap, generated from the running audit rather than written by hand.

Pricing & identities

Pricing validation report

Not yet published

What would make it publishable: Publish a dated pricing-validation report naming the identities tested, the tolerance for each, the inversion failures, and the Greek conventions in force — vega per 1.00 of volatility, theta per year of calendar time.

ATM term structure

Term-structure diagnostic

Not yet published

What would make it publishable: Publish a diagnostic separating the informative case from the tautological one. When put-call parity selects the same strike as the ATM search, both legs invert to the same volatility by construction and their agreement is evidence of nothing; the acceptance test is a residual distribution computed only over the dates where the two strikes differ, together with the rejected-observation count and the reasons.

Smile & surface

Surface diagnostic

Not yet published

What would make it publishable: Publish the residuals, the rejected observations and the slices that failed to repair — not a smooth chart. The stage advances to operational when a downstream consumer reads the surface in anger: the daily canary's off-ATM check is the intended first one, and it is not wired yet.

Every report published here will carry four things alongside its numbers: the timestamp of the data it was computed from, the kind of input that produced it, the version of the code that produced it, and its known limitations. The second of those matters more than it sounds. This warehouse has no option NBBO, so every analytic on this site is derived from traded prices — last trade, else day close — and never from a quote midpoint. A report that did not say so could be mistaken for one that was quote-based, and they are not comparable.

03 · Failure modes

How this system can lie to me

A stale feed that produces plausible-looking numbers is more dangerous than one that crashes, because nothing raises and the numbers still look like numbers. These two pages are the standing inventory of that problem and the procedure for the day it happens. They are working operational documents rather than write-ups, which is the point of linking them.

Standing inventory

Latent holes

The failures that would not announce themselves: where a source of truth can quietly diverge, which silent failures the current monitoring would miss, and the operational consistency gaps that have not been closed yet. Kept as a live list rather than a post-mortem, because the entries that matter are the ones nothing has surfaced.

Procedure

Red day

What to do when a check goes red: telling one kind of red from another, the repair path when the coverage audit fails, what a pricing-canary failure means as distinct from a data one, disk exhaustion, and early closes — which look like missing data every time and are not.

Target

Target architecture

The full intended system in one diagram — inputs, data foundation, analytics and decision, the trading control loop, and the research and governance loop that feeds back into it. Most of it is not built; the pipeline above says which parts are.

04 · Performance

Trading record has not started

No capital has been deployed and no observation has been recorded. The track-record page exists, computes every statistic in your browser from a public data file, and currently says so plainly rather than showing a placeholder.

When it does start, three kinds of result will be reported separately rather than joined into one line: backtest results from historical simulation, forward simulation against live data with no money at risk, and broker-executed results reconciled against actual fills. They answer different questions and carry very different evidential weight, and running them together is one of the more common ways a track record misleads.

05 · Next

The next milestone

Stated as an acceptance test rather than a task, so that it can be judged as passed or failed rather than as progress.

Volatility forecasting

Reproduce the baseline forecast evaluation from a frozen dataset and configuration, with a documented target horizon and temporal split, and report the HAR-RV error before any learned model is fitted. Schedule the forecast so it produces a dated series rather than a run.

This is the first stage in the pipeline that does not yet run, which is what makes it the frontier. Its status and this test are both read from the manifest; nothing on this page is typed by hand.

This page was last updated . Its contents are generated from data/components.json; the manifest's own history is in the repository.