--- title: How it works description: The path a dashboard takes from your AI tool through compile, validate and seed, to a scheduled refresh that rewrites only its data. updated: 2026-08-04 --- There are two loops. The **authoring loop** runs when you ask for a dashboard and involves your AI. The **refresh loop** runs on a schedule and involves nobody. Almost everything surprising about Dashies follows from the fact that these are separate. ## The authoring loop Your AI tool talks to the Dashies publish service over MCP. It sends a **spec**: one small YAML document naming a connection, a schedule, one or more datasets (each a SQL query plus its declared dimensions and measures), and the tiles that display them. The server then does four things, in order, and stops at the first failure: 1. **Compile.** The spec becomes one self-contained HTML file: the markup, the slots each tile reads from, an empty runtime marker, and a **refresh manifest** recording the SQL, the declarations and the schedule. 2. **Validate.** Structural and correctness rules run against the spec. A tile bound to a measure the query never returns, a measure that cannot be re-aggregated in the mode you picked, a filter that cannot be answered by the data you are shipping: each is refused with a pointer at the exact field. 3. **Seed.** Every dataset's SQL is executed once, read-only, through the same confined executor the scheduler will use later. The results are baked into the file. A dataset that fails, returns zero rows, or returns columns that do not match its declarations cannot publish. 4. **Store.** The file goes to object storage, the row goes to the database, and the previous body is snapshotted into version history. Seeding is why a freshly published dashboard already has real numbers on it instead of a loading state, and it is also the strongest check in the pipeline: it proves the SQL actually runs inside the executor that will run it unattended. ## The refresh loop A scheduler sweeps for due dashboards. For each one it re-runs the manifest's SQL against the same connection, and rewrites **only** the data inside the stored file. No AI is involved, no model is called, and the markup is not regenerated. | Stage | Who does it | What it touches | |---|---|---| | Author | your AI tool | writes the spec | | Compile, validate, seed | the publish service | produces the file and the manifest | | Store | the publish service | object storage plus a version snapshot | | Refresh | the scheduler, on your cadence | the data block inside the file, nothing else | | Serve | the router, on every request | injects the current runtime, then streams the file | ## Why only the data is rewritten The published file carries its numbers in exactly one place: a single `