# How it works

> What Renart stores in Git, what stays local, and how UI edits become reviewable files.

Renart stores authored definitions as files in your Git repository. The editor, canvas, and forms update those files. Execution history and deployment pins live in a separate local database; they are not part of the source you share.

## Assets are files

Every asset is one file in your repository. For a SQL asset that file contains the query you write in the editor, plus the metadata you manage in the workbench — name, description, columns, quality checks, materialization — encoded in a structured section of the same file. Renart maintains that encoding for you: when you rename an asset, add a check, or change the materialization in the UI, Renart rewrites the file.

Use the editor and properties panel to change these settings. Adding a `not_null` check under **Checks**, for example, changes the asset definition in Git. You can review or revert it together with the query that produces the column; you do not need to edit the metadata encoding yourself.

## The project is a folder

The rest of what you see in the UI maps to files the same way:

- A **pipeline** is a folder of asset files, with a `pipeline.yml` holding the pipeline’s name and defaults.
- **Connections and environments** from Project settings live in the project config file at the workspace root.
- **Notebooks** are folders of cell and source files plus an ordered manifest for text, controls, and visualizations.
- **Dashboards and reports** are compact YAML definitions under `dashboards/` and `reports/`; both the visual builder and Definition editor update the same file.
- Tracked Renart project settings and desired environment schedules live in `.renart/project.yml` and `.renart/schedules.yml`.
- Machine-local state that shouldn’t be shared — the scheduler database, deployment pins, deployed snapshots, and run history — lives in `.renart/state.db`, which is safe to gitignore.

## Why it’s built this way

- **Review and revert.** A visual edit — moving a node, adding a check, changing a schedule’s pipeline — is a file change you can diff, review in a pull request, and revert like any other code.
- **Branching works.** Pipeline work happens on branches, the same as the rest of your repository. Two people can work on different assets and merge.
- **Keep the source.** If you stop using Renart, your queries, metadata, and pipeline structure remain readable files.
- **Tools compose.** grep, code review, CI, backups — anything that works on files works on your pipelines.

## Related

- [Concepts](https://getrenart.com/docs/concepts.md) — the vocabulary the UI uses.
- [The asset editor](https://getrenart.com/docs/editing-assets/asset-editor.md) — where these files get edited in practice.