built on
Heterogeneous model review on every audit. Specialists run on one provider; adversarial reviewer runs on another. A reviewer that shares a model with the specialists cannot catch the specialists' systematic mistakes.
Ten specialists run in parallel. A heterogeneous reviewer refutes the weak findings. A citation gate validates that every survivor cites real code at a specific line. The signed packet is in your inbox within 48 hours.
This page is the full pipeline, step by step. The methodology is open source: github.com/FreeGuy-AI/closeread-io-methodology.
From repo URL to signed packet. Every step is logged, cost-stamped, and auditable.
You provide a repo URL, branch, and an optional questionnaire (listing platform, target timeline, concerns you want foregrounded). We provision a read-only deploy key scoped to the audit window. The key never touches more than the one repo and is revoked on packet delivery. Your source code never leaves our Cloudflare-backed ephemeral compute and is not retained beyond packet generation. Findings reference filepath:line, never raw source.
Ten specialist agents run in parallel, each focused on one buyer DD question. They read the codebase, surface findings, assign severity, assign a confidence score (0.0-1.0), and cite the specific file and line that triggered the finding. No specialist shares context with another; they each start from the same read-only checkout.
A reviewer model, running on a different provider than the specialists, receives each raw finding and attempts to refute it with specific evidence. The reviewer must cite a concrete reason a finding is wrong; "this might be a false positive" is not sufficient. Findings the reviewer cannot specifically refute survive. Findings it can refute specifically are dropped with a reason logged. Findings with a confidence score below 0.40 skip adversarial review entirely: low-confidence structural findings (like "we cannot determine the license of this vendored file") are themselves the signal. Sending them to a reviewer who also cannot determine the answer produces noise, not quality control.
Surviving findings are assembled into the packet: a buyer-facing summary (the artifact a buyer's DD team would produce themselves in week one of LOI) and a developer-facing finding ledger with remediation guidance. The packet is rendered to Markdown and PDF, signed with an Ed25519 key, and stamped with the exact dollar cost of the compute that produced it. Every finding in the ledger cites the specific file and line that triggered it.
You receive the packet via email: Markdown source, branded PDF, and the cost metadata JSON. A 30-day Q&A window opens immediately. You can ask follow-up questions on any finding and we will answer from the codebase state at audit time. At delivery, we ask (separately, not required) whether you want to make the packet public. If yes, it goes on closeread.io. If no, it stays private. You can revoke consent and take down a public packet at any time.
Three stages. Each specialist produces raw findings. The reviewer passes or drops each one. The gate validates that surviving findings cite code before anything reaches the packet.
The specialists that surface findings run on Anthropic's models. The adversarial reviewer that challenges those findings runs on a different provider: DeepSeek, Google Gemini, or OpenAI, rotated randomly across audits.
This is not variety for variety's sake. A reviewer that shares a model family with the specialists cannot catch the specialists' systematic mistakes. If Claude-based specialists share a bias (a pattern of false positives on a specific framework, a blind spot on a particular license type), a Claude-based reviewer will share the same bias and pass the same bad findings. An adversarial review only works if the reviewer is epistemically independent from the producer.
This property is the load-bearing implementation of the heterogeneous rebut-pattern from ICML MAS 2025 research on multi-agent systems. The verifier needs to be independent from what it verifies. We applied that to the audit pipeline from Day 1.
| Layer | Provider | Role |
|---|---|---|
| Specialists (all 10) | Anthropic | Surface findings from the codebase |
| Adversarial reviewer | DeepSeek · Gemini · OpenAI (rotated) | Refute weak findings with specific evidence |
| Code review (pipeline itself) | OpenAI Codex | Review every commit to the audit pipeline before merge |
| Local backend (Phase 2) | Llama 3.3 70B local via Ollama | On-machine reviewer for audits that must not leave the network |
The reviewer backend rotates randomly across each audit so no single-provider bias accumulates across the cohort. Per-audit cost metadata records which backend was used and what each call cost. The full breakdown (Anthropic specialist cost + reviewer cost) is stamped on every packet.
Every finding that survives adversarial review passes through one more check before it reaches the packet: it must cite a specific file and line in the codebase. No citation, no finding.
This is not pedantry. Uncited findings in a due diligence packet are useless. A buyer's counsel cannot act on "this project may have license compliance issues." They can act on "this dependency at package.json:34 is GPL-3.0, which triggers source-disclosure requirements if linked at distribution time."
The gate also has a confidence floor: findings the specialist scored below 0.40 confidence skip adversarial review entirely. Low-confidence structural findings (like "we cannot determine the license of this vendored file") are not weaknesses in the pipeline. They are honest signals. Sending them to a reviewer that also cannot determine the answer produces rejection noise, not quality control. The confidence floor was set after observing that adversarial reviewers over-reject when uncertain: the default behavior without a floor is "reject findings that might be wrong" rather than "reject findings that are provably wrong." The floor forces the default back to "pass unless specifically refutable."
The reviewer must refute a finding with specific evidence to drop it. Uncertainty is not grounds for rejection. If the reviewer cannot point to a specific reason a finding is wrong, the finding survives.
Findings scored below 0.40 by the specialist skip adversarial review. These are genuine low-confidence signals, not noise. They ship in the packet with their confidence score visible, flagged as "low confidence, manual review recommended."
This is a real finding structure from a Closeread audit on an open-source codebase, anonymized. It shows what the developer-facing ledger looks like: finding type, severity, confidence, exact file and line, explanation, and remediation estimate.
"bcrypt-cli": "^2.4.1"
This dependency is licensed GPL-3.0. If linked into closed-source software at distribution time, it may trigger source-disclosure requirements under the GPL. A buyer's legal review will flag this in week one of due diligence.
bcryptjs (MIT) or argon2 (Apache-2.0). Estimated effort: under 2 hours including test updates.
The buyer-facing summary groups findings by risk category (IP, operational, technical) and presents the top 10 by severity. The developer-facing ledger contains every surviving finding with full citations and remediation guidance. Both ship together in the same packet.
Closeread audits are useful. They are not everything. Be clear on the distinction before you buy.
We audit. We do not certify. The distinction matters in a transaction context, and we will always say so clearly.
Founding Alpha is open now. Eleven seats total. Ten paid at $500. One free, by invitation. Beta and Standard open after Alpha closes.
Ready to apply? Six fields, under three minutes.
Apply for Founding Alpha →Not ready to apply? Read the full methodology first: github.com/FreeGuy-AI/closeread-io-methodology. Sample packets on real codebases: closeread.io/samples.
If the methodology seems useful, the highest-leverage thing you can do is star the repo. No obligation, no email needed.
★ Star on GitHub →