A SQL model is a single transformation kept as a file, usually one SELECT statement that defines one table or view, with other models referenced by name so a tool can work out the order to build them. Projects keep models in a models/ folder, next to tests and configuration, and version them in Git.
For example, a project might hold a model file models/silver/orders.sql with a SELECT that reads the raw orders table, casts and renames the columns and removes duplicates, and a file models/gold/monthly_sales.sql whose SELECT reads the silver orders model by name and groups by month and region. A build tool reads both files, sees that the gold model depends on the silver one, and builds the silver table first, then the gold table. Nobody writes the build order by hand.
Each model is usually materialized as a view, as a table rebuilt in full, or as an incremental table that only processes new rows, chosen in configuration next to the SQL. Tests are attached to models, such as checks that a column is unique or that its values belong to a list, and documentation for each column often lives in the same folder. Because models are plain files, they are reviewed in pull requests like other code.
Keeping one model per table makes lineage visible: the references between files form a graph, and a change to one model shows which others are downstream. Large models with many steps are harder to test, so complex logic is often split into several small models. See also ELT, gold layer and data quality test.
The same layout works on any SQL platform, because a model is only a SELECT; what changes per platform is how it is materialized, such as a Delta table on Databricks or a dynamic table on Snowflake. That separation keeps business logic portable while the platform-specific parts stay in configuration. See also orchestration.
Emolysis projects use this familiar layout, with pipelines built from templates alongside the models. See Projects and emolysis.yml, and lineage for how models depend on each other.