How CoverClause handles your data

CoverClause public app — data handling and retention

CoverClause (coverclause.fly.dev) is the public self-serve wrapper around the same
engine. What follows describes exactly what its code does today — no claim below is
stronger than the implementation (`coverclause/db.py`, `coverclause/worker.py`).

• Contract text in the active database. Extracted contract text is stored on the job row only while the analysis is queued or running. It is set to `NULL` when analysis completes and equally when it fails. As a backstop for jobs stranded by a crash or restart, a sweeper (worker boot and roughly every 10 minutes) clears text from any job row older than 24 hours. The sweeper is in-process: if the service is down at that point, cleanup runs at the next start.
• Deletion mechanics and backups. SQLite `secure_delete` is enabled so deleted cell content is overwritten in the active database. SQLite WAL/journal frames can temporarily contain earlier page versions until checkpointed or overwritten. Fly.io also takes encrypted daily volume snapshots; the production volume's current snapshot retention is five days. Deleting an active row does not purge an already-created snapshot, so residual copies age out with that snapshot schedule.
• OpenAI. Contract text is processed by OpenAI's API and is not used to train models under the API data-usage terms. Public risk-transfer Responses calls set `store=false`, disabling Responses application-state storage. CoverClause does not currently claim Zero Data Retention: standard abuse-monitoring logs may contain prompts and responses and may be retained by OpenAI for up to 30 days unless a shorter legal or approved retention control applies.
• Other subprocessors. The email address and file name are processed by Resend for notification delivery; a result-ready email includes the private result link. Stripe processes checkout, payment, billing, fraud-prevention, refund, and dispute data; contract text and analysis findings are not sent to Stripe. The service is hosted on Fly.io infrastructure in Frankfurt and its persistent volume is encrypted. Data is shared with these processors only for those functions and is never sold.
• Derived extraction cache. To make repeated scoring reproducible, the engine stores derived true/false clause features and extraction metadata keyed by a SHA-256 content hash. The cache does not contain contract prose. Because multiple analyses can share one cache entry, deleting a result does not delete the shared derived entry; it remains until operational cache rotation.
• Analysis results. The result page (severity bands, findings, report) is retained for 30 days (`COVERCLAUSE_RESULT_TTL_DAYS`, default 30), after which the sweeper removes the result payload and job row from the active database. The optional analysis context supplied at upload (governing state, project state, agreement date, indemnitor role, project type, and contract type) lives only on that job row and follows the same deletion schedule. Every result page carries a "Delete this analysis now" button that removes the active job row and result.
• Email address. The email address provided at upload is retained as a contact record for analysis and product follow-up. A deletion request for that contact record can be sent to ajells21@gmail.com, subject to transaction records that must be kept for accounting, tax, fraud, refund, or dispute purposes.
• Conversion requests and funnel metadata. If a result-page offer is requested, the contact record also retains the offer selected, request time, and alert-delivery status so the request can be fulfilled. Content-free funnel events retain only an event time, event kind, and random job ID — never contract text, file name, or email. These records remain as operational/contact history after the result itself expires or is deleted; the job ID no longer resolves once its job row is gone.
• Paid-report orders. For a paid full report, CoverClause retains the payer's email, random job ID, Stripe Checkout Session and PaymentIntent identifiers, amount, currency, payment/refund status, timestamps, and delivery status. Card or bank-account details never enter CoverClause and are handled by Stripe. These payment records remain after an analysis result is deleted or expires because they are transaction records used for accounting, tax, fraud prevention, refunds, and dispute handling. Deleting an analysis deletes the report, not the corresponding payment record.
• File names. The uploaded file's name is kept on the contact record for up to 30 days, after which the sweeper clears it (the email address stays, as above). Using "Delete this analysis now" also clears the file name from the contact record immediately.
• Technical rate-limit records. Enforcing the daily free-tier caps stores the submitting IP address and date. These rows exist only for rate limiting and are purged by the sweeper after 48 hours.
• Stuck analyses. A job stuck in "running" for more than 15 minutes is returned to the queue (at most twice); after that it is marked failed with its contract text cleared. Recoveries are logged.
• Result URLs. Result and progress pages are addressed by an unguessable random ID and served with `Cache-Control: no-store` and `Referrer-Policy: no-referrer`, so they are not stored by shared caches and the URL is not leaked through browser referrers. All pages carry `noindex`, and application access logging is disabled. Notification emails still contain the private link, and hosting/email processors necessarily handle routing metadata; the link must be treated as confidential.
• No training. Uploaded documents are not used to train models (same API terms as the engine's standard mode above).