Privacy

Creating an account

Signing up happens at app.pinciteaudio.com, not here. The form asks for four things: your firm's name, your name, your email address, and a password. The password is never stored — what is stored is a one-way hash of it, from which the password cannot be recovered. You are also asked to accept the terms by ticking a box, and the time you ticked it is recorded along with which version of that page you were shown.

The signup page also runs a bot check: Cloudflare Turnstile. It is the one piece of third-party code any page of the application loads, and it loads on that page only. While it runs, Cloudflare processes ordinary request data from your browser — your IP address, user agent, and signals about how the page is being interacted with — to tell a person from a script, and hands the page a one-time token that our server sends back to Cloudflare to verify before accepting the form. Cloudflare states that Turnstile does not use this data to build advertising profiles. We never see the signals, only Cloudflare's yes-or-no answer; if the check cannot be verified, the signup is not accepted. The check protects the signup form — it is not in the path any recording or transcript takes, and the rest of the application loads nothing from Cloudflare.

Nothing is created when you submit that form. The four answers, the password hash and the terms record are held in a single pending row while we email the address a link to confirm it. Your account and your firm are created when you click that link. If you never do, the pending request expires three days later and can never be used after that. The expired row itself is cleared out automatically, normally within an hour or so of expiring while the system is running, and once it is cleared it falls out of the backups on the same horizon stated above; until then it holds nothing usable — the password exists in it only as a hash that cannot be reversed, and the link it answered to is dead.

We send one message to the address at that point: the confirmation link. If nobody confirms it, no account exists and the address is not added to any list. Once your account exists, the address receives a short set of service notices: that the account was created, that uploads are open once we finish setting up your firm's storage by hand, that a recording of yours finished processing, and that the account's password was changed. Each is triggered by something that happened on the account — none is marketing, none runs on a schedule, and all of them deliberately carry no matter, client or transcript detail. We keep a record of which account-setup notices went to your firm and when, so none is ever sent twice; it holds the notice's name and a time — not the text, which never varies, and not a second copy of your address, which is looked up at the moment of sending.

Your firm's name is also used to build the web address of your firm's connector page and the name of the private storage bucket your audio is kept in. Both are derived from it automatically, and neither is published anywhere we link to.

The application

This describes what the application stores while it processes a recording, and what is left after a matter is deleted. It is a description of the system; the undertaking is section 4a of the terms.

Six kinds of thing exist in the application, and separating them is the point — only one of them holds anybody's words.

• Operational records. The state each recording moved through, the error codes it produced, the technical shape of the audio — container, codec, sample rate, channel count, duration — and the metering: seconds processed, calls made to the transcription service, and what they cost. Server logs are the same kind of record, and no transcribed text is written into them.
• Quality measurements. The coverage ratio, the un-transcribed gap seconds, the seconds of detected speech that did not reach the transcript, word and utterance counts, and per-word confidence scores. Counts, ratios and durations. No words appear in them, and none of them can be turned back into words.
• Content. Transcripts, summaries, file names, matter names and any speaker names a user records. In the database these exist only as ciphertext under a key held for that one matter. The audio itself is held as objects in cloud storage.
• Identifiers and timestamps. Account, matter and recording identifiers, and when things happened. Opaque values, not descriptions of anything.
• Waitlist emails. The addresses submitted through this site's waitlist form, each with its submission time — described in the waitlist section above. They belong to prospective users rather than firms, sit outside the per-matter encryption story, and touch no matter, audio, or transcript data.
• Account details. Your firm's name, your name, your email address, a one-way hash of your password, and the record that you accepted the terms — described in creating an account above. Like waitlist emails these sit outside the per-matter encryption story, and they touch no matter, audio, or transcript data.
• Notice log. Which account-setup notices went to your firm and when (account created; uploads open) — a name and a time per notice, kept so none is sent twice. It holds no copy of the notice text and no second copy of your email address.

Deleting a matter destroys that matter's key and deletes its stored objects. Because the key is gone, the ciphertext cannot be read — including in backups that already exist, which is the reason content is stored this way rather than deleted row by row.

Three things remain afterwards, and naming them is more useful than implying there is nothing. The billing record: seconds and dollars, with the matter and recording identifiers removed from it. An activity log: identifiers, timestamps and the names of actions taken, never text. And the matter itself as a marker — its own reference number, jurisdiction and dates survive, so a firm can still recognise which matter was deleted, while its name is overwritten with a value no key can decrypt. Where an activity-log entry records a transcript digest — a one-way hash computed over the text — that hash remains, and cannot be turned back into the transcript. The quality measurements do not survive: they are stored against the recording, and the recording is deleted.

Work on transcription quality uses the operational records and quality measurements above, and recordings obtained for evaluation — public court audio and licensed speech datasets. Customer audio and customer transcripts are not used to develop the product.

Google is the only third party your audio reaches: Cloud Speech-to-Text transcribes it, Cloud Storage holds it while it is processed, Secret Manager holds the per-matter keys, and Vertex AI (Gemini) writes the short per-recording summary from the transcript text and the speaker labels rather than from the audio. Section 5 of the terms names them with the same detail.

Transcript text has one other destination, and only if your firm switches it on. Pincite Audio can be added inside claude.ai as a custom connector, which is the only way this product's transcripts reach Claude — no Anthropic surface accepts an audio file. Nothing is sent until your firm adds the connector, and nothing is sent on a schedule afterwards: each question you ask Claude that reaches your matters becomes a tool call to us, and we return what that call asks for. What goes back is the transcript passages requested, the matter names they belong to, any speaker names your firm has recorded, and the coverage and gap figures for the recordings involved. The audio does not. The connector holds one permission — read transcripts — and every tool behind it is a read. Once a passage is in a Claude conversation it sits in your firm's Anthropic account rather than ours, under whatever agreement your firm has with Anthropic; that is a question for them, and we do not answer it on your behalf. What we keep of it is a record of which tool was called and how much came back — the code that writes that record accepts eight fields, each a tool name, a count or a flag, and refuses anything else, so it cannot hold a word of the transcript or of the conversation.

Payments are processed by Stripe. When your firm buys minutes, the card details are entered on a page Stripe hosts and go to Stripe directly — they never pass through our servers, which store only opaque references into Stripe's records. No payment method is kept on file; each purchase is its own transaction. Stripe receives what you enter on its page and an internal identifier for your firm; it receives no audio, no transcript text, and no matter name, and it is not in the path a recording takes.

Hosting

The site is served by Cloudflare Pages. Delivering and protecting it involves Cloudflare processing ordinary request data — IP address, user agent, and timestamps — as our hosting provider.

Cloudflare also runs its own Web Analytics on this site, which loads a small script and reports page views and page-load timings. Cloudflare states that it sets no cookies, uses no fingerprinting, and does not track visitors across sites. It is separate from the Google Analytics described above, and it measures how fast pages load rather than who is reading them.

Cloudflare serves this website only. It is not in the path where transcript text is decrypted, which is the point of the architecture described on the home page.

Changes

If what this site collects changes, or what the application stores or destroys changes, this page changes with it and the date at the top moves. There is no notification mechanism: an address the application holds about you is used to contact you about beta access, or — once you have an account — to sign you in and tell you when your own recordings finish. It is not used to announce changes to this page.