Diagnostics

What Diagnostics is for

Diagnostics is the technical end of the Result review. It explains how the run was planned and executed, where time and resources were spent, which artifacts were produced, and why a reader or phase failed.

Use it after the decision-facing tabs. Internal ids, schema markers, paths, workers, chunks, and planner detail belong here rather than in the primary workflow.

Review the run phases

The phase timeline can include:

• input resolution and Prepared Data checkout;
• execution-model and capability validation;
• planning and resource estimate;
• engine initialization and warm-up;
• candidate or run execution;
• metrics and Robust evidence production;
• chart, event, and output retention;
• checksum and publication; and
• cleanup, cancellation, or recovery.

Each phase keeps its status, timing, warning, and corrective next action. A failed optional output is distinguished from a failure that invalidates the run.

Read resource and speed diagnostics

Diagnostics can show configured and effective workers, work attempted and completed, event or row counts, elapsed phases, throughput, peak memory, retained storage, cache reuse, and restart or resume state.

These values describe this workload on this machine. Compare speed only when data, coverage, Strategy or Portfolio version, fidelity, analysis depth, retained detail, hardware, and concurrent jobs are aligned.

Diagnose fidelity and replay

For event and order-book execution, Diagnostics can expose the technical evidence behind the operator-facing Validation summary:

• selected runtime layout and execution model;
• source coverage and event counts;
• anchors, gaps, resets, and sequence state;
• L2 or L3 route selection;
• reconstruction and queue-eligibility status;
• fallback count, which must remain zero for a valid requested L3 route; and
• blocked or malformed artifact detail.

Operator-facing conclusions remain in Validation. Diagnostics provides the exact supporting records.

Export a Result snapshot

Result snapshot packages the selected Run Output identity, linked Study Result, lineage, validation state, and retained diagnostic references for support or independent review.

Before exporting:

1. Confirm the Run Output and parent Study identities.
2. Record current warnings and blockers.
3. Include only the artifacts required for the support case.
4. Protect Strategy logic, market-data references, local paths, and licensed material.
5. Verify the exported checksum.

Export does not imply that snapshot restore is supported. Restore must remain unavailable until the app provides a validated import and lifecycle contract.

Recover a failed or partial result

• Refresh and verify that the selected identity did not change.
• Open Outputs for missing, stale, or malformed artifacts.
• Open System & Jobs for the producing job, retry, cancellation, or cleanup state.
• Use Validation to determine which conclusions remain available.
• Preserve the Run Output id, phase, error, and checksum when contacting support.

Do not delete a Run Output during diagnosis without understanding its linked Study or Portfolio Result and using the guarded lifecycle action.