| name | audit-rubric |
| description | Scoring rubric for evaluating production-AI deployment readiness. The marquee `production-audit` skill uses this rubric to compute the 0-100 score. Auto-loaded so scoring is consistent across sessions and so the user can self-score independently. Use this rubric whenever auditing, reviewing, or quantifying a deployment's production-readiness. |
| when_to_use | When the marquee `production-audit` skill needs a scoring framework. When the user asks "what's my audit score" or "rate my deployment". When manually walking through a self-assessment. |
| user-invocable | false |
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:
- Whether the pattern is firing (any rule hit in the underlying MCP scan)
- Where it's firing (production code path vs dev / test / scratch)
- How recent (last 7 days = elevated; older = baseline)
- 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 <15min | CRITICAL |
| P10.1 cron silent failure (confirmed exit-0-empty) | HIGH (CRITICAL if affects production data path) |
| P6.y output-action divergence (confirmed STATE_VIOLATED) | CRITICAL |
| P6.2 swallowed exceptions on LLM-call path | HIGH (CRITICAL if billing-related) |
| P9.1 wrong-model overspend (>$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: <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.
