# How flurry works

> Versions, rules for writes, the audit trail and trust levels.

Canonical: https://dvt.dev/docs/how-it-works/

```
 your AI ──► flurry tools ──► draft ──► you publish ──► version 3 is live
                                  │
                       reads only what your role can read

 a person ──► app form ──► write rule ──► Snowflake table
                               │
                       audit row: who, when, app version, why
```

## Every app is versioned

An app is a small bundle: its screens, its named queries and the rules for any data it may change. Your AI edits a **draft**; nothing goes live until someone publishes it. Each version keeps a change note, so the **Versions** page reads like a log, and you can compare any two versions or roll back.

More: [how apps are versioned](https://dvt.dev/docs/versioning/).

## Every write follows a rule

An app can only change data through a rule it declares, such as "a rep may change the next step on their own deals". flurry checks each write against that rule before it reaches the table. Blocked writes are recorded too, with the rule that stopped them.

## Every change leaves a record

Each write lands with an audit row: who made it, when, from which app and version, and the reason they gave. Open any changed row and ask **who changed this?** to see the chain.

More: [how governed writes work](https://dvt.dev/docs/governed-writes/).

## Trust levels

Apps move through stages that tell people how much to rely on them:

- **Personal**: yours alone, where every new app starts.
- **Exploratory**: shared to try out.
- **Shared**: in use by a team.
- **Certified**: checked by an admin. Certified apps come first in the Library.

An app that is replaced is marked deprecated and points to its successor, then retired.

## Your AI sees what you see

flurry runs every query as you, with your role. An agent connected as you can't read a table you can't read, and its changes go through the same drafts and rules as yours.