How flurry 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.
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.
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.