Home

CCA-Audit

A multi-agent code auditor in which no finding reaches your code unverified.

Specialised auditors read your diff in parallel. Their findings are deduplicated, and then each one is re-derived against the real code — mechanically, by the tool that can actually settle it, wherever such a tool exists, and by adversarial review where none does. Only findings that survive that gate are eligible to be fixed.

The design constraint the whole system is built around:

A check that could not run must never be indistinguishable from a check that passed.

That sentence is not a slogan here. It is the reason a missing analyzer escalates instead of refuting, the reason a clean static-analysis run is reported as uncertain rather than clean, and the reason a numeric finding on money-path code cannot be auto-fixed at all when the tool that would settle it is absent. See Reading-a-Verdict for what that means when you are the one holding the output.

---

Start here

→ Evaluating this as a work sample. Blind-Spots first — a verification tool that cannot state where it is blind is asking for trust it has not earned, and this one enforces its limits as tests rather than disclaimers. Then Evidence-Map, which routes every published claim to where it was measured and the limit it carries. Architecture for how the two halves fit together.

→ Running it on your own code. Reading-a-Verdict is the page you want: what each verdict obliges you to do, and how to tell a degraded run from a clean one. Then Tunables when you need to change something, and Hunt-Mode if you are pointing it at code you did not write.

→ Working on it. Architecture for the module map and the seam between the two layers, The-Deterministic-Layer for how a claim is settled and how to add a settler of your own.

→ Returning to it after six months. Tunables and The-Deterministic-Layer. Between them they hold the reasoning that is otherwise recoverable only by reading config.py docstrings — in particular why certain knobs are bounded rather than trusted.

---

What this wiki is, and is not

This wiki explains why: what each component is for, what it deliberately refuses to do, and what breaks when you get it wrong.

It is not the source of truth for any number. Measured results, default values and exact flag spellings all live in the repository, versioned alongside the code that produced them, and this wiki links to them rather than copying them. A claims table that drifts is worse than no claims table, and a wiki has no CI to catch drift — which is a particularly bad look for a tool whose entire thesis is that unverified assertions must not be trusted.

So: figures → benchmarks/results/ and the README. Defaults → cca_checks/config.py. Flag spelling → python -m cca_checks --help. Pipeline steps → docs/pipeline-diagram.md.

The short version of how it works

You run one command. The pipeline detects what changed, decides how much scrutiny the change deserves — trivial diffs run cheap, money and arithmetic diffs are forced to the full treatment, and you do not get to choose that by asserting your change is safe — and dispatches the auditors whose scope the diff actually touches.

Every surviving finding is then converted into a claim with a type, and handed to whichever component can settle that type of claim: a type checker for definedness and nullability, a pattern scanner for the presence of a dangerous sink, a generated failing test for crash impact, a property-based search for arithmetic. Each of those can only conclude what its evidence supports — so their verdicts are asymmetric, and a clean run is very rarely a pass. What no tool can settle goes to adversarial LLM review, which may adjudicate but may not overturn an artifact.

Only then is a fix written. The fix is itself checked for scope creep, and the run is gated on a mapping proving every confirmed finding has a fix and every edit traces back to a finding.