Skip to content

Core concepts

The mental model behind Dashies, in reading order - the artifact, how you author it, and what decides whether the numbers are right.

These pages explain why Dashies works the way it does. None of them contains steps; they exist so that when a procedure elsewhere says "bound the dimension" or "the connection is not available to this dashboard", you already know what that means.

They are ordered to be read straight through the first time, and dipped into afterwards.

The artifact

What a published dashboard actually is, and which parts of it change.

  • The dashboard file - one self-contained HTML file, and the three things inside it that Dashies cares about.
  • The data island - why refresh rewrites only one block, and why that means your design survives every refresh.
  • The runtime - the code that draws the charts is not in the file, and that is deliberate.

Authoring

How a dashboard gets written, and by what.

  • Spec vs hand-authored - the spec is the supported path; the escape hatches and what you give up by taking them.

Correctness

The pages that decide whether the numbers on the page are true. If you read only two, read the first two.

  • Datasets and the four modes - cube, lattice, hybrid, rows: what each ships, what it is correct for, and what it costs.
  • Measure correctness - additive versus non-additive, flow versus stock, and why a ratio is not a stored average.
  • Designing the cube - grain, cardinality, timezones, and writing SQL that will run unattended for a year.

The envelope

The operational rules around a working dashboard.

  • Connections and scope - a connection belongs permanently to one space, and getting that wrong publishes fine and then never refreshes.
  • Schedules - cadences, anchors, the precision you actually get, and what happens across a daylight-saving change.
  • Plans and what is gated - what a free plan does and does not include, and what a lapsed plan does to a live dashboard.
Last updated 2026-08-04