# Concepts | DRE > Reports, Sets, Bindings, templates, lookups, plugins, delivery, logs, verification and selecting. You're reading the docs for DRE 0.4 (v0.4.4). [This page for 0.5](https://getdre.com/docs/concepts/) · [New in 0.5](https://getdre.com/docs/new-in-0.5/) # Concepts New to a term? The [glossary](https://getdre.com/docs/v0.4/glossary/) defines DRE’s vocabulary and differences from dbt. - **Report**: one or more Jinja-templated SQL queries plus an output config, declared in YAML. A `.sql` file under `reports/` with no YAML is an _unmanaged_ report, meant for quick tests. - **Set** and **Binding**: one report can run as many named variants (clients, regions, departments). A Binding is a report paired with a Set, with its own profile, variables, query subset and output. - **Connections, destinations, sources and the target**: a _connection_ is what queries read from and a _destination_ where output goes, both in `profiles.yml`. A _source_ is a declared table (dbt’s `sources:`), read with `{{ source('sales', 'orders') }}`. A _target_ is an environment (`dev`, `prod`): each profile has an entry per target and picks one per run (`--target`, `DRE_TARGET`, else its own `target:`, else `dev`). Each query runs on its own connection when it names one (`profile:` on the query, or a source’s), else on the report’s, so one workbook can hold DuckDB, Postgres and Databricks tabs. See [connections](https://getdre.com/docs/v0.4/connections/) and [sources](https://getdre.com/docs/v0.4/sources/). - **Jinja everywhere**: SQL, paths and options render with `var()`, `env_var()`, `run.*` and your macros in `macros/`. `connection.*` (the query’s connection) and `profile('name')` read connection settings, so names can follow the environment: `{{ connection.catalog }}.{{ connection.schema }}.orders`. `run.date` is a date you can navigate (`run.date.prev_month.start.date`), in the run’s timezone (UTC unless you set one). `run_query()` and `columns()` let a macro query the query’s own connection while rendering. `ref('file')` reuses another `.sql` file as a subquery. See [templates](https://getdre.com/docs/v0.4/templates/). - **Lookups**: mapping tables you maintain as files in `lookups/` (csv, xlsx, xls, json, jsonl, yml) rather than in the database. `ref('countries')` makes one usable like a table: small ones are inlined into the SQL, larger ones (over 200 rows by default) are loaded into a temp table by the source plugin. `lookup('countries')` hands the rows to Jinja. Values are text unless a `lookups/.yml` config gives columns types; see [lookups](https://getdre.com/docs/v0.4/lookups/). - **Plugins**: every source, format and destination is a plugin that speaks DRE’s [plugin protocol](https://getdre.com/docs/v0.4/protocol/). Plugins ship in packages, one per system: `databricks` is the Databricks source and destination, `object_store` is S3, GCS and Azure Blob. A project declares each package once and DRE installs it on demand. - **Delivery**: one output can go to several destinations in a single run, e.g. object storage (S3, GCS, Azure Blob), SFTP/FTP, Databricks Volumes or workspace files, an email with the file attached, or a Slack channel. See [plugins](https://getdre.com/docs/v0.4/plugins/). - **Outputs and messages**: a report can have several outputs (`output:` as a list), all made from one run of its queries, each from its own `queries:`. A `message` output turns the results into a short headline posted to Slack, Teams, Google Chat or an email body; `when:` sends an output only when the data calls for it. See [messages](https://getdre.com/docs/v0.4/messages/). - **Logs**: each `dre run` of a report and Set writes `dre.log` in its own run folder (`target/run///runs//`), including the full SQL of each statement, the run’s settings and every step; it goes when the run is pruned (`keep_runs`). Other commands write to the console only. `--log-format json` prints the same events as JSON lines. - **Verification**: `dre validate` checks the project and compiles its SQL; with `-s` it also shows, per selected Binding, the compiled files, the target, each query’s connection, the output file and every destination (non-dev targets stand out). `dre compile` just renders the SQL into `target/compiled/` and lists the files. `dre validate --live` checks every statement against the database. `--preview` and schema-drift detection check a report before it reaches anyone. - **Generated files**: everything DRE writes goes in the _target path_, `target/` in the project by default: compiled SQL, each run’s output files, schema snapshots, `run_results.json` and the [manifest](https://getdre.com/docs/v0.4/manifest/). `--target-path`, `DRE_TARGET_PATH` or `target_path:` in `dre_project.yml` move it (see [below](https://getdre.com/docs/v0.4/target-path/)). - **Selecting**: `run`, `compile`, `validate` and `ls` take report names, `tag:`, `source:` or `source:.`, folder names or dotted folder paths, as arguments (`dre run daily monthly`) or with `-s`/`--select`. Several match any of them: `-s daily monthly`, `-s daily,monthly`, or repeated `-s` (a semicolon works too, quoted: `-s "daily;monthly"`). [Previous CLI reference](https://getdre.com/docs/v0.4/cli-reference/)[Next Connections and targets](https://getdre.com/docs/v0.4/connections/)