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
- Paste its address, from GitHub, GitLab, Azure DevOps, Bitbucket, Codeberg, Gitea or SourceHut. No account, and no access to anything of yours.
- 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.
- The report is public, and listed in the library.
- 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
- The collector reads it where it lives: your laptop, your CI or a server of yours.
- 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.
- 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
- The same collector runs in Confidential Compute, in your own Google Cloud project.
- Google Cloud attests which collector image ran, and signs the facts it sends. The report carries that signature.
- A buyer can check the facts were not edited, without trusting you or us.
A private target you're buying
- You send the target your key.
- The target runs the collector on its own systems, or in its own cloud, and sees the report first.
- The target decides who reads it, and shares the link with you.
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