M-01PUBLIC Methodology · Published, not proprietary theater

Judgment, calibrated

This page is written for the skeptical CTO your board just forwarded our name to. It shows the rubric, the calibration protocol, the reviewer standards — and the honest limits of what an audit can see.

§ 01RUBRIC The scoring skeleton

Five dimensions, scored 1–10, benchmarked by stage

Every dimension is scored against written banding criteria, not reviewer mood. An excerpt from the Code Quality & AI-Code Risk band definitions:

BandWhat earns it
8–10Provenance tracked systematically; duplication index at or below stage benchmark; all AI-written code passes independent human review; tests authored separately from implementation.
5–7Partial provenance; duplication above benchmark in isolated subsystems; review policy exists with measurable gaps; test authorship mixed.
3–4Provenance unreconstructable for material subsystems; duplication trending with the documented 8× market drift; comprehension gaps in at least one production-critical path.
1–2Unpriced: no provenance, no policy, model-authored tests asserting model-authored code, staff unable to explain failure behavior of critical subsystems.

Scores are reported against benchmark bands for comparable-stage companies, so "6/10 at Series A" means something a board can act on.

§ 02CALIBRATION How reviewers earn the rubric

No reviewer scores a client before agreeing with the bench

Every reviewer — staff-level engineers and former CTOs — scores a set of benchmark codebases independently before their first engagement. Scores are reconciled against the bench; reviewers join client work only once inter-rater agreement passes threshold. On every audit, two to three reviewers score independently, reconcile documented disagreements, and a red-team reviewer who hasn't seen the codebase attacks the draft's conclusions before anything ships.

Reviewers are named in your report, with their prior roles. Judgment you can't attribute is judgment you can't trust.

§ 03LIMITS What an audit cannot see

The honest boundary

An audit is a point-in-time examination of evidence. It cannot see: code that isn't in the repositories we're given; runtime behavior under production traffic we don't observe; intentions, only artifacts; or the future — a score describes the codebase on the day of examination. We state confidence levels per finding, we mark inference as inference, and where evidence is insufficient we say "insufficient evidence" rather than guessing. A firm that claims its audit sees everything is selling you the confidence inversion it should be auditing.

Poke holes in it

Thirty minutes with a senior reviewer. Bring your hardest questions about the rubric — that's what the call is for.

Book a scoping call