Every AI recruiting tool now operates under laws with teeth: NYC Local Law 144 bias audits, Colorado SB 26-189, California's FEHA automated-decision rules with their four-year record-keeping floor. All of them converge on the same question a vendor eventually gets asked: "Show me what your AI decided, and prove nobody touched the record afterwards." "Trust our logs" is not an answer. This is what an answer looks like.
SourcingNav is a live sourcing and screening platform for technical recruiting. Every consequential action its AI takes - scoring a candidate, ranking a slate, a screening decision that ends a candidacy - is written, at the moment it happens, into an AIR Blackbox audit chain:
None of this changed how recruiters work. It is a server-to-server feed from the product to a private AIR instance; the ingest credential never touches the browser.
One export, covering fourteen days of live operation:
| Decisions recorded | 450 |
| Adverse (candidacy-ending) decisions | 93 |
| Adverse decisions with no named human reviewer | 0 |
| Records carrying a valid signed receipt | 450 / 450 |
| Alterations detected at verification | 0 |
The number that matters is the zero. Under every automated-decision regime, the exposure question is "did your AI end someone's candidacy with no human in the loop?" For this deployment, across 93 adverse outcomes, the answer is: it did not - and that claim is not an assertion. It is a recomputable property of a signed file.
(The deployment also logged 163 engine outputs without a reviewer - scores and rankings, which are inputs a human weighs rather than decisions. The bundle separates those counts precisely so the number that matters cannot hide inside the one that does not.)
The export is a single .air-evidence file. Anyone holding it - an auditor, a customer, a regulator - can drop it on airblackbox.ai/verify and watch six checks run in their own browser: no upload, no account, no trust in the vendor, no trust in us. The page recomputes every digest, verifies every one of the 450 receipt signatures, recomputes the compliance counts from the raw records, and says plainly what it can and cannot prove.
Try it yourself right now with a sample bundle - ten fictional candidates, including one deliberately unreviewed rejection, so you can see what a finding looks like instead of a reassuring all-green.
Because honesty is the product: a verified bundle proves the records are intact and internally consistent. It does not by itself prove who issued them (pin the signer's fingerprint for that) or that nothing was omitted (external anchoring at record time is what constrains that). The verifier says so out loud. We published our own red-team review of exactly where that line sits.
About a week of integration: point the product's decision path at AIR's /ingest endpoint, store the tenant token server-side, add a download button. The chain, signing, anchoring, counting, and the browser verifier are the open-source platform doing its job.
If you build an AI recruiting product - or any product whose AI makes consequential decisions about people - this is what your customers' lawyers are going to start asking for. We can put it in your product in about a week.
Under NYC Local Law 144, Colorado SB 26-189, and California's FEHA automated-decision rules, a vendor must be able to show what its AI decided about a candidate, who reviewed it, and that the record was not altered afterwards. An HMAC-chained, signed, externally timestamped record makes that a verifiable property of a file rather than an assertion in a policy document.
Drop the file on airblackbox.ai/verify. The page runs entirely in the browser - no upload, no account - and recomputes every digest, verifies every decision receipt signature, and recomputes the compliance counts from the raw records. The air-evidence CLI performs the same checks plus full RFC 3161 timestamp validation.
No. VERIFIED proves the bundle is intact and internally consistent since signing. Attribution requires comparing the printed signer fingerprint against one obtained from the issuer separately, or pinning it with --expect-key. The verifier states this limit explicitly rather than implying more than it checked.
AIR Blackbox is open source (Apache 2.0). The scanner, chain, verifier, and evidence format are all inspectable - which is rather the point.