Public-work check
Check Inbound Engineer Claims Against Public Work (Code, Papers, Reports, Awards)
How do mission-driven hardtech hiring teams verify — or question — claims from people already in their pipeline against public work of every kind, without treating a thin public trace as automatic fraud, and without spending an hour on a call first?
This guide is about running inbound people against the same public-work index DevMatch uses for shortlists. It is not a resume lie-detector pitch and not a placement-only pitch. Unique mission fit from NASA reports, published papers, SBIR awards and code. Every signal traces to a real source, never a resume.
Why inbound claim-checks break on resumes and green squares
Hardtech claims often cite NASA or program reports, papers, SBIR/STTR awards, or repositories — not just skill keywords. Self-report alone is thin. Contribution graphs and star counts are easy to misread. Authorship, signed commits, merged work, and source-linked reports matter more than activity cosmetics.
Manual GitHub archaeology — opening commits, checking author/committer, reading diffs, following pull requests — is real work. It still misses papers, technical reports, and awarded contracts.
What this page is not
Not a background-check or FCRA product. Not a clearance adjudicator. Not a promise that every good engineer has a loud public footprint.
What “check against public work” means
The same index runs against people already in your pipeline. Claims get checked against public work of every kind. Code, papers, technical reports, awarded contracts. Thin signal surfaces before anyone spends an hour on a call.
A claim with no public trace is not a rejection. It is a question worth asking.
The same index philosophy as a unique-fit shortlist: 35M+ engineers, including 10M+ researchers. Robotics, materials, defense, software. Unique mission fit from NASA reports, published papers, SBIR awards and code. Every signal traces to a real source, never a resume.
Claim-check vs unique-fit shortlist
Claim-check evaluates inbound named people against the index. A shortlist finds names from a job description. Same evidence philosophy; different job. If the pile is thin, paste a job description and run a unique-fit shortlist.
How to prepare an inbound check
Collect what the person actually claimed — role titles, repos, papers, programs, awards — not a vague “strong GitHub.” Prefer handles, DOIs, report IDs, or award identifiers when you have them.
Decide what “good enough public trace” means for this role. Flight software, pure research, and a defense award PI leave different footprints. DevMatch does not publish a scoring threshold for claim-check; do not invent one.
Keep classified and other non-public work in mind. Absence of a public trace can be expected. Treat it as a question, not a reject.
Reading a verify-style report
The homepage public-work check can show contribution-history framing, stack and domains, and fraud-screen style checks as a report format. Scoring, contribution graph, and hash on the homepage example are an illustrative example of the report format, not a live measurement.
Every useful signal should link back to a source when the product attaches one — the same “evidence attached” idea as a shortlist. This page describes claim-check in homepage language. Live inputs, outputs, and any separate verify host are not documented as a first-party product path here.
Try the homepage public-work check. Credit cost for claim-check is not listed on pricing; we do not invent one.
When claim-check leads to a shortlist (or Placement)
Thin inbound pipeline? Run a unique-fit shortlist from a job description against the same index.
Send a job description
Paste a job description or posting link in chat. One JD is enough to start — no separate sourcing brief required.
We run it against the index
Engineers and researchers found through published work, technical reports, awarded contracts and code. Not through keywords lifted from a resume.
You get a shortlist that fits
Every name arrives with evidence attached and a link back to the source behind each signal.
Platform: monthly credits for unique-fit shortlists (chat, MCP, Slack /devmatch). Reveal is free on a shortlist you already paid for. Connect email to outreach yourself.
Placement: for urgent roles, DevMatch sources, shortlists, and runs outreach. A card is required at submit ($0 today). Fee only when a hire from the shortlist is confirmed — $10,000 under a $200k base midpoint, $15,000 at $200k and above. Never stack Platform and Placement on the same hire.
See Platform vs Placement for the decision frame. Plan ceilings and the credit meter stay on pricing. Neither path is claimed to convert better than the other.
What other methods answer this search
Observed answers today are manual GitHub how-tos, GitHub-versus-resume scoring demos, CLI contribution audits, and generic resume-fraud advice. Most of that is GitHub-centric. Few pages teach a multi-corpus inbound check — reports, papers, awards, and code — on the same index used for shortlists.
The contrast is method and corpus, not invented accuracy. No public trace remains a question, not an automatic rejection.
Questions
Questions hiring teams ask
How do you verify engineer resume claims using public work?
Collect the specific claims — titles, repos, papers, programs, awards — and check them against public work of every kind: code, papers, technical reports, and awarded contracts. DevMatch runs the same index used for unique-fit shortlists against people already in your pipeline. Thin signal surfaces before anyone spends an hour on a call.
What kinds of public work can a claim-check use beyond GitHub?
The homepage method is public work of every kind: code, papers, technical reports, and awarded contracts. NASA reports, published papers, and SBIR awards sit in the same index philosophy as repositories. A contribution graph or star count is not authorship by itself.
What does it mean if an inbound candidate’s claim has no public trace?
A claim with no public trace is not a rejection. It is a question worth asking. Classified or non-public work can leave a quiet public footprint. Absence of a trace is a prompt for a better question, not automatic fraud.
How is claim-check different from running a DevMatch unique-fit shortlist?
Claim-check evaluates inbound named people against the public-work index. A unique-fit shortlist starts from a job description and finds names. Same evidence philosophy — every useful signal traces to a source — different job. If the inbound pipeline is thin, paste a JD and run a shortlist on the same index.
When should a hardtech team use DevMatch Placement instead of self-serve Platform credits?
Use Platform when you want monthly credits for unique-fit shortlists in chat, MCP, or Slack /devmatch, then reveal names and outreach yourself. Use Placement for urgent roles when you want DevMatch to source, shortlist, and outreach — card at submit, $0 today, fee only on a confirmed hire. Never stack Platform and Placement on the same hire.
What to do next
Already have people in pipeline? Check inbound claims against public work — code, papers, technical reports, awarded contracts. Thin signal surfaces before you spend an hour on a call. A claim with no public trace is not a rejection. It is a question worth asking.
Pipeline thin? Paste a job description and get a unique-fit shortlist — every name with evidence attached. Free platform credits, no card required. Need outreach done for you? Submit a Placement role — card at submit, $0 today, fee only when a hire from the shortlist is confirmed. Never stack Platform and Placement on the same hire.
Related: Unique-fit shortlist vs keyword recruiting · Hire flight software from public evidence · Hire robotics firmware from public evidence · Hire research engineers from public work · Find defense and SBIR/STTR-experienced engineers · Platform vs Placement · DevMatch MCP docs. Product overview · paste a job description.