AI Vault Audit

Run one prompt across your AI vault to find what is bloated, duplicated, contradictory, or dead. Then act on the highest-leverage changes.

By James Schramko · Updated May 2026.

AI systems do not usually fail because one prompt is bad. They fail because the system accumulates old rules, duplicate files, stale routines, and conflicting authority.

If you have built an AI system across months or years, you have probably also accumulated overlap, contradictions, and files nobody can explain anymore. The instinct is to clean up file by file. That is slow and you cannot see the structural problems from inside the structure.

The work is a system audit, not a tidy. One prompt across the whole vault produces a structured diagnosis. You act on the diagnosis, not the symptom.

This is the maintenance layer for the AI System Optimization playbook. Build the system first. Audit it on cycle to keep it clean.

When to run it

Any one of these triggers is enough:

The vault feels heavy, slow to navigate, or contradictory in practice.
Three or more new files added in a 30-day window with no removals.
A routine or gate is firing on stale logic.
90 days since the last audit, regardless of how the vault feels.

Do not run more often than every 60 days. The audit triggers structural change. Compounded changes against a moving target produce noise.

If your vault has fewer than 20 active files, skip the audit. Manual pruning is faster. The audit is designed for systems that have outgrown your ability to review them file by file.

How to run it

Open Claude Code or your AI of choice. Point it at the vault root or the folder you want examined. Paste the prompt below directly. Do not add framing. Do not preload philosophy. The audit needs to start cold. Preloading weakens it.

You are conducting a systems audit of an operational AI framework repository used daily in a live business.

This is not a brainstorming exercise.

This is not a rewrite exercise.

Do not optimise for elegance, novelty, or theoretical purity.

Your job is to identify:

structural bloat
duplicated logic
overlapping protections
inconsistent authority layers
hidden contradictions
maintenance overhead
unclear ownership
token-heavy processes with weak ROI
governance friction
unnecessary abstraction
dead or superseded frameworks still influencing the system
naming drift
enforcement duplication
protocol inflation
places where operator judgment has been incorrectly codified
places where automation should replace manual process
places where automation weakens judgment and should remain manual

Assume:

the system evolved over time
many protections were added after real failures
some redundancy is intentional
not all asymmetry is a bug
the operator values leverage, speed, judgment quality, and low cognitive load over completeness

Critical instruction:

Do NOT recommend simplification unless you can explain:

what the existing mechanism is protecting against
why the protection is no longer worth the maintenance cost
what failure risk is introduced by removing it

Audit priorities:

Single source of truth violations
Multiple files solving the same problem
Frameworks whose maintenance cost exceeds practical value
Protocols that exist mainly to protect other protocols
Routing ambiguity
Gate overlap
Drift between stated architecture and actual implementation
Files with unclear authority or ownership
Excessive versioning/process overhead
Places where principles should replace procedures
Places where procedures should replace vague principles
Naming inconsistencies that increase cognitive load
Checks that create false confidence rather than real quality control
Enforcement layers that duplicate each other
Any signs of "system theatre" where complexity signals seriousness but does not materially improve outcomes

Required output format:

EXECUTIVE SUMMARY

Core diagnosis in plain language
Main structural risks
Main leverage opportunities

HIGH-CONFIDENCE REMOVALS

For each:

file/framework/process
why it should be removed
dependency risks
expected simplification gain

MERGE CANDIDATES

For each:

files involved
overlapping purpose
proposed consolidation structure
risks of merging

AUTHORITY PROBLEMS

conflicting rules
unclear ownership
circular references
source-of-truth violations

PROCESS FRICTION

routines that are too heavy
governance overhead
excessive gates/checks
token inefficiency
unnecessary review loops

ARCHITECTURE DRIFT

where the current implementation no longer matches the stated design philosophy

PROTECTED COMPLEXITY

Identify complexity that appears justified and should remain.

HIGHEST LEVERAGE CHANGES

Top 10 changes ranked by:

maintenance reduction
clarity increase
execution speed improvement
quality preservation

Rules:

Be specific.
Reference actual files and examples.
Prefer deletion over addition.
Prefer compression over expansion.
Do not invent new frameworks unless absolutely necessary.
Avoid generic productivity advice.
Do not praise the system unless tied to a specific architectural strength.

Do not act on the audit in the same pass. Read it first. Challenge it. Then execute only the changes that survive dependency and protection checks.

What to do with the results

Three filters before you act on anything the audit recommends.

First filter: protection check. If the audit suggests removing a mechanism without naming the failure mode it was built to prevent, hold it. Ask the question. Do not delete the protection.

Second filter: dependency check. Anything flagged for removal or merge needs a dependency scan. What else points at this file. What loops, gates, or routines call it. The audit may not see the full graph.

Third filter: operator judgment override. The audit treats the system as logic. Some choices are taste. If the audit recommends a change that removes something you built deliberately to enforce taste, the recommendation does not win.

Execution order

Work the recommendations in this order:

Source-of-truth conflicts first.
High-confidence removals second.
Merge candidates third.
Architecture drift fourth.
Authority problems last. These usually require a dedicated redesign session, not file edits.

Common mistakes

Skipping the protection check and deleting something that was load-bearing.
Acting on every recommendation instead of the highest-leverage ones.
Running the audit too often and producing churn instead of clarity.
Preloading philosophy or context before the prompt - the audit becomes a flattering review instead of a structural diagnosis.

The goal is not a smaller vault. The goal is a vault where every file is load-bearing.