> ## Documentation Index
> Fetch the complete documentation index at: https://critiqor-71f5274a.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Dashboard Sections: Reading Your Reliability Report
> A guide to every section of the Critiqor dashboard — from Executive Summary to Recommendations — and how to interpret each one for your agent.
The Critiqor dashboard is divided into purpose-built sections, each answering a specific question about your agent's run. Use this page as a reference for what each section shows, why it matters, and how to read it.
**What it shows**
The Executive Summary is the top-level verdict on your run. It presents a concise, plain-language assessment of the session's overall health — categorized as healthy, needs attention, or has significant issues.
**Why it's useful**
You can tell at a glance whether a run warrants deeper investigation. If the summary is healthy, you may not need to look further. If it flags attention or significant issues, it directs you to the right place to start.
**How to interpret it**
* **Healthy** — The run completed without notable reliability concerns. Review the Trust Score to confirm, but you likely don't need to dig into the diagnosis.
* **Needs attention** — One or more signals were flagged during the session. Read the Primary Diagnosis to understand what was observed.
* **Significant issues** — The run exhibited clear reliability problems. Move immediately to Primary Diagnosis and Runtime Evidence for a full breakdown.
**What it shows**
The Trust Score is a reliability signal expressed as a level — **High**, **Moderate**, or **Low** — accompanied by the confidence signals that informed it. It gives you a single, scannable indicator of how trustworthy the run's behavior was.
**Why it's useful**
It translates the session's observed behavior into a quick health indicator you can act on without reading the full report. Use it as your first filter: if the score is High, the run looks clean. If it's Moderate or Low, read the diagnosis.
**How to interpret it**
* **High** — The agent's behavior during the session was consistent and reliable. No significant concerns were detected.
* **Moderate** — Some signals warrant review. The run may have completed successfully, but there are patterns worth understanding before relying on this run's output.
* **Low** — The session exhibited behavior that meaningfully reduces reliability confidence. Review the Primary Diagnosis and Runtime Evidence before trusting the run's results.
**What it shows**
The Primary Diagnosis names the main finding for the run. When something went wrong — or when a pattern was observed that could lead to problems — this section describes it in plain language. Each diagnosis is grounded in observed runtime evidence from the session.
**Why it's useful**
Instead of reading through raw logs, you get a direct answer to the question: *what happened in this run?* The diagnosis gives you an actionable starting point rather than requiring you to piece together the story yourself.
**How to interpret it**
Each diagnosis includes a short description of the finding and a reference to the evidence that supports it. Use the diagnosis label to orient yourself, then navigate to **Runtime Evidence** if you need to verify or explore the underlying behavior in detail. If no issues were detected, this section confirms that the run completed without notable findings.
**What it shows**
Runtime Evidence is the detailed record of everything your agent did during the session: tool calls made, retries attempted, failures encountered, timing data, and behavioral patterns observed across the run.
**Why it's useful**
This is the raw evidence behind the diagnosis. It lets you verify why a finding was raised and trace the exact sequence of events that contributed to it. When the Executive Summary or Trust Score flags a problem, Runtime Evidence is where you go to understand the specifics.
**How to interpret it**
Look for patterns rather than isolated events. A single failed tool call may be unremarkable; repeated failures on the same tool, or a cascade of retries, indicates a systemic issue. Pay attention to timing data alongside failure counts — delays often point to external dependencies or resource constraints. Cross-reference what you see here with the Primary Diagnosis to confirm the connection between evidence and finding.
**What it shows**
The Runtime Timeline is a chronological view of your agent's activity during the session. It plots events — tool calls, retries, failures, completions — relative to each other in sequence, so you can see not just *what* happened but *when* and *in what order*.
**Why it's useful**
Some reliability problems are only visible in sequence. A retry cascade, for example, may look like separate events in a flat evidence list but becomes obvious as a pattern in the timeline. The timeline is especially useful for spotting bottlenecks, gaps in execution, or chains of dependent failures.
**How to interpret it**
Scan for clusters and gaps. A dense cluster of events in a short window may indicate a retry storm or rapid failure loop. A long gap with no activity may suggest a blocking call, a timeout, or a hung dependency. Use the timeline in combination with Runtime Evidence: the timeline shows you *when* to look, and the evidence tells you *what* was happening at that moment.
**What it shows**
Recommendations are actionable next steps generated from the run's diagnosis. Each recommendation is tied to a specific finding and describes a concrete action you can take to address it.
**Why it's useful**
Rather than leaving you to translate a diagnosis into action yourself, the Recommendations section does that work for you. It turns findings into a prioritized checklist you can work through after reviewing the run.
**How to interpret it**
Treat each recommendation as directly linked to the finding it references. If you disagree with a diagnosis or believe a finding was a false positive, you can deprioritize the associated recommendation. Work through the list in order — higher-priority recommendations appear first and typically address the most impactful issues. Once you've made changes based on a recommendation, run another observation session to verify the behavior has improved.
**What it shows**
Runs History is a list of your previous observation sessions, each displayed with its run ID, trust level, and a short diagnosis summary. It gives you a longitudinal view of your agent's reliability across multiple runs.
**Why it's useful**
A single run tells you about one session. Runs History tells you whether reliability is improving, degrading, or stable over time. It also lets you compare runs side by side — useful when you've made a change and want to confirm it had the intended effect.
**How to interpret it**
Look for trends in the trust level column. Consistent High scores across recent runs suggest stable, reliable behavior. A drift toward Moderate or Low — even without a single catastrophic run — may indicate a gradual degradation worth investigating. Click into any historical run to open its full report and review its diagnosis in detail.
**What it shows**
Settings surfaces configuration options for the current dashboard session, including visibility settings that control how this run is stored and accessed.
**Why it's useful**
It gives you control over how individual runs are retained and whether they appear in Runs History. Use it to manage the lifecycle of your reports, especially in environments where you're running frequent sessions and need to keep history manageable.
**How to interpret it**
Changes made in Settings apply to the current run's storage and display behavior. They do not affect previously saved runs. If you want to exclude a run from history — for example, a test session you don't need to track — configure that here before closing the dashboard.
A common workflow is **Executive Summary → Trust Score → Primary Diagnosis → Recommendations**. Use **Runtime Evidence** and **Runtime Timeline** when you need to understand the details behind a specific finding.