Trust
How Vedas treats your clients’ documents.
Written for the partner who has to answer the question and for the IT lead who has to check the answer. Each point below is how the system is built, and the line under it says where that can be seen.
Hosted in the United Kingdom.
The application and the job workers run in Railway’s EU West region. The database and every stored file sit in Supabase’s London region. Your practice is one tenancy: every row carries the practice’s id, and the database itself refuses a read across that line.
Row-level rules in Postgres. Region set at the account, not per deploy.
Read-only by construction.
A connector can list and read. The interface it is built against has no write, no delete and no send method, so an adapter for FYI, Xero, QuickBooks, Sage, Microsoft 365 or Companies House cannot gain one by mistake. Not a permission that is switched off. Absent.
One connector interface, read methods only, every adapter tested against it.
Fetched per job, never written back.
A job fetches the documents it needs into its own sandbox, under its own operating-system user, where no other job can see them. Nothing goes back to your practice system. Deliverables come to you in Vedas and a person files them.
One sandbox, one user id and one connector session per job. No filing tool exists.
Deleted after 30 days.
Source documents are purged 30 days after a job is done. A partner can choose 7 or 90 instead. The working tables, the deliverables and the job log stay, so the work can be audited after the source is gone.
Retention is a practice setting on the Billing page, applied by a nightly sweep.
No training on your data.
Nothing from your practice trains any model, ours or anyone else’s. Your practice’s memory is written in your words and exported in one click.
Model providers are used with data collection off. Memory export on the Memory page.
Zero-retention routing, and the route is recorded.
Every model request goes only to providers that keep nothing. If the first is busy, the request moves to the next provider on the same no-retention list, never to one that keeps data. If no such provider serves the model, the request fails and the job says so. The provider that served each request is written against that request.
Provider name on every usage event, visible in the practice’s usage history.
Memory approved word for word.
When you correct Vedas it offers to remember, in your words, with the date and the source. A partner approves each entry before it applies to the practice. Nothing is saved silently, and no tool exists that lets another assistant approve a memory on a person’s behalf. The memory belongs to the practice.
Approval is a partner action on the Memory page. There is no approve-memory tool.
If your IT lead wants to see it, show them.
Every job keeps its own log: which connector was read, which documents were fetched, which provider served each request and what it cost. A partner can open it from the job screen.