Creating interactive dashboards in Stata with dash

Billy Buchanan

Senior Research Scientist

SAG Corporation

https://wbuchanan.github.io/stataConference2026

dash is intended as a drop-in replacement for twoway, with some limitations
Filters, brushing & linking, Bootstrap.js, several schemes, dozens of graph types, and more supported
Output a standalone HTML file with everything needed^*
Developed using an AI coding assistant
ALL AI AGENTS LIE

Motivation

Several attendees at previous Stata Conferences have requested dashboard tooling
Last year, a few attendees asked about AI coding assistance and/or integration
Combining both in a single project seemed like a unique and interesting challenge

Creating dash

Design Decisions

Building directly in Stata would be less useful to more users
Java vs Python
Streamlit vs Bokeh
Mirror twoway's syntax and behavior as close as possible
Provide some additional features common to dashboards
Identify which AI Coding assistant would provide the best results

Talk about libhtml and libd3 for why direct implementation would not be useful
Java has superior support for low-level visualization, but that would require significantly more time/effort
Python does not have the same native support for low-level visualization, but has a large number of data visualization libraries that already implement best practices in interactive visualization.
Python is also the most widely used programming language, which means AI coding assistants will have had lots of exposure to it.
So, the decision came down to which Python library to use.
Streamlit is outstanding for developing web applications, but is a much younger library.
Bokeh is a significantly more mature library designed specifically for interactive data visualization and dashboard development
Other features like KPI cards, filtering, brushing and linking, drill down*, etc...
Hand coding this would be a massive task.

A very brief history of language models

2014 - seq2seq: Allows variable length input to variable length output (Sutskever, Vinyals & Le)
2015 - attention: Provides a way to encode context in addition to semantics of the tokens (Bahdanau, Cho & Bengio)
2017 - Transformers: Adds positional encoding to attention and computational efficiencies (Vaswani et al.)
The problem I needed to solve was translating Stata to Python

How and What to translate

Data could be translated using jsonio or the Stata Function Interface
Parsing Stata commands would be easier in Stata
Not everything needed a literal translation (e.g., if/in expressions)
The biggest translation task would be the graph type declarations and their options
The first step was to develop and execute the plan, followed by creating and executing additional plans

ALL AI CODING ASSISTANTS LIE
Unlike many language translation tasks, this work required translating across a couple of languages simultaneously.
Data would be translated directly into JavaScript Object Notation, while everything about how to use the data would be translated into Python.
The Python library would then generate the HTML, SVG, and JavaScript to render the visualizations.
Programming with an AI coding assistant starts the same way hand coding should start: with a clear and well scoped plan.
The plan would provide the on-going instructions for the AI coding assistant to follow.
AI coding assistants behave the way the fundamental assumptions in economic theory say people behave
Because their training process is designed to maximize their "reward," they will find the most efficient way possible to obtain the reward, including saying that work is completed even if it isn't

Examples

nlsw88: the code


sysuse nlsw88, clear
dash clear
format wage                                       %9.2f
format ttl_exp tenure                             %9.1f
format age grade hours                            %9.0f
format industry occupation union collgrad race    %9.0f
dash (scatter wage ttl_exp, msize(small))             ///
     (lfit    wage ttl_exp),                          ///
    name(g1) title("Hourly wage by total work experience") ///
    xtitle("Total work experience (years)")           ///
    ytitle("Hourly wage (USD)")
dash (scatter wage tenure, msize(small))              ///
     (lfit    wage tenure),                           ///
    name(g2) title("Hourly wage by tenure in current job") ///
    xtitle("Job tenure (years)")                      ///
    ytitle("Hourly wage (USD)")
dash (scatter wage grade, msize(small) jitter(3) jitterseed(1988)) ///
     (lfitci  wage grade),                            ///
    name(g3) title("Hourly wage by years of schooling")   ///
    xtitle("Highest grade completed")                 ///
    ytitle("Hourly wage (USD)")
dash (histogram wage, bin(40) density)                ///
     (kdensity  wage),                                ///
    name(g4) title("Distribution of hourly wages")        ///
    xtitle("Hourly wage (USD)") ytitle("Density")
dash (kdensity wage if union == 1)                    ///
     (kdensity wage if union == 0),                   ///
    name(g5) title("Wage density: union and nonunion workers") ///
    xtitle("Hourly wage (USD)") ytitle("Density")     ///
    legend(label(1 "Union") label(2 "Nonunion"))
dash kpi count(wage),   name(k1) title("Women")             fmt(%9.0fc) ///
    subtitle("in the current filters")   update(both)
dash kpi mean(wage),    name(k2) title("Mean hourly wage")  fmt(%9.2f)  ///
    subtitle("USD, 1988")                update(both)
dash kpi median(wage),  name(k3) title("Median hourly wage") fmt(%9.2f) ///
    subtitle("USD, 1988")                update(filter)
dash kpi p90(wage),     name(k4) title("90th percentile")   fmt(%9.2f)  ///
    subtitle("of the hourly wage")       update(filter)
dash kpi iqr(wage),     name(k5) title("Interquartile range") fmt(%9.2f) ///
    subtitle("of the hourly wage, USD") update(filter)
dash kpi count(wage),   name(k6) title("Selected")          fmt(%9.0fc) ///
    subtitle("box- or lasso-selected women") update(brush)
dash build,                                                          ///
    saving("dashboards/nlsw88-filters.html") replace nobrowser        ///
    title("Young women in the labour force, 1988")                   ///
    subtitle("NLSW 1988 extract, 2,246 women aged 34 to 46")         ///
    layout(bs)                                                       ///
    tabs(Overview: k1 k2 k6 g1 g2 g3 / Distributions: k3 k4 k5 g4 g5) ///
    filterposition(left)                                             ///
    filter(industry, type(dropdown) label("Industry")  exclude(g4))  ///
    filter(age,      type(range)    label("Age")       exclude(g4))  ///
    filter(hours,    type(slider)   label("Weekly hours, at least") exclude(g4)) ///
    link(g1 g2 g3)

Proves: filters of every type, cards in every update mode, and linked brushing. If the clock is short, do the brush and nothing else.
Do: Industry dropdown, pick Construction, the third entry. Women falls to 29, mean hourly wage to 7.56, and the three scatters thin out.
Do, if time: back to All. Drag Age to 39 to 43: 989 women. Drag the hours slider to 41: 390.
Do: reset, then box-select the top-right corner of the first scatter. Selected and Women drop to the count, the mean rises, and the same women light up on the other two scatters. Say: the fit lines do not move; that is on the known-issues slide.
Do, if time: Distributions tab. The wage histogram is excluded from every filter on purpose, so set a filter and watch the union and nonunion densities move against a fixed reference.
Say: a filter change clears a brush. Hover any point: the variable labels and the formats you set.
Stage: after clicking in the dashboard the arrow keys go to it, not the deck. Click the dark margin outside the iframe to get the deck back; Esc does not help. All four dashboards load at deck start and keep their state when you step away and back.
If asked about PNG: the toolbar's Save button writes the figures only; the cards, title, filters and tabs are not in the image.

sp500: the code


sysuse sp500, clear
dash clear
format close open high low change   %9.2f
format volume                       %12.0fc
recast double close open high low change
foreach v of varlist close open high low change {
    quietly replace `v' = round(`v' * 100) / 100
}
dash (rarea low high date, fcolor(gs13) lcolor(gs13))     ///
     (line  close date),                                  ///
    name(g1) title("Daily range and close")                   ///
    ytitle("Index level")                                 ///
    legend(label(1 "Low to high") label(2 "Close"))       ///
    hover(volume)
dash (area volume date, yaxis(2) fcolor(ltblue%60) lcolor(ltblue)) ///
     (line close date),                                   ///
    name(g2) title("Close and trading volume")                ///
    ytitle("Index level") ytitle2("Volume (thousands)")
dash spike change date,                                   ///
    name(g3) title("Daily change in the close")               ///
    ytitle("Change (index points)") yline(0)
dash kpi min(date),    name(k1) title("First trading day") ///
    subtitle("in the current range")
dash kpi max(date),    name(k2) title("Last trading day")  ///
    subtitle("in the current range")
dash kpi max(close),   name(k3) title("Highest close")  fmt(%9.2f)   ///
    subtitle("index level")
dash kpi mean(volume), name(k4) title("Mean daily volume") fmt(%12.0fc) ///
    subtitle("thousands of shares")
dash build,                                                          ///
    saving("dashboards/sp500-timeseries.html") replace nobrowser      ///
    title("S&P 500 in 2001")                                         ///
    subtitle("248 trading days; narrow the dates, then download what remains") ///
    layout(bs: k1=3 k2=3 k3=3 k4=3 / g1=12 / g2=7 g3=5)               ///
    filter(date,   type(range)  label("Trading days"))               ///
    filter(volume, type(slider) label("Daily volume, at least"))     ///
    csv

Proves: dates end to end, and the CSV download. If the clock is short, do the download and nothing else.
Say: the axis reads Jan 2001 to Jan 2002. Hover the close line: an ISO date, the low, the high, the volume.
Do: drag Trading days to roughly 2 July to 28 September. First and Last trading day re-read as dates as you drag; Highest close falls to 1236.72; Mean daily volume to 12,234.
Do: click Download CSV, to the right of the filters. The browser saves dashboard.csv: header close,date,low,high,volume,change; 59 rows, exactly the trading days in that window; ISO dates; prices to the cent; a missing value is an empty field. This is "how do I get this into my paper", answered.
Say: only the filters narrow the download. A box-selection does not, and a graph's own if does not. It is opt-in, via csv, because it hands every viewer of the page every row.
Do, if time: drag Daily volume to 13,706: 48 days, and First and Last become the first and last retained days.
Stage: the date slider needs a real mouse drag. Rehearse it once by hand before the talk; it was verified by value but not by a drag inside the deck. The volume and daily-change figures sit below the fold of the 900-pixel frame: scroll inside the dashboard to show them, or leave them for questions.
If asked about the tick labels: there is an open, cosmetic item in dash's bug log. The date tick models agree with Stata on about 60% of date ranges when you write xlabel(#N) yourself; a miss picks a different calendar step or end tick, and nothing is drawn in the wrong place. This axis uses the default ticker and reads correctly.
If asked about hover(): a variable named only in hover() is silently left out of the page; volume reaches the tooltip because a graph and a card also use it.

lifeexp: the code


sysuse lifeexp, clear
dash clear
format lexp        %9.0f
format gnppc       %12.0fc
format popgrowth   %9.2f
generate double lngnppc = ln(gnppc)
label variable lngnppc "log GNP per capita"
format lngnppc %9.2f
egen byte rank_lexp  = rank(lexp),   unique
egen byte rank_gnppc = rank(-gnppc), unique
generate str28 label_country = country if rank_lexp <= 6 | rank_gnppc <= 6
label variable label_country "Country"
dash (scatter lexp gnppc, colorvar(region) colordiscrete         ///
                          mlabel(label_country) mlabsize(small) mlabposition(3)), ///
    name(g1) title("Life expectancy and income, 1998")          ///
    xscale(log)                                                  ///
    xtitle("GNP per capita (USD, log scale)")                    ///
    ytitle("Life expectancy at birth (years)")                   ///
    hover(country)
dash (scatter lexp lngnppc, colorvar(region) colordiscrete)      ///
     (lfitci  lexp lngnppc),                                     ///
    name(g2) title("Linear in log income, with its 95% band")   ///
    xtitle("log GNP per capita")                                 ///
    ytitle("Life expectancy at birth (years)")                   ///
    hover(country)
dash kpi count(country),  name(k1) title("Countries")            fmt(%9.0f) ///
    subtitle("in the current filters")   update(both)
dash kpi mean(lexp),      name(k2) title("Mean life expectancy") fmt(%9.1f) ///
    subtitle("years at birth")           update(both)
dash kpi median(gnppc),   name(k3) title("Median GNP per capita") fmt(%12.0fc) ///
    subtitle("USD")                      update(both)
dash kpi mean(popgrowth), name(k4) title("Mean population growth") fmt(%9.2f) ///
    subtitle("percent per year")         update(both)
dash build,                                                          ///
    saving("dashboards/lifeexp-encoding.html") replace nobrowser      ///
    title("Life expectancy and national income, 1998")               ///
    subtitle("68 countries, drawn under Stata's stcolor scheme")     ///
    scheme(stcolor)                                                  ///
    layout(bs: k1=3 k2=3 k3=3 k4=3 / g1=7 g2=5)                       ///
    filter(region, type(dropdown) label("Region"))                   ///
    filter(lexp,   type(range)    label("Life expectancy"))          ///
    link(g1 g2)

Proves: marker labels, a log axis, colour by region, a fit with its band, all under a real StataCorp scheme: white background, the stcolor palette. This is the drop-in claim made visible. If the clock is short, do the box-select only.
Do: Region to North America: 14 countries; the cards read 14, 71.2, 1,873 and 1.69. Say: the colour key still lists all three regions; it never changes.
Do: back to All, then box-select the rich, long-lived cluster at the top right of the log figure. 20 countries; the same 20 highlight on the right-hand figure; the cards read 20, 77.2, 24,245 and 0.49, because all four follow a brush.
Do, if time: hover Switzerland, the point furthest right: GNP per capita, life expectancy, country.
Say: the band on the right-hand figure stays at the full sample under a filter or a brush.
If asked what differs from twoway under stcolor: the colorvar() key (a labelled categorical key here, a numeric colour axis in twoway), the log-axis tick labels (powers of ten here, 10,000 and 20,000 there), the colorvar() palette (the scheme's p1 to p3 here, twoway's colour ramp there), and title alignment (left here, centred there). Background, grid, palette, labels and axis titles match.

census: the code


sysuse census, clear
dash clear
format region  %9.0f
format medage  %9.2f
format pop     %12.0fc
generate double drate  = death    / pop * 1000
generate double mrate  = marriage / pop * 1000
generate double dvrate = divorce  / pop * 1000
generate double urban  = popurban / pop * 100
generate double old    = pop65p   / pop * 100
generate double young  = (poplt5 + pop5_17) / pop * 100
label variable drate  "Deaths per 1,000 residents"
label variable mrate  "Marriages per 1,000 residents"
label variable dvrate "Divorces per 1,000 residents"
label variable urban  "Urban share of the population (%)"
label variable old    "Share aged 65 and older (%)"
label variable young  "Share under 18 (%)"
format drate mrate dvrate urban old young %9.1f
dash (scatter dvrate mrate, msize(medium)),                          ///
    name(g1) title("Divorces and marriages")                          ///
    xscale(log) xsize(10) ysize(4)                                   ///
    xtitle("Marriages per 1,000 residents (log scale)")              ///
    ytitle("Divorces per 1,000 residents")                           ///
    hover(state)
dash (scatter drate old, msize(medium)),                             ///
    name(g2) title("Deaths and the share aged 65 and older")          ///
    xsize(10) ysize(4)                                               ///
    xtitle("Share aged 65 and older (%)")                            ///
    ytitle("Deaths per 1,000 residents")                             ///
    hover(state)
dash (scatter young medage, msize(medium)),                          ///
    name(g3) title("Share under 18 and median age")                   ///
    xsize(10) ysize(4)                                               ///
    xtitle("Median age (years)")                                     ///
    ytitle("Share under 18 (%)")                                     ///
    hover(state)
dash (scatter urban pop, msize(medium)                               ///
                         mlabel(state2) mlabsize(small) mlabposition(3)), ///
    name(g4) title("Urban share and population")                      ///
    xscale(log) xsize(10) ysize(4)                                   ///
    xtitle("Population (log scale)")                                 ///
    ytitle("Urban share of the population (%)")                      ///
    hover(state)
dash (scatter drate medage, msize(medium))                           ///
     (lfit    drate medage),                                         ///
    name(g5) title("Deaths and median age, by census region")         ///
    by(region, cols(2)) xlabel(#5) ylabel(#5) xsize(10) ysize(4)      ///
    xtitle("Median age (years)")                                     ///
    ytitle("Deaths per 1,000 residents")                             ///
    hover(state)
dash (scatter medage old, msize(medium))                             ///
     (lowess  medage old),                                           ///
    name(g6) title("Median age and the share aged 65 and older")      ///
    xtitle("Share aged 65 and older (%)")                            ///
    ytitle("Median age (years)")                                     ///
    hover(state)
dash (scatter medage young, msize(medium))                           ///
     (qfitci  medage young),                                         ///
    name(g7) title("Median age and the share under 18")               ///
    xtitle("Share under 18 (%)")                                     ///
    ytitle("Median age (years)")                                     ///
    hover(state)
dash kpi count(state), name(k1) title("States")            fmt(%9.0f) ///
    subtitle("in the current filters")   update(both)
dash kpi mean(medage), name(k2) title("Mean median age")   fmt(%9.1f) ///
    subtitle("years")                    update(both)
dash build,                                                          ///
    saving("dashboards/census-tabs.html") replace nobrowser           ///
    title("The 50 states in 1980")                                   ///
    subtitle("Census extract, drawn under Stata's economist scheme") ///
    scheme(economist)                                                ///
    layout(bs)                                                       ///
    tabs(Rates: g1 g2 g3 g4 / By region: g5 / Age structure: k1 k2 g6 g7) ///
    filter(region, type(dropdown) label("Census region"))            ///
    filter(medage, type(range)    label("Median age"))               ///
    link(g1 g2 g3 g4 g5)

The census counts become rates per 1,000 residents and shares of the population. Step through: setup, four scatters, the faceted figure, two smoothers, two cards, the build.
Nevada married 142 couples per 1,000 residents in 1980, ten times any other state, so the marriage axis is logged. xsize(10) ysize(4) are twoway's own options; here they set a figure's proportions so a tab's two rows fit one screen.
by(region, cols(2)): a panel per census region, with lfit fitted in each. xlabel(#5) ylabel(#5) are what put the four panels on one scale; without #N each panel takes its own range.
lowess and qfitci: two more of twoway's smoothers, drawn by dash's own implementation of Stata's estimator.
The build: scheme(economist), three tabs, and link() naming the four scatters and the faceted figure. A tab's grid is equal cells, so four graphs make a two by two.

Proves: three tabs, one selection shared by four graphs and four facet panels on one scale, lowess and qfitci, all under economist. If the clock is short, do the brush and the tab switch and nothing else.
Say: the blue-grey is the economist scheme; the Rates tab is four scatters in two rows.
Do: hover the lone point at the far right of Divorces and marriages: Nevada.
Do: box-select tool, then a box over the top right of Urban share and population, the big urban states. The same states light up on the other three scatters at once.
Do: keep the selection and click By region: the same states are highlighted inside their own panels, four panels on one scale, a fitted line in each.
Do: Census region to West: 13 states everywhere, and three of the four panels empty, as a region filter should. Back to All.
Do, if time: Age structure. States and Mean median age follow the brush too; with California, New York and Texas selected they read 3 and 30.0. Below them, lowess and qfitci with its band.
If asked why the four scatters are a two by two and not three over one: a tab's grid is equal cells, ceil(sqrt(n)) columns, and Bootstrap spans do not reach inside a tab. Outside the tabs the three-over-one shape works, but anything not in a tab is drawn below the whole tab strip, out of a 900-pixel frame.
If asked about exclude(): it cannot hold back a graph that is in a link group, because that graph draws from the group's one shared source; the region filter reaches the panels for that reason.

Wrapping Up

Known issues and limitations

Filters and brushes affect data but not computed layers (e.g., fitted lines)
Four plot types are not currently implemented: contour, contourline, rpcap, and rpspike
Not every option on every graph is fully supported
Non-supported options should not prevent using the command, but limit control of the aesthetics
There will be inaccuracies in the helpfile during development and until there is time to thoroughly verify what is supported

Lessons Learned

ALL AI CODING ASSISTANTS LIE
ALL AI CODING ASSISTANTS WILL TAKE THE SHORTEST PATH POSSIBLE TO "COMPLETE" A TASK
Task complexity and accurate performance are inversely related
The size of the scope of a task is also inversely related to accurate performance
Planning work for an AI coding assistant is more similar to programming than planning work for a human
The quality of the work varies significantly across the AI models
The quality also varies significantly across the companies developing the AI models

The first two points are inevitable and unavoidable.
Reinforcement learning uses an incentive to do anything to receive the "reward." Sometimes that means reporting that work is complete even if it isn't. Other times it can look like the work is complete, but it is due to hardcoded values being used instead of arguments passed to parameters.
Expect there to be a non-trivial number of errors or omissions and you'll likely never be disappointed.
AI coding assistants can perform impressively well on tightly scoped, well sequenced, and less complex tasks.
This means the planning process is vital to the success of your project.
The most costly models do tend to perform better across the board, but some of the least costly models perform equally well if the task is well-suited for them.
Just like not every model performs equally well, there is also a non-trivial difference in quality between companies building these tools.

Recommendations for using AI coding assistants with Stata

Plan for the AI coding assistant to be deceptive
Take advantage of retrieval augmented generation
Use a system prompt, or file, to define behavioral patterns you want the tool to exhibit
Spend the majority of your time making sure you have a well-developed plan
Make sure each discrete task in the plan is tightly scoped and that tasks are sequenced in a logical order
Use the most advanced model you can to build the planning documents
Use less advanced models to implement the plans and keep costs manageable
Use the most capable model to check the work of less advanced models
Use models from a competitor to check the work of your preferred coding assistant
Prepare to spend a significant amount of your time testing code and providing additional clarifying instructions
Assume you will need several iterations of plan development and execution for complex tasks to complete them

Be sure to explain retrieval augmented generation

If you plan for it to happen, you may be more likely to identify common deceptive practices which you can use to modify the system prompt.
Stata and the user community create exceptional documentation. Using the documentation allows the model to fill in a lot of gaps it has from its training.
I make sure to include information about commenting style and other aspects of the programming that I want the model to follow at all times
The plan is one of, if not the, most critical factors for the success of your project.
If the plan doesn't break things down into small enough tasks, force the tool to do that to increase the likelihood of success the first time around
The most advanced models with the greatest effort will produce better plans, but may be overkill for many coding tasks if the plans are well-developed
Sometimes the models with the least capacity are all you need.
However, you should use models with greater capacity to automate checking the work of models with lesser capacity. They will be more likely to catch things that the less capable models will consistently miss.
Just because a competitor's model doesn't perform as well at coding, doesn't mean it won't perform well at finding bugs or vulnerabilities
Think of AI coding assistants like incredibly capable undergrad/first year grad students. Just because they have the coding skill set, doesn't mean they are aware of common knowledge in the field or will infer things that are obvious with experience. You'll have to provide those instructions for them to learn how to figure it out.
I have yet to have an AI coding assistant fully implement everything in a single plan or develop a single plan that covers everything it will need for complex tasks. I assume the first plan will provide a foundation with multiple cracks that need to be fixed prior to framing a house on it and that multiple plans will be needed before that house is move-in ready.