Overview
Exploratory Data Analysis (EDA) is a guided workflow, run as a conversation with Dexter, that takes a raw data source and turns it into something your team can trust and reuse: a dashboard of the numbers that matter, backed by a pipeline that documents exactly how those numbers were produced.
EDA is a workflow, not a standalone object. There is no “EDA record” saved separately in the platform: what EDA produces — a Data Insight dashboard and a pipeline — are the durable artifacts. EDA is the process that gets you there.
The workflow is opinionated. Manufacturing data is notoriously dirty, misleadingly labeled, and full of codes whose meaning lives in someone’s head rather than the file. EDA enforces a thoroughness discipline: profile the source before extracting from it, surface ambiguities to the user before assuming them away, and never present a number without knowing where it came from.
Where It Lives in the UI
EDA is initiated from chat with Dexter. Three common entry points:
- The “Explore uploaded data” quick task: the clickable entry point. Selecting it pre-fills a chat prompt (“Find insights and gaps in your uploaded data”) and launches the workflow — often the most discoverable way in.
- From a source on the Data page: open the source and ask Dexter to explore it.
- From chat directly: reference the source by name and ask for exploratory analysis.
The workflow runs in the conversation. Its outputs — the dashboard and the pipeline — appear on the Insights tab and the Pipelines tab under Data, and are linked from the source itself.
When to Use EDA vs. Plain Chat
The line isn’t rigid. A plain-chat question can escalate into EDA the moment it becomes clear the source needs real understanding before the answer will be trustworthy.
What “Thorough” Means Here
Thoroughness in EDA is specific, not aspirational:
- No sampling. The workflow profiles the full source, not a sampled head. Sampling hides the rows that break assumptions.
- Codes and tags get resolved with you. Station IDs, operation codes, status flags, and unit conventions are confirmed against operator knowledge before they’re used in a chart.
- Gaps are surfaced, not smoothed over. Missing days, dropped sensor readings, and impossible values are called out and dispositioned by you before extraction.
- Assumptions are named. Every judgment call that shapes a number — which rows to drop, how to join, which aggregation window — is recorded in the pipeline node that made it.
Step by Step
- Orient. Dexter scans the file and asks targeted questions: where the data came from, what you want to accomplish with it, and which figures matter most. This sets the target dashboard.
- Profile. Dexter reads the full source, documents its schema, value ranges, and shape, and flags anomalies. Large or complex files are routed through a dedicated profiling discipline; Excel workbooks get special handling for merged cells, hidden sheets, and formulas.
- Assess quality. Dexter surfaces gaps, ambiguous codes, and terms it isn’t sure about, and confirms interpretation with you. If understanding shifts, profiling repeats.
- Extract and present. With interpretation settled, Dexter builds a Data Insight dashboard with the charts you asked for, keeping working notes on the cleaning and joins alongside it.
- Document as a pipeline. Once the dashboard is settled, Dexter writes the pipeline: sources bound to the underlying files, transformation nodes carrying the actual code that ran, and outputs bound to the dashboard. Every number on the chart is now traceable through the pipeline back to the file and the code that produced it.
- Drive downstream work. With the source understood, the same pipeline can add outputs feeding a simulation model, a BOM, a planning model, a lookup table, or a report, reusing the derivation rather than redoing it. For data that arrives on a recurring cadence, Dexter can also turn the derivation into a reusable custom workflow so future pulls repeat the same steps.
What You Get at the End
- A Data Insight dashboard on the Insights tab, containing the charts produced from the source.
- A pipeline on the Pipelines tab, whose outputs bind to those charts. Every non-trivial number on the dashboard traces back through the pipeline to the source file and the code that produced it. The same pipeline can later carry additional outputs — a model, a BOM, a report — reusing the derivation rather than rebuilding it.
- Confirmed interpretation of the source’s codes, units, and quirks, captured in the pipeline’s node descriptions so future work on the same source starts from settled ground.
Limits and Caveats
EDA is Dexter-driven. The workflow runs through the conversation with Dexter. The “Explore uploaded data” quick task launches that conversation for you — there is no separate, no-chat EDA screen in the product today.
- Pipelines are not executed by the platform. They document work that already ran. Re-running an EDA against a fresh upload re-does the work in the conversation and saves over the same pipeline slug. See Pipelines.
- Dashboards produced by EDA are factory-scoped. They are the right home for numbers the team revisits between projects. Charts scoped to a specific simulation run, experiment, or Monte Carlo request live with that run, not on an EDA dashboard.
- Source quality is a hard floor. If the source is missing the columns needed for the target figure, or you cannot resolve a critical code, EDA will surface the gap and stop rather than fabricate a number.
- Multiple sources are supported, but relationships must be confirmed. Joining across sources (MES to ERP, cycle log to work order) requires you to confirm the join key’s meaning; the workflow will not silently guess.
For what happens to the artifacts afterward — refreshing dashboards, re-deriving pipelines against fresh uploads — see Insights and Pipelines. 
