Skip to content

Audit - the adversarial pressure-test

Most code-scanning tools optimise for recall and hand you the triage. You get four hundred findings, you read thirty, and you stop trusting the tool.

audit inverts that. It hunts for weakness and incoherence rather than mere inconsistency, then makes every candidate survive an independent panel whose job is to refute it. What reaches your backlog has already been argued against and won.

The fastest way to see what it does is to point it at a repository that has never heard of SDLC Studio:

/sdlc-studio audit --profile repo

It reads the code, hunts three things - architecture, code quality and defensive security - and files what survives as bugs and change requests with allocated ids. It restructures nothing, asks for no PRD, and requires no adoption. If the findings are not worth having, you have lost an afternoon of compute and nothing else.

find ──► verify ──► merge ──► file
(lenses, (refute (dedup + (bug / CR / RFC,
until-dry) panel, classify) ids allocated)
N-of-M)

Recall first. Before any of it, the project’s ranked lessons are read - because a lesson this project already paid for is a lens. What went wrong last time is where to look first.

Find. One finder agent per lens, each re-run until dry: it keeps going until two consecutive rounds turn up nothing new. A simple “run it once” pass misses the tail, and the tail is where the interesting defects live.

Verify. Every candidate faces N sceptics whose brief is to destroy it. See how it verifies.

Merge. Survivors are deduplicated by file and claim, so one defect found through three lenses is one finding, not three.

File. Findings become real artefacts through the same tooling everything else uses, which refuses a hollow artefact. Triage-then-approve is the default for a whole-project audit; auto-filing is opt-in, because auto-filing once produced shallow artefacts nobody could act on.

audit sits alongside the cheap passes rather than above them. review, reconcile and verify are fast and run constantly. An audit is the expensive, deliberate sweep you run when you want to know what you are not seeing.

An audit can spend millions of tokens across hundreds of agents, and most harnesses only tell you a workflow was large after it has launched. So the estimate comes first:

Terminal window
audit_cost.py --lenses 8 --rounds 2 --votes 3

It reports agents, tokens and minutes with a large or small verdict. Large means you see the number and the scope and give an explicit go-ahead before anything fans out. See how it verifies.

A filed finding can name the lens that found it and the audit run it came from. That pairing is what turns an audit from a one-off into a measurement:

A lens seen once is the lens working. A lens seen across two runs is a detector owed - the same class keeps recurring, so it deserves a mechanical check rather than another sweep.

The two go together or not at all, and an unregistered run id is refused, so a typo cannot manufacture a second run and with it a false verdict.