This policy explains what personal data SourcingNav processes, why, who it is shared with, how long it is kept, and the rights you have over it. It covers two groups of people: recruiters who hold accounts, and candidates whose information is processed by those recruiters.
SourcingNav is operated by Jason Shotwell (sole proprietor). For candidate data entered or sourced by a recruiter, that recruiter is the controller and SourcingNav acts as a processor on their behalf. For account and billing data we are the controller. Contact: hello@sourcingnav.com.
| Category | Examples | Where it comes from |
|---|---|---|
| Professional profile | Name, public profile URL, headline, employer, job title, location, skills | Public web search results; the public profile page a recruiter opens |
| Application data | Résumé, cover letter, email, phone, work authorisation and export-control answers | Submitted by the candidate through a job posting |
| Voluntary self-identification | Gender, race/ethnicity, veteran and disability status | Optional, candidate-provided, opt-in only |
| Contact data | Work email, verification status | Self-published sources and licensed lookup providers, on an explicit recruiter action |
| Engagement records | Messages sent, replies, opens, clicks, interview notes, scores and decisions | Generated by use of the Service |
| Links between people | Who co-authored a work or a technical report (from OpenAlex, OSTI and NASA's technical reports server); two people who were at one employer in the same years, read from the public profile pages a recruiter opened | Public research records; the pages a recruiter opens |
| Account data | Recruiter name, email, settings, usage counts | Provided by the recruiter |
| Public records | Companies: who won federal contracts, filed for work visas, runs a regulated plant, files with the SEC, holds patents, sponsors a retirement plan, holds a research award, is a nonprofit hospital, university or research institute, or filed a WARN layoff notice, with city and state; counts of employers and employees by county and industry. People: the FAA's register of certificated mechanics and repairmen (name, city, state, certificate kind) and the CMS NPPES register of clinicians (NPI, name, credential, practice city and state, specialty) | Federal and state public records and the Research Organization Registry, downloaded as they are published; see below |
Beside what recruiters enter, SourcingNav holds copies of public records that United States federal and state agencies publish for anyone to download, reduced to the columns the desk reads. The federal records are works of the United States government and carry no copyright; the state WARN notices are public records of the states that publish them; the Research Organization Registry is published under the CC0 public domain dedication, with its location data from GeoNames under the Creative Commons Attribution 4.0 licence. They are used to tell a recruiter which employers near a search do the work, how a market pays, who is laying people off and where its graduates come from, never to score a person. Almost all of them describe companies and places, not people:
What is never read from any of these files: a point of contact, an attorney or preparer, an email address, a phone number, a street address, a postal code, a coordinate or a person's name. The Form D related-persons and signature files are never opened. An individual who files with the SEC, and an individual patent assignee or inventor, is never a row. Each file's columns are named in the loader that reads it, and a file missing a column it needs writes nothing.
The registers of people. The first is the FAA's Airmen Certification register of mechanics with Airframe or Powerplant ratings and repairmen, which the FAA publishes monthly and which lets a recruiter find aircraft technicians near a search without a paid lookup. We keep a person's name, city, state and certificate kind, and never a street address, a postal code, a medical class, a date of birth or a pilot. Each entry has one page of its own, shown only to a signed-in recruiter, which says the entry came from a public register. California law treats information lawfully made available from a government record as publicly available; we still honour removal. If you are in the register and want your entry out of SourcingNav, email hello@sourcingnav.com with your name, city and state as the FAA lists them. We mark your page's address as do-not-show by hand, which hides the entry from every search, every page and every recruiter, and the monthly reload of the FAA file cannot bring it back. The FAA's own option to withhold your address does not remove your name from the file it publishes, so ask us as well.
The second is the NPPES register of every US clinician's National Provider Identifier record, which the Centers for Medicare & Medicaid Services publishes monthly and which lets a recruiter find nurses, nurse practitioners and physician assistants, physicians and allied clinicians near a search without a paid lookup. For an individual clinician in the states loaded we keep the NPI, the name, the credential text, the practice city and state and the kind of clinician the primary specialty describes, and never a street address, a postal code, a phone or fax number, a mailing address, gender, a licence number, another identifier, a date of birth or an organisation. Entries are read only by a search for the same kind of clinician in the same towns, and each has one page of its own shown only to a signed-in recruiter. Removal works the same way: email hello@sourcingnav.com with your name, city and state as the register lists them, we mark your page's address as do-not-show by hand, and a reload of the CMS file cannot bring it back.
The SourcingNav Chrome extension is a window onto a recruiter's own SourcingNav account, shown beside a public profile page in their browser. It reads the visible name, headline, location, current employer, experience text and photo address of the one profile the recruiter is viewing, only when the recruiter clicks in the panel, and sends that to the recruiter's SourcingNav account at sourcingnav.com and nowhere else. On a LinkedIn people search it reads, on the same click, the name, headline and location of the results already on screen. It does not crawl, scroll, open profiles or page through results, does not run in the background, does not read any other page, never adds or changes anything on LinkedIn’s page (everything it shows appears in Chrome’s side panel), and does not read or require LinkedIn Recruiter. The only thing it stores in the browser is the recruiter's own SourcingNav session token, saved when they click Connect in Settings and removable by uninstalling the extension. Everything it saves is processed under this policy exactly as if the recruiter had typed it into sourcingnav.com. It is installed from the Chrome Web Store, where its permissions are listed and justified; when the recruiter uses LinkedIn’s own Save to PDF, the extension notices that one download finishing and names it in the panel, and reads nothing else from the browser.
SourcingNav is a high-risk AI system under the EU AI Act (Annex III, employment). It ranks and scores candidates against a role and can suggest that someone is passed over. Two things are always true:
We do not infer protected characteristics, and we do not use them as inputs to scoring.
A learned order. A desk's sheet may also be ordered by what the candidates that desk contacted went on to do (answered, interviewed, received an offer, were placed, stayed). The learned order reads only the score and the three checks the card showed (title, must-have skills, place), reorders only people who already show the evidence, is used only when it orders that desk's own past outcomes better than the rules do, never changes a recorded score, and is recorded like every ranking. It is learned for one desk and never from another's.
Widening a search. A recruiter may ask a search to also look in more places: historically Black colleges and universities, veterans and transition programs, and non-traditional paths such as apprenticeships and community college. That changes where we look, not how anyone is scored; everyone it finds is scored by the same rules, and nothing about any person is inferred from it.
We do not sell personal data and we do not share it for cross-context behavioural advertising. Candidate records are never pooled across recruiter accounts. We use these categories of processor; the full subprocessor list is read from the code and names every service, what it receives, and which ones run only when they are switched on:
| Purpose | Providers | What they receive |
|---|---|---|
| Hosting and database | Vercel, Turso | Service data at rest and in transit |
| Email delivery | Resend; your own Outlook or Gmail if connected | Message content and recipient address |
| AI inference | Anthropic; OpenAI and Voyage AI for embeddings and re-ranking; Groq for speech to text | Job and profile text for parsing, scoring, ranking and drafting; recorded meeting audio for transcription |
| Public web search | Serper (Google), SerpApi, Exa, Perplexity, Brave, Tavily, People Data Labs, GitHub, OpenAlex | Query strings only — job titles, skills, place and company names; and, to read one person's public profile (a location or job-change check, a closer read of a search's top results, or a recruiter's click to enrich a profile), that profile's address, or the person's name and employer. No score, note or decision is ever sent to a search provider. |
| Contact lookup | Hunter, SignalHire | Name, employer and profile URL, on an explicit recruiter action |
| Calendars and messaging | Google, Microsoft, Slack, Zoom, Twilio, when switched on | Meetings, messages and transcripts that pass through the connected account; a shortlist a recruiter posts to their Slack carries each candidate's name, current title, employer, place and up to three lines of evidence, and never anyone who opted out |
| Billing | Stripe | The account's email address; card details go to Stripe directly |
| Decision receipts | The AIR Blackbox receipt server | The receipt of each candidate-affecting decision (see compliance) |
We may also disclose data where required by law, or in connection with a merger or sale of assets, in which case this policy continues to apply.
Processing takes place primarily in the United States. Where data is transferred out of the EEA or UK, we rely on Standard Contractual Clauses and equivalent safeguards with our processors.
| Data | Retention |
|---|---|
| Candidates in an active pipeline | While the search is open |
| Candidates on a closed search, not placed | 2 years after the search closed, then anonymised |
| Placed candidates | 7 years after the placement, then anonymised |
| Captured public profile pages and uploaded résumés | 3 years, then deleted |
| Location cache and the public page text read beside it | 45 days |
| Our copy of a message sent to Slack | 30 days after it is sent; a message that failed or never went is cleared 30 days after it was queued. The message itself lives in the customer's Slack |
| Automated-decision audit records | 7 years (hashes, not résumé text) |
| Recruiter account | While active; deleted 90 days after the recruiter asks, unless they cancel first |
| Public records | Until the next load of the same file replaces them; a register entry marked do-not-show stays hidden through every reload |
Retention windows are enforced by an automated sweep, not by policy alone. The sweep runs every few minutes and does a small, capped amount of work each time, so a window is reached within days of its date, not to the minute. A verified deletion request overrides all of the above except records we are legally required to keep.
What anonymised means. When a candidate's window passes, their identity leaves the role's records: the name becomes "Anonymised candidate"; the email, phone, profile address, résumé text, notes, the search snippet and headline, the card a search showed, interview notes and the body of messages sent about the role are cleared; a profile address used as a key is replaced by a random code that cannot be traced back to them; and the desk's person record for them, with its keys, is deleted. What stays is what the desk's own numbers are made of: the role, the stage each person reached, the dates, the scores, the skills matched, the verdicts and the reasons recorded for decisions. The automated-decision receipts and the log of stage changes are append-only and are never rewritten; they hold hashes and stages, not a résumé.
Who is kept for longer, and why. A candidate is anonymised only when nothing else on the same recruiter's desk still holds them. They are kept while they are on another role that is open or closed less than 2 years ago, while a placement of theirs is less than 7 years old, while a search found them in the last 2 years, while they are in the desk's pipeline for another role, or while they are on the desk's own People list; when that reason lapses, the next sweep anonymises them. If any of this cannot be read, the candidate is kept and looked at again later; the sweep never anonymises on a guess. Two things are outside these windows: a message a recruiter sent that was not about a role stays with the recruiter who sent it, and the rows of a search never saved as a role stay while the desk does. A candidate can ask for deletion at any time, which reaches all of it.
Deleting a recruiter account. A recruiter asks on Settings, signed in; an API key can never ask. Asking signs the account out everywhere, revokes its API keys and holds everything waiting to be sent, and until the date nothing is searched, spent or sent in its name. Signing in again within the 90 days lets them cancel: queued emails and follow-ups come back as drafts to approve, and scheduled sends are cancelled. On the date, what is deleted depends on whose the desk is. In a workspace with other working members, the desk's roles, people and notes belong to the company and stay with it as the recruiter's former desk, labelled with their name; what is deleted is the recruiter's own account: the login and address, the sessions and keys, the mailbox and calendar connections, and their own profile (signature, pitch, booking page and settings). Anywhere else the desk is the recruiter's own, and every record the account holds is deleted with it. On both paths, the automated-decision receipts, the log of stage changes, the audit log of account actions and the do-not-contact list are kept, because they are records we are required to keep or protections people asked for; they name the account only by an internal id. Our basis for keeping them is that Article 12 of the EU AI Act asks a high-risk system to keep logs of its decisions, and that an opt-out has to hold for good; check with counsel on how long your own obligations run.
Depending on where you live you may have the right to access, correct, delete, port, restrict or object to processing, and to withdraw consent. California residents additionally have rights to know, delete, correct, and to opt out of sale or sharing — we do not sell or share personal data, and we honour Delete Act (SB 362) style requests. You will not be discriminated against for exercising any right.
Use sourcingnav.com/privacy-request, or email hello@sourcingnav.com. We verify by email before acting. If you are in the EEA or UK you may also complain to your local supervisory authority.
Access requires authentication; API keys are stored hashed and are read-limited by default; outbound links and webhooks are signature-verified; opt-outs are enforced before every send and every contact lookup. No system is perfectly secure, and we do not claim otherwise. What is in place, and what is not yet, is on the security page.
The Service is not directed to anyone under 16 and we do not knowingly process their data.
We will post changes here with a new effective date and, for material changes affecting account holders, notify by email.