From a question to a model, or to something smaller

A person who asks for a model usually wants an answer. The answer may already be on a dashboard, or be one question over a model the tenant already has, one column added to an existing model, a macro, or a look at the data. A new model is one possible outcome of this workflow, and ending without one is often the right result.

A model is one dbt SELECT that the platform turns into a table in the customer's own analytics schema, named after the model. Reports and dashboards read that table. A build writes into a staging schema first, and the table is replaced only when the build passed its tests: a build that failed leaves the last passing version in place, and a first build that failed leaves nothing for Reports to read. A wrong model does not fail loudly: it becomes a dashboard that shows a wrong number as if it were a fact. A second model for a concept the tenant already defines is wrong more quietly still: two tables that will disagree. So this workflow is slow on purpose. Find out what the tenant already has, understand what the person needs, read the data, agree a plan, and let the person decide every change.