--- name: convention-audit type: convention description: >- The audit apparatus Sonar uses to open an engagement — the category sets per audit type (App, Design System, Team, the technical/sourcing-feasibility audit, and the conversion-diagnostic variant) and the four-card ladder (Finding → Theme Summary → Opportunity → Initiative) that carries an observation through to a fundable intervention. Read before running any audit or diagnostic (skill-discovery-audit, skill-conversion-diagnostic) so findings are captured against a consistent category set, clustered the same way, and tagged with the same Double-Diamond stage. Surfaced by the a1.Muse engagement; grown as audits are repeated across clients. --- # Audit system How Sonar audits a venture at the start of an engagement and turns what it sees into prioritised, fundable direction. Two things are fixed here: the **category sets** an audit runs against, and the **card ladder** that every finding climbs. Owned by Sonar; read by the audit and diagnostic skills. > *This is the canonical copy of this convention. Any human-readable A1 client version is a downstream rendering — edit here.* ## Two audit objects There are two distinct objects, captured here as variants of one convention: * **Quality audits** — assess a thing against a standard. App, Design System, Team, and technical/sourcing-feasibility audits are quality audits: each runs against its category set (below) and asks "where does this fall short of good?" * **Conversion diagnostic** — assesses a *funnel*, not a thing. Its categories are the funnel stages crossed with a lens (forces, barriers), not the columns below; it asks "where do qualified users leak?" See `skill-conversion-diagnostic`. It uses the same card ladder, so its findings are comparable to a quality audit's. Pick the object first; it decides the category set. ## Category sets — quality audits * **App audit:** Accessibility · Bugs · Brand & Content · UX · UI * **Design System audit:** Tokens · Structure · Accessibility · Interaction · Documentation · Architecture · Design→Code · Adoption · Metrics * **Team audit:** three umbrellas — People · Process · Tools * **Technical / Sourcing Feasibility audit:** Sourcing (can the item be found at all, and where — official domain vs third-party vs nowhere) · Sourcing difficulty (how hard to obtain, access barriers, auth/paywall) · Provenance & trust (is the source authoritative and safe) · Parseability (is the item version/metadata extractable in a usable form) · Stability (is the source URL / location durable, or does it churn) · Coverage & distribution (across the inventory, how much is sourceable, and how is it distributed across domains/sources). Use this set when the object under review is the **feasibility of obtaining and using a set of items** — a per-item assessment of whether each can be sourced, how hard, from where, and how reliably — rather than the quality of an interface, a system, or a team. It sits beside the App / Design System / Team quality audits as a fourth quality-audit variant, and climbs the same Finding → Theme Summary → Opportunity → Initiative ladder: a per-item finding (this firmware is only on a forum, version not parseable) clusters into a theme (a class of items is hard to source), opens an opportunity, and funds an initiative. (Surfaced by firmup A1-84 — "audit the founder's inventory for firmware sourcing difficulty + domain distribution": per item, can the firmware be found on an official domain, how hard, version parseable, access barrier, URL stability — a genuine Sonar discovery/audit engagement that fit none of the App/Design System/Team sets, so was routed to Sonar with no matching category set, 2026-07-06, APP-447. May also add a category-set option in `skill-discovery-audit`.) Use the set that matches the object under review. A category that yields no findings is left empty, not forced. ## The Double-Diamond stage tag Every finding and opportunity carries one Double-Diamond stage tag, so the work shows which phase it belongs to: **Discover · Define · Develop · Deliver** Discover and Define are divergent-then-convergent on the *problem*; Develop and Deliver on the *solution*. An audit lives mostly in Discover/Define; the tag keeps a premature solution visible as out-of-phase. ## The card ladder — the common currency Every observation climbs the same four-rung ladder. The ladder is the shared currency across audits, diagnostics, and the engagement playbook, so a finding from any source prioritises the same way. Lite templates (the fields actually used): * **Finding** — one observation. Fields: *observation*, *evidence* (what was seen, where), *category* (from the set above), *stage tag*, *severity* (per `standard-prioritisation`). The atomic unit. * **Theme Summary** — a cluster of findings that share a cause. Fields: *theme*, *member findings*, *root cause*, *How-Might-We(s)*, *priority*. Where findings become insight. * **Opportunity** — a HMW reframed as a space to act in. Fields: *opportunity statement*, *linked themes*, *expected impact*, *confidence* (known / assumed / unknown). Where insight becomes direction. * **Initiative** — a fundable intervention. Fields: *intervention*, *opportunities addressed*, *effort*, *owner*, *priority score* (per `standard-prioritisation`). Where direction becomes a plan. The ladder is climbed in order: many Findings cluster into fewer Theme Summaries, which open Opportunities, which are funded as Initiatives. Do not skip a rung — an Initiative with no Theme beneath it is a solution in search of a problem. ## Quick checklist before running an audit - [ ] Audit object chosen (quality audit vs conversion diagnostic), and the right category set with it (App / Design System / Team / Technical-Sourcing Feasibility for quality audits)? - [ ] Each finding captured as a Finding card with evidence, category, stage tag, severity? - [ ] Findings clustered into Theme Summaries with a named root cause and HMWs, not left as a flat list? - [ ] Priority applied per `standard-prioritisation`, not ad hoc? - [ ] Confidence tagged (known / assumed / unknown), with high-severity unknowns routed to research-first? - [ ] Tone clean per `cos.tov`?