> For the complete documentation index, see [llms.txt](https://docs.concurrence.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.concurrence.com/intelligence-and-analytics/intelligence/analytics-dashboards.md).

# Analytics and Dashboards

Workspace analytics, pipeline observability, entity inspection, dashboards, and the Insights Agent - with their freshness and evidence boundaries.

Concurrence exposes several workspace-scoped analytics surfaces. They do not share one universal data source, refresh schedule, or filter contract. Interpret each result according to the evidence that produced it:

| Surface                          | Primary Evidence                                                         | Important Boundary                                                            |
| -------------------------------- | ------------------------------------------------------------------------ | ----------------------------------------------------------------------------- |
| **Call intelligence**            | Completed voice interaction artifacts                                    | Fields can be null or absent when the required call evidence was not produced |
| **Production eval analytics**    | Persisted assertion and metric verdicts                                  | Covers only conversations that were evaluated                                 |
| **Surface analytics**            | Surface lifecycle and saved-field state                                  | A drop-off correlation does not prove that a field caused abandonment         |
| **World and pipeline analytics** | Serving projections, per-source ingestion health, and diagnostic queries | Live status and historical counts can have different freshness                |
| **Metric store**                 | Recent metric values and durable metric history                          | Latest API reads can be fresher than dashboard panels                         |

## Call and Eval Analytics

Voice call analytics read the call-intelligence projection for the selected workspace and time window.

| View                         | What It Returns                                                                                                                        |
| ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| **Call quality**             | Average, p50, and p95 quality score; call count; escalation rate; average duration; a time series; and quality-score bands             |
| **Advanced call statistics** | p50, p95, and p99 duration; quality percentiles; a trend with p95 audio latency; and service and direction breakdowns                  |
| **Emotion trends**           | Dominant-emotion counts and average valence and arousal over time when emotion evidence exists                                         |
| **Latency**                  | Engine p50 and p95, audio time-to-first-byte p50, p95, and p99, plus average navigation and render values                              |
| **Tool performance**         | Aggregate tool calls, successes, failures, failure rate, and a time series. It does not provide per-tool duration or per-tool ranking. |
| **Operator performance**     | Escalation count and rate, operator-handled count, escalated-call duration, quality comparison, and an escalation trend                |
| **Eval quality**             | Overall and per-eval-key pass rate and average score, plus a trend across persisted production eval verdicts                           |

Most call-intelligence endpoints accept a one-hour, one-day, or one-week interval, an optional service filter, which must be a service UUID, and a `days` lookback of up to 90 days. Advanced call statistics, tool performance, and eval quality also take `group_by=service_id`, which returns, in one response, the results for each service with data in the window; see [Per-Service Results](https://docs.concurrence.com/developer-guide/platform-api/safety/analytics#per-service-results). Endpoints that accept explicit start and end dates use those dates instead of the lookback. Advanced call statistics can also filter by inbound or outbound direction. The explicit comparison endpoint accepts separate current and previous date ranges and returns absolute and percentage deltas.

The workspace home composite is narrower: it returns six headline call KPIs for a one-to-90-day window and compares applicable values with the preceding equal-length period.

{% hint style="warning" %}
An empty series can mean that no eligible evidence exists or that an asynchronous projection has not caught up. It is not proof that the measured behavior did not occur. These views return `503` when the analytics store can't answer; see [Unavailable Analytics](https://docs.concurrence.com/developer-guide/platform-api/safety/analytics#unavailable-analytics).
{% endhint %}

### Call Detail and Retention

Aggregate analytics and call detail have separate availability paths. A retained analytics row does not guarantee that a recording, transcript, full turn history, or every post-call artifact is still available. Apply the workspace's retention policy to each artifact type and treat missing evidence as unknown rather than zero.

### Production Eval Evidence

Production eval analytics are channel-agnostic because verdicts are keyed to the durable conversation. Voice, text, SMS, and email conversations can contribute when an eval actually ran and persisted a result.

Eval scores are model- or assertion-derived evidence, not proof of factual, clinical, or regulatory correctness. Automatic post-conversation evaluation is feature- and configuration-dependent, and the manual evaluation endpoint persists its results rather than acting as a non-persisting preview.

## Surface Analytics

[Surfaces](/channels/surfaces.md) have four analytics views:

| View                      | What It Returns                                                                                                  |
| ------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| **Completion rates**      | Created, opened, completed, and abandoned totals; completion and drop-off rates; a trend; and a source breakdown |
| **Channel effectiveness** | Delivery count, completion count and rate, and average completion time by observed channel                       |
| **Field abandonment**     | Overall abandonment plus saved and missing counts for fields on abandoned surfaces                               |
| **Entity history**        | Completion statistics, the most frequently observed channel, and recent surfaces for one entity                  |

Date-based surface views default to a 30-day lookback, with `days` capped at 90. Views that accept explicit start and end dates use those dates instead. Completion rates additionally support interval and entity filters. Entity history uses a separate result limit rather than a date-range filter.

Field-level results describe where incomplete submissions stopped. Use them to form a hypothesis, then validate wording or workflow changes with controlled comparisons. The data alone cannot establish that a question was confusing, unnecessary, or too sensitive.

## Event and Data Quality Analytics

### Event Breakdown

The event-breakdown view returns current aggregate counts by event type and reported source. It is useful for checking whether expected event families and sources are represented. It is not a historical time series, so do not infer when a source became quiet from this response alone.

Use pipeline source history or connector-health data for temporal ingestion evidence.

### Current Data-Quality Coverage

When its serving projection has data, the data-quality endpoint returns an aggregate projected confidence value and event count.

Do not use this response as a complete confidence distribution or source-quality comparison.

## Pipeline Observability

Pipeline observability reads stored workspace read models and diagnostic analytics:

| View                  | What It Shows                                                                                                   |
| --------------------- | --------------------------------------------------------------------------------------------------------------- |
| **Status**            | Total events, read-model status and sync time, and entity count                                                 |
| **Sources**           | Configured sources with activation, stored health status, and event counts                                      |
| **Source detail**     | Source metadata, recent failures, diagnostic event history, and outbound summary when those reads are available |
| **Outbound**          | Per-sink synced, failed, and pending counts plus an attempt log                                                 |
| **Throughput**        | Hourly or daily ingestion counts for the requested window                                                       |
| **Entity resolution** | Historical `same_as` edge counts and the currently reported resolution-loop status                              |

Diagnostic history, outbound, and throughput views can return empty results when their analytical reader is unavailable. Summary responses expose read-model availability separately where supported; preserve that distinction in alerts and dashboards.

### Connector Health and Loop Latency

Two Sensorium views add operational evidence:

* **Connector health** - events in the last hour and rolling 24 hours, mean events per minute, most recent ingestion time, a freshness category, and read-model status for each observed source.
* **Loop latency** - the median time between paired sensing and agent-action events over a one-to-168-hour window, with hourly counts, median values, and a truncation flag.

Loop latency covers only events the pairing logic can associate. A low pair count or a truncated sample limits what can be concluded about end-to-end behavior.

## Workspace and Agent Health

### Workspace Health Composite

The Platform API exposes a composite used by the Developer Console home page. Its three sections fail independently and the response identifies degraded sections.

| Section          | Current Observed Coverage                                                                   |
| ---------------- | ------------------------------------------------------------------------------------------- |
| **Voice**        | Active calls, active escalations, calls today, average quality, and today's escalation rate |
| **Data quality** | Entity count and historical recent `same_as` edge count                                     |
| **Identity**     | Active API key count                                                                        |

The active-call values come from the live voice service. Calls today, average quality, and the daily escalation rate count production calls since midnight UTC, the same totals the analytics dashboard reports.

### Developer Console Production Health

The Developer Console home page shows a workspace pulse with active agents, calls today, active calls, average quality, escalation rate, and tool success. Agent cards link to a production detail page with call-quality, latency, emotion, and aggregate tool-performance charts plus recent calls.

The current status badge is a UI heuristic:

* **Paused** - the service is inactive.
* **Degraded** - the average call-quality score is below 80, or the selected period contains zero calls.
* **Live** - neither degraded condition is met.
* **Unknown** - the service's call analytics couldn't be read, so its health isn't measured. The pulse and the production detail charts then show **Analytics unavailable** rather than zero or no data.

`Live` is not a safety certification, availability guarantee, or proof that all analytical inputs are present. Escalation rate is displayed but does not determine the badge.

## Entity Inspection

Entity intelligence exposes four current behaviors:

| Capability             | Current Behavior                                                                                                     |
| ---------------------- | -------------------------------------------------------------------------------------------------------------------- |
| **Relationship graph** | One level of stored current edges and neighbor metadata                                                              |
| **Provenance**         | Entity identity and historical `same_as` merge information; source and confidence-history arrays are currently empty |
| **Duplicate history**  | Historical `same_as` edges ordered by stored confidence. It does not run a current duplicate-detection model.        |
| **Search**             | Case-insensitive display-name search with entity-type filtering and pagination                                       |

Historical `same_as` rows came from the earlier resolver. The active pipeline does not create new merge edges. Lineage responses also retain empty outbound-sink and review-history arrays for compatibility, so they are not a complete delivery or governance audit.

### Narrative Briefs

Brief routes accept patient, cohort, territory, emirate, and district entities, with a separate workspace-level route. Responses include Markdown and structured content, evidence identifiers, confidence, event count, version, generation time, and a truncation indicator when a brief has evidence.

The current serving path does not yet load event evidence into brief generation. A generation request therefore produces the empty-evidence response rather than a synthesized patient or population narrative. Do not use the current brief response as a clinical summary. A read before any brief exists returns a successful empty shape with `event_id: null`.

## Dashboards

Three immutable built-in dashboard templates are visible to every workspace:

| Dashboard                 | Current Panels                                                                                                                                                        |
| ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Data Browser Insights** | Operational views over available FHIR resources, world entities, facilities, and provider availability                                                                |
| **Realtime Metric Store** | Metric summary, numerical scores, daily scored events, production versus simulation values, categorical distribution, entity coverage, freshness, and per-call scores |
| **Eval Summary**          | Workspace-aggregate eval scores by metric, trend, and categorical outcome                                                                                             |

Definitions are available without workspace setup, but panels can be empty or unavailable until their source data and analytical query path are ready. The built-in templates refresh every five minutes by default.

Workspace dashboards are separate mutable resources. The dashboard API supports create, list, read by ID or slug, update, soft delete, and panel execution. Built-in templates cannot be updated or deleted through the workspace API. Panel queries are executed with workspace scoping, and execution requires data-view permission.

### Embeddable Rendering

The Developer Console renders dashboard definitions with the `@amigo-ai/dashboards` component package. The same `DashboardEmbed` component can fetch a definition by slug, execute its panels, apply declared filters, and refresh on an interval when supplied with a Platform API base URL, workspace ID, and valid authentication.

Embedding does not weaken workspace authorization. External applications must protect credentials and preserve the Platform API's data-view permission boundary.

## Insights Agent

The Insights page combines a proactive digest with conversational analysis:

* The digest and suggested questions can remain unchanged for up to five minutes after source data changes.
* Chat creates a workspace-scoped session and streams progress, tool activity, structured result blocks, follow-up suggestions, and completion events over SSE.
* Result blocks can contain text, metric cards, tables, entity lists, and Plotly charts.
* Tool labels and results can be visible, but hidden model reasoning is not exposed.
* A session uses one model for every answer. When that model is rate limited or unavailable, the chat returns an error block and keeps the session rather than switching models.

The agent can use guarded workspace queries, entity reads, call analytics, metric values, and available analytical functions. The freshness of an answer depends on the selected tool and its underlying projection. Model-generated interpretation can be incomplete or incorrect, and malformed visual blocks can be discarded by the client. Verify material operational or clinical conclusions against the cited records and direct API results.

Useful questions include:

* "How has call quality changed over the last seven days?"
* "Show production and simulation values for these metric keys."
* "Which entity types are represented in this workspace?"
* "Summarize recent call volume and escalation rate."

{% hint style="info" %}
**Developer Guide** - For request parameters and response schemas, see [Analytics](https://docs.concurrence.com/developer-guide/platform-api/safety/analytics) and [Insights](https://docs.concurrence.com/developer-guide/platform-api/safety/insights) in the developer guide.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.concurrence.com/intelligence-and-analytics/intelligence/analytics-dashboards.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.