Technical due diligence workspace
An investor asks to review a target company's code. The company connects its own repositories and chooses what to share. The workspace grades what it is given, cites the files behind every conclusion, and names the model that produced each section of the report.
- IndustryInvestment diligence
- EngagementIn-house product build
- StatusIn active development
What it does
An investor needs to know what they are buying before the money moves. This workspace answers that question with a graded, evidence-backed report on the target company's codebase, instead of a summary the reader has to take on trust.
It runs as a two-party flow. The investor opens the review and sends an invitation; the target company connects its own account and selects exactly which repositories enter it. Nothing is analysed that the company did not hand over.
Diligence that could not show its work
Technical reviews tend to arrive as conclusions, with no way for the reader to check them or to see what was never looked at.
Conclusions without evidence
A written review says a codebase is risky or sound. The reader cannot follow that judgement back to a file, or tell whether the reviewer opened that part of the code at all.
Access asked for before trust exists
The target company is expected to hand its source over early in a deal, in one piece, with no say in what is shared and no record of where it went.
Gaps that read like clean results
When a check does not complete, a report tends to average around the hole. Missing evidence and a good result end up looking identical on the page.
A workspace built around what it can prove
What we designed and built, as four capabilities that are visible in the report it produces.
Consent-led repository access
The investor opens a review and sends an invitation. The target company connects its own account and picks which repositories enter the review, so access is granted on the company's terms.
- Two-party invitation and hand-off
- The company selects what is shared
- Working copies deleted when the run ends
A staged analysis pipeline
The review runs as a sequence of stages. Each writes its own result, so a stage that fails degrades the report and the run carries on.
- Indexing, adversarial security analysis, verification
- Flow mapping, dependency and credential scanning
- Change history, architecture, technical debt, report
Grades with the evidence attached
The codebase is graded across complexity, test coverage, dependencies, architecture, duplication, security posture, maintainability and technical debt, each with the measurements behind the letter.
- Findings carry file and line locations
- Security findings carry a reproducible proof
- Technical debt uses a published cost model, formula shown
Honesty written into the report
The report is built to be checkable. Its readiness checklist has three states: pass, fail, and insufficient evidence.
- An incomplete run withholds the overall grade
- Absent findings are reported as insufficient evidence, never as a clean result
- The verification pass treats a code comment as a claim to check
Where the work happened, and who did it
Four things that are true about a run.
Every section names the model that wrote it
The report carries a provenance table: the stage, the provider, the model and the endpoint. That last column is the difference between work that ran on the local machine and work that left the building.
Each stage can be pinned to a different model
Sensitive analysis can stay on a model running on your own hardware while routine passes go elsewhere. The choice is made per stage, not once per installation.
It can run with no vendor account at all
A local model runtime needs no credential, and the workspace can run against repositories on your own disk, reachable only from that machine.
What you mark sensitive never reaches a model
Files matching your own sensitive-path rules are filtered out before anything is sent. Stored credentials are encrypted at rest, and endpoints recorded in the report are stripped of anything secret.
What it changes about a review
The change here is qualitative, so that is what we publish. Nothing on this page is a number from a run we cannot show you.
Traceable
Every conclusion
A grade can be followed back to the files and lines that produced it, and the reader can see which model wrote the section they are reading.
Your hardware
Where analysis runs
Any stage can be pinned to a model on the operator's own machine, so sensitive code does not have to leave it in order to be reviewed.
Never averaged
Missing evidence
A gap is reported as a gap. When coverage is incomplete the report withholds the overall grade.
Reviewing a technical investment?
We build diligence tooling that shows its evidence and runs where you need it to run. Tell us what you are evaluating.
Talk to us