Monitor

What Monitor is for

Monitor is the command center for one selected deployment. It combines the operating controls, current chart, positions, account and deployment health, reconciliation state, and recent events needed for supervised operation.

The managed Live runtime continues independently of the browser. Closing or refreshing the website does not safely pause a deployment.

Verify the selected deployment

Start with the operating strip. Confirm the deployment name, mode, runtime state, source revision, account, and instrument scope before using any action.

The strip reports:

• whether the selected deployment is Ready, Warning, Blocked, Recovering, or Unavailable;
• whether order entry is open or closed;
• the first blocker and number of additional blockers;
• journal and projection progress;
• provider freshness;
• the latest evaluation and decision; and
• the latest requested operator action and its outcome.

A running process does not prove that market data is current, the provider agrees with local state, or order entry is safe.

Read the chart and positions

The chart provides bounded, read-only context for the selected deployment and instrument. It can show current market data and retained deployment overlays where available. It does not control execution, and chart failure or browser suspension does not change the runtime.

Use the Positions table for the current account or deployment-scoped position projection. Open a row to review quantity, average price, value, cost basis, unrealized profit or loss, source, and update time where available.

For a Portfolio, confirm both the coordinated account exposure and the member attribution. Do not interpret member rows as independent capital pools when the Portfolio uses shared capital.

Read performance health correctly

Live health separates the boundaries that can slow or block operation:

• local event processing and decision work;
• durable mutation and journal progress;
• provider transport and response;
• market-data and order-stream freshness; and
• reconciliation with independent provider snapshots.

Health may be Healthy, Elevated, Degraded but Current, Lagging, Blocked for Integrity, Recovering, or Unavailable. Tail latency and queue state matter more than a single average. A benchmark result is not proof that the current session is safe.

When detailed timing is available, the interface names the measured boundary and keeps provider network time separate from local processing. Uncertified performance targets are not presented as achieved product claims.

Use lifecycle actions

Available actions come from the current deployment state and action policy.

• Arm starts an eligible inactive deployment after readiness and any required confirmation.
• Pause stops new strategy-originated risk while preserving the deployment state required for review and recovery.
• Resume reopens operation only after current readiness, provider, and reconciliation checks pass.
• Reconcile compares durable Arizmic state with independent provider orders, fills, positions, and account state.
• Flatten Deployment requests closure of positions owned by the deployment and tracks the resulting orders and fills.
• Deployment Kill prioritizes the emergency stop policy, including cancellation and risk closure defined for that deployment.

An accepted button request is not the same as completed action. Follow the action state through Activity and confirm the provider result independently.

Reconcile before retrying

Reconcile when an order outcome is unknown, a stream has a gap, the application restarts, the provider reconnects, or local and provider state disagree.

1. Keep order entry closed.
2. Preserve the current deployment, order, and event evidence.
3. Refresh independent provider orders, fills, positions, and account state.
4. Review every mismatch and unattributed item.
5. Apply the supported corrective action.
6. Resume only after the blocker clears and current snapshots agree.

Unknown mutations remain in flight until a provider report or independent snapshot resolves them. Never treat a timeout as a rejection or submit a replacement merely because the first acknowledgement is missing.

Recover after interruption

After restart or reconnect, the managed runtime restores its generation, journal position, market-data cursor, Strategy state, timers, orders, positions, risk reservations, and unresolved mutations. It reconciles where required before accepting new risk.

If restoration cannot prove one safe state, the deployment remains blocked with a corrective action. Do not clear the state by creating a duplicate deployment or changing the account binding.

Verify Flatten and Kill

Flatten and Kill are complete only after independent order and position truth confirms the required terminal state. Continue monitoring when either action is Pending.

If any owned order, position, provider ambiguity, or reconciliation mismatch remains, keep order entry closed, inspect Orders and Activity, and use the documented retry or recovery action. Do not assume that a Killed label means the account is flat.