Data Security & Governance

What This Page Is — And Isn't

This is a plain-language account of data handling for CREdocket's account system, Watchlists/Portfolio entities, and the two AI-assisted tools (the Case Value Calculator and the Lease Clause Redline Checker). It is not a substitute for our Privacy Policy or Terms of Service, which remain the governing legal documents — this page goes into more operational detail on the questions we hear most: does anything train on your documents, where does the data actually live, and what security posture does a two-person, Supabase-hosted site actually have (as opposed to what a page like this might be tempted to imply). Where we don't have a firm answer yet, we say so directly rather than paper over it.

What We Collect, and Why

Account information. An email address and password (handled by Supabase, our backend provider), used to sign you in and associate your Watchlists, Portfolio entities, purchases, and usage limits with your account.

Case descriptions and uploaded documents. When you use the Case Value Calculator or the Lease Clause Redline Checker, you type a description and/or upload or paste a document. This is collected to generate your analysis — see the dedicated section below for exactly what happens to it, because that's the part with the most misconceptions.

Watchlist and Portfolio entity names. If you add a property, tenant, lender, guarantor, or other counterparty name to your Portfolio (so we can match it against new matters added to the tracker), that name — plus the entity type and any note you add — is collected and stored, described in detail below.

Uploaded Case Documents & Descriptions: What Actually Happens

The raw file itself is never uploaded to any server. Text extraction (PDF via pdf.js, .docx via mammoth.js, .txt via the browser's own file reader) happens entirely inside your browser, on your own device. This is stated directly in our source code — js/case-valuation.js's own header comment reads: "the raw file is never uploaded or stored anywhere; only the extracted text is sent to the case-valuation-analyze Edge Function." js/lease-clause-redline.js uses the identical client-side extraction approach (its own comment describes it as mirroring the Calculator's). Neither tool has any code path that transmits the original file object anywhere.

The extracted text passes through our server once, and isn't written to our database. We read the request-handling code in both backend functions (supabase/functions/case-valuation-analyze/index.ts and supabase/functions/lease-clause-redline/index.ts) specifically to check this. Each function reads your description/document/clause text from the incoming request, sends it to Anthropic's Claude API for analysis, and streams the result back to your browser. Searching both files for every database write they perform turns up exactly two — one per function — and both write only { user_id, category, tool, credit_source } (which practice-area category was detected, which tool you used, and which credit paid for it). Neither insert includes your description, your document text, or your clause text in any form. The database table these writes go into (case_valuation_analyses, see case_valuation_project/schema_analysis.sql) doesn't even have a column that could hold it — its schema is just an id, your user id, a category label, and a timestamp. So the honest answer is: we don't store the substance of what you submit at all, not "we store it but keep it private" — there's no table for it to land in even if we wanted to.

What we could still see, in principle: the request briefly passes through our Supabase Edge Function's runtime logs on the way to Anthropic. We don't have a code path that persists those logs into a queryable table, but we also haven't independently audited how long Supabase's own platform-level function-invocation logging retains that transient data by default — flagging that honestly as something we haven't fully verified, rather than asserting a specific number we don't actually know.

Does Any of This Train an AI Model?

The analysis itself is performed by Claude, Anthropic's model, called directly through Anthropic's commercial API with a standard API key — nothing in our integration invokes any Anthropic feature that requires opting into their data-sharing program (we checked: there's no such parameter anywhere in either Edge Function's API call). That matters because, per Anthropic's own current published policy for commercial/API customers: "We will not use your chats or coding sessions to train our models, unless you choose to participate in our Development Partner Program" — an opt-in program we have not enabled. (Source: Anthropic Privacy Center — "How do you use personal data in model training?", fetched directly from Anthropic's own site.)

On retention specifically: Anthropic's published policy for standard commercial API customers (which is what we are — we have not negotiated a Zero Data Retention agreement with Anthropic) states that inputs and outputs are automatically deleted from their backend within 30 days of receipt or generation, with narrow exceptions for legal holds or a subsequent negotiated retention arrangement. (Source: Anthropic Privacy Center — "How long do you store my organization's data?".) Separately, Anthropic's API documentation notes that content flagged by their automated trust-and-safety systems can be retained longer — up to 2 years — regardless of any retention arrangement; that's Anthropic's exception, not ours, and would only apply if content triggered their abuse-detection systems. (Source: Claude Platform Docs — "API and data retention.")

Watchlist & Portfolio Entity Names

Unlike the description above, tagged entity names are stored — this is the point of the feature: matching a tenant, lender, or counterparty name you enter against every new matter added to the tracker going forward. They live in a Supabase table (portfolio_entities) alongside the entity type and any note you add. We checked this table's actual row-level-security policy in its migration file (case_valuation_project/schema_portfolio_entities.sql): it restricts every operation — read, create, update, delete — to rows where auth.uid() = user_id, meaning only your own signed-in session (or our service-role backend) can ever see or touch your entries; no other user's session can read them, regardless of what that session requests. There's no additional field-level encryption on the entity name beyond Supabase's standard database encryption (see Security Posture below) — it's protected by access control, not by being unreadable to us.

You can remove any Portfolio entity yourself at any time — the account page has a "Remove" action that deletes the row immediately (we confirmed this in js/portfolio-entities.js); there's no waiting period or approval step. Short of that, entity names are retained indefinitely for as long as your account exists — we don't have an automatic expiration or purge job for this table today, and we're saying that plainly rather than describing an aspirational retention period we haven't actually built.

Security Posture, Honestly

In transit: every connection to credocket.com and to our Supabase backend is over HTTPS/TLS.

At rest: our database runs on Supabase's hosted infrastructure. Per Supabase's own published security page, "all customer data is encrypted at rest with AES-256 and in transit via TLS." (Source: supabase.com/security, fetched directly.) That's Supabase's platform-level control, applied to everything we store there — we haven't layered any additional application-level encryption of our own on top of it.

SOC 2 — an important distinction: Supabase itself states it is "SOC 2 Type 2 compliant" (same source, supabase.com/security). That's a real, verifiable certification of our infrastructure provider — it is not a certification of CREdocket. CREdocket has not undergone a SOC 2 examination, a penetration test, or any independent third-party security audit of its own application code. We're a small, actively-developed site, and that's the honest current state, not something we want a page like this to blur by leaning on our vendor's compliance posture as if it were our own. A SOC 2 examination for CREdocket itself is a roadmap item, not a present-tense fact — realistically something to pursue as a self-serve business tier matures and the cost/benefit of a formal audit makes more sense, not before then.

Account deletion: there is currently no self-serve "delete my account" button. If you want your account and associated data removed, see Requesting Deletion below.

Requesting Deletion

To request deletion of your account, your stored Watchlist/Portfolio data, or any other information we hold about you, contact us through the Contact page — that form goes directly to us, not to a database (see our Privacy Policy for how the contact form itself works). We'll confirm what's been removed. Note the scope of what we can act on: we can delete what's in our own Supabase tables; we cannot retroactively delete a request that already passed through Anthropic's API and was handled under Anthropic's own 30-day (or shorter) retention window described above — by the time you'd typically think to ask, it's likely already gone on their end regardless.

Changes to This Page

We'll update this page as our actual practices change — including, we hope, replacing some of the "not yet in place" items above with real ones. Material changes will be reflected by an updated "last updated" date at the top.