# The Mined-Commit Author Verdict: Keep, Verify, or Drop

*You will score one commit-mined author record across five dimensions and assign a Keep, Verify, or Drop verdict two teammates would reproduce.*

- Canonical URL: https://www.refolk.ai/guides/mined-commit-author-verdict
- Pillar: Process, data, and compliance
- Format: Framework
- Published: 2026-09-21
- Last reviewed: 2026-09-21
- Reading time: 15 min

For each author record pulled from public commit history, you have to decide one thing before it enters the pipeline: is this a real, reachable, lawfully usable person, or is it noise, a ghost, a bot, or a liability. This guide is for recruiting and revenue operations, and for anyone answerable for how the data was gathered. It gives you a five-dimension scoring model that turns one author line into a single Keep, Verify, or Drop verdict that two teammates would grade the same way.

Other guides cover collecting a repo batch, cleaning the log into a deduplicated file, and clearing a whole batch for lawful outreach. None of them scores one record. That is the gap here: a per-record rubric that replaces scattered forum threads on noreply formats and commit spoofing with one repeatable call.

## What the verdict decides, and why one record needs its own score

The verdict decides whether a single commit-mined author line is trustworthy enough to keep, needs a second look before you trust it, or should be dropped on sight. Batch clearance answers whether you were allowed to collect the log at all. This answers whether this row is a person you can act on.

The reason one row needs its own score is that commit-mined records fail in ways that are invisible at the batch level. Two records can look identical - same name shape, same domain, same repo - and one is a live signed author while the other is an orphaned alias that stopped mapping to an account after a rename. The batch is clean; the row is worthless. You only catch that by scoring the row.

**53,136 - US software engineers in Refolk's index listing Git and GitHub skills**

Against 4,637 in Germany, an 11.5x ratio - the same rubric yields more Drops per capita in the smaller, stricter market.

The five dimensions are identity attribution, email type, currency, spoof risk, and lawful-use posture. Each one proves something specific, and each one has a way it lies. The rest of this guide defines each dimension, gives you the procedure to score them, and then spends real time on how the whole thing goes wrong.

## The email-type dimension: what each address can and cannot do

The email type sets the ceiling on what a record can ever be. Before you score anything else, classify the address, because a non-deliverable type caps deliverability at zero no matter how clean the rest of the record looks.

There are five types, and they are not close substitutes.

| Email type | Deliverable? | Attribution durable on rename? |
|---|---|---|
| Real address on account | Yes | Yes, if kept on the account |
| ID-based noreply | No | Yes |
| Name-based noreply | No | No |
| Bot `[bot]` noreply | No | Not a person |
| `noreply@github.com` (web-flow) | No | Not a person |

The two noreply forms look alike and behave differently. If an account was created after July 18, 2017, its noreply address takes the form `ID+USERNAME@users.noreply.github.com` - a numeric ID, a plus sign, then the username. If an account predates that date and enabled privacy before it, the form is `USERNAME@users.noreply.github.com` with no numeric prefix.

That numeric prefix is the tell. The ID-based form maps to contributions using the user ID, so it survives a username change. The name-based form loses its account link the moment the user renames. Two records that read the same differ entirely in durability, and the only visible difference is the number in front of the address.

> **Note:** The noreply domain is an identifier, not a mailbox
>
> Any address ending in users.noreply.github.com is non-deliverable by design. Its only value is as an attribution key, and only the ID-based form holds that key across a rename.

Bot addresses use the same noreply form with a bracketed name, such as `49699333+dependabot[bot]@users.noreply.github.com`. Web-UI edits are committed by `GitHub <noreply@github.com>`, which is the committer, not the human author. Both are non-persons that will slip through if you match on shape alone.

## The identity dimension: attribution is a lookup, and it lies

Attribution on GitHub is a lookup against unauthenticated metadata, so a profile photo next to a commit is not evidence that the named person wrote it. Understand this mechanism before you trust any record, because it is the root of the single most dangerous failure mode.

Each Git commit carries an email set locally with `git config user.email`. GitHub attributes the commit to whichever account currently has that email on file. The server implicitly trusts the email metadata in the commit log, looks it up against current users, and displays that user as the author. There is no commit-level identity authentication in that path.

The consequence is that a plausible email proves nothing. By default, git and therefore GitHub do not validate the author of a commit, so anyone with write access to a repository can push code under any valid repo user's email address. The record will show the impersonated person's name and avatar. Email plausibility is not identity proof.

> A profile photo next to a commit is a lookup result, not a witness statement.
> </pull>
>
> The one checkable identity signal is a cryptographic signature. Commits are marked Verified when signed with a GPG, SSH, or S/MIME key that GitHub could verify; if the signature cannot be verified they show Unverified; unsigned commits show no status at all.
>
> | Status | Meaning | Trust for identity |
> |---|---|---|
> | Verified | Cryptographically valid GPG, SSH, or S/MIME | High |
> | Unverified | Signature present, cannot verify | Low |
> | No status | Commit not signed | None, spoofable |
>
> Verified status is durable. When a signature is verified on push, a verification record is stored alongside the commit. That record cannot be edited and persists even if the signing key is later rotated, revoked, or the contributor leaves. It also surfaces a `verified_at` field through the REST API, so you can check it programmatically at batch scale.

figure
kind: flow
title: How a commit becomes an attributed author
caption: Attribution is a metadata lookup with no author authentication, which is why signature status is the only trustworthy checkpoint.
step: Commit carries email :: git config user.email is written into the commit, locally and unauthenticated
step: GitHub looks it up :: the server matches that email against current accounts
step: Author is displayed :: the matched account's name and avatar are shown, trusted implicitly
step: Signature is the gate :: only a Verified GPG/SSH/S/MIME signature proves the named person made the commit
```

## The lawful-use dimension: the policy names your use case

Lawful-use posture is a hard gate, not a nicety, because the GitHub Acceptable Use Policy names recruiters, headhunters, and job boards by role. Score it before Keep, because a technically perfect record can still fail here.

The load-bearing rule sits in the Acceptable Use Policies, not the Privacy Statement. It states that you may not use information from the Service, whether scraped, collected through the API, or obtained otherwise, for spamming purposes, including sending unsolicited emails to users or selling personal information, such as to recruiters, headhunters, and job boards. If your intended outreach is exactly that, the record fails regardless of its identity score.

The policy also sets purpose-limitation: if you collect personal information from the Service, you agree to use it only for the purpose the user authorized, to reasonably secure it, and to respond promptly to complaints, removal requests, and do-not-contact requests. That is an operating requirement, not a checkbox.

Jurisdiction sharpens the gate. The private-email setting hides the address from the public profile but does not affect its visibility in commits to public repositories. A data protection authority has scrutinized recruiting researchers via public commit emails and found that users did not expect such contact. The people most likely to complain are precisely the ones you can still harvest, which is the mechanism behind that finding.

> **Watch out:** Private is not unreachable, and that is the trap
>
> The profile toggle never touches commit metadata. A real deliverable address can still sit in the .patch file of someone who believes they are private, so weigh the expectation finding before you contact them.

Market skew concentrates this risk. In Refolk's index, US and Germany GitHub-skilled engineers split roughly 92 to 8 percent, an 11.5x ratio in favor of the US. Germany's smaller pool sits under a stricter data-protection regime, so the same rubric produces more Drops per capita there. Treat jurisdiction as a modifier on every record, not a batch-level footnote.

| Country | Matching people | Share of the two-market pool |
|---|---|---|
| United States | 53,136 | 92.0% (derived) |
| Germany | 4,637 | 8.0% (derived) |
| US-to-Germany ratio | 11.5x (derived) | - |

Refolk's index counts are exact; the shares and ratio are derived from those counts. A US seniority split was attempted but the filter returned inconsistent values, so it is excluded rather than reported unreliably.

If you would rather start from people who already clear the identity and deliverability bars instead of grading raw commit lines one by one, [Refolk](/) lets you ask for them in plain English and returns the records to score.

I ran this search: `Rust maintainers in Berlin whose recent public commits use a real deliverable email, not a noreply address` - [see the full result list](https://www.refolk.ai/s/ensehgfzv8).

*Returns maintainers with current deliverable addresses in a stricter jurisdiction, so you can apply the lawful-use gate before you spend scoring time.*

## Scoring one record: the seven-step procedure

Run every record through the same seven steps in the same order. The order matters: extraction is the primary pull, and email-type classification follows it, because the peer-reviewed and vendor sources treat commit metadata as the source of truth rather than starting from a profile.

#### From raw author line to verdict

1. **Pull the raw author line** - Extract name, email, and commit hash from public history, reading the second line of the commit .patch file where the author and their email appear. Done when name, email, hash, and repo are captured.
2. **Classify the email type** - Sort the address into real deliverable, ID-based noreply, name-based noreply, bot, or web-flow committer. Done when the record carries exactly one type tag.
3. **Score identity attribution** - Check whether the address resolves to a live account and whether the commit shows a Verified signature. Done when the record reads Verified, attributed, or orphan.
4. **Score spoof risk** - Flag whether the commit is signed. An unsigned commit under a generic deliverable email is spoofable, since write access lets anyone push under any repo user. Done when a signed-versus-unsigned flag is set.
5. **Score currency** - Compare the commit date to now and check whether the author still uses the address in recent cross-repo activity. Done when a last-seen date is attached and bounce risk is noted.
6. **Score lawful-use posture** - Apply the AUP purpose-limitation test and the record's jurisdiction. If the intended outreach is unsolicited recruiting email, that is what the policy names. Done when a use-basis note is recorded.
7. **Assign the verdict** - Combine the five sub-scores into a single Keep, Verify, or Drop. Done when the verdict is one two teammates would independently reproduce.

The verdict itself follows a small number of rules rather than a weighted average, so it stays reproducible.

- **Drop** if the email type is bot or web-flow, if it is a name-based noreply orphan that no longer maps to an account, or if the lawful-use gate fails.
- **Verify** if the address is a real deliverable one but the commit is unsigned, or if the commit is old enough that the address may bounce, or if identity is attributed but not Verified.
- **Keep** only when the address is deliverable and current, the commit is Verified, and the lawful-use posture is cleared.

**Per-record scoring line**

```
name | email | hash | repo
email_type: real | id-noreply | name-noreply | bot | web-flow
identity: verified | attributed | orphan
spoof_flag: signed | unsigned
last_seen: YYYY-MM-DD | bounce-risk
lawful_use: cleared | jurisdiction-flag | fails-aup
verdict: KEEP | VERIFY | DROP
reason: <one line naming the deciding sub-score>
```

*One row per author. Fill each field from the matching step; the verdict follows the Drop/Verify/Keep rules above.*

The `reason` field is what makes two teammates agree. It forces you to name the single sub-score that decided the verdict, so a disagreement becomes a specific argument about one field rather than a vague difference of feel.

## How this goes wrong: the failure modes

Most bad records do not look bad. They pass a glance and fail a check, so the value of this rubric is almost entirely in the failure modes below. Each one names the false positive and the check that catches it.

### Spoofed author passes as real
An unsigned commit with a valid-looking email resolves to a real profile but was set by anyone with write access. The false positive is convincing: the real person's avatar sits next to the commit. The check is to require a Verified signature. An avatar is a lookup result; only the signature is proof.

### Name-noreply orphan
A `username@users.noreply.github.com` record stopped mapping to the account after a rename, so you enrich a ghost that no live person controls. The check is to distinguish the ID-based form from the name-based form. The numeric prefix means durable; its absence means the link may already be broken.

### Bot treated as a person
Bot committers use the noreply form and read like normal contributors in a log. The check is a string match on `[bot]` against the noreply domain. Anything that matches is not a person and should be dropped, not verified.

### Private assumed unreachable, or the reverse
Either you skip a developer because their profile email is private while their real address sits in the commit .patch, or you contact someone who genuinely believed they were private. The check is twofold: read the patch metadata so you do not miss a reachable address, and weigh the DPA expectation finding so you do not contact someone who never expected it.

### Web-flow committer mistaken for author
`GitHub <noreply@github.com>` appears as the committer on web-UI edits and is not the human who wrote the change. The check is to read the author field, not the committer field, whenever the two differ.

### Stale address
A years-old commit carries an address the person lost when they changed employers. The false positive is a deliverable-looking domain that now bounces. The check is to cross-reference the author's recent commits for a current address before you trust the old one.

### Lawful-use blind spot
The record is technically clean, but the intended outreach is exactly what the AUP names: unsolicited recruiting email. The check is to apply purpose-limitation before Keep. A clean identity does not override a failed lawful-use gate.

#### Where a record lands

Horizontal axis runs from Weak identity (unsigned or orphaned) to Strong identity (Verified, live account). Vertical axis runs from Non-deliverable (noreply, bot, stale) to Deliverable and current.

| Quadrant | What it means |
| --- | --- |
| Non-deliverable, weak identity | Drop - no channel and no proof |
| Non-deliverable, strong identity | Verify - use as attribution key, resolve the person another way |
| Deliverable, weak identity | Verify - require a signature before you trust the author |
| Deliverable, strong identity | Keep - once lawful-use clears |

*Deliverability sets whether a record can act; identity strength sets whether you can trust it, and the two axes decide the verdict.*

## Keeping the rubric honest over time

The rubric holds only if you re-check the parts that move. Two things drift: GitHub's formats and policies, and your own records' currency. Build both re-checks into the cadence rather than trusting a one-time pass.

The email-type and signature facts are documented in GitHub's own reference pages, so re-read the email-addresses reference and the commit-signature-verification docs when you notice a new address shape you cannot classify. The lawful-use gate lives in the Acceptable Use Policies; treat any change there as a reason to re-score cleared records, not just new ones. The private-versus-commit exposure fact and the DPA expectation finding come from peer-reviewed work, which is the sturdiest input here.

Be honest about what is not established. There is no authoritative public figure for the share of users who expose a profile email; the roughly 15 percent number is vendor-stated, so use it as a rough planning input and not as a hard rate. A GitHub policy that blocks disposable or temporary email providers at verification is not established in the docs reviewed, so do not assume one exists. And unauthenticated API calls are capped at 60 per hour per IP by vendor account, which shapes how fast you can check signature status at scale.

#### Before you record the verdict

- [ ] The email type is tagged as one of real, ID-noreply, name-noreply, bot, or web-flow.
- [ ] Bot and web-flow committers are dropped, not verified.
- [ ] A name-based noreply record is confirmed to still map to a live account before Keep.
- [ ] Identity reads Verified, not merely attributed by avatar, for any Keep.
- [ ] An unsigned commit under a deliverable email is marked Verify for spoof risk.
- [ ] A last-seen date is attached and stale addresses are re-checked against recent commits.
- [ ] The lawful-use gate is cleared, with jurisdiction noted for stricter regimes.
- [ ] The reason field names the single sub-score that decided the verdict.

> **Rule:** No Keep without a Verified signature and a cleared lawful-use gate
>
> Deliverability and currency are necessary but not sufficient. A record earns Keep only when the commit is Verified and the intended use passes the AUP purpose-limitation test.

Run the checklist on every record and the reason field on every disagreement. That combination is what makes the verdict reproducible: not that everyone feels the same way about a record, but that everyone is arguing about the same named field against the same documented facts.

## Frequently asked questions

### Is a noreply commit email ever usable for outreach?

No. Any address ending in users.noreply.github.com is non-deliverable by design, so it will never reach a person by email. It still has value as an identifier: an ID-based noreply address (the form with a numeric prefix) maps durably to one account even after a rename, which makes it useful for confirming identity and resolving the person through another channel. Treat the noreply address as attribution data, never as a contact address.

### How do I know a GitHub commit author is real and not spoofed?

Require a Verified signature. GitHub attributes commits by matching the commit email against accounts with no author authentication, so anyone with write access can push under any repo user's email. A cryptographically Verified GPG, SSH, or S/MIME signature is the only checkable proof that the named person made the commit, and its verification record is immutable and persists even if keys are later rotated or revoked.

### Does the private-email setting mean a developer is unreachable?

No, and this is the common trap. The private-email toggle hides the address on the public profile but does not touch the address inside commits to public repositories. A real deliverable email can still sit in the commit .patch file for someone who believes they are private. A data protection authority has found that users in this position did not expect recruiting contact, so treat these records as a lawful-use risk, not a free contact.

### How do I tell a bot commit from a person?

String-match the address. Bot committers use the noreply form with a bracketed name, such as 49699333+dependabot[bot]@users.noreply.github.com, so matching [bot] against the noreply domain catches them. Also check for GitHub noreply@github.com, which is the committer on web-UI edits rather than a human. Read the author field, not the committer field, when the two differ.

### Can I use commit-mined emails for recruiting outreach?

Not without clearing the lawful-use gate first. The GitHub Acceptable Use Policy forbids using Service information for unsolicited email and names recruiters, headhunters, and job boards specifically. It also requires you to use collected personal information only for the purpose the user authorized and to honor do-not-contact requests. Score the intended use before Keep and get your own legal or compliance sign-off for your jurisdiction, since a technically clean record can still fail this test.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/mined-commit-author-verdict*