---
name: standard-prioritisation
type: standard
description: >-
  The quality bar for how Sonar prioritises — severity tiers for audit and
  release-gating work, Impact × Effort × Confidence scoring for roadmap and
  intervention work, and the known/assumed/unknown confidence overlay that routes
  high-severity unknowns to a research-first track. Read before scoring or
  sequencing any findings, opportunities, or interventions (skill-prioritise,
  skill-discovery-audit) so priority is derived the same way and a number can be
  defended. Surfaced by the a1.Muse engagement; grown as it is reused.
---

# Prioritisation standard

How Sonar decides what matters most, and in what order. This is a *standard*, not a convention: the axes are derived deliberately and a score can pass or fail review, rather than being an arbitrary-but-shared choice. It explains **how each axis is derived**, so two people scoring the same finding land in the same place. Owned by Sonar; read by every skill that ranks or gates work.

> *This is the canonical copy of this standard. Any human-readable A1 client version is a downstream rendering — edit here.*
>
> **Note on type.** This is the first `standard-` artefact. `core-operating-model` defines *standard* as a Layer-5 atomic rule (a quality bar you pass or fail), distinct from a *convention* (an arbitrary-but-shared choice). `convention-artefact-format`'s type enum and `build-manifest.ts` do not yet list `standard`; adding it is a small follow-up so the agents site classifies this correctly.

## Pick the method by context

Two methods, chosen by the work in front of you — never both at once on the same item:

* **Method A — Severity tiers.** For audit findings and release-gating: "how bad is this, and does it block?"
* **Method B — Impact × Effort × Confidence.** For the roadmap and interventions: "what's the best thing to do next?"

A finding is triaged with A; the intervention that answers it is scored with B.

## Method A — Severity tiers

Three tiers, for the design-audit and release-gating framing.

* **Critical** — blocks the core job, breaks a release gate, or causes real harm (accessibility failure, data loss, broken purchase). Must be fixed before ship.
* **High** — materially degrades the experience or conversion but does not block. Fix soon; schedule into the next cycle.
* **Low** — a real but minor issue. Fix opportunistically.

**Accumulation rule.** Severity is not only per-item. Where many High findings cluster at one point in the experience, the *point* escalates: as a guide, more than three High findings at a single step escalate that step to Critical, because their combined effect blocks the job even if no single one does. Accumulation is assessed per step, not across the whole audit.

## Method B — Impact × Effort × Confidence

For sequencing interventions. Each axis is High / Medium / Low, derived as follows — the rubric is the point of the method, so derive, don't guess:

* **Impact** — how much this moves the metric that matters (the core-job conversion or the named KPI).
  * *High* — moves the primary metric materially, or unblocks a Critical.
  * *Medium* — moves a secondary metric, or a modest move on the primary.
  * *Low* — marginal or indirect effect.
* **Effort** — cost to deliver, in time and complexity (inverted — low effort is good).
  * *Low* — days; one owner; no new dependency.
  * *Medium* — a cycle; some coordination or a new component.
  * *High* — multiple cycles; cross-team or a structural change.
* **Confidence** — how sure we are the impact and effort estimates hold (see overlay below).
  * *High* — grounded in evidence (data, direct observation).
  * *Medium* — reasoned from analogy or partial evidence.
  * *Low* — assumption or unknown.

Sequence by Impact first, break ties on Effort (prefer low), and treat low Confidence as a flag to de-risk before committing, not a reason to drop. Plot the set on an Impact × Effort 2×2 to make the quick wins (high impact, low effort) and the big bets (high impact, high effort) visible.

## The confidence overlay — known / assumed / unknown

Every scored item also carries a confidence tag, independent of the score:

* **Known** — backed by evidence.
* **Assumed** — a reasonable belief, not yet verified.
* **Unknown** — a gap; we don't yet know.

**The routing rule:** a high-severity or high-impact item tagged **unknown** does not go on the build track — it goes on a **research-first track**, to be turned into a known before it is committed. This stops the plan betting heavily on guesses. Low-stakes unknowns can ride along; high-stakes unknowns are research tasks first.

## Quick checklist before publishing a priority

- [ ] Right method for the context (severity for audit/gate, IEC for roadmap)?
- [ ] Each axis *derived* from the rubric, not asserted?
- [ ] Accumulation checked — clustered Highs escalated where they block a step?
- [ ] Confidence tagged, and high-stakes unknowns routed to research-first?
- [ ] Result legible as a ranked table and, for interventions, an Impact × Effort 2×2?
- [ ] Tone clean per `cos.tov`?