Public Candidate Data Is Not a Blank Check for AI Matching

Public candidate data can support AI matching when the use matches the context in which people shared it. But public access is not unlimited permission. A responsible system discloses the profiles it derives, preserves the source and purpose, copies only what it needs, lets candidates correct or remove data, explains what a score cannot prove, and keeps consequential decisions under meaningful human review.

That distinction became unusually concrete this week. A Show HN project called HN Match Maker turned Hacker News’s monthly hiring threads into a searchable, ranked marketplace. The build is clever. It is also a compact case study in the product decisions every AI recruiting team now has to make.

The easy reactions, “it was public, so anything goes” and “there was no opt-in, so it must be illegal,” both miss the interesting part. The source posts explicitly invite work opportunities. Matching aligns with that purpose. Yet extraction, enrichment, durable republication, and ranking create a new data product about people who only wrote a comment in someone else’s forum.

The right question is not whether public data can be used. It is how to preserve the person’s original intent while adding automation.

What HN Match Maker Actually Does

Every month, Hacker News publishes two companion threads: “Who is hiring?” and “Who wants to be hired?” The candidate thread asks people to list location, remote preference, technologies, résumé, and email. It also gives readers a narrow instruction: contact those addresses only to discuss work opportunities.

HN Match Maker uses the public HN API to collect top-level comments from both threads. According to its method page, an LLM extracts skills, domain, seniority, salary range, location and remote preference, and visa needs. The system then removes pairs with hard conflicts, such as remote versus on-site, non-overlapping salary bands, or visa mismatch. It ranks the remainder.

The published formula is refreshingly specific:

At our 2 September snapshot, the site displayed 105 jobs and 130 candidates. That creates up to 13,650 possible pairs before hard filters. Individual profile pages include synthesized details, a list of ranked jobs, a factor breakdown, and a link to the original HN comment.

Those choices already make the project more transparent than an opaque “AI says 87% fit” badge. You can see the source and inspect the factors. The maker explicitly calls the score a measure of plausible fit rather than a hiring decision and warns that automated extraction can misread terse posts.

But arithmetic transparency is not the same as validated matching. One public example reproduced the formula to about 44 out of 100. That shows that the calculation is inspectable. It does not tell us whether 44 is useful, whether a better candidate scored lower, whether missing fields systematically help or hurt, or whether anyone has measured hiring outcomes.

The Strongest Case for Using the Posts

The best argument for this kind of matching is not that “the internet is public.” It is that the original context was recruitment.

People in “Who wants to be hired?” volunteered professional information so employers could find them. The thread asks readers to contact them about work. A tool that makes relevant job opportunities easier to discover is much closer to the stated purpose than a data broker using the same comments to build credit profiles or advertising audiences.

This context matters under both product ethics and data protection analysis. Under the GDPR, consent is not the only possible lawful basis. A controller may sometimes rely on legitimate interests after documenting the interest, why the processing is necessary, and why the person’s rights do not outweigh it. Public availability and reasonable expectations both factor into that assessment.

So an article that says “AI matching always requires consent” would be comforting, simple, and wrong.

The better rule is: preserve the boundary the person chose. A public job-seeking post supports recruitment discovery. It does not automatically support unrelated enrichment, permanent retention, sensitive inference, resale, or an automated rejection. Even within recruiting, changing a comment into a durable profile with inferred seniority and ranked recommendations changes the accessibility and meaning of the data.

That is where a product needs more than a source link.

Where Public Discovery Becomes Silent Profiling

There are five separate operations hiding inside the phrase “AI matching”:

1. Collection: importing a public comment or résumé.
2. Enrichment: turning free text into structured or inferred attributes.
3. Retrieval: helping a recruiter find relevant records.
4. Recommendation: ordering people by a predicted fit.
5. Action: contacting, shortlisting, or rejecting someone.

Each step increases the impact on the person. Each needs its own controls.

A source-aware system records where a profile came from, when it was collected, and what purpose governed the source. An enrichment system distinguishes copied facts from model inferences. A retrieval system shows the evidence that caused a result to appear. A recommendation system documents weights, missing-data behavior, limits, and validation. An action system assigns a named person responsibility for what happens next.

Collapsing all five into one “public data” permission is how a useful sourcing feature quietly becomes a shadow candidate database.

The UK’s Information Commissioner’s Office found exactly this pattern in its audits of recruitment AI providers. Its November 2024 summary says some tools collected much more information than necessary and retained it indefinitely to build large candidate databases without candidates’ knowledge. The regulator issued almost 300 recommendations, all accepted or partially accepted.

The ICO’s practical questions are useful even outside the UK: What is the purpose? What is the lawful basis? Who is controller and processor? What information is genuinely necessary? How will candidates learn what the tool does, correct errors, and challenge an automated outcome? How long will the record live?

None of that proves that HN Match Maker broke a law. Its operator, location, private processes, and full technical architecture are not public. It does show why a visible privacy notice, retention policy, and correction or removal route belong in the product, not in a future legal backlog.

A Score Breakdown Is Not Validation

Explainability has at least three layers, and recruiting products often ship only the first.

Calculation: Can a user reproduce the score from the displayed factors? HN Match Maker does reasonably well here.

Interpretation: Does the user know what the score means? A 44 might be weak, typical, or excellent depending on the distribution and threshold. Without calibration, it is just a number dressed up with decimal confidence.

Validity: Does the score improve the outcome it claims to support? That requires testing against relevant judgments or outcomes, monitoring error patterns, and checking whether performance differs across groups and job types.

A fixed weighting also embeds product judgments. Why should skill overlap count twice as much as seniority? How are “Ruby,” “Rails,” and “Hotwire” normalized? Does a missing salary range get a neutral value, a penalty, or uncertainty? Is “domain fit” based on explicit experience or an LLM’s guess? A transparent formula makes these questions visible; it does not answer them.

NIST’s AI Risk Management Framework offers a useful operating model: govern, map, measure, and manage. It is voluntary guidance, not hiring law. Its value lies in its lifecycle approach. Teams document intended use, measure performance and impacts, collect feedback from affected people, monitor production behavior, and define how humans can override or stop the system.

For a candidate matcher, useful measures include:

• Extraction error rates by field and source format
• The share of matches recruiters dismiss immediately
• Candidate correction, removal, and complaint rates
• Override rates and reasons
• Conversion from suggested match to mutual conversation
• Outcome differences across roles, locations, seniority levels, and relevant groups
• Stale-profile and failed-contact rates

If you cannot describe what would make you lower a model’s influence or switch it off, you do not have oversight. You have faith with a dashboard.

Seven Controls for Context-Aware Candidate Matching

The controls below separate a useful matching product from an unaccountable people index.

1. Store purpose with provenance

Keep the source URL, collection date, source type, and stated purpose beside the record. “Public web” is too broad a source category to govern later use. A post inviting employment contact and a conference attendee list may both be public while supporting very different expectations.

2. Notify before the profile becomes consequential

Tell candidates that their data was collected, what was copied, what was inferred, why it is being processed, who can see it, and how long it will stay. Where indirect-collection notice law applies, this may be a duty. Elsewhere, it remains a product choice that builds trust.

For a small directory with reachable profile links, “notice is impossible” should not be the default design assumption.

3. Minimize republication

A matcher usually does not need to republish an entire résumé, personal email, or raw post to prove relevance. Show recruiters the smallest useful evidence and send them to the original source where appropriate. Do not infer protected or sensitive characteristics simply because a model can.

4. Separate facts, inferences, and missing values

Label “stated by candidate,” “extracted from source,” and “model-inferred” differently. Show when salary, seniority, or location is missing instead of quietly manufacturing certainty. Give the candidate and recruiter a way to correct the record.

5. Start the retention clock at collection

Candidate data should expire. A monthly hiring post comes with an obvious clock: the source itself is time-bound. Refresh only when there is a new signal or an explicit renewal, not whenever a crawler happens to revisit the page.

6. Make suppression and deletion easy

Offer a clear correction, opt-out, suppression, and deletion route from the profile itself. Erasure is not absolute in every jurisdiction, but forcing a person to reverse-engineer the operator’s identity is poor product design regardless of the legal minimum.

7. Keep matching separate from decisions and messages

A match score should surface evidence, not serve as an automatic rejection gate. A recruiter should choose whom to review and why. Contact should require a separate approval bound to the exact recipient and message. That boundary limits the harm from a bad extraction or a poorly calibrated score.

What This Looks Like in Kit—and Where Kit Still Has Work

Kit deliberately separates talent-pool consent, search, retention, and outreach approval.

Candidates who join a public Kit talent pool accept a rendered consent statement and verify their email. Their records then follow a configurable retention period, set to 24 months by default. Before expiry, the system can warn and request renewal; records with declined or expired consent are anonymized. Recruiters can use resume extraction and search across verified entries, but the search returns evidence rather than a role-fit score. It does not claim that cosine similarity predicts who should be hired.

When a recruiter moves from discovery to contact, Kit treats that as another decision. Outreach approval is tied to the exact recipient, sender, subject, body, version, approver, and approval time. Change the message and the approval no longer matches. The same principle applies: search can suggest; a person owns the action. See Candidate Privacy & Consent and Reviewing and Sending Messages for the current workflow.

There is also a real gap. Kit’s bulk CV import records provenance and requires the importing employer to attest that it has a lawful basis and will notify candidates. But imported talent-pool records are currently unverified and have no recorded consent. They do not enter ordinary verified search and do not appear to join the same consent-expiration sweep automatically. Kit does not offer a general candidate self-service account for deleting a talent-pool record, either.

Those limits are worth stating plainly. An attestation is not consent, and recording provenance is not the same as completing the lifecycle. The next product step is to bring imported records into a notice, verification, renewal, and deletion flow that preserves source context, without pretending that every jurisdiction or source has the same rule.

That is a more honest position than putting a “responsible AI” label on a hidden score.

Matching Is Discovery, Not Adjudication

HN Match Maker is useful because it sits on the boundary. The source data was public. The candidates invited work opportunities. The project exposes its formula and links to original evidence. Those are meaningful points in its favor.

The unresolved questions begin where the new product layer begins: Was the person told about the synthesized profile? Can they fix or remove it? What expires? Which fields are inferred? What does the score predict? How is it tested? Who is accountable when a recruiter treats ranking as judgment?

The answer is not to ban matching or demand a consent modal for every link. It is to design the system so context survives automation.

Keep provenance attached. Minimize what you copy. Show uncertainty. Let people correct the record. Expire stale data. Measure outcomes and overrides. Require a human to own the shortlist, rejection, and message.

Public intent can justify discovery. It is not a blank check for a permanent profile or an invisible decision.

If you want a talent pool where consent, verified search, retention, and outreach approval are separate controls, start a free Kit trial. The product does not cover every edge case. That is exactly why the controls and gaps should stay visible.