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. Below is part of a real report, on prometheus/prometheus, as its public page shows it. The notes beside it say what each part is for.

Borehole
Risk register · free tier
prometheus/prometheus
dff7878 · 18,736 commits · 1,691 files

Reads strong: 4 of 6 rated dimensions are strong, 2 are adequate and none is significant.

DimensionRating
01 Architecture & Codebase — including AI provenance strong
02 Engineering Process & SDLC Maturity strong
03 Organization & Key-Person Risk strong
04 Product & Engineering Maturity adequate
05 Security & Reliability Posture adequate
06 Observability & Operations strong
07 Fit with the Acquirer not assessable
strong adequate significant findings not assessable from a repository
Provenance disclosure does not affect any rating
1% of the code standing today was written in AI-declared commits
55/13,573 commits declaring an agent
confidence: high
This is a lower bound. It counts what the repository declares. Undeclared AI authorship is invisible here, and a single rebase removes the trailers this rests on. Absence of a declaration is absence of disclosure, not absence of AI authorship.

Product & Engineering Maturity

04 · adequate
04.3

109 direct dependencies in a single manifest

adequate

go.mod declares 109 direct dependencies. Each one is a maintenance obligation, a supply-chain surface and a potential licence question that transfers with the asset. The count says nothing about whether any given dependency was a good choice; it says how many such choices a buyer inherits.

Evidence
direct-dependenciesgo.mod — 109 declared
direct-dependenciesweb/ui/mantine-ui/package.json — 39 declared
direct-dependenciesweb/ui/react-app/package.json — 38 declared
direct-dependenciesweb/ui/module/codemirror-promql/package.json — 2 declared
6 more findings in the full report

What a person adds

Product & Engineering Maturity

04 · minimal coverage
  1. measured 1,532 commits landed in the last year, against 1,085 the year before (+41%). What drove it: new people, a deadline, or code produced faster than before? Answer lives in: The team04.11

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 →