What ships, what’s in progress

Tenant isolation

Every hot table that holds fund data carries Postgres row-level security (RLS) policies scoping reads + writes to the owning user. Cross-fund retrieval is forbidden at the database layer, not just the application layer.

Server-side reads go through a service-role client only when the request is owner-scoped by the application layer (e.g., the analysis pipeline that generates a memo on the owning user’s behalf).

Encryption

Deck files in Supabase Storage are encrypted at rest with AES-256, and all traffic to and from the application runs over TLS 1.3. Payment details go straight to Stripe through tokenized checkout, so raw card numbers never reach Verdict infrastructure.

Authentication and access control

Accounts are managed by Clerk on production keys served from clerk.useverdict.io. Every request to a data route resolves the signed-in user on the server before any record is read or written, and that scoping is enforced a second time at the database layer by row-level security.

The Supabase service-role key that grants server-side database access lives only in Vercel environment secrets, never in source control, and stays separate from the dedicated secret used to sign internal chain-trigger tokens.

Data retention tiers

Decks can be flagged at upload time. Each tier has a different storage lifetime for the raw PDF; the generated memo always persists for the account lifetime so the GP can return to it. Tier selection is at /dashboard/new under “Retention”.

Full retention language for memo feedback and self-audit memory sits in the Data Processing Addendum section 04.

Deletion and data rights

You can delete any single memo and its source deck from the report viewer at any time, and the deck file leaves Storage in the same operation. Deleting your account removes your fund profile, every memo, every uploaded deck, your feedback rows, your Clerk session, and your Stripe customer record. The moment an account is marked for deletion it loses access to its data, ahead of the hard purge that finishes within seven days.

Memos export to PDF straight from the viewer, and a structured export of your account data is available on request. The full rights language, including the GDPR and CCPA specifics, sits in the Privacy Policy.

No training on your data

Pitch decks, generated memos, and feedback rows are never used to train any foundation model. Verdict’s model provider, Anthropic, processes each call under commercial API terms that prohibit training on customer data; inputs and outputs may be retained for up to 30 days for trust-and-safety review, then deleted. Per-fund calibration doescompound inside the fund’s own account, RLS-scoped to that fund only.

Sub-processors

Verdict runs on a small set of infrastructure providers, and your data reaches each one only as far as normal product operation requires. The complete list, with a link to every provider’s own privacy commitments, is kept current in the Privacy Policy. The summary here is what a security reviewer usually asks for first.

Audit trail

Every memo run leaves machine-readable evidence the GP can audit post-hoc. No hidden state; no “trust us, the model said so.”

• Per-call telemetry: per-call cost, latency, cache hit rate, token usage.
• Failure records: structured rows for any task that throws or fails validation. Surfaces in the report viewer as a Resume button.
• Task lifecycle log: per-task lifecycle markers (gate decision · model-call boundaries · database write boundaries) for the founder-mode post-analysis task fanout.
• Self-audit memory: self-audit findings that compound across memos. Each new memo reads prior lessons to catch recurring failure modes.

In progress

What’s not done yet, with honest timing. Procurement teams reading this should treat these as commitments, not marketing.

Incident response & questions

Security concern, suspected incident, or procurement questionnaire? security@useverdict.io. 24-hour acknowledgment SLA. Incident-response runbook is documented internally; outbound notifications follow GDPR Article 33 timing (72 hours from awareness, when applicable).

A machine-readable contact for security researchers is published at /.well-known/security.txt.