Audit Rubric (35-pattern scoring)

The Aufgaard audit produces a 0-100 score. This rubric is the canonical scoring framework — same logic across sessions, same logic the bundle's Field Reference PDF documents.

Scoring formula

Start at 100. Subtract:

• −15 per CRITICAL finding — confirmed, actively-firing, in-production-path
• −5 per HIGH finding — confirmed pattern hit but in a less-critical path, OR a critical pattern with mitigating controls
• −2 per MEDIUM finding — pattern matches loosely, or short-window observation
• 0 for partial-coverage gaps — honest disclosure that we couldn't measure

Floor at 0. Cap at 100. Round to integer.

Severity assignment per pattern

For each of the 35 patterns, the audit assigns a severity based on:

1. Whether the pattern is firing (any rule hit in the underlying MCP scan)
2. Where it's firing (production code path vs dev / test / scratch)
3. How recent (last 7 days = elevated; older = baseline)
4. Mitigation present (e.g. bash-vet hook IS active = mitigated even if rule fires; without hook = critical)

Default severity ladder

Score interpretation

Coverage modifier

The aggregate audit score is the BASE. We also report a coverage modifier for honesty:

Effective score: <BASE> · Coverage: <N>/35 patterns measurable from your data (<%>%)

If only 23 of 35 patterns are measurable from the user's data (e.g. they don't have a JSONL log for cost-tracker yet), the score is computed from those 23 patterns only — and we say so. We don't pretend a partial scan is a full audit.

Example:

Score: 78/100 (across 23 measurable patterns) · 12 patterns uncovered or unmeasurable from current data — see Coverage breakdown for the gap list.

Recommendation templates

For each finding, the audit suggests a remediation. Templates:

CRITICAL — Halt

> 🔴 P-id: <pattern> — CRITICAL
> Halt expansion of [feature]; remediate immediately.
> Specific action: [grounded in the data — e.g. "rewrite cron-summarizer at <line> to add explicit heartbeat + non-zero exit on no-data scenario"]

HIGH — Address this week

> 🟡 P-id: <pattern> — HIGH
> Address within 7 days.
> Specific action: [grounded in the data]

MEDIUM — Schedule

> 🟢 P-id: <pattern> — MEDIUM
> Schedule for next maintenance window.
> Specific action: [grounded in the data]

Anti-patterns in scoring

These would invalidate an audit:

• ❌ Speculation — "this might be P5.y" without an actual rule hit. Don't penalize for "could happen"; penalize for "is happening."
• ❌ Padding — listing 7 medium findings when 2 of them are the same root cause. Group into one.
• ❌ Generic recommendations — "improve error handling" is not a recommendation; "rewrite line 17 of api.py to remove except: pass" is.
• ❌ Hidden assumptions — if the data is incomplete, say so. Don't compute a 95/100 from a 5/35-pattern partial scan and pretend it's comprehensive.

Re-audit cadence

The audit is point-in-time. Re-run via /aufgaard:production-audit:

• After any major code change that touches LLM-call sites or agent config
• After any package upgrade of a dependency in the catalogue
• Weekly as a routine pulse-check
• After incident response to verify the fix didn't introduce new patterns
• Before any expansion (new agent, new domain, new integration)

The audit report should always include a "Next audit recommended in [N] days" footer based on the score band — higher scores get longer cadences.

Score-trend tracking (future)

Scoring history is currently per-session. Future v1.x could persist scores to a local file for trend tracking ("score went 78 → 84 over 30 days; you fixed P6.2 in agents/billing.py"). Not yet built; flagged as enhancement.