Where your documents go.

What leaves, and what does not

One thing leaves. To read your rate card, the contract’s text is sent to Anthropic’s API, which proposes a rate structure. That is the only outbound transmission in the product, and it is the reason the reading step is a proposal you confirm line by line rather than something applied behind your back.

Nothing else goes anywhere. The audit runs on your data in your database. The claim letter is generated for you to copy; the product never sends anything to your provider, and your provider is never told you are checking.

Where the documents sit

In a private storage bucket — not public, enforced at the database rather than by convention. Object paths are keyed to your organisation, and the policy that reads them fails closed: a path it cannot parse is denied rather than allowed.

documents bucket · public = false
path scheme · <organization_id>/<uuid>-<filename>
policy · denies when the leading segment is not your org, or does not parse

Row-level security, on everything

Every table in the system carries row-level security, and every policy asks the same question: are you a member of the organisation that owns this row. Rate cards, invoices, activity, audit results, discrepancies, disputes, billing — all of it.

The application never holds a key that can bypass those policies. There is no service-role credential in the request path, so a bug in the application cannot read across organisations even if it tries.

What we cannot honestly claim yet

No SOC 2. No penetration test. No security questionnaire on file. The architecture above is real and verifiable in the code, but it has not been audited by anyone outside this project, and saying otherwise would contradict the one thing this product is for.

If you need a signed attestation before uploading a commercial contract, you should not upload one yet. Send a redacted rate card to the free audit instead and judge the output.