TensorAction is a local-first control plane + immutable registry we are building for quants.
It will let you version features & targets, pin dataset definitions, and promote deployable artifacts that fail fast on mismatched inputs.
Most quant failures aren’t model failures — they’re feature/label versioning, dataset composition, and distribution failures.
Quiet breakages propagate across notebooks, backtests, and execution until PnL is the first alert.
Paid data gets re-fetched across notebooks and backtests. Without range-aware caching, iteration becomes a tax (and rate limits become a bottleneck).
Alignment and joins hide leakage when they live in one-off scripts instead of versioned recipes.
Backtests manufacture profits when costs and execution constraints aren’t explicit. Without comparable assumptions, “winners” don’t survive live.
The live system doesn’t match the backtest: different datasets, feature versions, or transforms.
Data, research, and deployment don’t share a common source of truth — so “paper profits” appear.
TensorAction is being built to provide a structured DataOps layer by making features, labels, and deployment share the same versioned inputs and dataset definitions.
Six primitives we are building to prevent drift by pinning features, labels, and datasets to versioned inputs and explicit dataset definitions.
You will publish features and labels to the cloud. We will handle versioning, caching, and streaming distribution to your notebooks, backtests, and production runtimes.
You will develop with a fast local cache or enable auto-sync for immediate updates. SmartCache will fetch only uncached time windows so you don’t re-pay for the same vendor data. You will be able to manually push versioned primitives to share across your infrastructure.
Compute once, reuse everywhere. Research and production will pull the exact same versioned inputs — no shadow datasets, no “worked in backtest” surprises.
Dataset joins and timestamp alignment will be explicit, versioned, and repeatable — so look‑ahead bias can’t sneak in through ad‑hoc glue code.
Strategies will carry lineage: inputs, dataset definition, and versions. If live inputs don’t match what was tested, it won’t run.
You will keep your IP and compute private. We will orchestrate metadata and workflow while you run workloads where you want.
TensorAction is a hybrid-cloud platform for quants we are building around the hardest MVP: a reliable feature and label registry. It will store authoritative feature streams in the cloud, define datasets with explicit dataset definitions (joins/alignment), and stream the exact same versions to any local or remote environment. It will deliver reproducibility + deploy-safe lineage without forcing you into a single backtesting runtime.
Everything you need to know about TensorAction
TensorAction is a hybrid-cloud data registry for quant research and deployment, designed so the exact same versioned inputs flow from backtests to production without drift.
Quantitative researchers, solo systematic traders, and small teams who need a reliable feature/label registry and reproducible data distribution from research to production.
No. TensorAction is a control plane + data registry. You will run compute on your own machines (BYO-Compute) using your preferred research and backtesting engines; TensorAction will store your features and labels, plus recipes and results.
SmartCache is range-aware: request a time window and it only fetches uncached periods via your data-provider callback, then stores the result for reuse across research and backtests.
S3/Postgres are great storage primitives, but TensorAction adds the missing layer: immutable versions, explicit join/alignment contracts, reproducible caching/streaming, and deploy-time input validation. Feast is a great feature store; TensorAction isn’t replacing it — you can keep Feast for feature definition/serving and use TensorAction to pin datasets and enforce lineage and safety from research to production.
Yes. You can run the registry locally with full privacy and keep data in a local cache as long as you want. Start local and enable cloud sync when you need a cloud registry, or stay fully local.
TensorAction uses a BYO-compute model: heavy processing stays on your machines, not ours. The cloud registry is access-controlled by workspace, and clients never receive raw storage credentials.
Parquet + Arrow, so it plugs into common quant tooling (pandas, Polars, DuckDB, and your existing backtesting/research stack). Data will be streamable (range/chunk reads) so you don’t have to pull whole datasets to run. You keep your runtime; TensorAction focuses on the registry, contracts, and lineage.
Yes. The SDK is fully open source and developed in public, so you can audit every line, run it locally, and see exactly how data moves and is cached. Issues, PRs, and discussions stay open, and contributions are welcome.
It’s designed for large, real-world datasets. You should be able to keep hundreds of gigabytes per user at low cost, and scale beyond that as needed.
Pricing will be simple, predictable, and usage-based. Expect clear metering and guardrails (like caching and retention) so costs don’t surprise you.
You will publish features and labels with clear identity, schema, and versioning. Dataset definitions will capture joins and alignment, and the registry will ensure the same inputs are reused across your research, backtests, and live runs.
Request access and we’ll reach out with onboarding details.