Data stays tied to the service path
Blacklight collects and keeps the data it needs to generate, deliver, support, and govern resume requests. It is not built around ad tracking, resale, or off-site behavioral profiling.
Technical Trust Appendix
Privacy, retention, and technical handling appendix
This appendix is for reviewers who want more operational detail than the public trust packet without dropping all the way into internal implementation notes or runbooks.
Blacklight Resumes is operated by Blacklight AI Resumes Inc.
Technical posture in plain language
Application records are not open-ended
Normal retention, scheduled minimization, and purge behavior are part of the system. A deletion request speeds up removal for a specific person or request, but it is not the only reason cleanup happens.
Tokenized access is bounded
Access tokens used for status links, campaigns, feedback, and similar flows are handled as hashes in storage so the raw token is not the system record.
Retention windows
These are the current baseline windows reflected in the application policy snapshot. Different record classes have different windows because delivery, privacy handling, support, and accountability do not all need the same retention period.
Delete-request delay
3 daysPrivacy deletion requests are queued with a short delay window before purge processing begins.
Case-file retention
120 daysOne recoverable case file is retained briefly for operations, support, and dispute handling unless a legal hold applies.
Email outbox content
30 daysTransactional email content is redacted on schedule and also redacted earlier on privacy purge when linked to a request.
Audit events
30/730 daysIP address, user-agent, and similar request-origin details age out first; the broader audit record remains longer for accountability.
Site events
30/180 daysIP address, user-agent, and similar request-origin details are minimized earlier than the site event record itself.
Queue payloads
7/90/180 daysPayload trim happens first, followed by different succeeded and failure retention windows.
Contact attachments / tickets
6 / 12 monthsAttachments clear sooner than the support ticket record that documents the interaction.
What gets minimized or removed
Stored delivery files and uploaded source documents are removed on schedule rather than retained indefinitely.
One short-lived recoverable case file is retained briefly for operations, dispute handling, and continuity unless a legal hold requires more time.
Personal details in request records are scrubbed or minimized when purge workflows complete.
Transactional email content linked to a request is redacted on schedule and earlier when privacy purge requires it.
Older request-origin details such as IP address and user-agent data are removed or minimized before the longer-lived event record ages out.
Operational queue payloads are trimmed before the underlying job records are later deleted on their own schedule.
When a request is fully purged, the remaining record is reduced to the minimum state needed to show that the purge occurred.
Confirmation and audit follow-through still happen, but they do not depend on keeping the original personal-information payload intact.
Hashed identifiers and bounded tokens
Where tokenized access or low-friction abuse controls are needed, the system uses hashed values so the stored record is the hash, not the original token or raw input.
Status-link tokens are stored as hashes rather than as reusable raw tokens in the database.
Campaign and embed access tokens are hashed before lookup/storage so the raw token is not the system record.
Feedback and contact verification tokens follow the same pattern: the raw value is used once, while the stored record is the hash.
Upload rate limiting and some access-request abuse checks use hashed IP values rather than keeping the raw client IP in the application record for that purpose.
Analytics use anonymized or hashed session linkage and respect Do Not Track instead of relying on third-party tracking scripts.
Analytics and public-site privacy stance
Cookie-light public experience
The public site is intentionally light on tracking. The current policy stance is no off-site trackers and no advertising-cookie stack layered across the site.
Local preference storage
Some user experience preferences, such as theme selection, may be stored locally in the browser. That is separate from third-party tracking or ad-tech profiling.
Do Not Track respected
Internal analytics route through first-party handling and respect Do Not Track rather than relying on external tracking scripts to build audience profiles.
AI processing boundaries
Where AI is used
AI is used inside the resume-generation workflow and supporting analysis tasks, not as a general-purpose chat layer spread across the whole product.
What is kept as the business record
Blacklight keeps its own request records, outputs, status data, and delivery artifacts in its system. The application does not depend on an external chat history as the official record of the service.
API storage setting
OpenAI API requests in the current workflow are configured with response storage turned off, so the service is not asking OpenAI to store responses for later API retrieval.
Core providers
Supabase
Application database, auth, and storage.
Stripe
Payment processing and invoice/payment records.
Postmark
Transactional email delivery.
Cloudflare
Web delivery and edge infrastructure.
OpenAI
Bounded model processing inside the resume-generation workflow; API calls are configured not to store responses for later retrieval.
When to ask for more detail
If your institution needs answers beyond this appendix, the next step is the trust contact flow or a formal questionnaire exchange. That is the right point for deeper institution-specific review rather than turning the public trust center into an internal runbook.