Blacklight Resumes Trust Packet

Security and access controls

Admin and partner access are separate, partner visibility is limited by organization, role, and location, and sensitive changes require recent authenticator verification and audit evidence.

Data handling and retention

Request data stays tied to generation, delivery, support, billing, and accountable operations. Record-specific retention, minimization, legal-hold, and deletion workflows limit how long sensitive content remains.

AI usage and model handling

Applicant-facing AI is limited to bounded resume-generation and supporting analysis. Separate internal model workflows assist partner research, materials, quality assurance, and editorial work without replacing Blacklight’s official business records.

Service readiness and privacy practices

Production uses reviewed releases, explicit rollback inventories, monitored queue and service health, private request artifacts, a tracking-light public site, and documented incident and recovery boundaries.

Accessibility baseline

Blacklight maintains an automated accessibility baseline across key public review surfaces and preview-safe portal shells. The practical target is WCAG 2.2 AA, but Blacklight does not currently describe this as a formal accessibility certification.

DOCX document format

Delivered resume and cover-letter DOCX files stay plain-text and single-column for applicant tracking system (ATS) compatibility while also using meaningful headings, list structure, language information, and document properties to improve assistive-technology handling.

Access by role and location

Partner access depends on each person’s role and can also be limited by location so staff do not automatically see account-wide request activity when narrower visibility is more appropriate.

Hosted-link and embed controls

Partners can manage hosted intake links and embeds, and higher-risk actions such as revocation or location deletion are intentionally constrained to the right roles and flows.

Aggregate reporting

Reporting-only users and special-event organizers in the default aggregate-only mode can review program activity without receiving participant records. Participant-level access is reserved for authorized staff with a legitimate participant-support role.

Sponsor boundary

Funding a special event does not grant the sponsor attendee names, contact information, resumes, request logs, portal access, mailing-list rights, or recruiting access. Any future follow-up requires a separate voluntary participant choice.

Billing and review state

Recurring billing and special-event terms are managed as explicit states. Event records distinguish fixed blocks from flexible capacity, preserve the accepted reserve and spending ceiling, create reconciliation invoices as drafts, and require authorized Blacklight approval before a draft is finalized or sent.

Agreement evidence

Before event access is activated, Blacklight records the accepting organizer representative, work email, title, written acceptance method and time, quote or order reference, terms version, and a versioned record of the accepted terms.

Public requests, partner accounts, and admin tools are separated so the same person does not automatically have the same level of access everywhere.

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

The public request form stays simple, while privileged controls are limited to signed-in staff and authorized partner users.

Production migrations and runtime releases use reviewed source, exact-target checks, durable release controls, health verification, and recorded rollback inventory rather than an untracked dashboard-only deployment path.

Blacklight also maintains an automated accessibility baseline across key public review surfaces and preview-safe portal shells, while keeping the trust claim itself narrower than a formal accessibility certification.

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.

Special events default to aggregate-only organizer reporting. Sponsors do not receive participant names, contact information, resumes, request logs, portal access, or recruiting rights merely because they funded access.

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

Launch verification stores bounded operational evidence, including the authorized actor, active campaign, configuration fingerprint, and a hash of the confirmed public link rather than a reusable raw link token.

Delivered resume and cover-letter DOCX files stay plain-text and single-column for applicant tracking system (ATS) compatibility. They also use Word headings, lists, language information, and document properties to work better with assistive technology.

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

Some records are reduced or redacted on schedule even when no one asks for deletion. A validated deletion request can move the specific record into a faster removal process.

Service records are kept only as long as needed to deliver the service, support the request, and meet limited legal or security obligations before they are reduced or removed.

Serious issues follow a defined response process instead of being treated like ordinary support questions.

The focus is on quick assessment, a focused investigation, and limiting harm when something affects privacy, delivery, partner access, or service availability.

Public trust materials stay high-level on purpose, but the response process includes escalation, containment, communication, and follow-through when a real issue affects the 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 actions require stronger authentication, especially for account changes, partner-access decisions, or administrative overrides.

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.

Reporting-only users and aggregate-only event organizers do not receive participant records. Operational participant access must be explicitly assigned for a legitimate support need, and sponsorship alone never grants that access.

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

Partner portal terms acceptance, event quote acceptance evidence, reconciliation-draft creation, and authorized Blacklight invoice approval are recorded as separate reviewable steps.

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 to help generate resumes. It is not an open-ended chat product operating across the whole site.

The service creates and compares a limited number of draft versions, keeps the version that passes more quality checks, and runs automated checks for missing or inconsistent content before release.

Blacklight does not manually approve every package. Human support handles exceptions such as delivery, payment, access, or an unresolved service failure.

Applicant-request model processing is limited to the request. Blacklight stores the service results it needs in its own system instead of relying on an OpenAI-hosted conversation history as the business record.

Separate internal model workflows can assist partner research, commercial materials, quality assurance, and editorial work. They are bounded to those administrative tasks and remain review-controlled.

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; Zoho for business email, CRM-linked outreach logging, and meeting scheduling where enabled; and OpenAI for resume generation plus bounded internal research, editorial, quality-assurance, and partner-material workflows.

Each provider performs a specific part of the service and is not part of a larger advertising, analytics, or reseller network.

The provider list is intentionally narrow so partner review can focus on the services actually involved in hosting, delivery, payments, and AI 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 publish internal recovery instructions, but it explains that recovery and service continuity are treated as ongoing requirements.

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.