Visualizations are how you see your data in Delphi. Every chart, map, table, and metric card on a dashboard is a visualization, and every visualization reads from one or more datasets. They’re stored on each command center and render in the metrics grid by default.
Chart types
Delphi ships eleven visualization types, tuned for different questions:
- line — trends over time. The default when you’re asking “how has X changed?”
- bar — comparison across categories.
- stacked_bar — composition over categories, with each bar broken into parts.
- area — volume over time. Useful when the total matters as much as the individual series.
- pie — composition at a single point in time. Good for a handful of slices, bad for more than six.
- scatter — correlation between two variables.
- geo — geographic distribution. Routes through Delphi’s map renderer — see Maps for the details.
- table — detailed data for readers who want rows and columns instead of a chart.
- comparison — side-by-side of key figures, typically for before/after or current-vs-target.
- sparkline — a minimal inline trend, used primarily on KPI cards.
- markdown — a rich-text block for notes, commentary, or section headers. Visualizations don’t have to be charts.
Each visualization carries a title, a description, the datasets it reads from, and an optional set of series labels you can override when the auto-generated ones aren’t quite right. The freshness tag mirrors the one on datasets, so a chart built on historic data is visually labeled as such without anyone having to look it up.
The metrics grid
The metrics page on every command center is a grid: KPI cards across the top, visualizations below. Visualizations are placed into one of three layout categories:
- Hero — the key insight for this command center. Typically one or two per dashboard. Visually prominent, full-width or large.
- Supporting — context for the hero. The default layout category for most visualizations.
- Reference — detail on demand. Smaller, denser, often below the fold.
Delphi picks a layout category when it creates a visualization; you can ask it to promote, demote, or swap cards via chat. The grid isn’t free-form — it’s opinionated about what deserves the reader’s eye first.
Visualizations can also be nested: any chart can carry a small set of supporting charts beneath it so the agent can render a main chart alongside context views without forcing them all to compete for hero space.
Tabs
A busy command center can outgrow a single grid. When a dashboard has more than a handful of KPIs and visualizations, you can group them into tabs — named horizontal sections sitting between the initiative overview and the metrics grid. Each KPI and visualization can be pinned to a specific tab; anything unpinned lands in a synthetic General tab that always shows up first.
The active tab is part of the URL, so a permalink to a specific view of the dashboard survives page reload, share-by-link, and back-button navigation. Tabs are styled to match the rest of the platform — uppercase, letter-spaced labels with a cyan underline on the active one — and the bar uses real WAI-ARIA tab semantics so keyboard users and screen readers see the same structure visual users do.
Filtering is strict: the General tab shows only the unflagged items, and any other tab shows only the items explicitly tagged for it. Live updates respect the active tab — when an agent adds, removes, or retags a card mid-session, the grid reorganizes itself without needing a page reload. Ask Delphi in chat to “split the metrics into Operations and Finance tabs” or “move the streamflow charts to a Hydrology tab” and the dashboard reshapes accordingly.
Initiative hero layouts
A command center that orchestrates several initiatives can render a hero panel above the grid that summarizes the whole tree at once. There are three modes:
- point — initiatives plotted as points on a map using the lat/lon attached to each one. Good for asset trackers, field operations, and anything where each initiative is a place.
- polygon — initiatives rendered as polygon overlays from explicit GeoJSON attached to each one. Useful when initiatives correspond to bounded regions you’ve defined yourself.
- named-region — initiatives painted from named admin boundaries that Delphi resolves against its bundled GeoJSON catalog (countries, states, watersheds). The cleanest option when your initiatives line up with standard administrative geographies.
Each mode reads the geographic context attached to each child initiative — see command centers and child initiatives for how that lineage is set up. Switching modes is a chat away, and the panel falls back gracefully if a particular initiative is missing the data the chosen mode needs.
Suggested datasets
Some dashboards start with a list of suggested datasets — data sources Delphi thinks would make the command center more useful but hasn’t fetched yet. Each suggestion carries a metric name, a source (Data Commons, NOAA, World Bank, or your own warehouse), a short description of why it’s relevant, and an optional query or endpoint hint. Suggested datasets are typically generated during onboarding based on your stated problem and domain — they’re Delphi’s reading of “you probably want these.”
Accepting a suggested dataset turns it into a real dataset: Delphi fetches the data, wires up the connector if needed, and drops a visualization into the grid. Declining one closes it out so it doesn’t re-suggest itself.
Creating a visualization via chat
Chat is the primary editing surface. You describe the outcome you want and Delphi picks the right type, dataset, and layout.
Build a line chart showing daily active users on our main product over the last 90 days.
Add a stacked bar comparing ticket volume by priority over the last six months.
Show me an area chart of reservoir capacity by month for the entire water year, with last year overlaid for comparison.
Swap the line chart at the top for a comparison card showing this quarter’s revenue against the target.
If a dataset already exists, Delphi will use it. If not, it’ll wire up a new one — you don’t have to separate the data fetch from the visualization request.
Editing a visualization
There is no separate edit mode. The same chat panel you used to build a chart is how you modify it. “Add last year as a second series,” “switch to a log scale,” “filter out the weekends,” “move this to the hero slot,” “add a sparkline version for the KPI card” — all of it runs through chat. The agent rewrites the visualization document and the grid re-renders.
Classification and visibility
Visualizations inherit their classification from the datasets they read, propagated as the maximum sensitivity across sources (fail-closed on missing). If a chart reads from a confidential dataset, viewers and analysts won’t see it even though they can load the dashboard — they get a placeholder indicating the card is gated, not the data behind it. See roles and permissions for the full classification model.
The same inherited classification badge that lives on KPI cards sits in the header of every visualization too: a sensitivity tier pill plus a four-bar credibility meter sourced from the weakest upstream classification. Hovering the badge reveals the exact tier and credibility score, so anyone reading the chart can tell at a glance how trustworthy the data behind it is. Synthetic-backed visualizations carry the SAMPLE label and gaussian-blur overlay the same way KPIs and datasets do.
When to build a KPI instead
If you want a single hero number with a lineage graph, a target, a comparison period, and a provenance badge, you want a KPI, not a visualization. KPIs and visualizations live side by side on the metrics grid, but they’re different objects with different capabilities — KPIs carry versioning and provenance that visualizations don’t, and visualizations carry rendering detail that KPIs don’t need.