Blacklight Resumes Trust Packet

Public intake, partner workflows, and admin operations are separated into different surfaces so the same person is not moving through every part of the system with the same level of access.

Sensitive actions such as billing changes, privacy handling, partner-access changes, and high-risk admin actions sit behind stronger authentication requirements and auditability.

The platform is designed to keep customer-facing intake simple while keeping privileged operational controls limited to authenticated internal or partner-authorized paths.

Blacklight collects the information needed to generate, deliver, and support resume requests: intake details, uploaded documents, selected targets, delivery records, and support or privacy follow-up when needed.

That data stays tied to the service path rather than being reused for ad targeting, third-party tracking, or unrelated marketing profiling.

The public site is intentionally cookie-light and tracking-light, so the normal assumptions people make about ad-tech stacks do not apply here.

Blacklight uses normal retention windows and scheduled cleanup rather than keeping full personal information indefinitely by default.

Some records are minimized or redacted on schedule even when no one files a deletion request, while deletion requests move the specific request into a faster removal workflow.

In practice, that means operational records are kept only for the period needed to deliver the service, support the request, and satisfy limited legal or security obligations before they are minimized or removed.

Operational issues are reviewed through a defined handling path instead of being treated like ordinary support noise when sensitive systems or partner-facing workflows are involved.

The focus is on fast triage, scoped investigation, and limiting the blast radius when something affects privacy, delivery, partner access, or continuity.

Public trust materials stay high-level on purpose, but the operating posture behind them is built around escalation, containment, communication, and follow-through when a real issue affects service or data handling.

Partner and admin capabilities are split by role so routine visibility, billing actions, user management, and higher-risk controls do not all sit behind the same permission level.

Sensitive routes use stronger authentication expectations, especially where account changes, partner-access decisions, or operational overrides are involved.

Location-aware and role-aware access boundaries are part of the model so larger organizations can limit what staff see when broader access is not appropriate.

Higher-risk actions such as sensitive admin updates, billing changes, privacy handling, and partner-access changes are captured for traceability.

The goal is not surveillance of ordinary use. It is accountability around the kinds of actions that matter in support, privacy, and partner operations.

This gives reviewers a first-pass answer to “how would you know who changed something important?” without opening internal dashboards during procurement.

AI is used inside the resume-generation workflow rather than as an open-ended chat product layered across the whole site.

Model processing is scoped to the request workflow, and Blacklight stores the service outputs it needs in its own system rather than relying on an OpenAI-hosted conversation history as the business record.

That means partners can review AI use as one bounded part of the service path: generation happens for the request, outputs are kept in Blacklight systems, and the platform record does not depend on a separate chat history living elsewhere.

Current core vendors include Supabase for application data, auth, and storage; Stripe for payments; Postmark for transactional email delivery; Cloudflare for web delivery and edge infrastructure; and OpenAI for model processing inside resume generation.

Each provider is tied to a specific operational role in the service path rather than being part of a larger advertising, analytics, or reseller network.

The vendor footprint is intentionally narrow and service-specific so partner review can focus on the providers actually involved in hosting, delivery, payments, and bounded model processing.

Core operations are set up with continuity in mind so a temporary problem in one layer does not automatically become a total service loss.

The public trust page does not expose internal recovery runbooks, but it does state clearly that resilience, recovery, and continuity are treated as operational requirements rather than afterthoughts.

The practical expectation is straightforward: Blacklight is run so temporary faults can be recovered from, partner-facing operations can be restored, and continuity is part of normal operations rather than an afterthought.

The questionnaire packet is the structured next step for institutions that cannot move forward on a public trust page alone.

It is meant to shorten back-and-forth by giving Blacklight and the partner a common starting point instead of starting every review from scratch.

It is best suited to organizations that already use a formal procurement checklist, vendor questionnaire, or privacy/security review template and need Blacklight to answer within that structure.