Repository Evidence Review
Raising soon? Before you raise, we check whether the evidence in your repository supports the technical claims in your deck, and give you a record your investor can rerun themselves.
Selling to enterprise? Before your next customer security review, we check whether the evidence in your repository supports what your questionnaire says about how your code is built, tested and released, and give the buyer a record they can rerun.
What it is not: no penetration testing, no certification, and no guarantee that the software is safe or free of defects. For a questionnaire it speaks only to how code is built, tested and released.
Book 20 minutes to pick the decision and the commit. We leave the call with the one question the review will answer and the commit it will answer it at.
It is a fixed-scope, fixed-fee review of one repository that answers one named question about it, with evidence your customer, buyer or acquirer can rerun and get the same result. It also serves engineering leaders deciding whether to accept a delivery from AI agents or contractors.
What it is
One repository, one named decision, one frozen commit. Before work starts we write down the decision in a single sentence, for example: does the evidence at this commit support the claim that an AI-originated change cannot reach production without approval? Everything in the review serves that sentence; anything that does not is out of scope.
What we check
The review has two parts, kept separate in every deliverable so you can see which findings anyone can reproduce and which rest on judgement.
- Evidence review (reproducible). Cejel, our open-source tool, scores the pinned revision against a published rubric: tests that really assert something, committed secrets, CI and release gating, and claims made against what the code shows. It runs offline in your own environment, and nothing is uploaded.
- Adversarial reading (judgement). A senior engineer reads the implementation against your written claims and challenges them: unsupported assumptions, controls that depend on something outside the boundary, paths the claims do not account for. Each finding comes with its reasoning.
Two checks are always included, because a green CI run misses them:
- Tests you didn’t choose. We check whether a passing result rests only on tests the author chose or on stubs, and whether the record holds a clean build and an end-to-end run against the real service.
- New code that is actually used. Each change is traced back to a real entry point by the reviewer, so code that merged but nothing calls is found.
Your existing test results enter as claims to check, not as proof. Where the tests do support your claims, that statement is stronger afterwards because it was challenged.
What you get
- A report, certificate and attestation from the tooling, bound to the exact commit.
- One reproducibility rerun on identical inputs, so you see the result repeat rather than take it on trust.
- An evidence and limitations review covering both parts, each finding marked with the part it came from.
- A 60-minute evidence session and a 60-minute readout.
- A two-page decision memo written for a non-engineer, ready to put in front of a customer, buyer or acquirer: what was established, what was not, and what remains open.
What it is not
The review produces evidence, not an audit, a certification or a guarantee. It does not include penetration, runtime or exploit testing, exhaustive defect coverage, remediation work, or legal or regulatory certification. No deliverable says the software is safe, secure or defect-free. A path that appears to break a claim is described with its evidence, not exploited, and finding no such path is not proof that none exists.
How it runs
Two to three weeks from kickoff to readout, once the commit is frozen and access is in place.
- Agree the named decision and the scope, and sign a mutual NDA.
- You provide read access to the frozen commit, your claims written in your own words before we read the code, and any test or evidence package you rely on.
- We run the evidence review in your environment, do the adversarial reading and the reproducibility rerun.
- You receive the deliverables, then we hold the evidence session and the readout.
Your time: about two hours across the two sessions, plus answers to questions during the review. Your code, claims and evidence stay confidential and are never quoted to a third party. Our tools and method remain ours, and your code remains yours.
Price and terms
| Option | Fee | What it includes |
|---|---|---|
| Repository Evidence Review | C$7,500 | Fixed fee, one repository, one named decision |
| Design-partner place | C$3,500 | Identical scope, in return for two feedback sessions, a named reference if the review succeeds, and permission to publish an anonymised case study. Five places; closes at five or on 30 November 2026 |
Canadian dollars plus applicable taxes. 50% is paid at kickoff. The other 50% is owed only if the readout gives you a decision you can act on; an adverse or inconclusive result counts, because you can act on it. Price list version 2026-10-27.1.
Start a review
Book 20 minutes to pick the decision and the commit at team@barglabs.ai. If it fits, scope, option and kickoff date are agreed on the same call.