Worth separating the layers though, because "alternative to dbt" undersells what Malloy is for. dbt transforms and materializes tables. Malloy describes what th

Worth separating the layers though, because "alternative to dbt" undersells what Malloy is for. dbt transforms and materializes tables. Malloy describes what the tables mean -- dimensions, measures, join paths, who's allowed to see what -- and compiles that down to SQL. It sits on top of dbt models fine, and plenty of people run it exactly that way. Publisher runs the model: you define the what, the engine figures out how. You write down what counts as a sale, how revenue is calculated, who sees which rows. Reshaping the data out of the form your systems store it in, deciding what to precompute, serving whichever agent or dashboard or API is asking -- that's the Publisher's job. A chart spec has to get its numbers from somewhere. If "revenue" is defined inline in the chart's SQL, the definition problem moved, it didn't get solved. Define it once in a model and the chart just renders it. Engineering detail if anyone wants it: https://www.credibledata.com/blog/posts/inside-the-ai-analytics-engine https://www.credibledata.com/blog/posts/inside-the-ai-analyt...