Status, Errors, Security, Storage, and Version Compatibility

Start with the owner of the state

Arizmic uses different status systems because they answer different questions. The nearest owning page is authoritative:

• System & Jobs -> Jobs owns queued work, attempts, progress, cancellation, failure, and retry;
• the object's Library, Catalog, or inspector owns whether a Dataset, Signal, Strategy, Portfolio, Study, Result, or Deployment is present and usable;
• Readiness owns whether one exact requested workflow can proceed;
• Validation owns what a completed Result can support;
• Live owns deployment, decision, order, fill, risk, and reconciliation state; and
• System & Jobs -> Information owns the running version, build, schemas, and advertised execution modes.

Do not collapse these into one green or red badge. A completed Job can produce an object whose validation is blocked. A connected broker can still be ineligible for one deployment. An Available Dataset can still lack the fidelity or window required by a Study.

Job lifecycle

Progress is not a time estimate. Preparation, external requests, calculation, artifact writing, and cleanup have different costs. Use the named phase and last update with the percentage.

Attempt and retry rules

• A restart creates another attempt; it does not erase the earlier attempt.
• Correct a bad input, credential, storage condition, or compatibility problem before retrying.
• If an external provider or broker outcome is uncertain, reconcile it before repeating the request. A blind retry can duplicate work, orders, or charges.
• A temporary file from a failed or canceled attempt is not a Dataset, Prepared object, Study Result, Run Output, or export.
• Clear Job history only after linked output, support, billing, or incident questions are resolved.

Object lifecycle and availability

Friendly names, recency, matching columns, or a nearby file are not identity. Immutable versions and Results keep their original lineage even when a newer version becomes active.

Readiness versus availability versus validation

Never use a general object badge to override the later, more specific check.

Error and severity dictionary

The first visible error in a chain often identifies the owner. Later failures may only report that a dependent phase could not continue.

Recovery decision order

1. Preserve the exact object, Job, attempt, page, time, timezone, version, and visible error.
2. Determine whether the failure belongs to input data, a saved definition, Readiness, storage, a credential/provider, execution, artifact publication, or the running workstation.
3. Check whether an external request or Live action has an uncertain outcome.
4. Correct the earliest owning condition.
5. Refresh or run the supported validation/freshness check.
6. Create a new estimate if any material request field changed.
7. Retry through the offered control or submit a new request from the owning page.
8. Verify the new output by identity; never assume success from disappearance of the old error.

Restarting the application is not a substitute for reconciliation. Repeatedly submitting the same uncertain request can make the situation harder to audit.

Credential and connection boundaries

Credentials are provider- and field-specific. API key, client ID, client secret, account token, browser authorization, and gateway session are not interchangeable.

Secret-handling rules

• Obtain secrets from the provider's official account or developer workflow.
• Save them only through the product's protected credential control.
• After storage, use the masked configuration state or protected reference; Arizmic should not display a reusable secret.
• Never paste secrets into Strategy code, prompts, Notebook cells, labels, screenshots, diagnostics, Activity notes, or ordinary support messages.
• Rotate or revoke secrets after suspected exposure, provider revocation, scope changes, or the applicable access policy.
• Removing Arizmic's secret reference does not necessarily revoke the secret at the provider. Revoke it in the provider's own security controls when required.
• Test a rotated credential with a small bounded request before starting large work or arming a deployment.

A successful connection test proves only the fields reported by that test. Entitlement, account environment, streaming, ordering, calibration, and release certification remain separate checks.

Diagnostics and support redaction

Before sharing a diagnostic file, Result snapshot, screenshot, or log excerpt, remove information not required for the case, including:

• API keys, access or refresh tokens, client secrets, passwords, license keys, authorization codes, and gateway credentials;
• account numbers, personal information, billing identifiers, and private endpoints;
• unrestricted local paths and user names;
• licensed raw market data or full proprietary Datasets;
• proprietary Strategy, Signal, Portfolio, Notebook, prompt, or conversation content; and
• unrelated object identifiers or operational history.

Keep the safe evidence that makes the issue reproducible: product Version and Build, operating system, page and action, approximate time and timezone, safe object identity, Job ID/attempt, exact visible error, and the result of one launcher-managed restart or freshness check.

Storage ownership map

Changing the application installation must not silently decide the fate of application data. Evicting Prepared cache must not delete canonical Datasets or retained Results. Clearing Activity or Job history must not delete the owned objects those records describe.

Pin, evict, rebuild, remove, and delete

Before a destructive action, verify the exact path or object identity, the dependency preview, active checkouts or Jobs, retained Results, and whether a tested backup exists. Never use manual filesystem deletion as a shortcut around an object-level blocker.

Backup and restore boundary

The supported general backup is a cold backup of the complete active application-data folder:

1. finish or safely cancel Jobs;
2. resolve uncertain provider or Live activity;
3. stop Notebook sessions and supervised Live deployments;
4. close Arizmic and let the launcher stop managed services;
5. copy the entire reported application-data folder;
6. record source path, Version, Build, operating system, and time; and
7. verify that the backup is readable and contains the expected content.

A copy taken while services are writing can contain mismatched catalog and payload state. An exported Result snapshot is not a workstation backup, and snapshot export does not imply that snapshot restore is supported.

Protect backups as sensitive research material even when reusable secrets are kept in the operating-system credential store.

Version and schema compatibility

Historical readers use the retained object and execution identity. They do not silently reinterpret an old Result with the current Strategy, Portfolio, schema, plugin, preset, or engine behavior.

Compatibility outcomes

Unknown historical schemas stay visible as blocked inventory. Similar fields or filenames are not permission to reinterpret them.

Safe update sequence

1. Read the release notes and supported platform/architecture statement.
2. Confirm the active application-data path and current Version/Build.
3. Create and verify a cold backup.
4. Stop Arizmic and all launcher-managed processes.
5. Verify the signed or notarized package from the official distribution path.
6. Install through the supported platform workflow.
7. Wait for the launcher to reach Ready.
8. Confirm the new Version, Build, Process, and Started values in Information.
9. Run Check Workstation and accept only the offered managed reconnect or workstation update.
10. Verify Jobs, Activity, storage, and one retained object before large or Live work.

An update does not silently recompute old Prepared Data, Studies, or Results. If a release requires migration or rebuilding, its release notes and the owning page must identify the exact scope and compatibility result.

Stop when the package signature fails, the platform is unsupported, the data folder is unavailable, UI and workstation identities disagree, a required migration cannot be previewed, or retained objects disappear. Preserve the working installation and backup while investigating.

Live unknown-state rules

Live actions require a stricter response because another system can change while local confirmation is unavailable.

• A submitted order is not safely retryable until broker order and fill state are reconciled.
• A local cancellation request is not a broker cancellation confirmation.
• A connection test is not proof of continuous market/account streams or order permission.
• A displayed position is not authoritative while account state is stale or reconciliation is incomplete.
• Pause, Flatten, and Kill have different scopes; verify their effective state and resulting orders/fills rather than inferring from a clicked control.
• Arizmic-owned and externally created broker orders remain distinguishable.
• When state is unknown, fail closed, preserve the incident sequence, and use the provider/account reconciliation owner before resuming.

Never use a blind duplicate order, repeated Flatten, application termination, or local record deletion as reconciliation.

How Arizmic processes status and compatibility

user request
  -> exact object and running-version identity
  -> local validation, readiness, permissions, and capability checks
  -> accepted durable Job or supervised Live action
  -> attempt and phase transitions with bounded Activity evidence
  -> owner-specific publication or external reconciliation
  -> schema, checksum, lineage, and compatibility readers
  -> public Available / Not applicable / Blocked outcome and next action

Status is projected from the owner closest to the decision. Storage paths, files, provider responses, and logs are supporting evidence; they do not become valid objects by themselves. Destructive actions flow through dependency and scope checks. Version compatibility flows through explicit schema and semantic readers. Unknown, ambiguous, stale, or mismatched state fails closed where an action could corrupt evidence, duplicate external work, or create Live risk.

Next

Use Jobs for an operation, System Settings for storage and workstation checks, Information for Version/Build/schema identity, and Activity and Support for an incident timeline. For maintenance, follow Updates, Backup, and Uninstall.