Where your data lives, who touches it, and what we have not built yet

Notes, participant records, claim data and evidence assessments live in a Supabase Postgres database in ap-southeast-2 (Sydney), migrated there on 6 August 2026 from a Mumbai region.

How to check us: Ask us for the project region and we will show you.

The app runs as serverless functions on Vercel. Requests are processed in whichever region Vercel routes them to, which is not necessarily Australia, and data in transit through those functions leaves Australia in that case. The stored data does not. If your procurement requires Australian-only processing end to end, tell us before you sign anything — we would rather lose the deal than have you find this in an audit.

Voice recordings go to the Supabase Storage bucket attached to the same Sydney project, under a path scoped to the worker who recorded them.

What a worker writes or dictates is sent to Anthropic’s API to produce the draft. Anthropic processes it in the United States. This is the single largest exception to Australian residency and we state it plainly rather than burying it under "AI-powered".

We do not train models on customer content, and we do not sell, share or licence note content. Content sent to Anthropic’s API is not used to train their models under their commercial terms.

ShiftNote never finalises or submits anything. Every output is a draft, and the worker confirms a short review checklist before a note can be copied, downloaded or exported. The worker stays the author and stays responsible for accuracy.

Prompts forbid inventing a time, dose, duration or outcome the worker did not give. Anything ambiguous is listed as a missing detail with the worker’s own wording in brackets rather than guessed at. Where a worker writes in another language, their original words are kept on the record and are one tap away from the English draft they confirm.

How to check us: The rules are pinned by tests, and a separate harness (npm run test:translation) grades the live model against planted traps in seven languages.

The dictation path uses the phone or browser’s own speech recognition, so audio does not leave the handset for it. A separate server-side transcription route exists as a fallback and is inert unless a transcription endpoint is configured — ask us whether one is configured for your deployment and we will tell you which provider and region it points at.

All traffic is HTTPS. Data at rest is encrypted by our database and storage provider. We do not operate our own key management, and we do not offer customer-managed keys.

Access is enforced in the database itself, not only in application code. A worker can read only their own notes; a provider admin can read only their own organisation’s data.

Claim import, claim-to-note matching and outcome capture are restricted to organisation admins. The exposure dashboard is open to any member. That is two roles, not a permission matrix — if you need finer separation between finance, quality and service delivery, it is not there yet.

Separate finance, quality and service-delivery roles with per-area permissions. Not built.

Authentication is handled by Supabase Auth over the PKCE flow. Passwords are checked against known-breached password lists at sign-up and change.

Not available. Our auth provider supports it and we have not turned it on or built the enrolment flow. If MFA is a procurement requirement for you, say so — it moves up the list.

Every note now writes a version row on creation and on each edit: who acted, when, what changed, the content at that point, and a hash that includes the previous version’s hash. Database rules reject updates and deletes on those rows, so a version cannot be quietly rewritten. It is marked in progress rather than available because it protects records from this point forward — notes written before it shipped have no history to show, and we have not built the reviewer-facing UI that reads the chain back.

The worker’s original input, the generated draft and the reviewed version are separate records, so it is always possible to see what the worker said, what the model produced, and what a person changed. ShiftNote does not witness or validate that a support was delivered — the worker attests to that.

The hash chain makes an undetected edit-in-place hard. It is not a published, independently verifiable proof — there is no external anchoring and no signing key. Do not read it as one, and we will not sell it as one.

Recordings are deleted on a schedule rather than accumulating indefinitely.

Notes are kept until an account is deleted. There is no retention policy, no organisation-level retention setting and no deletion hold. The seven-year obligation on providers is real; our implementation of it is not built, so "ShiftNote keeps your records for seven years" is a claim we do not make.

A worker can delete their account and their notes from within the product. Deletion is not obstructed and does not require contacting us.

An evidence pack can be exported as a PDF for claims that are matched and scored. There is no full organisation export of every record in a machine-readable format yet.

No note content, participant reference, diagnosis, medication detail or incident description is sent to our analytics provider. Events carry counts, categories and durations only.

How to check us: Every analytics call in the codebase sends a fixed property set — none of them includes free text.

Our error tracker is configured not to attach cookies, headers or request bodies, and session replay masks all text and blocks media, because the note editor holds participant information on screen.

The note editor scans what you type and warns you if it looks like a phone number, street address, date of birth, Medicare number or email address, before anything is generated. It does not detect names.

API requests are logged with a request id, route and outcome. Note text and participant details are not written to logs.

Report a vulnerability to info@shiftnote.com.au and it reaches the person who can fix it. We are a small team; we will acknowledge within two business days.

We monitor errors and can revoke access and rotate credentials quickly. A written incident response plan with notification timeframes under the Notifiable Data Breaches scheme is being drafted and is not finished.

Providers cannot yet see a log of who in their organisation did what. Note-level history is being recorded now (see record provenance); surfacing it as an organisation audit log is separate work.

Backups are taken by our database provider under the plan we hold. We have not published a tested restore procedure with a stated recovery objective, so we are not going to imply one exists.

Rate limits are enforced per running instance rather than across the fleet, because the distributed rate-limit store is not configured. The public health endpoint reports this state rather than hiding it.