The platform

The AI platform behind the investment judgment.

Big Lever AI combines specialized software-analysis tools with an execution and analysis system developed in-house. The platform examines code, dependencies, configuration, and development history together. It reconciles overlapping results, investigates contradictions, and traces gaps in the evidence to build a coherent account of software condition.

We interpret that evidence against the decision you need to make: what you will inherit, what needs repair, or whether the software can defend its position. Every material finding is reproduced by an independent method and confirmed by a named reviewer before delivery. You receive the conclusion, its supporting evidence, and the coverage limits that affect it.

01

What we examine—and why it matters.

The examination connects software condition to the assumptions behind the investment: growth, security, continuity, repair effort, and differentiation. The agreed scope identifies the parts of the system the decision depends on and the evidence needed to examine them.

AI-written code on critical surfaces
Changes marked as AI-written or AI-assisted, the important parts of the system they touched, and their ownership and review trail.
Architecture drift
Components that change together more often than their intended boundaries suggest. These patterns help identify where a planned change could require work across more of the system than expected.
Technical debt
Complexity and duplication against published thresholds.
Test quality
Whether tests on critical parts of the system check behavior rather than merely execute code. This helps assess how much confidence the existing tests provide when the team changes critical behavior.
Scalability
Code patterns that constrain growth in load. The examination reads the implementation; load testing is a separate activity. These findings help test whether the implementation supports the growth assumptions behind the investment.
Credentials and secrets
Passwords, keys, and tokens in the code and its history.
Known vulnerabilities
Dependencies with published security advisories. Reachability in the system is assessed separately when commissioned.
Malicious dependencies
Components matching a maintained list of known-malicious packages.
Authorization enforcement
Whether access to records is checked against the caller's authorization.
Injection and data flow
Paths from untrusted input to sensitive operations.
Sensitive-data exposure
Paths by which regulated or secret data can reach logs, storage, or responses without protection.
Infrastructure configuration
Failed checks in committed build and deployment configuration.
IP and licensing
Licenses and associated obligations on third-party components shipped with the product. These findings identify obligations the buyer may inherit and requirements that could affect how the product is distributed.
Key-person concentration
Concentration of recorded contribution and ownership across components. This helps identify where continuity and future development depend on retaining particular contributors.
AI-model dependence
Reliance on third-party hosted models, identified in source and dependencies.

The question and agreed criteria determine how the findings are interpreted and organized.

02

How an engagement proceeds

01

Intake

We agree the question, the important parts of the system, the assessment criteria, and the required evidence. For re-underwriting, the brief records the product's intended job and the owner's thesis.

02

Access

The client provides an agreed repository mirror and the associated artifacts. Access, handling, and retention arrangements are established before analysis.

03

Measurement

The harness runs the configured examination across each defined population. Missing inputs and method limits are recorded against the measurements they affect.

04

Reconciliation

The analysis layer brings the results together, follows disagreements and gaps to ground, and retains the source of each finding.

05

Confirmation

Every material finding is reproduced by an independent method and confirmed by a named reviewer.

06

Delivery

The findings are presented with the product's conclusions, relevance, and evidence. Coverage and unresolved questions remain visible.

03

Reconciliation turns separate results into one account.

Each tool sees the code through its own method. A dependency inspection, a source-code check, and an examination of change history can reveal different parts of the same issue. Agreement can strengthen the evidence. Disagreement prompts investigation.

The result is a consolidated set of findings with their evidence attached, giving the reviewer a basis for assessing significance across the different tools' results. In the largest calibration case below, roughly 7,400 raw signals were examined for each retained finding.

Calibration · nine public codebases584,773

raw signals examined across the corpus.

Retained333

findings, each connected to its supporting evidence — one for every 1,756 raw signals.

Largest case27

findings from 199,359 signals — 7,384 to 1.

04

What a finding carries

01

Status

Confirmed findings have their measurement and confirmation on record. Unconfirmed signals remain visible, are sized separately, and are excluded from confirmed exposure totals.

02

Relevance

The finding's importance to the commissioned question: acquisition exposure, technical defensibility, remediation priorities, or an applicable control requirement.

03

Evidence and location

The affected code, configuration, dependency, or history; the measured population; the confirming method; and the named reviewer.

04

Implication

The likely consequence for the engagement, with the reasoning behind it. The Tech Report connects findings to acquisition economics; re-underwriting assesses bearing on technical viability.

Repair estimate · effort at the incumbent team's demonstrated pace

S
Under one engineer-week
M
One to under four engineer-weeks
L
Four to under twelve engineer-weeks
XL
Twelve engineer-weeks or more, with a stated floor

These are effort estimates. Calendar duration depends on staffing and scheduling.

Illustrative example

One finding, traced

Requirement
Customer-facing record access must enforce the caller's authorization.
Population
All 41 customer-facing endpoints in the agreed examination. Six internal administrative routes are recorded separately as outside this example's scope.
Finding
Three endpoints return records by identifier without checking the caller's authorization.
Location
The three affected code locations, each identified by file and line.
Confirmation
Reproduced by an independent method, with the confirming evidence, named reviewer, and review date retained.
Result
Confirmed exception · High relevance · Fix band M
Meaning
Establishes unauthorized-access exposure. It does not establish that exploitation has occurred.

05

Coverage is part of the result.

Every limit identifies its source. If requested inputs were withheld, the record includes the request, date, and responsible party. If the method has an inherent limit, the platform owns that limit in the report. This keeps an unexamined area from being mistaken for a clean result.

Measured

The defined check covered its full population.

Partially measured

A named limit affects the conclusion.

Not measured

The class carries no reading.

Coverage is printed near the front of the deliverable, alongside the conclusions it affects.

06

The repeatability record

In calibration, repeat examinations returned identical findings when inputs and measurement configuration were held constant. This gives the examination a consistent baseline: when assessing a later result, the reviewer can check what changed in the software, inputs, or examination settings.

With the platform · calibration9 / 9

public codebases returned identical findings in repeat examinations with inputs and measurement configuration held constant.

Same tools without the execution harness · calibration6 / 9

public codebases returned identical findings in the comparison runs.

Corpus9

public codebases. Last measured 23 July 2026; supporting test records retained by Big Lever AI.

07

What you receive

Every deliverable includes a guide to reading it, the commissioned question and scope, the product's conclusions, the coverage record, a register of findings, and the evidence supporting each finding. Stable finding IDs connect the executive account to the technical detail.

Sample access

Examine the deliverable.

Sample material is available through an invitation-only proof room.

For professional firms

Configured to your firm's engagement.

The same platform can be configured across the question, examination scope, analytical focus, criteria, materiality, and deliverable. Applications include technical diligence, AI defensibility, remediation planning, and compliance inspection.

The platform

Put the technical evidence behind your next decision.