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

Status, feedback, and similar one-time access records store token hashes. Hosted campaign lookup uses a token hash, while the protected campaign record retains the portal token needed to reuse the same published link until rotation or revocation.

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.

Event access starts aggregate-only

Special-event organizers receive aggregate reporting by default. Participant records are returned only when the event explicitly enables operational-support access for authorized staff, and sponsorship alone never changes that boundary.

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 lookups use token hashes, and launch verification stores a hash of the confirmed share URL. The protected campaign record retains the portal token needed to reuse the same published hosted link until explicit rotation or revocation.

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

Applicant-facing AI is used inside the resume-generation workflow and supporting analysis tasks, not as a general-purpose customer chat. Separate bounded internal workflows assist partner research, commercial materials, quality assurance, and editorial work.

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

Applicant request processing uses server-side OpenAI API calls with response storage turned off. Internal model-assisted outputs remain bounded to their administrative purpose and subject to the applicable review workflow.

Web-surface baseline

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

Certification boundary

Blacklight should describe the current target as practical WCAG 2.2 AA alignment 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.

Production and preview use separate Cloudflare Workers and separate Supabase projects so staging verification does not rely on production customer data.

Production database changes run through a protected workflow that identifies the exact migration set and verifies the migration ledger after application.

Sensitive partner lifecycle releases can pause affected database writes while a compatible runtime set is deployed and checked, preventing older writers from bypassing the release boundary.

Release evidence records the reviewed source, active runtime versions, deployment identity, health and authorization checks, and a complete compatible rollback inventory.

Additive schema changes are retained during recovery. Blacklight prefers a reviewed forward fix and uses mutation fences before restoring an older compatible runtime.

Supabase

Application database, auth, and storage.

Stripe

Payment processing and invoice/payment records.

Postmark

Transactional email delivery.

Zoho

Business email, CRM-linked outreach logging, and trust, commercial, or onboarding scheduling where meetings are enabled.

Cloudflare

Web delivery and edge infrastructure.

OpenAI

AI model processing for resume generation and bounded internal research, editorial, quality-assurance, and partner-material workflows. Applicant request processing uses server-side calls with response storage disabled.

Launch configuration and hosted links

Seven server-derived checks cover the program owner, support destination, delivery mode, conditional embed origin, conditional location scope, service region, and audience. Link creation waits for those checks, reuses the current scoped link by default, and rotates a token only through a separately confirmed replacement flow.

Launch confirmation evidence

Launch verification binds an authorized partner confirmation to the active campaign, a fingerprint of the launch configuration, and a hash of the confirmed public link. A material configuration change requires the public lane to be checked again.

Scoped reporting

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

Billing state and retry handling

Recurring billing changes use durable operation state and provider reconciliation so retries converge on the recorded intent instead of silently applying a different charge, subscription, or adjustment.

Event agreement and reconciliation

Special-event activation requires recorded written acceptance evidence tied to the current event, pricing, capacity, privacy mode, and spending terms. Flexible-capacity reconciliation creates a draft invoice that stays unsent until authorized Blacklight approval.

Location deletion boundary

Deleting a partner location revokes its active hosted access and can remove the location reference from historical requests while leaving the request and its other required business records intact. The product treats this as a destructive action and requires the operator to confirm the intended location and current revision.