What auditing Pebbles taught us

A framework is just a nice document until it meets a real product. So before proposing Kritik as part of Arkaik, it ran on Pebbles: five surfaces (web, iOS, Android, an admin back-office, and the database they all share), eleven domains, 88 criteria, every score backed by evidence from the code.

The first lesson was about shape. The matrix told one story at a glance: strong craft, missing launch-hardening. Architecture and agent-readiness sat in the B band on most surfaces; safety, store compliance and GDPR sat at the bottom. And because four clients share one database contract, the weak spots repeated identically across columns. That's not five bugs, it's one gap seen five times, and only a per-surface matrix makes that obvious.

The second lesson was the cap. The database surface scored respectably on security maturity, yet showed a D with an asterisk: one open critical finding. An average would have hidden the single exploitable hole behind a row of healthy criteria. The cap refused to, and that's exactly the behavior you want from a quality score you're going to show people.

The third was about trust. Every critical and high finding went through an independent attempt to disprove it before it was kept. All 41 survived. That's the step that turns an agent-generated audit from "interesting" into "actionable": findings that argue with themselves before they reach you.

The last lesson was about who does the work. The whole audit was run by a small army of agents, one per cell, plus cross-surface and verification passes. Which settled the design question: Kritik has to be built to be run by agents, repeatedly, with the results landing in the same journal everything else in Arkaik grows from.