The Engineering Team Signal Reference: What a Startup's Repos Prove

This reference is for investors, platform partners, and angels who need to diligence the engineering team behind an open-source or dev-tool round using only public data, before there is a term sheet or a data room. It covers nine team signals in a company's public GitHub org. For each one it gives what the signal proves, the point where it becomes a diligence question, and the specific way it misleads. Jump to the row you need, then use the procedure and the failure modes to check what you read.

What can a startup's public commit history prove?

Public commit history proves three things: who touched which files in the public repos, under which self-declared identity, and through which merge path. It does not directly prove who wrote the code, who is employed, or who still works at the company. Those are inferences you build on top of the history, and each one fails in a known way.

Most technical due diligence checklists are written for founders. They assume private repo access and team interviews, and the one published benchmark is a one-week checklist. This reference works earlier than that. Working earlier is cheaper and faster, but it also means every finding below is an inference from outside the company, and your memo should say so.

Four layers sit between a commit on the default branch and the person who wrote it. Clear them from the outside in.

GitHub takes authorship from the author field of a Git commit, and that field holds whatever the committer typed into their Git config. Treat every name as a claim until you have cleared the layers above it.

The team signal reference: nine signals, row by row

Nine signals answer the team question. Together they tell you who builds the product, how concentrated the knowledge is, who controls merges and releases, who joined from the community, who left, how much code agents wrote, and whether the public history is real. Each row gives a definition, what the signal proves, when it becomes a diligence question, and how it lies.

Where no public threshold exists, the row says so. Do not invent one for the memo. State the bar you chose for this company and why you chose it.

1. Employee vs community commit share

This is the share of human commits in a stated time window written by the company's employees versus outside contributors. CHAOSS, the open-source community-health project, measures it as Organizational Diversity: the percentage of contributions from each organization in a defined period.

• Proves: whether the product is built in-house, by its users, or by both. It also shows whether "community" in the pitch means code or only attention.
• Becomes a question when: the share contradicts the pitch, or moves sharply between two windows. No public standard sets a healthy external share. CHAOSS itself says the threshold should differ between a project with 1,000 contributing organizations and one with perhaps 10.
• Misleads when: employees commit from personal gmail addresses and get counted as community. It also misleads when squash merges make the employee who pressed merge the author of a community contributor's work.

2. Founder commit trajectory

This is the technical founder's share of human commits, quarter by quarter.

• Proves: whether the founder still builds, has handed the work off, or still holds everything.
• Becomes a question when: one name holds 90% of commits at a stage where the round is meant to fund a team. The founder-facing rule of thumb reads that as a bus factor of one. It is also a question when the founder's share falls and nobody takes over their files.
• Misleads when: the founder mostly reviews and merges. Under squash merging, a founder who only reviews looks like the sole author. GitHub's squash attribution has also changed over time, so a quarterly series that spans one of those changes can show a trend that the platform created. Look up the change dates in GitHub's changelog before comparing quarters across them.

3. Knowledge concentration (truck factor)

The truck factor is the smallest number of people whose departure would leave more than half the files orphaned, meaning no remaining author can be assigned to them. Its commit-count cousin, the Contributor Absence Factor (formerly called bus factor), is the number of top contributors you need to reach 50% of contributions.

• Proves: who holds file-level knowledge, by name.
• Becomes a question when: the core includes a non-employee or a departed employee, or shrinks from one window to the next. The level on its own tells you little, as the concentration section below explains.
• Misleads when: merge commits are counted as regular commits. Avelino's tool counts them, which inflates whoever runs merges.

4. Merge-rights holders

These are the people who merge pull requests into the default branch, plus the owners named in CODEOWNERS.

• Proves: who decides what ships. Under squash merging it also shows who collects authorship credit.
• Becomes a question when: a single person merges everything, or when pull requests are merged by their own author. One practitioner's rule: pull requests merged by their own author within a minute mean knowledge has not spread.
• Misleads when: a merge bot or CI identity holds the button and hides the human who controls it. It also misleads when some members hide their org membership, which makes the visible merger list incomplete. I have not verified whether membership is hidden by default, so check the org page yourself.

5. Contributors hired from the community

These are authors who first appear as outside contributors and later commit under the company's domain or list the company on their profile.

• Proves: the company can recruit from its own users. That is a real hiring channel, and evidence that the community is technical rather than decorative.
• Becomes a question when: the pitch names community hiring as a channel and no transitions show up. It is also a question when a hired contributor's pre-hire code sits in proprietary files, which is covered in the document request section.
• Misleads when: an existing employee switches from a personal to a company email. The switch looks exactly like a community hire. Merge identities first, then check the start date on their profile.

6. Silent departures

A silent departure is an employee whose public commits stopped and who never announced leaving.

• Proves: a possible departure. If the person's files sit in the truck-factor core, it also proves an area of the code with no current author.
• Becomes a question when: the departed person held files with high authorship, or several early engineers stopped within the same window. To classify why they left, pair this signal with the library's Early-Team Departure Read.
• Misleads when: someone switches email (the old identity stops and a new one starts), or moves to private repos and goes quiet in public.

7. Release ownership

This is the person who tags releases and publishes them.

• Proves: who has operational control of shipping.
• Becomes a question when: one person tags every release, or the person tagging releases no longer appears to work at the company.
• Misleads when: a release bot tags on someone's behalf. Then the real owner is whoever edits the release workflow, not the identity on the tag.

8. Agent-authored share

This is the share of commits written or co-written by coding agents. A competitor checklist treats how much of the codebase AI wrote as one of seven diligence checks. The NVCA model documents added a GenAI tool-usage subsection to their IP representations (section 2.8(l) in the April 2024 form).

• Proves: how the team works, and what the company will need to disclose under a priced-round IP rep.
• Becomes a question when: agent work is concentrated in the proprietary core, or the share jumps. No public threshold exists.
• Misleads when: developers remove the trailers. A developer can use AI heavily and strip the trailer before pushing, so a missing trailer is not proof of human work. Trailers can also be false, as covered in the failure modes section.

Markers to count:

• Copilot cloud agent commits are authored by Copilot, with the human who started the task as co-author. Each commit message links to the agent session logs, and the commits are signed and show as "Verified".
• A squash-merged agent pull request credits Co-authored-by: copilot-swe-agent[bot].
• Repo files such as CLAUDE.md and .cursorrules.
• Wider coverage: the "Agentic Much?" study keeps 86 file-based, 20 branch-based and 4 label-based heuristics for 48 coding agents. The open-source commit-check project also detects AI attribution.

9. History resets and exports

This is a public repo whose history does not reflect the real work, such as a private monorepo synced out by a bot.

• Proves: only that the public repo is a distribution channel.
• Becomes a question when: you see one committer identity and bulk commits. At that point every authorship signal above is meaningless. Ask for read access or stop computing them.
• Misleads when: nobody checks for it. An export never misleads you once you have caught it, but if you miss it, every other row is wrong.

How are the concentration metrics computed?

Three metrics answer "how concentrated is this team", and each counts something different. Contributor Absence Factor counts people to half the commits, the truck factor counts people to half the files, and Elephant Factor counts companies to half the commits. Report all three with the time window stated, because they disagree for good reasons.

The truck factor method and what it found

The standard truck factor comes from Avelino, Valente and Hora, who studied 133 systems in six languages: more than 373K files, 41 MLOC and 2 million commits. They removed the author with the most files, one at a time, until more than half the files had no author. File authorship uses Fritz's degree-of-authorship model (DOA), which scores how much one developer owns one file:

DOA = 3.293 + 1.098 * FA + 0.164 * DL - 0.321 * ln(1 + AC)

FA records whether the developer created the file. DL is the number of changes they made, and AC is the number of changes made by other developers. A developer counts as an author when the absolute DOA is at least 3.293 and the normalized DOA is at least 0.75. The AVL tooling also has a configurable option to exclude developers who authored less than 10% of the total files.

The results set the baseline: 34% of systems had a truck factor of 1 and 30% had a truck factor of 2. A later paper rounds this to 65% at 2 or less.

A low truck factor is the normal case; the finding is who sits in the core and whether it is shrinking.

Two limits belong in the memo. First, the authors concede the DOA weights were derived for other systems. Second, in their validation, 84% of developers agreed or partly agreed on who the main authors were, but only 53% agreed or partly agreed with the truck factor estimates. Use the named authors with more confidence than the number.

Elephant Factor on a startup repo

Bitergia coined Elephant Factor and presented it at OSCON 2015. On a repo run by one company it equals 1 by design, and one study left it out because it is unlikely to apply to smaller packages. For a startup, read the community share in signal 1 instead.

What survives each merge path?

The merge path decides whose name ends up on main. Merge commits and rebases keep the original authors. Squash merges make whoever merged the author. The default squash message setting deletes co-author trailers entirely.

GitHub's squash attribution changed in stages. Squash merging came first and co-author trailers came later. GitHub then began crediting every commit author in a pull request as a co-author on the squash commit, and later made the merger the author. Even within the current behavior, GitHub support has said "we should be setting the author as a co-author and we can see that's not happening every time". On Copilot pull requests, the person squash-merging cannot choose "Change author".

How large the undercount is in practice has not been established publicly. GitHub's documentation also says nothing about mirrors or private monorepos. Check the repo's merge settings from its recent history: look for squash commits with no trailers at all.

How to run the team read from a public GitHub org

The procedure takes a startup's public org to a set of dated findings and document requests in eight steps. By my desk estimate (not a benchmark), that is about a day and a half of analyst time plus a partner review. Steps 2 and 4 are the slow ones and the ones that most often go wrong.

Sources disagree on where to start. The CHAOSS practitioner guide starts with Elephant Factor. The founder-facing checklist starts with git shortlog -sn and its 90% rule. For a startup I start with identities, because the other numbers are only as good as the identity merge underneath them.

A .mailmap file lists a canonical identity followed by each contributor identity that should fold into it. One person can show up as a company address, a personal gmail address, an old-domain address, and a bot-like alias.

Jane Doe <jane@company.com> <jane.doe@gmail.com>
Jane Doe <jane@company.com> <jane@old-company-domain.com>
Jane Doe <jane@company.com> <jdoe-ci@users.noreply.github.com>
Sam Lee <sam@company.com> <sam.lee.dev@gmail.com>

The documented practice for step 4 is the CNCF fork of gitdm. It uses an email-map file that ties emails directly to employers, and it buckets the rest as Independent, Not Found, and Unknown. The Unknown bucket is where the read gets slow, because each author needs a lookup against public profiles. Refolk cuts that lookup down: ask for the people behind a repo in plain English, and you get profiles with current and past employers, which moves authors out of Unknown and into Employee or Former. Nobody has published a typical match rate for a startup org, so report your own Unknown count in the memo.

Signals 5 and 6 are where an employer lookup pays off most, because they hinge on past employers, not current ones.

How team signals go wrong: failure modes and false positives

Every signal in this reference has a known false positive, and most come from four causes: merge paths, identity, automation, and exports. Run the check on each item below before any finding goes into a memo.

1. Commit concentration. Squash merges credit whoever presses merge. False positive: a founder who only reviews looks like the sole author. Check: count authors of pull requests, not authors of commits on main.
2. Agent share. A missing trailer is not proof of human work, because developers can remove trailers before pushing. The reverse also happens. VS Code 1.117 changed the trailer setting's default to "all", a bug then attributed non-Copilot code completions to Copilot, and 1.118 changed the default to "chatAndAgent". Check: look for file markers such as CLAUDE.md and .cursorrules, and note the date of each change. Do not compare agent share across the 1.117 window.
3. Silent departures. A switch from a personal to a company email, or back, looks like someone leaving. Check: merge identities with .mailmap before using last-commit dates.
4. Elephant Factor. On a company-run repo it equals 1 by design. False positive: treating that as a red flag. Check: use the community share instead.
5. Truck factor. Avelino's TruckFactor tool counts merges as regular commits, which inflates whoever runs them. Check: re-run with merge commits excluded and report both numbers.
6. Public repo as an export. If a bot syncs a private monorepo out to the public repo, every authorship signal is meaningless. Check: look for a single committer identity and bulk commits.
7. Affiliation. Authors on personal gmail look like community contributors even when they are employees. Check: the profile company field, and whether they are visible org members. I have not verified whether org membership is hidden by default, so a missing member listing proves nothing.
8. IP mapping. A SAFE gives no assignment rep. False negative: assuming the paperwork covers a community contributor with high DOA in proprietary code. No document covers that gap until the priced round.

Who replaces the people the signals flag?

When the read names a key person, the next question is how hard they would be to replace. The answer depends on the role and the geography. In Refolk's index, the US pool of Founding Engineers is 6.7 times the UK pool, and the UK pool is concentrated in one city.

The maintainer comparison changes how you should read signal 3. In Refolk's index, US maintainers are a smaller pool than Founding Engineers and far more likely to hold founder or CTO titles. If the truck-factor core is one maintainer, that person is often also the founder or CTO, so key person risk and founder risk are the same finding.

These samples are 25 profiles each, so treat the percentages as directional. To test a specific company's replacement depth, run a Refolk search for the exact role and city, for example founding engineers in London at seed-stage developer tools companies. Then count how many plausible replacements come back.

How to turn team signals into document requests

Which document a signal maps to depends on the financing instrument. The YC post-money SAFE carries only a knowledge-qualified rep: the company "owns or possesses (or can obtain on commercially reasonable terms)" sufficient IP rights, with no assignment rep. The NVCA stock purchase agreement (section 2.9 in the October 2025 form) represents that current and former employees and consultants have assigned their work product under signed confidentiality and invention-assignment agreements.

So at a SAFE, signals about departed employees and community authors are questions for the founder with no document to point them at. At a priced round, they become specific requests against section 2.9. Two variables sort them: how much a person authored in proprietary code, and whether they are a current employee.

Company:
Repos read (original / fork / mirror):
Time window:
Identities merged: [n people from n emails]  Unknown employer: [n]

Finding: [signal name, e.g. Silent departure]
Person: [canonical identity]  Status: [Employee / Former / Community / Unknown]
Evidence: [last commit date; files with DOA above threshold; merge or release role]
Checks run: [mailmap merged / merge commits excluded / bots removed / export ruled out]
Instrument: [SAFE / priced round]
Request: [signed confidentiality and invention-assignment agreement covering this person's contributions, or founder question if SAFE]
Founder question: [one sentence, neutral, e.g. "Who owns the code previously maintained by this person?"]

Before you send the memo, and how to keep the read current

A team read goes stale with every release, so check it once before it goes to the partnership and re-run it at each new round. Two inputs drift on their own: GitHub's merge attribution and agent trailer defaults. Re-check both against the platform's changelog rather than trusting the values written here.

To keep the read current, store the .mailmap and the employer labels with the deal file. At the next round, diff the new history against them: new identities, newly silent identities, changes in who merges and releases, and movement in the community share. The diff is usually more informative than a fresh read, because departures and handoffs show up as changes, not levels.