Technology / System architecture
One lineage graph. Across the stack.
A Python SDK over a Rust core connects data, experiments, model versions, and execution. Every run carries the context needed to inspect and reproduce it.
- DeclarePython SDK and research workspace
- CoordinateControl plane: compile, materialize, schedule, and record
- RunEmber data · Forge experiments · Model registry · Backtest and paper runtime
- PreserveOne lineage graph connects datasets, runs, and model versions.
What the architecture is for
Three properties, and everything follows.
- Correct. A result reflects only what was knowable when the decision would have been made. Point-in-time correctness is enforced in the data path.
- Reproducible. A result can be re-derived from its record (same code, data, environment, seed) by someone else, later.
- Comparable. Two results can be evaluated under one methodology, in one environment, so their differences are differences in the strategies and not in the measurement.
These are the properties of scientific evidence. They are also the minimum requirements for a market in intelligence and for composing intelligence into products. The stack below is what it takes to guarantee them at scale, for many tenants, continuously.
Correctness of evidence
Where the guarantees live.
Every dataset declares its keys and timestamp; every read is as-of a moment. Training frames are assembled from what was knowable at each row's decision time; joins are as-of joins; label windows are explicit. Look-ahead is prevented in the read path.
Each run is anchored to the exact code, data versions, environment, and seeds that produced it. Runs diff; any run replays; a production model traces to the experiment and data that produced it. Sweeps are data.
An event-driven simulator with a full-depth limit order book: orders rest in queue, cross the spread, consume depth; fills, slippage, and costs come from the book's state. The same strategy code runs in a live session without translation.
Ember · the feature store
Declared once. Served point-in-time-correct, offline and online.
Datasets, featuresets, and derived streams are declared as typed expressions and materialized server-side; all computation happens on the platform. Reads are point-in-time-correct offline (training frames over history) and online (latest and as-of lookups for live decisions) from one definition, with a write path that enforces schema and validates data on entry.
Momentum
Cross-sectional momentum over the spot tape. Joined point-in-time to SpotBars.
close / close.shift(5) - 1ret.rolling(30).std() * 1440 ** 0.5(bid_vol - ask_vol) / (bid_vol + ask_vol)A durable log is the source of truth
Columnar history serves range and point-in-time reads; a per-replica serving index answers latest and as-of lookups in microseconds. Reference data and time series are distinguished by storage class and routed accordingly.
Derived pipelines with checkpointed state
A leader-elected reactor executes server-side operators (windows, lags, joins, aggregations) with state that survives restarts and replay, so a windowed aggregation resumes where it left off.
Branches isolate experiments
Git-style branches keep experimental definitions away from production reads until merged. The catalog holds definitions, lineage, watermarks, and checkpoints: metadata only.
Forge · pipelines and experiments
You declare the graph. The platform runs it.
Pipelines are declared as steps with dependencies and executed remotely on managed compute; the declaration describes the work, and the platform decides where it runs. Hyperparameter sweeps fan out as trials with shared identity. Metrics stream to a columnar store and are queryable across runs, which is what makes experiment comparison (across seeds, parameters, time, and strategies) a single view. Backtests and live sessions are runs in the same system, with the same provenance.
| trial | lr | depth | val loss | seed σ |
|---|---|---|---|---|
t-19best | 1.2e-3 | 6 | 0.0271 | ±0.0009 |
t-22 | 8.0e-4 | 7 | 0.0284 | ±0.0011 |
t-11 | 2.5e-3 | 5 | 0.0302 | ±0.0019 |
t-04 | 5.0e-3 | 8 | 0.0337 | ±0.0041 |
Registry · models, strategies, lineage
Immutable versions. Promotion with provenance.
Artifacts are immutable and versioned, with lineage to the run, features, data versions, and branch that produced them. Promotion through stages is gated and reversible. A deployed model binds to a live session automatically; a listed strategy references the registry version its evidence was produced from. Chunked, deduplicated transfer keeps hundreds of versions cheap.
v0.9.0prodc81d0eSpotBars@v1112d agov0.10.0staging9b27f4SpotBars@v123d agov0.11.0deva4f1c2SpotBars@v12just nowv0.8.2archived3e60aaSpotBars@v1031d agoExecution at scale
Metered, attributed, shared.
Server-side execution
A shared, quota-managed compute cluster with per-organization priority. Workspaces run on managed Kubernetes and pause when idle.
Streaming and history
Streaming ingestion on a durable log; columnar history on object storage; in-process analytical reads for point-in-time and range queries.
Every second attributed
Compute-seconds and storage bytes are metered and attributed to an owner, which is why the platform can be priced on what it measures.
Isolation and trust
Soft at the compute layer. Hard at the data layer.
Per-organization isolation
Namespaces with database-level isolation. Compute is shared under quotas; data is isolated per organization.
IdP-agnostic sign-in
OIDC with any identity provider, passkey sign-in, scoped and auto-refreshing credentials, encrypted secrets, RBAC-guarded operators.
Yours
Your code, data, models, and strategies are yours. You control what is listed.
Rust, and why
The Python you write is a declaration. The Rust we run is the platform.
The SDK is a thin, typed Python surface over a Rust core; business logic lives in Rust. Compilation, materialization, scheduling, lineage, and data movement run in a memory-safe, concurrent engine, which is how a feature store, an experiment engine, a registry, and a backtester stay correct under multi-tenant load with predictable latency. The web application is Rust compiled to WebAssembly, so the SDK and the interface share real code.
thin SDK, heavy core# the SDK is a thin, typed surface; all logic lives in Rust
@featureset
class Momentum(Featureset):
ret_5m: float = Feature(expr=close / close.shift(5) - 1)
# commit ships the declaration to the Rust engine,
# which typechecks, materializes, and serves it.
client.commit(featuresets=[Momentum])
# this process never touches pandas, a GIL, or your CPUWhat is shown here
Diagrams describe the real shape of the system. Strategy names and run identifiers in illustrations are examples. This site shows the structure of the system and the evidence it produces; performance figures only mean something inside their methodology, so they live on the platform.