01
Controls described here are operating controlsThe packet reflects the current production architecture, access model, data lifecycle, and operational release posture rather than a future-state feature list.
Trust Package
Blacklight separates public, partner, and administrative access; limits sensitive changes by role, organization, location, and recent authenticator verification; keeps request data tied to delivery and accountable operations; and records the evidence needed to investigate changes, recover work, and apply retention rules.
Current production posture
Partner access is server-scoped, sensitive actions require stronger authentication, public capability lookup and launch confirmation use hashed evidence while protected hosted-link records support stable-link reuse, and production releases are tied to reviewed source, verified migrations, health checks, and rollback inventory.
Blacklight Resumes · Public control summary, not a certification
Materials
The packet gives one decision-ready overview. Topic summaries and the technical appendix add detail about access, retention, providers, incident handling, recovery, audit evidence, and AI processing without exposing secrets or internal runbooks.
Claims stay limited to current evidence. Where a provider, professional review, or contractual commitment is still external, the package says so directly.
Security reviewers, technical approvers, and mission-driven partners validating baseline controls before rollout.
A high-level summary of the system, sign-in protections, and access controls for an organization’s first review.
Open summaryReviewers validating privileged access, role separation, and operator safeguards.
Admin and partner permissions, with multi-factor authentication and separate roles for higher-risk actions.
Open summarySecurity and compliance reviewers focused on traceability and sensitive-event review.
Sensitive admin and billing actions are logged for review and traceability.
Open summaryTeams that need to know how incidents, outages, and high-risk operational issues are handled.
How serious service or security issues are prioritized, investigated, and handled.
Open summaryTeams validating resilience expectations before rollout or paid conversion.
Recovery approach and continuity expectations for partner-facing operations.
Open summaryOrganizations reviewing model usage, limits on AI use, and how exceptions are handled.
Where AI is used, what automated checks happen before release, and when human support becomes involved.
Open summaryPrivacy, legal, and operations teams reviewing data scope and handling expectations.
What partner and end-user data enters the system, where it goes, and how its use is limited to providing the service.
Open summaryInstitutions reviewing deletion workflows, privacy requests, and retention controls.
How long information is kept, how scheduled cleanup works, and what happens when someone requests deletion.
Open summaryProcurement and legal teams reviewing vendor dependencies and external service providers.
Current core vendors involved in hosting, billing, identity, messaging, scheduling, and model operations.
Open summaryAssurance boundary
The strongest trust document is precise about both safeguards and limits. These boundaries apply across the packet, appendix, and topic summaries.
01
Controls described here are operating controlsThe packet reflects the current production architecture, access model, data lifecycle, and operational release posture rather than a future-state feature list.
02
Evidence is bounded to what Blacklight can verifyBlacklight distinguishes application evidence from provider guarantees and does not claim provider-side deletion, availability, or residency without separate support.
03
No certification is impliedThe public package does not claim SOC 2 certification, a completed penetration test, a VPAT, attorney approval, formal WCAG conformance, or contractual recovery objectives.
04
The current service is adult-onlyBlacklight does not activate K–12 or under-18 programs. Any future teen pathway requires separate product, privacy, contract, and legal review before intake can open.
Use the public material first. Switch to questionnaire, booking, or contact only if the review has already become a formal process.
Once you request formal trust follow-up, keep reviewer details, questionnaire scope, and procurement timing on that confirmation thread instead of opening a second request for the same review.
Best when procurement, rollout, privacy, or launch questions are easier to resolve live.
Book live trust reviewBest when the documents support a real program decision and your team is ready to review fit, launch plans, and trust questions together.
Start partner reviewBest when the public packet and summaries are no longer enough and your team needs formal follow-up on one confirmation thread.
Request formal trust follow-upOpen the institutional questionnaire templateControl coverage
The summaries below state the current control position first, then route to deeper evidence only when a reviewer needs it.
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.
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.
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.
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.