SourcingNavCompliance

NYC Local Law 144 and the EU AI Act: what SourcingNav does, and what it does not

Read from the code on 16 October 2026 · Not legal advice

SourcingNav ranks people against a role and explains every rank; a person decides what happens next. This page sets out where that puts the product under New York City's Local Law 144 and the EU AI Act, what in the product backs each point, and, plainly, what is not done. It describes the software. It is not legal advice and not a certification, and it does not make anyone's use of SourcingNav lawful.

The short version. The engine scores, orders and explains; it never rejects, advances or contacts anyone on its own. Every decision it touches writes a receipt to an append-only chain. A bias report reads only what applicants chose to tell us. A synthetic trial kit lets a buyer test any tool without real candidates. The independent bias audit New York City requires has not been done, and the EU AI Act's conformity steps have not been taken.

Where the engine sits

What it does

Reads a role's requirements, then scores and orders the people a search finds or who apply.
Shows on every row three lights (title, must-have, place: yes, no or unknown, each with its reason) and the evidence a score rested on.
Can hold a row back from the list with a sentence saying why (another field, a different level, out of reach). The row is counted and the reason is shown; nobody is told no.

What it never does on its own

It does not reject anyone. A pass is a person's decision, and it cannot be recorded without a reason, which is written back as a sentence a reader a month later can follow.
It does not advance anyone. An automated agent can move a person to prospect or contacted and never further; every later stage is a person's move.
It does not contact anyone. Outreach is drafted for a recruiter to approve, and a message goes out only when a recruiter sends it or schedules it. The gated-autonomy setting proposes messages for one-tap approval and never sends on its own.
It does not read protected characteristics. They are not inputs to scoring and are not inferred. The criteria a recruiter types are checked for protected-attribute words, and a hit is flagged on the receipt for a reviewer to see rather than silently dropped.

The receipt says which was which

For every decision the engine made, the receipt's screening.human_reviewer is empty and human_review_required is true. A decision a person made names that person. Filling the reviewer from the account holder would claim a review that never happened, so the code never does.

New York City Local Law 144

What the law covers

Local Law 144 of 2021 regulates automated employment decision tools (AEDTs) used to screen candidates for employment, or employees for promotion, in New York City. It defines an AEDT as a computational process, derived from machine learning, statistical modelling, data analytics or artificial intelligence, that issues a simplified output such as a score, a classification or a recommendation, and is used to substantially assist or replace discretionary decision-making. Its duties fall on the employer or employment agency that uses the tool:

a bias audit by an independent auditor no more than a year before the tool is used, and a public summary of its results;
notice to candidates who live in the City at least ten business days before the tool is used: that it will be used, which qualifications and characteristics it assesses, and how to request an alternative selection process or an accommodation;
information about the data the tool uses, its source and how long it is kept.

Where SourcingNav sits

SourcingNav issues scores and an order, so it can be the kind of tool the law describes. Whether a given use is covered turns on how much a team relies on that output: the City's rules read "substantially assist or replace" as relying on the output alone, weighting it more than any other criterion, or using it to overrule other conclusions, a person's included. A team that sorts or screens New York City candidates on SourcingNav's scores should plan as though the law applies, and make that call with its counsel.

What SourcingNav gives a team toward it

The bias report (below): selection rates and impact ratios by sex, race / ethnicity and their intersection, the categories the law's audits report, at every step of the applicant funnel and for the engine's own match call. These are the numbers an independent auditor starts from.
The receipts chain (below): a dated record of each time the engine scored, ranked or held someone back, with the criteria and the version that produced it, which is what an audit samples.
A notice on SourcingNav's own application page (quoted below).
The vendor trial kit (below), for testing a tool, SourcingNav included, without handing anyone real candidates.

Not done.

No independent bias audit of SourcingNav has been published, and SourcingNav publishes no audit summary. The audit the law requires is an independent auditor's, not ours, and it is the employer's to obtain.
SourcingNav does not send the advance notice. The notice on its application page is shown at the moment of applying; it is not the ten-business-day notice.
A person found by a search, rather than one who applied, is not told by SourcingNav that a tool ranked them.
There is no way inside SourcingNav for a candidate to request an alternative selection process; that request goes to the employer or the recruiter.
The bias report reads only applicants who answered the voluntary survey. People found by search never see it, so the report cannot measure the engine's effect on them.
The report reads the engine's call as a yes at a fixed score of 60. The City's rules measure a scoring tool by the share of each group scoring above the median; an auditor would compute that from the scores, which SourcingNav keeps.

Check with counsel before relying on any of this for a New York City role.

The receipts chain

Every decision that affects a candidate writes a receipt the moment it happens. These are the kinds that do:

Kind	The decision
`candidate_scored`	An evaluation produced a fit score.
`candidate_ranked`	Results were put in an order for a person to read.
`candidate_filtered`	Someone was held back from a result set.
`candidate_rejected`	A person passed on someone, with the reason.
`outreach_drafted`	A message was written about a named person.
`search_criteria`	A search's criteria were set, where implicit filtering would hide.
`contact_info_requested`	A paid lookup of a named person's contact details was made.
`profile_captured`	A named person's full profile text was stored.
`offer_decided`	An offer was extended, accepted, declined, rescinded or started.
`source_probed`	A public data source's front door was tested before anything was taken from it.

What a receipt holds

The kind of decision and when it happened (the decision's own time, not the delivery time).
The criteria text, up to 2,000 characters, and a reference to the person or role it concerns.
The decision's inputs and outputs: for a score, what matched, what did not and the evidence it rested on. A rule decision names the scorer's version, which is a fingerprint of the scoring code itself; a model's decision names the prompt's hash and the model that answered.
Any protected-attribute words found in the criteria, as flags.
human_reviewer and human_review_required, as above, and the four standing commitments (no protected-attribute inference, no autonomous rejection, a human before contact, explainable on request).

How it is kept

Each receipt is one row in an outbox, keyed by an event id written once, so a retry is recognised instead of appended. Because that write is safe to repeat, it is retried when the database connection drops mid-write.
A scheduled job delivers the outbox in order, one batch at a time, every five minutes, to the AIR Blackbox receipt server, which keeps the chain and answers with a receipt id and a chain hash. Both are stored beside the row. A delivery that fails stays pending and is retried in order; only a receipt the server rejects as malformed six times stops being sent.
The chain is append-only. A delivered receipt is never edited, so an improvement to what receipts carry shows as a boundary between two eras rather than a rewrite.
Separately, sensitive actions write to an audit table whose rows are chained by HMAC-SHA256 over each event's sequence number, the SHA-256 hashes of its inputs and outputs, and the previous link. It stores the hashes, not the payload, and changing any row breaks the chain from that point on.
Settings shows a desk its own receipts with their receipt ids and chain hashes. Every desk's receipts go to one chain, so the evidence bundle the chain server produces spans every desk on SourcingNav, and only SourcingNav's operator can download it; a team, its workspace admin included, cannot download a bundle of its own yet. Those bundles hold real candidates; demonstrations use fabricated ones.

The bias report

On the Measure page, the bias report (/api/desk/fairness) asks one question: does any group pass a step at well under another group's rate?

Self-identification only. It reads nothing but the answers applicants chose to give on the voluntary survey, stored apart from the application. Nobody's sex, race or anything else is guessed from a name, a photo or a school. The survey answers are read by the form, by erasure and by this report, never by anything that scores.
Every step. Selection rates by group at each step of the applicant funnel (applied, advanced, interviewed, offered, hired), applied to hired end to end, and the engine's own match call on the same applicants.
The four-fifths rule. A group whose rate is under 80% of the highest group's rate at the same step is flagged. It is a screen, not a verdict.
Small numbers are hidden. A group with fewer than 5 people at a step is shown as "fewer than 5", is given no rate and is never the yardstick.
Honest counting. Declining to answer is not a group, and someone still waiting on a decision is not a no.
Nobody in particular. No name, email, application or answer for any one person leaves the endpoint, and a desk sees its own applicants only.

The report is where an audit starts, not the audit. Local Law 144 requires an independent auditor, and the report says so on the page.

Candidate notice and opt-out

SourcingNav's own application page tells every applicant, beside the form:

Notice of automated assessment: applications submitted here are screened with the help of an automated assessment tool that compares your experience to this role's stated requirements. A human recruiter reviews the results and makes every decision. Screening records are kept in an audit trail.

The self-identification survey on that page is optional, and declining is always an answer.
Every outreach email sent from the desk says it came via SourcingNav and carries an unsubscribe link. Mail sent through a connected Outlook mailbox also carries the one-click unsubscribe header mail apps act on.
Anyone can stop contact, get a copy of their data, or have it deleted at sourcingnav.com/privacy-request. The request is verified by email to the address itself. The opt-out takes effect at once, a deletion is carried out end to end by a daily job, and an access request is logged with its 30-day deadline.
The opt-out list is checked before a person is researched, added to a pipeline, looked up for contact details, or sent anything.
A candidate can ask for the reasoning behind a decision that affected them (privacy policy, section 4).

The vendor trial kit

On the Measure page, a team evaluating any AI recruiting tool can download a trial kit instead of handing a vendor real candidates (api/_synthetic.py).

Nobody in it is real. It is generated from a seed and a date, never from a table. Every email address is on example.com, every phone number is 555-0100 to 555-0199, every street is invented, and every résumé and job description is marked synthetic. The same inputs make the same bytes.
Two halves that never travel together. The vendor's half holds roles and candidates. The half HR keeps holds the answer key: how well each candidate truly fits each role and why, the traps planted in the pool, and the fairness twins.
Traps and twins. Keyword stuffers, recruiters who name the skills they hire for, a company wearing a skill's acronym, students on senior roles, the right title with every must-have last used in a job that ended eight years ago. Twins are identical résumés that differ in one thing (a name's origin or sex, a career break, the school) and should score alike.
A grader. It reports precision at 10, NDCG at 10, strong fits found, traps let through, twins split, and the four-fifths reading of the vendor's picks beside the answer key's own.
SourcingNav takes its own test. Before every change is merged, the same kit grades SourcingNav's scorer, and the scores may not fall.

Data boundaries

No employer-system imports. SourcingNav does not connect to another applicant tracking system or an employer's HR system, and imports no candidate lists from one. The one exception is a customer's own export: a team switching to SourcingNav may upload the file it exported from the system it is leaving, on its word that the data is its own, and anyone who opted out is dropped from it.
No scraping LinkedIn. Nothing in SourcingNav crawls LinkedIn, logs in to it or walks its pages, and LinkedIn Recruiter is never read. The browser extension reads only what is already on the recruiter's screen when they click, and changes nothing on LinkedIn's page. Otherwise a profile reaches the desk as a public search result, or from one of the indexes on the subprocessor list.
No contact lists bought. A contact detail is looked up one person at a time, on a recruiter's click, after the opt-out list is checked, and each paid lookup is receipted.
Never pooled. One workspace's people are never shown to another, and what the engine learns from a desk's likes and passes stays with that desk.

The EU AI Act

The Act lists AI systems intended for the recruitment or selection of people (placing targeted job adverts, analysing and filtering applications, evaluating candidates) as high-risk, in Annex III, point 4. SourcingNav's own privacy policy treats it as one. The Act gives most duties to the provider who builds and places the system on the market, which for SourcingNav is SourcingNav, and others to the deployer who uses it, which is the recruiting team. This table maps the main duties to what exists.

Duty (article)	Whose	What exists in SourcingNav	Not done
Risk management (9)	Provider	A written risk assessment with mitigations; every failure found becomes a test that keeps it fixed, run on every change.	Not a formal risk management system kept against a standard.
Data governance (10)	Provider	A written data governance document; a versioned vocabulary stamped on receipts; the scorer graded on synthetic people with fairness twins; protected characteristics never an input; self-identification kept apart.	No formal examination of the recruiter verdicts the engine learns from for bias, beyond the benches.
Technical documentation (11, Annex IV)	Provider	Every score traceable to the scoring code's fingerprint or to a prompt hash and model.	No Annex IV technical file has been compiled.
Record-keeping (12); keeping the logs (26)	Provider builds, deployer keeps	The receipts chain and the HMAC audit table above.	How long a deployer must keep logs is the deployer's to set; SourcingNav's retention windows are in its privacy policy.
Transparency to deployers (13)	Provider	Each row's lights, evidence and reasons; this page.	No formal instructions for use with declared accuracy figures.
Human oversight (14, 26)	Provider designs, deployer assigns	The engine proposes and a person decides; agents stop at `contacted`; passes need a reason; receipts say which decisions a person made.	Who on a team oversees the system, and their training, is the deployer's to arrange.
Accuracy, robustness, cybersecurity (15)	Provider	Ranking quality ratcheted per role family on every change; the security page.	No independent testing.
Quality management (17)	Provider	A test gate on every change, and a merge only after it passes.	No documented quality management system.
Conformity assessment, declaration, CE marking, registration (43, 47, 48, 49)	Provider	None.	None of these has been done.
Post-market monitoring, serious incidents (72, 73)	Provider	Operator alerts on errors and on any receipt that could not be queued.	No monitoring plan or incident-reporting procedure under the Act.
Authorised representative (22)	Provider outside the EU	None.	No EU representative is named on this site.
Telling people they are subject to the system (26)	Deployer	The notice on SourcingNav's application page.	People found by search are not told by SourcingNav before a recruiter contacts them.

The Act's dates for these duties have been the subject of proposed changes. Which ones apply to a team, and when, depends on its role and its use.

Check with counsel before relying on any of this for a role in the EU.

What this page is not

It is not a certification, an audit, a conformity assessment or legal advice. It describes what the software does today, read from its code, and it changes when the code does. Who the third parties are is on the subprocessor list; how data is protected is on the security page. Questions: hello@sourcingnav.com.