The short version for healthcare
We are not set up to receive protected health information and we do not sign business associate agreements. Every model we build runs on de-identified exports — case IDs, payers, CPTs, dates of service, dollars — and nothing in a financial model needs a patient's name, date of birth or record number. The list of what to strip is below. If a file with identifiers in it reaches us, we delete it and ask for the export again.
Where it lives
- Accounts, requests, messages, plan status: a Postgres database at Supabase, in a US region, encrypted at rest and in transit.
- Files you attach and files we deliver: a private storage bucket at Supabase. Nothing in it has a public address.
- The website: Vercel, in the United States.
- Card details: Stripe. The card number never touches our systems; we hold the card's brand and last four digits so your billing page can show them.
Who can open it
- You can see your own requests, messages and files, and nobody else's. That is enforced by row-level security rules in the database on every table, not by the application remembering to filter.
- The operator can see every request, because building your workbook is the service. One person.
- Files are opened through links that expire after one hour and are issued only to the file's owner or the operator. A link forwarded to someone else stops working within the hour.
- The database enforces that only the operator can attach a deliverable to a request, and that a client can withdraw their own inputs but never the delivered file.
What reads it
A request is built by an automated pipeline before the operator checks it. The pipeline downloads your brief and your attachments to a working folder on a server we run, and an automated builder — a large language model, Anthropic's Claude, running under our account — reads them to build the workbook. A second automated pass checks the result. The operator reviews the finished file and is the only thing that can deliver it to your board.
The builder's instructions confine it to that working folder: it may not contact anything outside it, run commands the pipeline did not give it, or act on instructions found inside a client file. Client text is quoted into the build prompt, which is why the brief and each message have length limits.
We do not use your files or your numbers to train anything of our own, and nothing you send is shared with, sold to, or used for marketing by anyone.
What we accept
- Up to 25 MB a file, up to twenty files a request. Spreadsheets, CSV and text exports, accounting-package exports, PDFs, images and zips (28 extensions). HTML and SVG are refused, because they execute when opened from a link.
- Uploads go straight from your browser to the private bucket under your own account's folder; the storage rules refuse a write anywhere else.
How to send a healthcare export
Strip these before it leaves your system. Most EMR, practice-management and billing exports can be run without them; if yours cannot, delete the columns in the export before attaching it.
| Leave out | Why the model does not need it | |
|---|---|---|
| 1 | Names | Patient, member and guarantor names. A case log needs a case ID; a period needs a patient ID. Neither needs the person. |
| 2 | Dates about a person | Date of birth, admission, discharge, death. Keep the dates that drive the model — the case date, the period start, the invoice date — and drop the ones about the individual. |
| 3 | Record numbers | MRN, member ID, claim number, SSN, account number. Replace with a sequence (P-0001) before exporting if the export tool cannot leave them out. |
| 4 | Contact details | Addresses, phone numbers, email addresses of patients or members. A model never uses them. |
| 5 | Anything smaller than a ZIP3 | Street, city and full ZIP on a patient. Payer, plan and facility are fine; they are about the business. |
Keep everything about the business: payer, plan, CPT or DRG, facility, discipline, rep, surgeon (a role or an initial is enough), dates of service, units and dollars. The sample workbooks show exactly the shape that arrives.
How long it is kept
- Your board — requests, messages, attachments and delivered files — for as long as your account exists, so a workbook is still there when you need it a year later.
- The pipeline's working folder for a request stays on our server after the build so a revision can start from it. It is not on a public server and it is not shared. Ask, and it is deleted on request.
- When you ask us to delete your account, we delete the account, its requests, its messages, every file attached to them, and the working folders, and confirm by reply.
Signing in and the site
- Passwords are stored only as a hash by Supabase Auth; we never see one. You can change yours from Billing & account, and changing it requires the current one.
- Two cookies: the one that keeps you signed in, and one set on a first visit that remembers where the visit came from (the referring site and any campaign tag) for thirty days. It holds no identifier.
- We keep our own count of page views — the path, the referring site and a device class (phone, tablet, desktop). No IP address is stored and no third-party analytics or advertising script runs on any page.
- Every response carries a strict framing policy, a content-type lock, a referrer policy and a permissions policy that turns off the camera, microphone, location and payment APIs.
What we do not claim
- We do not sign business associate agreements today and do not accept PHI. If your work genuinely requires one, say so before sending anything and we will tell you honestly whether we can get there.
- We hold no SOC 2, ISO 27001 or HITRUST attestation. The providers we build on publish theirs; ours would be a statement about one person and a pipeline, and we would rather describe the controls than imply an audit.
Questions
Anything on this page you would like verified, ask: sturdylaw@gmail.com, or talk to a person first. The privacy policy is the companion to this page: what we collect and your rights over it.