The Verifiable GitHub Portfolio: How Engineers Prove They Actually Built Their Repos

The unverified portfolio is dead

A green GitHub contribution graph used to be a credible signal. In 2026 it isn't. Anyone can git init, paste from an LLM, push for thirty days, and call it a project. Recruiters know this. Hiring managers know this. The result is that real engineers — the ones who actually understand their own code — are filtered out by the same screen that lets confident copy-pasters through.

A verifiable portfolio fixes that. Instead of asking the reader to trust the repository, you attach evidence that you can reason about it: an interrogation trace, a fault-injection response, and a public badge that ties them back to a specific commit.

What "verifiable" actually means

A repository is verifiable when three things travel with it:

• A reasoning trace — recorded answers to architectural questions about why the code looks the way it does.
• A fault-recovery log — evidence you can debug your own system when a real-world bug is planted in it.
• A signed badge — an immutable link tying both back to a specific commit hash, so the proof can't drift from the code.

The four moves that make a repo defensible

1. Write the README as if a stranger will run it tomorrow

Architecture decisions, tradeoffs, and the one thing you would rebuild differently. This is what an interrogator — human or AI — will probe first. Vague READMEs read as borrowed work.

2. Leave a fault diary

A short FAULTS.md listing real bugs you hit, what they looked like, and how you confirmed the fix. Debug history is the hardest thing to fake and the most telling thing to read.

3. Make tests narrate intent, not coverage

Tests named after the behavior they protect (cancels in-flight fetch on unmount) are far stronger evidence than 90% line coverage on a generated suite.

4. Pin a verification badge to the repo

The badge — issued against a specific commit — is what lets a recruiter skip directly from your profile to the moment your understanding was checked.

How ProofWork AI does the verification

ProofWork AI ingests the entire repository inside Gemini's 2M-token context window, identifies the load-bearing files, and runs a three-stage interrogation:

1. Code Interrogator. Architectural cross-examination — why this choice over the obvious alternative.
2. Chaos Challenge. Edge-case stress events shaped to your specific code paths.
3. Bug Injection. A real-world defect is planted in a high-traffic path and you are asked to find it.

The output is a Reasoning Report and a Verified Understanding Badge — the same artifact you saw in the live prototype.

What this looks like on a resume

One link per project. Recruiters get a 30-second view: score, depth ("senior-mid"), commit hash, and the questions you actually answered. No more "did they really build this" — the badge answers it.

Start with one repository

Pick the project you're proudest of — the one you'd want a hiring manager to read first. Verify that one. The rest of your profile inherits the credibility.