The development platform
From hypothesis to deployed intelligence, without building the institution first.
A scientific ML environment designed for quantitative finance. Acquire data, construct features, train and evaluate models and agents, backtest with the discipline the domain demands, deploy, monitor, and iterate, all on one system with one provenance chain. Live today.
The problem with building it yourself
The institution is the overhead.
Serious quantitative research has a fixed cost that has nothing to do with the idea: point-in-time data plumbing, a feature layer that keeps the future out of the past, experiment tracking that survives a rename, a backtester that models the order book, deployment that can be watched and killed, and enough provenance that a result from six months ago can be reproduced today. Funds employ teams to build this. An individual builds it badly, or once, or skips it, and every methodological shortcut taken along the way shows up later as a strategy that worked in research and fails live.
Promethean is that institution, as a platform. You bring the hypothesis.
The research lifecycle
One loop, one system.
Acquire
Managed market-data feeds and your own datasets (files, tables, object stores, streams), declared once and kept current server-side. Reference data, time series, and alternative data are first-class and distinguished by design.
Construct
Features and derived datasets as typed expressions: windows, lags, joins, aggregations, and transformations that the platform materializes, versions, and serves point-in-time-correct, offline for training and online for live decisions, from one definition.
Hypothesize and train
Models and agents defined in Python, trained on managed compute with hyperparameter sweeps as a first-class experiment type. Every trial is a run; every run has an identity.
Evaluate
Out-of-sample by default. Risk and robustness (drawdown, exposure, turnover, regime sensitivity, stability across seeds and parameters) alongside return, because a headline number without its distribution tells you very little.
Backtest
Event-driven simulation against a full-depth order book, provenance-tracked and diffable against the version in production.
Deploy and monitor
A registered model becomes a live session on real market data (paper today) with equity, positions, fills, and feed health streamed back; pausable, killable, metered.
Then iterate: a new branch of data, a new feature, a new run, compared against the last one.
Methodology is enforced
The mistakes that ruin quantitative research are prevented in the read path.
Most bad strategies are good ideas evaluated wrongly: a feature that quietly uses tomorrow's close; a training set that overlaps the test window; a backtest that fills at prices that never traded; a result that fails to reproduce because the data moved underneath it.
- Point-in-time reads. Every read of a feature or dataset is as-of a timestamp. Training frames are assembled from what was knowable at each row's decision time. Look-ahead becomes a type error.
- Leakage boundaries. Datasets, features, and labels are declared with their timestamps and keys; joins are as-of joins; label windows are explicit. The platform keeps the future out of the past.
- Reproducible experiments. A run's identity is the exact code, data versions, environment, and seed. Re-running it produces the same result, or a diff that explains why.
- Robustness over headline. Evaluation surfaces distributions across seeds, parameter neighbourhoods, and time, so that a result which only holds at one point in parameter space is visible as such.
- Versioned everything. Datasets, features, models, experiments, and strategies are versioned, with lineage from any artifact back to its inputs. Branch the data to experiment; merge when it holds.
Backtesting
Simulate the book, not the bar.
Backtests here are event-driven simulations against a full-depth limit order book: your strategy's orders rest in queue, cross the spread, and consume depth like real orders would. Fills, slippage, and costs come from the book's state, not from an assumption. Every backtest is a run with identity, diffable against production and reproducible on demand, and the same strategy code moves to a live session without translation.
- ✓No look-ahead bias
- ✓Survivorship-free universe
- ✓As-of-timestamped fundamentals
- ✓Byte-reproducible run
Deploy, monitor, iterate
Deployment is part of the experiment.
Promote a model from the registry and it becomes a live session bound to real market data, with its own run identity, its own metrics, and its own kill switch. Watch equity, positions, fills, and feed health as they happen. Pause at a step boundary. Stop and flatten cleanly. Compare live behaviour against the backtest that justified the deployment.
Live execution today is paper: real data, simulated fills, no capital at risk. Real-money execution comes after the regulatory and venue work it requires. That sequencing is deliberate.
Reproducibility as a contract
Every run reproduces.
Every run records its pipeline version, dataset and feature versions, hyperparameters, runtime environment, and seeds in one immutable record alongside its artifacts. Any historical result replays. Any two runs diff. Any production model traces to the data it saw and the experiment that produced it. This is what makes a result an asset, and it is what the marketplace and the portfolio layer are built on.
inspecting a run's lineage# every run records: code, data versions, hyperparameters,
# runtime environment, and random seeds
run = client.pipelines.run(
train,
hyperparams={"lr": 1e-3, "depth": 6},
branch="experiment/feature-v3",
)
run.lineage()
# → pipeline: train@a1b2c3
# → datasets: SpotBars@v12 (branch: experiment/feature-v3)
# → features: Momentum@v4
# → env: python 3.12 · torch 2.4 · promethean 0.3.30
# → seed: 42The workspace
A research environment that is already set up.
A collaborative, browser-based workspace on managed compute with the SDK, a language server, a terminal wired to remote execution, and real-time collaboration. There is nothing to install. You can also use your own editor with the same SDK; the platform is indifferent to where the declaration was written.
# features.py: features as expressions
from promethean import Featureset, Feature, feature
from .datasets import SpotBars, OrderFlow
@featureset
class Momentum(Featureset):
"""Cross-sectional momentum over the spot tape."""
ret_5m: float = Feature(
expr=SpotBars.close / SpotBars.close.shift(5) - 1,
)
rv_30m: float = Feature(
expr=SpotBars.ret.rolling(30).std() * 1440 ** 0.5,
)
@feature
def ofi_imbalance(self) -> float:
bid, ask = OrderFlow.bid_vol, OrderFlow.ask_vol
return (bid - ask) / (bid + ask)
momentum-alpha ❯ promethean commit ./strategy
✓ resolved 2 datasets · 1 featureset · 1 pipeline
✓ typechecked Momentum (3 expressions · point-in-time)
→ backfill SpotBars@v12 ████████████░░ 84% 2.1M rows/s
→ submit RayJob train.momentum (8 CPU · 1 A10G)
▸ run a4f1c2 epoch 12/40 val loss 0.0271 seed 42
momentum-alpha ❯
Where a validated strategy goes
A validated result has somewhere to go.
A strategy that has been evaluated under the platform's methodology carries evidence other people can trust. That opens paths that were previously closed to an individual researcher:
- Distribution. Listing on the marketplace, where evaluation is standardized and discovery is by evidence.
- Capital. Access to allocators through appropriate structures, without raising a fund.
- Reputation. A reproducible track record is a credential independent of employer.
- Composition. As the portfolio layer develops, a specialized strategy becomes a component of larger products, and participates accordingly.
Economics for builders are being designed within the appropriate regulatory framework and are not yet offered.
Who builds here
Four kinds of builder.
The independent researcher
Has a signal and no infrastructure. Has been running a strategy off a laptop, a cron job, and a spreadsheet, and knows the evaluation was never rigorous.
The small quantitative team
Spends more on operations than research. Needs multi-tenant infrastructure with isolation and chargeback, and eventually a distribution channel that runs without a sales org.
The ML engineer entering finance
Has the modelling skill and wants the domain's discipline (point-in-time, leakage, regimes) as defaults.
The academic
Has a method that deserves a live test with real provenance, so that the paper's result and the market's are the same result.
Learning the discipline
The platform teaches what it enforces.
Quantcademy is a set of in-app courses that teach the platform's discipline on the platform itself: point-in-time data, feature construction, evaluation, backtesting, deployment. For an engineer entering the field it is the fastest route to producing intelligence that can be trusted. For the ecosystem it is how supply grows.
Underneath
The systems that make this possible.
Ember
The feature store: datasets and features as typed declarations, materialized server-side, served point-in-time-correct offline and online, over a durable log and columnar history.
Forge
Pipelines, sweeps, metrics, and remote execution on managed compute, under the reproducibility contract.
Registry
Immutable, versioned models and strategies with lineage to the run and data that produced them; promotion with provenance.
Build on it.
The platform is live and onboarding by cohort. If you are building quantitative strategies, models, or agents, or want to, request access and tell us what you are working on.
Request builder access