Understand core objects and versions

What this guide is for

Arizmic passes named, versioned objects between its pages. Understanding those objects is the fastest way to understand the workstation and avoid comparing results that were produced from different inputs.

The practical rule is:

Select the exact input versions, let Arizmic record what was used, and treat a changed definition as a new version rather than silently changing old work.

You do not need to memorize internal identifiers. You should be able to answer which Dataset, Signal, Strategy, Portfolio, and Study produced the Result you are reading.

Instrument

An Instrument describes what a market-data symbol means: venue, asset, currency, contract details, timezone, session rules, price scale, and other properties needed to interpret timestamps and values correctly.

A symbol alone is not enough. The same text can mean different products or session conventions at different providers. Confirm the Instrument mapping when importing data and before combining data from multiple sources.

Dataset

A Dataset is a retained market-data source registered in Data Manager. It records the source, Instrument mapping, schema, coverage, timestamp meaning, and content identity needed to distinguish it from another import.

Importing a corrected file or requesting a different provider window creates a new candidate and, after review, a new Dataset version. It does not rewrite a Dataset that an older Study already used.

Use Data Manager -> Catalog to select the exact Dataset and inspect its coverage and state.

Prepared Data

Prepared Data is a reusable form derived from a Dataset for a declared use, such as bars, aligned arrays, trades, quotes, or supported order-book replay.

Its identity includes the Dataset and the preparation settings. Two Prepared Data items created from the same Dataset can differ because their interval, session handling, price basis, or required market-data level differs.

Strategies and Studies should request the capability they need. Arizmic then reuses a compatible prepared build or shows what is missing. Do not select a higher-fidelity label unless the Dataset actually contains the required fields.

Signal and Signal Output

A Signal is a reusable Python calculation with declared inputs, parameters, data-level requirements, and output columns. A moving average, session VWAP, order-flow imbalance, or queue-related measure can be a Signal.

A Signal Output is the result of applying one exact Signal version and parameter set to compatible Prepared Data. A Strategy can depend on that declared output without copying the calculation into its own code.

Signals can depend on other Signals. Review upstream dependencies before sharing or installing a Signal package so the complete required set is available.

Strategy and Strategy Configuration

A Strategy defines the rules that turn data and Signals into decisions, orders, sizing, and exits. It can be supplied by Arizmic, authored with the Python SDK, built with the visual composer, or proposed through AI Companion and reviewed before saving.

A Strategy Configuration pins one Strategy version to a concrete parameter set and supported execution assumptions. The Strategy answers what rules are available; the Configuration answers which exact settings are being used.

Editing a draft does not change a saved version. Save a new version and select it explicitly in the next Study.

Portfolio and Portfolio Configuration

A Portfolio combines exact Strategy Configurations with allocation, shared capital, priority, admission, and risk rules. It is more than a list of backtests because members can compete for the same account resources.

A Portfolio Configuration pins the member versions and the portfolio-level settings used by a Portfolio Study. Changing a member Strategy version or an allocation produces a different configuration.

Study and Study Result

A Study defines work to run. It identifies whether the subject is a Strategy or Portfolio, the selected inputs, the method, the parameter domain, the execution fidelity, resource limits, and any supported validation design.

Examples include one fixed Strategy run, a bounded parameter search, a walk-forward design, or a Portfolio Study. The available controls depend on the selected subject, data, and implemented Study capability.

A Study Result records the outcome of that exact design, including its status, trials or candidates where applicable, retained views, validation blocks, diagnostics, and produced Run Outputs.

Changing a Study and running it again creates a distinct request and Result.

Run Output

A Run Output is the retained result of one executable Strategy or Portfolio configuration on exact inputs and execution assumptions. Results reads this object across overview, chart, performance, parameters, trades, robustness, diagnostics, and output views when those artifacts are present.

Not every Run Output contains every view. Availability depends on the Study, retention settings, subject, data, fidelity, and whether the run completed. Missing information stays unavailable; it should not be interpreted as zero or as a passing check.

Deployment and Live records

A Deployment binds an approved Strategy release candidate to a supported broker connection, account, Instrument mapping, risk policy, and operating mode. It is a separate object from a Study or Run Output.

Live keeps operational decisions, orders, fills, reconciliation, risk events, and operator actions under the deployment or session that produced them. Backtest and Paper results inform a deployment decision but do not guarantee live behavior.

Notebook project and AI conversation

A Notebook project is editable Marimo Python source plus its environment, bound context, and project metadata. It can read supported, bounded workstation data without becoming a Dataset, Strategy, Study, or Result.

An AI conversation records messages, disclosed context, model information, proposals, approvals, and receipts according to the AI Companion permission system. AI can explain or propose changes; it does not silently change the identity of an owning product object.

Follow one object chain

A typical Strategy run follows this chain:

1. An Instrument gives the market meaning.
2. A Dataset supplies the retained source data.
3. Prepared Data supplies the form required by the selected Strategy.
4. Signal versions and outputs provide reusable calculations where needed.
5. A Strategy Configuration pins the rule version and parameters.
6. A Study pins the inputs, method, fidelity, and bounds.
7. A Job executes the request.
8. A Study Result and Run Output retain what happened.

Portfolio work inserts a Portfolio Configuration between the member Strategy Configurations and the Study. Live work starts from a separately approved candidate and creates a Deployment rather than treating a Run Output as a live session.

Check versions before comparing Results

Before comparing two runs, confirm:

• Dataset and Prepared Data identities;
• Instrument and session meaning;
• Signal and Strategy versions;
• parameter values and Portfolio membership where applicable;
• Study method and validation design;
• execution fidelity and cost assumptions; and
• retained output completeness.

If any material input differs, describe the comparison as a comparison of two different configurations. Do not attribute the difference to a single parameter unless the rest of the inputs were held fixed.

Next, use Your First Strategy Run to follow this object chain once in the workstation.