Privacy Policy

Scope and product template status

CV Pilot (also referred to in the product UI as ResumeTailor) is a resume- and cover-letter tailoring MVP. This Privacy Policy describes data handling as implemented in the current application code and configuration surface. It is a product transparency template requiring counsel review; it does not claim GDPR/CCPA compliance, certifications, or jurisdiction-specific rights.

Effective date: 2026-08-26. Last updated: 2026-08-31.

Sensitive user content

Resumes, job descriptions, job URLs, AI-generated tailoring suggestions, accept/reject review decisions, and cover-letter content are sensitive user content. Treat them as private career materials. The product stores structured forms of this content on owner-scoped application records after you authenticate and persist an application; it does not treat them as public.

What the product collects

Authentication identity from Clerk (the signed-in owner id used to scope application and credit records). Account profile details shown in Clerk-hosted UI are processed by Clerk according to Clerk’s own terms and privacy materials.

Application records owned by your Clerk user id may include: job URL; original resume file name; parsed resume JSON (plain text, section/paragraph structure, and—for supported uploads—a bounded, sanitized Word formatting template with preview metadata); resume byte-size and MIME metadata; job description plain text and source/status metadata (manual paste or URL fetch); optional job title/company fields; AI tailoring status, validated structured suggestions, and review decisions; cover-letter status and validated structured letter JSON; and related timestamps/attempt identifiers used for idempotency and lifecycle control.

Credit account balance, immutable credit ledger entries (amounts, balances, entry types, attempt ids, idempotency keys, optional application id references, and verified Stripe Checkout Session references on purchase rows), and credit purchase-order records used for Checkout idempotency and fulfillment audit.

Abuse-control records: per-scope rate/concurrency buckets keyed by a pseudonymous subject key. Authenticated limits use the Clerk owner id. Unauthenticated/IP-scoped limits use an HMAC-hashed trusted client IP combined with a guest scope id. Raw IP addresses are not persisted.

Before signup, limited guest tailor continuity metadata (resume file name, job URL, a boolean flag that a manual job paste was provided, and an unguessable claim token) may be held in the browser’s sessionStorage, and the claim token alone may appear in the same-origin Clerk return URL. Guest DOCX bytes and pasted job description text are held only in the current browser tab’s memory for the shortest practical period and are never written to sessionStorage, localStorage, cookies, Clerk metadata, URLs, logs, or unauthenticated server persistence. Processing and AI generation begin only after authentication; signup does not spend credits.

DOCX binaries and generated files

Uploaded Word (.docx) source bytes are parsed in memory on the server and are not persisted as the original file blob. For supported uploads, the product stores a bounded, allowlisted, sanitized formatting template (styles, paragraph/run properties, numbering, and safe internal package parts) plus structured plain text and preview metadata needed to render and regenerate documents. Macros, embedded active content, and external relationships are removed and are not retained. Unsupported or oversized templates fall back to text-only parsing while still storing plain text.

Tailored resume and cover-letter .docx downloads are generated on demand in memory from reviewed/validated structured content and any retained safe formatting template on authenticated download routes. Generated DOCX bytes are not stored as durable application blobs.

How the product uses data

To authenticate you, create and show owner-scoped applications, ingest resumes and job descriptions, run AI tailoring and cover-letter generation, record accept/reject decisions, generate on-demand downloads, enforce integer credit costs, fulfill one-time credit pack purchases, limit abuse of expensive endpoints, and delete application private content when you request application deletion.

Authentication (Clerk)

Sign-in and sign-up are provided by Clerk. Dashboard routes and application mutation/download APIs require a Clerk session. Application rows, credit accounts, and purchase orders are keyed to Clerk’s stable user id (owner-scoped). This product does not implement whole-Clerk-account deletion in application code.

AI processing

Resume tailoring and cover-letter generation use a server-only configured AI provider (OpenAI-compatible chat completions; credentials such as AI_API_KEY stay on the server and must not use a NEXT_PUBLIC_ prefix). Prompts include resume- and job-derived context needed to produce bounded structured suggestions or letters. Only schema-validated structured results are persisted—not raw provider transcripts. AI output can be incomplete or incorrect; see the Terms.

The default documented base URL targets an OpenAI-compatible endpoint when configured. The exact model and base URL follow server environment configuration.

Job URL retrieval

You may paste a job description manually or ask the product to fetch a public HTTP(S) job URL stored on your application. Fetching uses a pinned, SSRF-resistant transport with bounded timeouts, redirects, and response size. Fetched HTML is not rendered or stored as markup; only normalized plain text and safe metadata are retained. Job fetch configuration does not use a scraping API key.

Payments and credits (Stripe)

Credit units are server-authoritative integers, not currency. CV generation costs 2 units; cover-letter generation costs 1 unit. A one-time MVP trial grant may initialize a new owner’s balance (default 5 units unless overridden server-side).

One-time credit packs are purchased through Stripe Checkout in payment mode. The client submits only a pack id and purchase-attempt id; amounts, currency, Price IDs, and success/cancel URLs are server-derived. Credits are granted only after the Stripe webhook verifies the paid session against the persisted order—never from browser redirects alone. Stripe processes card and checkout details under Stripe’s own terms.

Storage (Neon / Postgres) and hosting

Application, credit, purchase-order, and abuse-limiter data are persisted in PostgreSQL via Neon as configured by DATABASE_URL. The application is delivered through ordinary hosting and network providers that terminate TLS and route traffic; this template does not invent a specific cloud region, certification, or subprocessor list beyond what the repository configures.

Application deletion and retained audit records

From an application detail page, an authenticated owner can confirm deletion of that application. Deletion is owner-scoped: it removes the applications row and private content stored on it (parsed resume JSON/text, any retained sanitized formatting template and preview metadata, job description text/metadata, AI tailoring suggestions, review decisions, and cover-letter JSON). Uploaded DOCX source file bytes were never stored as blobs.

Deletion is blocked briefly while CV or cover-letter generation is provisional (status generating, including staged output awaiting credit finalize/promote), with a generic “Generation is finishing; try again shortly.” response. This is application-level deletion only — not whole-account deletion.

Minimal billing and credit audit records may remain after application deletion: per-owner credit balances, immutable credit ledger entries, and Stripe purchase-order / fulfillment records needed for balance integrity, Checkout idempotency, charge reconciliation, and fraud prevention. Ledger applicationId values may remain as orphan UUIDs without a foreign key. No fixed retention schedule is claimed beyond “deleted with the application row” versus “minimal accounting records retained.”

Security limitations

The codebase uses owner scoping, server-only secrets, webhook signature verification, abuse limiting, and SSRF-resistant job fetching as implemented. This template does not claim formal security certifications, guaranteed uptime, absolute confidentiality against all threats, or that every third-party processor’s controls are verified here.

Your choices

You can avoid uploading resumes or pasting job text you do not want processed. You can use manual job description paste instead of URL fetch. You can accept or reject individual AI suggestions before download. You can delete individual applications when generation is not provisional. Account-level deletion through this application is not implemented; manage Clerk account options through Clerk’s interfaces where available.

No product support email or mailing address is configured in this repository’s environment template, so this page does not invent a contact address.

Changes

If product behavior changes, this template should be updated to match the code. The last-updated date above reflects the current documented revision of this copy.