Audit Rubric

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

| Pattern category | Default if firing in production path | |---|---| | P5.y bash destructive (active BLOCK match) | CRITICAL if no hook; HIGH with hook | | P5.z agent-config attack (active BLOCK match) | CRITICAL — always | | P3.4 HERMES.md / 429-imminent $50/mo waste) | MEDIUM | | P7.2 no per-agent cost attribution | MEDIUM | | P2.x OOM / CPU spike (active) | HIGH | | P3.1-P3.3 connection / networking (active) | HIGH (MEDIUM if intermittent) | | Partial coverage (e.g. ~ tier in catalogue) | DON'T penalize — this is honest disclosure | | Uncovered (❌ tier in catalogue) | DON'T penalize — flagged as gap |

Score interpretation

| Range | Color | Verdict | |---|---|---| | 90-100 | 🟢 | Excellent — production-ready; maintenance mode | | 75-89 | 🟢 | Good — minor polish; nothing blocking deploy | | 60-74 | 🟡 | Watch — at least 1 high finding; address this week | | 40-59 | 🟡 | Attention needed — multiple high findings; address before next major change | | 20-39 | 🔴 | At-risk — critical findings present; halt expansions, fix critical | | 0-19 | 🔴 | Production-AI emergency — multiple critical findings; serious review needed |

Coverage modifier

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

Effective score:  · Coverage: /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:  — CRITICAL
> Halt expansion of [feature]; remediate immediately.
> Specific action: [grounded in the data — e.g. "rewrite cron-summarizer at  to add explicit heartbeat + non-zero exit on no-data scenario"]

HIGH — Address this week

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

MEDIUM — Schedule

> 🟢 P-id:  — 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.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: temurkhan13
• Source: temurkhan13/aufgaard
• License: MIT

Install and usage instructions live in the source repository linked above.