AI policy
This document explains how Glozo uses data, models, and automation. It describes what our system does, what it does not do, which decisions remain with the user, and where Glozo sits relative to current US employment law.
What Glozo is
Glozo is a sourcing layer. We help recruiters find and shortlist candidates from public data before any application is filed. We do not sit between a candidate and a hire decision.
A typical use is this. A recruiter describes a role they need to fill. Our search reads 30+ public sources and surfaces candidates whose work history, publicly demonstrated skills, and market signals look like a fit for the role. The recruiter decides who to research further, who to message, and who to invite into a process.
The line we draw is structural. Sourcing happens before applications exist. Once a candidate applies to a specific job, they enter the employer's hiring funnel. Glozo does not participate in what happens after that point.
What Glozo is not
Several categories of hiring tool are regulated under recent US employment law. Glozo is not one of those categories, and the architecture of the product is the reason.
The relevant regulations cover systems that score, rank, screen, or filter job applicants. New York City Local Law 144 calls them Automated Employment Decision Tools and requires annual bias audits and applicant notification. Illinois HB 3773 (effective January 1, 2026) creates a similar disclosure regime. California's FEHA guidance treats automated decision systems as covered by existing anti-discrimination law. The Mobley v. Workday class action, certified by the Northern District of California in May 2025, extends Title VII liability theories to vendors of applicant-screening software.
All of these regulations target one specific activity: a system evaluating people who have already applied for a specific job. That is not what Glozo does. Our users are recruiters and hiring teams looking for candidates who have not yet applied anywhere, and our system reads only public profile data, never application materials.
Glozo does not produce a candidate score. The output on a candidate card is a matching summary, a written explanation of why a public profile looks relevant to the role. It is not a numerical score, percentile, or yes/no recommendation.
Glozo does not make hire, no-hire, advance, or reject decisions on the user's behalf. Every choice about who to message, who to interview, who to advance, and who to hire is made by a human user.
Glozo is not an applicant-evaluation system like HireVue, Pymetrics, or the Workday products at issue in Mobley. We do not see applications. We do not produce adverse impact reports on applicants, because we do not evaluate applicants.
Data sources
Glozo's candidate database is built from public profile data across 30+ sources. The primary ones are LinkedIn, GitHub, GitLab, conference talks and proceedings, technical blogs, design portfolios, open-source contribution graphs, and similar professional sites that publish work for the public to see. We do not access non-public profiles, employer-side application systems, ATSes, or internal HR data.
Contact information (work emails, phone numbers) is obtained from third-party data providers operating under their own compliance frameworks. We do not extract contact data from non-public sources.
We do not collect or use protected-class attributes as inputs to any of our models. The categories we exclude include race, religion, age, sex, gender identity, sexual orientation, national origin, disability status, pregnancy status, and veteran status. Where these attributes appear on a public profile because the candidate chose to publish them, our system does not surface them in search results and does not let them influence what we surface.
All data collection follows GDPR and CCPA / CPRA requirements. Candidates have rights to access, correct, and delete the data we hold about them. The mechanism is documented in our Privacy Policy.
How the Skill Graph works
The Skill Graph is our internal representation of a candidate's work history and demonstrated capabilities. The engine reads public sources for a given candidate and builds a weighted graph where each node corresponds to a skill or technology and the weight corresponds to evidence of depth.
Depth is calculated from signals like length of tenure in roles where the skill was central, scale and complexity of the projects on which the skill appeared, and whether the candidate produced original work using the skill (open-source commits, talks, papers, public artifacts). The same skill name with different evidence produces different weights. "Used Python at university five years ago" and "led the Python backend at a 200-engineer org for three years" resolve to two different nodes in the graph.
When a recruiter runs a search, the engine matches the role description to the Skill Graph and produces a matching summary on each candidate card. The summary is narrative. It explains, in plain English, what about the public profile looks relevant to the role. Results are ordered by closeness of match to the search request, but no candidate receives a fixed score, fitness number, or pass/fail flag.
How the Market Value estimate works
The Market Value estimate on each candidate card is a salary range produced by a statistical model that reads more than 10 million market signals each month. Inputs include current job listings, salary disclosure data from US states with pay transparency laws (Colorado, New York, California, Washington, Illinois, and others), industry compensation surveys, and publicly reported total compensation for comparable roles.
The estimate describes the market, not the candidate. It answers the question "approximately what would a person with this profile, in this role, in this location, expect to be paid right now?" It does not answer "what is this person worth" or "what should this person be paid." Glozo does not produce individual worth assessments.
Recruiters use the estimate to qualify outreach before spending budget. A candidate sitting in a $250K to $320K market range will not respond to a $140K outreach, and the estimate exists so recruiters do not spend reveal credits and outreach time on people who are out of band. The candidate never sees the estimate. It is internal context for the recruiter.
How the Open-to-Offers signal works
The Open-to-Offers signal flags candidates who appear likely to be receptive to a hiring conversation right now, based on patterns in their public behavior. It is not the LinkedIn "Open to Work" badge, which is self-reported by the candidate. Most of the people who carry our signal have made no public statement about being open to a new role.
The model reads public-behavior features across the same 30+ sources. The specific weights are proprietary, but the categories include profile-update activity, engagement on competitor or peer company pages, technical-community participation, and changes in posting patterns that historically correlate with a person being open to a conversation.
The signal is intentionally cautious. In a typical search of 200 senior tech candidates, approximately 15 receive the signal, roughly 7 to 8 percent. We picked this calibration after testing: a higher hit rate produced more false positives, and false positives result in outreach to people who are not actually open. That wastes the recruiter's time and clutters candidate inboxes.
The signal is a probability cue, not a guarantee. A candidate carrying the signal might decline a message. A candidate without it might respond enthusiastically to a well-timed one. Recruiters use the signal to prioritize, not to gate.
Human oversight
Every choice that affects a candidate's professional life is made by a human user of Glozo, not by Glozo itself. This is not a marketing position. It is the architecture of the product.
Glozo can surface a candidate for a search. It cannot send a message on its own. The recruiter writes or approves every outreach.
Glozo can show a candidate's matching summary, market value range, and openness signal. It cannot weigh those signals into a decision. Whether to message, interview, advance, or pass on a candidate is the user's call. We provide context. We do not provide recommendations.
Glozo's search results are generated from the candidate database and the search request, not from the recruiter's prior behavior in the product. We have intentionally avoided building a feedback loop where past clicks, messages, or hires would change who appears in future searches. A feedback loop of that kind is one of the mechanisms by which sourcing tools can develop adverse impact over time, and the product is designed without one.
Bias and limitations
No sourcing system is bias-free, including ours. The public profile data we read carries selection effects: who chooses to be on LinkedIn, who maintains a GitHub, who speaks at conferences, who writes publicly. Those choices correlate with demographic factors and produce uneven representation in any candidate database built on public data, ours included.
Several things we do not claim. We do not claim Glozo eliminates bias from sourcing. We do not claim the Skill Graph is bias-free as a model: it is trained on public work artifacts, and the people who produce public work artifacts are not a demographically representative sample. We do not claim the Open-to-Offers signal is calibration-perfect across demographic groups.
What we do, instead, is concrete. We exclude protected-class attributes from model inputs. We do not surface those attributes to recruiters. We do not use behavioral feedback from recruiters to amplify past selection patterns. And we surface market value information so that recruiters can pre-qualify outreach by budget fit instead of by surface signals (school name, photo, name) that have historically been the channel for bias in recruiting.
If you are evaluating Glozo for a regulated context and need specific information about our bias monitoring practices, contact us at [email protected]. We will share what we can.
Regulatory posture
Glozo operates entirely in the pre-application sourcing layer. That positioning is the foundation of our compliance posture with US employment law.
New York City Local Law 144
Effective July 2023, LL 144 requires bias audits for "Automated Employment Decision Tools" used by employers to make or substantially assist employment decisions. Glozo is not an AEDT under the statute because our users are not employers acting on their own applicants, and Glozo does not make or substantially assist hire decisions. We surface candidates. The user decides what to do with them.
Illinois HB 3773
Effective January 1, 2026, HB 3773 amends the Illinois Human Rights Act to cover the use of AI in employment decisions. The amendment focuses on employer use of AI in hiring, screening, and discharge. As with LL 144, Glozo's pre-application sourcing role places us outside the scope of the amendment.
California FEHA and CRD regulations
California's Fair Employment and Housing Act, as interpreted by the Civil Rights Department's regulations on automated decision systems, targets applicant-screening systems and AI tools used to make or substantially assist hiring decisions. Glozo's sourcing function does not fall within the scoped activities.
Mobley v. Workday
Mobley v. Workday (N.D. Cal., class certified May 2025) extends potential Title VII liability to vendors that provide AI-based applicant-screening software. The case turns on whether Workday's tools functioned as an agent of employer-customers in screening applicants. Glozo does not screen applicants, does not interact with employer ATSes, and does not produce employment recommendations. The agent theory at issue in Mobley does not reach Glozo's product as currently designed.
GDPR and CCPA / CPRA
GDPR applies to any EU data subjects whose public profiles appear in our sources. CCPA and CPRA apply to California residents whose data we hold. We treat all candidate data, regardless of region, as subject to the access, correction, and deletion rights granted under these regimes. The mechanism for exercising those rights is documented in our Privacy Policy.
Illinois BIPA
The Illinois Biometric Information Privacy Act is not implicated by Glozo's product. We do not collect or process biometric data. No facial recognition, voiceprints, retinal scans, or other categories defined by the statute.
Updates and contact
This document was last updated on May 22, 2026.
Material changes to the policy will be noted with a new date and a brief change log on this page. We do not silently update what we claim.
Questions about anything in this document, requests for additional information about our practices, or notices from compliance teams evaluating Glozo can be sent to [email protected].
For candidate-side requests (access, correction, deletion of personal data), please use the contact instructions in our Privacy Policy.