> ## Documentation Index
> Fetch the complete documentation index at: https://docs.prodexlabs.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Insights

> Data Insight dashboards are factory-scoped pages of charts — the durable home for numbers your team revisits across projects and runs.

## Overview

An Insight is a **factory-scoped dashboard**: a named page in ProDex that holds one or more chart panels. Dashboards are how the team keeps durable visibility on numbers that matter across projects — cycle times, throughput trends, order mix, quality rates, anything worth revisiting rather than recomputing.

Dashboards are independent of any specific simulation [run](/product/runs), [experiment](/product/experiments), or [Monte Carlo](/product/monte-carlo) request. They live in the workspace, not inside a run.

<Info>
  **Naming.** The dashboard object is a **Data Insight**; the charts inside it are **insights**. The parent-child relationship is load-bearing: a chart cannot exist without its dashboard. See [Data Overview](/product/data-overview) for how dashboards fit the wider data lifecycle.
</Info>

## Where Dashboards Live

On the **Data page**, in the **Insights** tab. The tab lists every dashboard in the [Factory](/product/factory-management); selecting one opens it as a page with its name and description at the top and its charts laid out below. Each chart is a self-contained panel: title, chart, and a short description of what it shows and how it's computed.

## When to Use a Dashboard vs. Other Visibility Surfaces

| Surface                                           | Use when                                                                                                                                                        |
| ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Data Insight dashboard**                        | The numbers matter across projects and runs — a durable page the team revisits (cycle-time trends, order backlog, [EDA](/product/exploratory-analysis) outputs) |
| **[Run Results](/product/results-and-analytics)** | The chart is meaningful only for one specific simulation run. Lives with the run, not on a dashboard                                                            |
| **[Experiment](/product/experiments) results**    | You're comparing multiple simulation configurations side by side. Lives with the experiment                                                                     |
| **[Monte Carlo](/product/monte-carlo) results**   | You're looking at the distribution of outcomes across many repetitions of the same configuration. Lives with the Monte Carlo request                            |

Dashboards pair naturally with [pipelines](/product/templates): a pipeline's output nodes bind to the dashboard the numbers land on, so every value on a chart is traceable back through the pipeline to the source file that produced it.

## Anatomy of a Dashboard

**Dashboard fields:**

* **Name** (required): shown at the top of the page and in the Insights list
* **Description** (optional): context on what the dashboard is for

**Chart fields.** Each chart panel carries:

* **Title**: the panel heading
* **Short description**: one or two plain-text sentences on what the chart shows
* **Formula** (optional): a LaTeX expression for charts of derived metrics
* **Explanation**: one or two plain-text sentences on how the value is computed, including data provenance
* **Chart structure and data**: the chart type, axes, series, and the data points themselves
* **Axis formatting**: how numbers render, drawn from four families — numeric (integer, decimal, compact `42M`, percentage, currency), elapsed durations (`2m 30s`, `1h 30m`, and coarser day/hour and month/day variants), clock times (hour and minute since midnight), and absolute dates and datetimes

Chart data is committed inline on the chart: a chart is a **self-contained snapshot, not a live query**.

## Chart Types

Thirteen types are supported:

| Type              | Use when...                                                        |
| ----------------- | ------------------------------------------------------------------ |
| **line**          | Tracking a metric over a continuous axis (time, position)          |
| **area**          | Same as line but emphasizing magnitude under the curve             |
| **stacked\_area** | Component contributions over time                                  |
| **bar**           | Comparing values across discrete categories                        |
| **stacked\_bar**  | Bars decomposed into stacked sub-categories                        |
| **pie**           | Part-to-whole breakdown                                            |
| **scatter**       | Relationship between two variables                                 |
| **histogram**     | Distribution of a single variable across bins                      |
| **table**         | Tabular layout for dense numeric data                              |
| **heatmap**       | Two-dimensional intensity grid                                     |
| **gantt**         | Time-based intervals for jobs or events                            |
| **box\_plot**     | Spread, quartiles, and outliers across groups                      |
| **mixed**         | Series of different types (line + bar, bar + scatter) on one chart |

In practice you rarely name a primitive type directly. When you ask Dexter for a *distribution*, a *breakdown* of one dimension by another, a *trend* over time, a *pareto*, or a *schedule*, it reaches for a higher-level **composite** that resolves down to one of the thirteen primitives above (a breakdown becomes a bar or stacked bar, a distribution a histogram, and so on). The primitive is what gets persisted on the chart; the composite is just how the request is phrased.

## Creating a Dashboard

Two ways:

* **Ask [Dexter](/product/dexter/chat-and-tasks).** In the natural flow of an [Exploratory Analysis](/product/exploratory-analysis), Dexter creates the dashboard as part of turning a data source into something the team can revisit. This is the primary path.
* **Create one directly.** From the Insights tab, add a new dashboard with a name and an optional description. It opens empty, ready for charts to be added.

## Adding and Editing Charts

New charts are added by describing what you want and letting Dexter build them — either from the dashboard itself or in chat (*"add a histogram of cycle times from the latest upload to the Q3 dashboard"*). Dexter picks the chart type, pulls the data, writes the descriptions, and commits the chart to the dashboard. To edit a chart's data, type, labels, or descriptions, ask Dexter to update it and the chart is rewritten in place.

## Refreshing Charts

Charts are **static snapshots**. The data that renders is the data that was committed when the chart was last generated; there is no auto-refresh and no scheduled recomputation.

When the underlying data has changed — a new upload, a corrected interpretation, a fresh integration pull — ask Dexter to regenerate the affected chart(s) (*"refresh the throughput chart with the latest data"*). A chart is regenerated from its underlying data, not by executing a pipeline: Dexter re-runs the query or derivation against the current data and rewrites the chart in place. When that chart came out of a [pipeline](/product/templates), Dexter also re-saves the pipeline as the updated record of the derivation. On the dashboard side the chart just shows the new numbers; on the storage side the previous snapshot is replaced — no version history is kept on the chart itself.

<Warning>
  **A chart's numbers are only as fresh as the last regeneration.** Dashboards used for standing metrics should be refreshed on a cadence that matches how often the team looks at them.
</Warning>

## Sharing and Permissions

Dashboards are **factory-scoped**. Any user with access to the factory can see every dashboard in it. There are no per-dashboard permissions, no view-only sharing, and no external share links today — treat every dashboard as visible to the whole factory team.

For sharing outside the factory, generate a [report](/product/dexter/reports): ask Dexter to build a PDF or an Excel deliverable from a dashboard and it lands as a downloadable file under Reports.

## Reordering, Renaming, Deletion

Renaming and deletion are the reliable structural operations: ask Dexter to *"rename this dashboard to Q3 Throughput"* or to *"drop the WIP chart"* (a single chart or a whole dashboard can be removed), and it rewrites the affected files so the change appears on the dashboard. Reordering charts within a dashboard by asking Dexter (*"move the cycle-time chart above the utilization chart"*) is best-effort — the layout is driven by how the charts are stored, so a reorder request may not always land the way a rename or delete does.

## Limits and Caveats

* **Static data.** Charts do not query live sources at view time; freshness is a function of when Dexter last regenerated the chart.
* **Factory-wide visibility.** No per-dashboard access controls.
* **Chart-size ceiling.** Inline data means very large point counts hurt load and render times; summarize in a pipeline first.
* **No cross-factory dashboards.** A dashboard belongs to exactly one factory.
* **Provenance lives on the pipeline, not the dashboard.** A dashboard doesn't store how its numbers were computed — that lives on the [pipeline](/product/templates) whose outputs bind to the dashboard. Reach the derivation by clicking through from the chart to the pipeline.