How it works

This is a report. How to read one.

Borehole reads a repository's git history and working tree, and rates it on the seven dimensions a deal team cares about.

How a survey runs

The same checks run every way. What differs is where the code is read.

A public repository

  1. Paste its address, from GitHub, GitLab, Azure DevOps, Bitbucket, Codeberg, Gitea or SourceHut. No account, and no access to anything of yours.
  2. Borehole's worker clones it and reads it: the history and the working tree, at one commit. The clone uses no credential and is deleted when the survey ends.
  3. The report is public, and listed in the library.
  4. A paid survey gets a second read. A language model reads each finding against the code, and withdraws one it judges the code contradicts. The report says which and why. It never adds a finding and never raises a band. How the pieces fit.

A private repository, on your machine

  1. The collector reads it where it lives: your laptop, your CI or a server of yours.
  2. It sends what the checks need: never whole files; facts and short excerpts of up to 120 characters where a check matched. The dry run prints all of it, and sends nothing.
  3. The report is private to your account. Sending takes a Report key.
pip install -U borehole
borehole collect . --dry-run

A private repository, in your own cloud

  1. The same collector runs in Confidential Compute, in your own Google Cloud project.
  2. Google Cloud attests which collector image ran, and signs the facts it sends. The report carries that signature.
  3. A buyer can check the facts were not edited, without trusting you or us.

Run it in your own cloud →

A private target you're buying

  1. You send the target your key.
  2. The target runs the collector on its own systems, or in its own cloud, and sees the report first.
  3. The target decides who reads it, and shares the link with you.

Surveying a target →

What the seven dimensions cover

106 checks read the first six. Each dimension also hands a person the questions the code cannot settle: 41 in all, each with where its answer lives.

01
Architecture & Codebase — including AI provenance11 checks
A person adds: design walkthrough · submodule access · design review with your architects · build-vs-buy calls full
02
Engineering Process & SDLC Maturity16 checks
A person adds: review depth · planning and estimation · incident-response review high
03
Organization & Key-Person Risk10 checks
A person adds: key people in the deal · gaps in the history · untouched subsystems · who actually mentors · hiring and bench · levelling · working pattern · retention risk · culture partial
04
Product & Engineering Maturity19 checks
A person adds: delivery trend · roadmap review · experiment tracking · model card · whether the debt is funded · commercial consistency minimal
05
Security & Reliability Posture34 checks
A person adds: credential rotation · threat model · infrastructure drift · app permissions · incident history · penetration-test review · compliance evidence partial
06
Observability & Operations16 checks
A person adds: restore rehearsal · alert routing · whether anyone watches the telemetry · postmortem walkthrough · SLO attainment · on-call rotation · cost and capacity partial
07
Fit with the AcquirerNo automated checks: the engagement
A person adds: systems overlap · integration plan · team fit · deal dependencies · contract constraints none
Coverage: how much of a dimension a repository can answer at all

Try it on a repository →Read the docs →