Frequently Asked Questions

Arizmic is a local-first algorithmic trading workstation for independent traders and strategy builders. Data import and cataloging, signal and strategy authoring, high-speed parameter search, fidelity-aware validation, notebooks, portfolio construction, and supervised live deployment run in one desktop application instead of a chain of disconnected tools.

One inspectable strategy contract carries from authoring through validation and deployment, so a dataset, parameter, cost assumption, or strategy definition does not quietly change at a handoff. Arizmic is a strategy development environment, not a signal service, a brokerage, or a promise of returns.

It is not charting software. Charts exist where they earn their cost: a Chart Output can be requested as part of a run, and notebooks plot equity paths, drawdown shapes, return distributions, and parameter surfaces with the standard Python stack. But rendering full chart output across a long study is expensive work that answers little. The value of a thousand-trial sweep is in the recorded metrics, the trial accounting, and the evidence labels, not in a thousand pictures. Discovery narrows candidates; charts are for the handful you then examine closely.

It is not a discretionary trading terminal. Live deployment exists to run versioned strategies and multi-strategy portfolio algorithms under their own risk gates. There is no manual order ticket, no depth-of-market ladder, and no click-trading surface, because those belong to a different kind of product. The one manual intervention is the kill-switch: an operator can cancel open orders at any moment and, where configured, flatten positions. That is a safety control, not an execution interface.

It is also not a hosted service, a multi-tenant platform, or a strategy marketplace. Nothing is uploaded to be backtested, and there is no venue for selling strategies to other users. Those are deliberate non-goals rather than features waiting to arrive.

On your computer. Projects, imported datasets, signal and strategy definitions, notebooks, credentials, and strategy outputs stay local by default, and local workloads carry no Arizmic cloud-compute or per-backtest charge.

Local-first is not offline-only. Information leaves the device when you connect a data service, hosted model, broker, licensing service, or update service. Device security, access control, and backups stay with you; Security describes the full boundary.

Arizmic avoids platform lock-in by using your local compute, retaining your alpha and research artifacts locally by default, connecting directly to your provider relationships, and letting you select supported AI models. Every billing interval exposes the same supported functionality, and Arizmic adds no per-backtest or metered AI-relay charges.

Local-first does not make every dependency free. Data, model, broker, connectivity, entitlement, and hardware costs remain separate and are billed by the providers you choose. Arizmic connects those services into one locally managed workflow without reselling their usage or requiring your research to live inside a hosted platform.

Choose data that matches your markets, strategy, and required fidelity, using local files or your own supported provider accounts. Arizmic supports Databento MBO full-depth (L3) market data and Rithmic futures execution alongside its bar, trade, quote, market-by-price (MBP), and market-by-order (MBO) research paths.

Each supported integration names the datasets, endpoints, markets, and entitlements it covers rather than implying universal coverage, so the data and evaluator can match the question being tested. The support matrix remains the authority on what a given connection does.

You bring your own accounts and credentials. Requests go directly to the provider you selected rather than through an Arizmic-operated relay, and provider, model, broker, connectivity, entitlement, and hardware costs are billed by those providers. If an integration you need is missing, request it through Support.

Basic Python familiarity is useful, but coding is not required. AI Companion turns a plain-English idea into reusable, adjustable signals and strategies; Visual Composer recombines those objects into variations without spending model tokens on every adjustment; and the Python SDK remains the direct-code path when you want it.

There are three ways to author one. Composer expresses the idea as structured blocks you can read at a glance. The Strategy SDK is Python, for derived formulas, reusable helper code, and version-controlled review. The AI Companion drafts a strategy from a description you refine. They are not three products: all three compile to the same validated intermediate representation, so a Composer strategy and an SDK strategy are the same object downstream — same studies, same validation, same results — and moving between paths does not mean rebuilding the work. Signals declare the inputs and prepared data they require, so missing requirements surface before a study runs rather than after. Notebooks sit beside these as a separate strategy-development surface rather than a fourth way to author a strategy.

Study design then fixes the dataset, parameter space, objective, and cost assumptions. Vectorized search covers broad parameter surfaces quickly, adaptive studies prioritize trials, and selected candidates move to event-driven validation. Every run records the inputs and assumptions it used.

The two languages answer different questions. Strategy work — signal definitions, strategy logic, study design, notebooks, the SDK — is Python, because that is where the trading ecosystem already lives, and because a strategy you cannot read is a strategy you cannot audit. The hot paths underneath are Rust: event replay, queue modelling, fill arithmetic, checksumming, and parallel trial execution. A sweep that touches billions of events cannot afford interpreter overhead per event, and Rust gives that throughput without the memory-safety class of bugs that makes a fast engine untrustworthy.

The seam is where the discipline lives. The Rust kernels carry parity evidence against an independent reference implementation, so speed is never taken on trust; fill arithmetic runs in integer tick space rather than floating point, so price representation cannot drift on a high-value instrument. The workstation is CPU-first and needs no GPU. You write Python and read Python — the native layer is an accelerator with proof attached, not a black box you are asked to believe.

Because a classic notebook lets stale output masquerade as current truth. Cells run in whatever order you happened to click, a variable can survive the deletion of the code that defined it, and the file on disk is JSON that resists diffing and code review. For strategy work whose value depends on reproducibility, that is the wrong substrate.

Marimo builds a dependency graph from the code itself and executes along it. Change a lookback window and everything downstream re-evaluates or is visibly marked stale — never silently wrong. A slider bound to a variable re-runs only the cells that depend on it, so parameter effects are explorable without callback plumbing. The notebook is stored as an ordinary .py program, so it diffs, tests, and versions alongside the rest of the project. Where automatic re-evaluation would multiply expensive work, templates put the costly read behind an explicit run control rather than pretending the cost is not there.

Arizmic gives your preferred AI model an integrated, permissioned research harness with direct workstation context, reusable product objects, validation, studies, evidence, and controlled actions. You can connect a ChatGPT subscription through OAuth, use supported API-key or compatible-endpoint routes, or run supported local models; OpenAI Platform API billing remains separate from an ordinary ChatGPT subscription.

Working with a preferred model inside Arizmic avoids manually transferring changing project context into an external chat, relying on uncertain handoffs between tools, or repeatedly spending tokens to recreate product objects for routine adjustments. Approved context goes directly to the route you choose rather than through an Arizmic-operated model relay.

The assistant works within the same permissions you have. Its output is reviewable material that still requires validation, and it holds no independent order authority: it cannot place, modify, or cancel an order.

The complete supported fidelity range is included in every subscription. Validation depth is not reserved for a higher tier.

What limits depth is data and method. Vector, bar, trade, quote, and supported depth evaluators each declare their own assumptions, and trade-, quote-, or depth-aware evaluation requires data that carries those inputs. Prepared and cached surfaces make broad exploration fast; event- and depth-aware validation is where a shortlist gets examined closely. A modeled fill is never presented as a guaranteed fill.

Preparation, not raw horsepower. Expensive work that does not depend on your parameters — session anchors, volume and auction profiles, footprints, signal outputs — is computed once, checksummed, and reused across every trial in every later study. A tool without a prepared-data layer recomputes all of it on every single trial, which is why broad sweeps become impractical there and routine here. Prepared surfaces are rebuildable rather than precious: evictable by default, pinnable when they earn their disk.

That is also why the workflow separates discovery from validation. Vectorized search covers a broad parameter surface cheaply, adaptive studies concentrate trials where the objective is actually moving, and only the surviving candidates pay for event-driven validation. Running everything at maximum fidelity is not thoroughness; it is spending your compute budget on candidates you were going to discard.

Because the record makes it checkable rather than asking you to remember. Every result names the exact dataset version it consumed and binds its subject, parameters, program, execution assumptions, and environment identity, so you can reproduce it months later. Results are immutable — re-running publishes a new record instead of editing the old one, and annotations live in a separate layer. Discovery results and validation runs are distinct record types, so a vector sweep cannot present itself as execution truth.

Two details matter more than they sound. Trial accounting records how many parameter sets were requested, attempted, completed, failed, pruned, retried, deduped, and burned — the number nobody remembers when quoting a Sharpe ratio. And lookahead is prevented by the signal contract rather than by your discipline: a signal declares its temporal access structure and the required history window is derived from it, so there is no operator-entered field to get wrong. Where a metric cannot be computed from the available data, it stays unavailable rather than being quietly substituted.

Arizmic layers out-of-sample testing, walk-forward studies, Monte Carlo analysis, parameter surfaces, trial accounting, cost assumptions, deeper execution validation, and established optimization frameworks including Optuna so you can examine fragility from multiple angles. No framework, score, or test proves future performance.

The workflow separates discovery from confirmation. Broad and adaptive studies help map where an idea appears to work; reserved data, alternate windows, perturbations, and higher-fidelity evaluation test whether that behavior survives changed conditions and more realistic execution assumptions. The resulting evidence stays attached to the versioned strategy and its exact inputs instead of being reduced to one headline metric.

Optimization is treated as an experiment with an audit trail, not a machine for manufacturing a best backtest. Requested, attempted, completed, failed, pruned, retried, deduplicated, and burned trials remain visible, while assumptions and unavailable metrics stay explicit. These controls help expose sensitivity and selection effects, but they cannot remove market risk or guarantee that historical behavior will persist.

A portfolio is a versioned strategy subject, not a reporting view stacked on top of finished backtests. Shared capital, allocation, risk, and constraints are evaluated directly rather than estimated after the fact, because the interaction between strategies is usually where the surprises live. Strategy studies and portfolio studies use one authoring grammar, so moving up a level does not mean learning a second system.

Composition stays distinct from execution. Portfolio work answers how a set of strategies behaves together on shared data and assumptions; it does not allocate capital or rebalance on its own. Notebooks bind to the same catalog, runs, and results, so an investigation that should not be reduced to a fixed dashboard stays reproducible and moves back into the workflow without a manual export step.

Arizmic uses a deliberate progression from validation to sandbox, paper, and supported live deployment. Each stage proves more of the real stack while preserving the versioned strategy contract, risk gates, reconciliation, operator control, and provider-specific availability.

In three deliberate stages. Sandbox runs a local simulated broker against live market data, so strategy logic, order lifecycle, and risk gates are exercised under live conditions without anything leaving the machine. Paper connects to the broker's real API with a test account, which is the only way to test the integration itself. Live is the same lifecycle against real capital. What you validate is what you deploy, and one deployment contract covers a single strategy or a whole portfolio.

Every order passes the pre-trade risk gates before dispatch — drawdown halt, order and notional ceilings, position and leverage caps, a daily-loss circuit breaker, and a stale-feed kill — and a blocked order is logged rather than quietly dropped. The live service runs locally and keeps running when the interface is closed, with no cloud round trip between your strategy and your broker. Reconciliation is independent and fails closed: unknown order state, stale credentials, or a lost reconciliation blocks new risk instead of guessing. Broker availability remains provider-, environment-, account-, and jurisdiction-specific, a backtest is not a guarantee of live behaviour, and the risk of loss is yours.

The Individual license covers one individual with two activated installations, billed monthly, every six months, or annually. Every interval provides the same product: the complete supported fidelity range, generally released updates, and reasonable-efforts support. The recurring price stays locked while a subscription remains uninterrupted, and the pricing section carries current rates.

Purchasing, subscription management, and license keys are handled through Lemon Squeezy. For more than one seat, start an organization conversation through Support.

Windows, macOS, and Linux. Each release names its supported operating-system versions, processor architectures, package formats, and installer signing, along with a tested minimum and a separate recommended hardware configuration.

Requirements scale with the work. A small bar-based project is not comparable to a large universe, high-resolution data, a long optimization study, or depth data, and disk space has to cover datasets, prepared caches, results, and backups. System requirements carries the current detail.