The chart the model never draws: emit a spec, not a picture

LiveReview has published how its analytics chatbot, Livi, produces charts from review data: the language model writes a Vega-Lite specification, and the company's own Go code inserts the real query results into `data.values` before anything is rendered ^[2][5][9]. That ordering is the whole design, and it is the part worth copying, because it moves the failure surface from "the picture is wrong" to "the object does not conform".

The alternative the post rejects is having the model produce an image. According to the author, even if you got an image model to draw a bar chart, you would have no way to verify that the numbers on it are real ^[4]. That is the correct objection. A rendered PNG is an opaque artefact: there is no field to check, no type to reject, no diff against the result set. A Vega-Lite document is the opposite. It is JSON with a grammar, so `mark: bar`, an x encoding on a temporal `month` field, and a y encoding on a quantitative `review_count` field is the entire chart ^[5][6]. Vega-Lite does the drawing ^[7].

The consequence is a narrower job for the model. LiveReview's framing is that the LLM is filling in a well-defined schema, and that models are better at choosing between `mark: bar` and `mark: line` than at hallucinating 600 pixels of a correct y-axis ^[7][8]. The stronger property is the data split: the model writes SQL, LiveReview executes it, and the result set is stitched in by their code, so the model has presentation latitude and no authority over the values ^[9]. It is also why one definition can serve two renderers, a live interactive graph in the browser and a flat PNG in a Slack thread ^[10].

The rest of the pipeline exists because the SQL half is where the real risk sits. There are two SQL-writing steps rather than one: the first estimates how many rows the answer has, so the system can decide whether a chart is appropriate or whether the user should get a CSV instead, and the second fetches the data and specifies how to draw it ^[11]. Nobody wants a bar chart with 4,000 bars ^[12]. Every generated query goes through a guard that rejects anything not read-only, checks each table against a denylist, and looks for the shape of a tenant-isolation bypass, including constant-versus-constant comparisons and a bare `OR TRUE` ^[13]. The failure the author names is `org_id = 1 OR 1 = 1` ^[14]. The model also sees only a narrowed slice of the schema, because there are 58 tables and counting, covering reviews, pull requests, AI comments and review feedback, and dumping all of them into every prompt is both expensive and a good way to confuse the model about which `created_at` belongs to which table ^[15][16].

One gap in the published account: the excerpt describes validation for the generated SQL, but no equivalent validation step for the generated chart specification ^[17]. Vega-Lite has a published schema, so that check is available; it is just not described here. If you build this pattern, the guard on the spec is not optional, because a syntactically valid document can still reference a field the result set does not contain.

What to watch: whether the two-step row-count probe survives contact with expensive queries, and whether the SQL guard's denylist approach holds as the table count keeps rising past 58 ^[11][13][16].