> ## Documentation Index > Fetch the complete documentation index at: https://docs.cloudsquid.io/llms.txt > Use this file to discover all available pages before exploring further. # From audit to prevention > The adoption path in three stages — start read-only on historical data, turn findings into recoveries, then run the same checks continuously on live events. Most teams don't start by automating a process. They start by finding out what's actually happening in it. That's the shape of adoption here, and it's deliberate: **proof before automation**. You see real findings from your own data before any process changes, before any system is connected, before anyone is asked to trust an agent with live work. Three stages. ## 1. Audit — start read-only Load historical exports and documents into a fresh project. Nothing is connected; nothing is live. The agent investigates the full population — not a sample — and every finding it reports carries its evidence: the rows it compared, the amounts, the documents. * **Isolated.** A new project with its own data, its own grants. No production system is touched. * **Full coverage.** Sampling was a capacity constraint, not a methodology. The agent checks every transaction because it can. * **Evidence per finding.** A finding without a trace is an opinion. Each one shows what was compared and why it's a problem. * **The worst case is a clean bill of health.** If the checks come back empty, you've learned something worth knowing, at no risk. This is where trust gets earned, because nothing is at stake yet. The cookbook: historical exports into a fresh project, a check-catalog SOP, findings with evidence. ## 2. Recover — findings become work Findings aren't a report you file. They arrive as cases in the [review](/concepts/review-approvals) queue, each with its evidence, and your team decides what to do with each one: raise the dispute, issue the correction, reclaim the credit. The work is real work — approvals, disputes, corrections — and it runs through the same review layer everything else does. What you recover in this stage is what justifies the next one. ## 3. Prevent — the same checks, continuously Here's the part that makes the sequencing worth it: **the checks don't change.** The SOP that found money in a 24-month lookback is the same SOP that runs on live events. What changes is when it runs: | | Audit stage | Prevention stage | | ------- | ------------------------------ | ----------------------------------------------------- | | Input | Historical exports, in a batch | Live events — inbox, tickets, syncs | | Timing | After the fact | Pre-payment, pre-approval | | Trigger | You run it | [Workflows](/concepts/integrations) fire on the event | | Output | Findings to investigate | Cases to approve before money moves | The controls stay on. [Approval gates](/concepts/review-approvals) still sit in front of anything that leaves the system. As confidence grows, [agentic approval](/concepts/review-approvals#agentic-approval-mode) takes the routine cases so your team sees the exceptions, and [RBAC](/concepts/governance) widens access as more of the org adopts the process. And once cases are being reviewed continuously, [the improvement loop](/concepts/improvement-loop) starts feeding reviewer decisions back into the SOP — so the checks get sharper exactly where they were wrong. ## Why this order Catching a duplicate payment after it went out is a recovery. Catching it before it goes out is a control. You want the second one — but you get there by proving the first one works on data nobody can dispute, because it's your own history. Starting at prevention means asking a team to trust an agent with live decisions before they've seen it be right about anything. Starting at audit means the first thing they see is money the agent found, with the evidence attached. Stage one, as a complete recipe. Stage three: the same checks, running continuously on incoming invoices. The control layer that stays on through all three stages. What turns a batch run into a continuous one.