Activity

What Activity is for

Activity is the scoped operating timeline for Live. It combines active alerts with durable account, selected-deployment, and unattributed execution events so you can reconstruct what happened in journal order.

The workstation-wide Activity Log remains separate. Use it when an incident also involves imports, jobs, settings, updates, or other non-Live surfaces.

Read the three scopes

Activity separates events that have different ownership:

• Account Activity covers provider and account events that affect the connected account.
• Selected Deployment Activity covers events attributed to the chosen deployment and runtime generation.
• Unattributed Activity keeps external or unresolved provider events visible without assigning them to Arizmic logic.

Do not hide unattributed orders, fills, or positions merely because they were created outside Arizmic. They can affect capital, risk, and reconciliation.

Read active alerts

Account and selected-deployment alerts are shown separately with warning and critical counts. An alert summarizes a current condition; the event timeline provides the durable sequence behind it.

Examples include stale market data, blocked order entry, provider-session problems, queue or projection lag, risk limits, unresolved mutations, reconciliation mismatch, and pending Flatten or Kill work.

Read the alert's scope, observed time, freshness, blocker, and recommended action. A recovered condition should not remain presented as current merely because its earlier event is retained.

Filter the event timeline

Use the event filters to focus on submit, accept, fill, cancel, reject, risk block, operator, or reconciliation events. Pagination applies to the complete selected scope, so confirm the page and time range before concluding that an event is missing.

Open a row to inspect its deployment, runtime generation, session, source decision, order or fill identity, provider context, journal sequence, and related state transition where applicable.

Reconstruct an incident

For an unexpected order, fill, position, or risk action:

1. record the selected deployment, account, provider environment, and time range;
2. preserve the active alerts before changing state;
3. find the originating decision;
4. follow its durable order reservation and provider lifecycle;
5. identify fills and resulting position or risk changes;
6. include operator, restart, reconnect, and reconciliation events; and
7. compare independent provider truth before deciding the final outcome.

Use stable identities and journal order rather than sorting only by display time. Several events can share a timestamp while still having a deterministic settlement sequence.

Read overload and recovery events

The Live execution path uses bounded queues and prioritizes cancellations, Flatten, Kill, execution reports, and risk transitions. Activity reports when local processing is elevated, lagging, blocked for integrity, or recovering.

The event should distinguish local decision work, durable persistence, provider transport, market-data freshness, and reconciliation. Provider response time is not labeled as local execution latency.

When capacity or integrity is at risk, Live closes new risk before silently dropping safety-critical events. Follow the reported corrective action and confirm recovery in Monitor.

Preserve evidence before recovery

Before retrying an unknown mutation or clearing a mismatch, retain:

• deployment and runtime-generation identity;
• journal and projection high-watermarks;
• account, order, fill, and position snapshots;
• provider-session and stream freshness;
• alerts and blocker reasons;
• operator actions and their outcomes; and
• the relevant Activity window.

Do not include credentials, license keys, private strategy source, or unrelated account data in a support record. Review exported or copied diagnostics before sharing them.

When Activity appears incomplete

First verify the selected scope, filters, page, and time window. Then check journal/projection lag and provider-stream freshness in Monitor.

If a durable journal event exists but its projection is behind, keep order entry closed when the missing state affects safety. If no durable event exists for a provider-reported mutation, preserve the discrepancy and reconcile rather than fabricating local history.