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, experiment, or Monte Carlo request. They live in the workspace, not inside a run.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 for how dashboards fit the wider data lifecycle.
Where Dashboards Live
On the Data page, in the Insights tab. The tab lists every dashboard in the Factory; 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
Dashboards pair naturally with pipelines: 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
- 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 Types
Thirteen types are supported:
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. In the natural flow of an 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, 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.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: 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 whose outputs bind to the dashboard. Reach the derivation by clicking through from the chart to the pipeline.