Privacy, retention, and technical handling appendix

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.

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.

Billing records are retained separately

Invoice copies, payment status history, and contract-linked billing records follow a longer business-record retention schedule than resume artifacts because accounting, audit, dispute, and collections needs do not end on the same timeline as request delivery.

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.

Partner controls are scoped

Partner operations such as reporting, hosted-link management, and billing changes are role-scoped and, where applicable, location-scoped rather than broadly visible to every partner user.

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.

Billing records and invoice copies can remain on a longer retention schedule even when request artifacts are later minimized or purged.

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.

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.

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.

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.

Billing access is limited

Billing records, invoice copies, and payment state are intended for billing, admin, finance, support, legal, or similarly authorized roles with a legitimate operational need, rather than broad partner-wide visibility by default.

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.

Web-surface baseline

Key public review surfaces and preview-safe portal shells are part of the automated accessibility validation path, so the accessibility posture is not just a point-in-time manual opinion.

Certification boundary

Blacklight should describe the current target as a practical WCAG 2.2 AA posture with meaningful automated coverage, not as a formal accessibility certification or completed external audit.

DOCX semantic structure

Delivered resume and cover-letter DOCX files now use semantic headings, real list structure, numbering, default language metadata, and document properties instead of relying on bare paragraph output alone.

ATS-safe formatting restraint

The document path still avoids tables-for-layout, text boxes, multi-column structure, and other decorative patterns that can complicate ATS parsing, so the accessibility improvement does not depend on visually complex Word formatting.

Supabase

Application database, auth, and storage.

Stripe

Payment processing and invoice/payment records.

Postmark

Transactional email delivery.

Cal.com

Partner commercial, trust, and onboarding booking workflows where scheduling is enabled.

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.

Hosted links and embeds are managed through explicit partner controls rather than unmanaged raw links alone.

Partner reporting is designed around aggregate and scoped visibility, including location-aware reporting where the account configuration supports it.

Recurring partner billing changes are represented as explicit state transitions such as active plan, scheduled change, or meeting-based review.

Trust, commercial, and onboarding review workflows can route through booking and support paths without requiring those meeting records to become the system of record for request content.