System requirements and dependencies

Current support boundary

Arizmic is a packaged local workstation with a browser-like interface, a local API, Python research services, durable local storage, and optional connections to external data, AI, and broker providers.

The intended packaged release targets are:

Linux is not a current end-user packaged target. Repository/developer services may run in other environments, but that does not create a supported workstation release.

There is no certified universal minimum CPU, RAM, GPU, or disk number at the reviewed revision. Required resources vary materially with data shape, coverage, candidate count, fidelity, evidence depth, concurrency, and retained outputs. Use the in-app System Profile and each Study estimate rather than treating a marketing minimum as permission to run a large workload.

Packaged-user requirements

An end user needs:

• one supported signed package for the exact platform and architecture;
• permission to install and launch a local desktop application;
• a writable local application-data/results volume;
• enough current free disk for source data, canonical Datasets, Prepared Data, temporary build space, Results, exports, journals, and backups;
• enough available memory and CPU capacity for the intended workload;
• a desktop viewport at least 1024 CSS pixels wide;
• local loopback networking available for the launcher, interface, and API; and
• external network access only for explicitly selected provider, AI, update, or support workflows.

The packaged user should not install Python, Node.js, DuckDB, Optuna, Marimo, or other application dependencies manually unless a release-specific recovery procedure explicitly requires it. The signed package owns its runtime closure. Installing ad hoc developer packages into it makes support and reproduction ambiguous.

Hardware guidance comes from the current workload

Open System & Jobs -> System Settings and inspect System Profile. It reports:

• logical CPU cores;
• total physical RAM when the platform probe can resolve it;
• currently available RAM;
• free space on the volume containing the Results root;
• a measured read/write IO profile and test timestamp;
• active and queued work; and
• readiness classification and recommendations.

Available RAM is a point-in-time operating-system observation, not installed capacity. Free disk applies to the current Results volume, not every possible import source. Retest IO after changing drives or storage configuration; do not repeat the benchmark while important work is using the same disk.

Read the status as:

• Ready: the current profile has no resource blocker under its general thresholds; it is not approval for every Study.
• Constrained: the workstation remains usable, but one or more memory, disk, IO, or queue facts warrant a smaller request or operational change.
• Blocked/Unavailable: a required measurement, storage owner, or service is not usable. Resolve it before durable or expensive work.

Every Study has a more specific estimate. Review exact candidate/trial count, Prepared requirements, duration/resource estimates, concurrency, disk needs, and blockers after the complete request is authored. Shortening the window, reducing candidate count, lowering retained evidence, or serializing work can reduce requirements; silently changing fidelity or scientific meaning cannot.

Storage requirements and locations

The application-data root owns catalogs, canonical Dataset payloads, Prepared Data, raw source bundles where retained, Study/Run results, local operational state, and other workstation records.

Default platform locations are:

A saved operator location can override the default. Always confirm the active location and storage-integrity state in System Settings before importing or running work.

Use a local, writable, stable filesystem approved by the release. Do not point the active root at a temporary folder, synced consumer folder, removable drive, or network share unless that exact storage mode is certified. Capacity planning must include:

retained source/raw data
  + normalized immutable Datasets
  + Prepared outputs and build staging
  + Study and Run artifacts
  + journals, temporary publication space and exports
  + backup headroom

Atomic publication can require temporary space in addition to final artifact size. Never run the volume to zero free space and assume completed catalog rows prove every payload was retained safely.

Local ports and service boundary

The launcher starts and coordinates a local interface and API. The generated Notebook client currently defaults to http://127.0.0.1:8000, but end users should follow the launcher's reported address rather than hard-code developer ports. The interface and API must belong to the same coherent application revision.

Loopback traffic is local machine communication. It does not mean every feature is offline: provider imports, AI model calls, update checks, broker connections, and support transfers can contact external services when the operator explicitly uses them.

Local firewall, endpoint protection, proxy, VPN, browser extension, or occupied port rules can block startup. Repair the exact conflict through supported system/application controls. Do not disable security software broadly or expose the local API to a public interface to make launch work.

Network dependency matrix

Application dependency groups

These groups describe ownership, not manual installation instructions.

Package presence alone does not make a method supported. Capability depends on the complete combination of dependency, platform, request topology, data shape, runtime implementation, fixture evidence, and release state.

Optional acceleration

No GPU is required for the current baseline workstation contract. Some future or optional model-backed optimization, local AI, or numerical paths may benefit from or require acceleration, but they must declare:

• supported OS/architecture and device/runtime versions;
• memory and driver requirements;
• deterministic/fallback behavior;
• exact capability state when acceleration is absent; and
• retained parity and performance evidence.

Do not install an arbitrary CUDA, ROCm, Metal, Torch, compiler, or driver stack into the packaged app based on a page label. If the exact capability reports Blocked, choose a scientifically valid supported method or use a certified build containing the required runtime.

Notebook environment is separate

The workstation environment and each Marimo sandbox are different dependency owners.

• The packaged/repository lock controls the application runtime.
• A Notebook .py file can declare direct PEP 723 requirements.
• Marimo --sandbox and uv resolve a separate environment for that file.
• PEP 723 declarations are not a complete transitive lock.
• A machine-local package cache is not reproduction evidence.

At the reviewed revision, a scaffold can launch while its cell fails to import arizmic.api.generated_read_client. The coarse Notebook prerequisite check does not preflight uv, full resolution, local Arizmic import, API compatibility, or every declared dependency. Preserve the error and do not repair it by widening sys.path, importing private service modules, disabling sandboxing, or installing into the application runtime.

Provider, credential, and entitlement dependencies

Historical data, remote AI, Paper, and future real operation each have separate providers and secret owners. For every connection, distinguish:

• the provider definition;
• installed adapter/runtime;
• environment and endpoint;
• credential presence and scope;
• account or data entitlement;
• connection test;
• capability/readiness result; and
• retained certification where execution is consequential.

A configured credential does not prove entitlement. A tested connection does not prove import mapping, model availability, broker Instrument identity, order support, or Live certification.

Store secrets only through the intended credential surface. Never place them in Dataset mappings, Signal/Strategy source, Notebook files, Study names, operator reasons, screenshots, diagnostics exports, support packets, or AI prompts.

Compatibility and upgrade requirements

Before installing or upgrading, require release-specific evidence for:

• supported platform and architecture;
• signature/notarization and package checksum;
• application, API and UI revision compatibility;
• storage schema and migration path;
• generated-client/OpenAPI compatibility;
• plugin/Library package contract versions;
• provider adapter and certification compatibility; and
• backup, rollback, uninstall and data-preservation behavior.

Back up through the supported data-owner workflow before a migration. Replacing application files is not a supported storage rollback. After upgrade, run the first-launch health check and verify the active data root, System Profile, API, Jobs, Activity, and one bounded smoke workflow before new long work.

Troubleshooting lookup

Technical dependency boundary

signed platform package
  -> launcher-controlled local UI + API + storage owners
  -> request-specific capability and resource preflight
  -> optional isolated Notebook or provider dependencies
  -> exact Job/operation
  -> retained result, artifact, journal or receipt

End-user support attaches to the signed package and its declared extension points. Repository locks, optional groups, developer scripts, upstream editor menus, and importable Python modules do not become public support contracts unless the release explicitly says so.

Next

Use Install and Launch and First Launch and Health Check for setup. Use System Settings, Information, and Benchmarks to inspect the current machine, and Environments, Dependencies, and Locks for Notebook-specific behavior.