System: MWMS
Document Type: Framework
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, AI Business Systems Brain, AI Manager, AI Employee Router, Brain Room, Content Brain, Offer Brain, Sales Brain, Creative Brain, Course Absorption System, Future AIBS Client Systems
Parent Page: HeadOffice
Owner: Martyn
Developer Boundary: No Development Action Authorized By This Page
Source Of Truth: MCR
Purpose
The purpose of this document is to define the MWMS AI Brain Audit And Decay Prevention Framework.
This framework establishes how MWMS detects, prevents, reviews, and corrects decay inside AI Brains, context libraries, skills, AI Employee procedures, offer files, voice systems, customer language banks, and client-specific AI systems.
MWMS will not remain accurate simply because a Brain, file, skill, or context library was once created correctly.
AI systems decay when:
offers change
markets shift
buyer language changes
old claims become unsafe
skills overlap
voice files become stale
client context changes
old positioning remains active
new proof is not added
retired language keeps resurfacing
AI Employees keep repeating old instructions
context libraries become bloated or duplicated
manual corrections are not turned into system updates
This framework exists to ensure MWMS treats AI Brains and AI skills as living systems, not static documents.
The goal is to prevent useful AI infrastructure from slowly becoming outdated, noisy, unsafe, or unreliable.
Scope
This framework applies to all MWMS Brains, AI Employees, context libraries, skill systems, offer libraries, client libraries, and future AIBS client systems.
This includes:
HeadOffice Brain
AI Business Systems Brain
AI Manager
AI Employee Router
Brain Room
Course Absorption System
Newsletter Intelligence
Opportunity System
Offer Brain
Content Brain
Creative Brain
Sales Brain
Conversion Brain
Customer Brain
Research Brain
Affiliate Brain
Ads Brain
Product Brain
Strategy Brain
Operations Brain
future AIBS client systems
This framework applies to:
AI Brain audits
context library audits
skill audits
voice audits
offer context audits
client Brain audits
customer language audits
retired language audits
proof library audits
AI Employee procedure audits
workflow drift reviews
manual correction reviews
This framework does not authorize technical development, plugin changes, Supabase changes, WordPress changes, automation wiring, or M developer action.
Core Definition
AI Brain Decay refers to the gradual loss of accuracy, usefulness, alignment, safety, or operational value inside an AI system.
Decay can occur in:
context files
skills
AI Employee instructions
voice rules
offer profiles
proof libraries
customer language banks
folder structures
workflow procedures
Brain routing rules
client context
manual prompts
audit records
Decay is not always obvious.
A system may still produce polished outputs while becoming less accurate.
The warning sign is not whether the output looks good.
The warning sign is whether the output still reflects current source truth, current strategy, current offer logic, current buyer reality, and current MWMS governance.
Core Principle
The core principle of this framework is:
Every AI Brain, skill, and context library must be reviewed before drift becomes operational damage.
MWMS must not wait until a system completely fails.
Small decay should be detected early.
Small corrections should be made before they compound.
This aligns with the MWMS Kaizen philosophy.
AI Brain audit work is not cleanup for its own sake.
It is ecosystem protection.
Primary Decay Types
MWMS recognizes ten major types of AI Brain decay.
- Context Decay
Context Decay occurs when source files are no longer current.
Examples:
offer details changed
price changed
buyer profile changed
positioning changed
proof changed
methodology changed
old campaign notes remain active
customer language is outdated
Risk:
AI Employees create outputs from stale context.
- Skill Decay
Skill Decay occurs when a reusable AI skill no longer follows the best current procedure.
Examples:
skill uses outdated rules
skill misses new standards
skill triggers incorrectly
skill produces old format
skill ignores new validation rules
skill overlaps with another skill
Risk:
Repeated work becomes repeatedly wrong.
- Voice Decay
Voice Decay occurs when AI output no longer sounds like the approved voice.
Examples:
copy becomes too polished
tone becomes generic
old phrases return
AI uses words the founder dislikes
brand becomes inconsistent
outputs from different Brains sound unrelated
Risk:
Trust and brand coherence weaken.
- Offer Decay
Offer Decay occurs when the AI system’s understanding of the offer no longer matches reality.
Examples:
old offer promise remains active
new inclusions are missing
old bonuses are mentioned
wrong audience is targeted
risk reversal changed
delivery model changed
Risk:
Public-facing assets misrepresent the offer.
- Proof Decay
Proof Decay occurs when proof assets become incomplete, outdated, unsupported, or risky.
Examples:
old testimonials remain active
case studies are no longer accurate
claims lack evidence
new proof is not added
compliance-sensitive claims are not flagged
Risk:
Sales, ads, and content use weak or unsafe credibility signals.
- Customer Language Decay
Customer Language Decay occurs when buyer wording, objections, anxieties, and desired outcomes are no longer current.
Examples:
new objections appear
old customer phrases are overused
buyer sophistication changes
market language shifts
support tickets reveal new friction
Risk:
Copy becomes disconnected from buyer reality.
- Folder Decay
Folder Decay occurs when the context library structure becomes messy.
Examples:
duplicate files
unclear source truth
drafts mixed with approved files
project files left active
archive files used accidentally
client files mixed with internal files
Risk:
AI Employees read the wrong files.
- Routing Decay
Routing Decay occurs when work no longer flows to the correct Brain, Employee, queue, or review path.
Examples:
course insights routed to wrong Brain
newsletter signals over-prioritized
offer decisions skip Research Brain
financial decisions skip Finance Brain
content outputs skip validation
Risk:
The system makes wrong operational decisions.
- Governance Decay
Governance Decay occurs when standards are not followed consistently.
Examples:
MCR pages use wrong structure
human review is skipped
change impact declarations are missing
citations or external course language leak into page output
M’s active boundary is ignored
Risk:
MCR becomes inconsistent and harder to govern.
- Client System Decay
Client System Decay occurs in future AIBS systems when client-specific context, skills, reports, or workflows become outdated.
Examples:
client offer changes
client approval rules change
client voice changes
client campaign goals change
client tool permissions change
client context leaks into another system
Risk:
Client-facing AI becomes unsafe, inaccurate, or untrustworthy.
Audit Triggers
MWMS should audit AI Brains, skills, and context libraries when any of the following occur.
Scheduled Trigger
quarterly review
monthly light check
after major campaign cycle
after launch
after major client delivery
after major course absorption block
after major system update
Performance Trigger
AI output keeps needing correction
output requires rewriting instead of polishing
content sounds generic
ads lose message clarity
reports become less useful
client feedback identifies mismatch
human operator keeps repeating the same correction
Context Trigger
offer changes
price changes
buyer profile changes
voice changes
new objections appear
new proof appears
compliance risk changes
old language is retired
new customer research is collected
System Trigger
new standard created
Brain rule changed
skill updated
workflow changed
tool permission changed
folder structure changed
AI Employee role changed
MCR page structure changed
Risk Trigger
public-facing output risk
client-facing output risk
paid traffic risk
compliance risk
financial decision risk
developer handoff risk
private client context risk
Audit Cadence
MWMS uses three audit cadences.
Light Monthly Check
Purpose:
Catch obvious drift early.
Checks:
duplicate files
wrong folders
stale drafts
retired language resurfacing
repeated user corrections
skills producing wrong formats
outputs sounding generic
missing review status
Quarterly Full Audit
Purpose:
Review active systems properly.
Checks:
context accuracy
skill usefulness
voice consistency
offer accuracy
customer language freshness
proof status
folder governance
AI Employee alignment
Brain routing accuracy
human review requirements
Kaizen learning capture
Event-Based Audit
Purpose:
Review immediately after a major change.
Triggered by:
new offer
new client
new launch
campaign result
major user correction
new compliance concern
major course absorption
major Brain update
new AI Employee creation
Audit Objects
MWMS may audit different objects depending on need.
Context Library Audit
Checks whether the context library remains accurate, current, specific, and source-grounded.
Skill Audit
Checks whether a reusable AI skill still performs the correct procedure.
Voice Audit
Checks whether AI output still matches the approved voice.
Offer Audit
Checks whether AI output still matches the current offer.
Proof Audit
Checks whether proof remains approved, current, and safe.
Customer Language Audit
Checks whether customer wording and objections remain current.
Folder Audit
Checks whether context files are stored correctly.
AI Employee Audit
Checks whether the AI Employee role, capability, context, skill, permission, and output behaviour remain aligned.
Client Brain Audit
Checks whether a future AIBS client system remains accurate, isolated, permissioned, and useful.
Standard Audit Workflow
MWMS uses the following audit workflow.
Step 1: Identify Audit Object
Define what is being audited.
Examples:
Offer Context Library
Voice Architecture
Course Absorption Skill
Client Report Skill
Content Brain output
AIBS client library
Step 2: Identify Current Source Of Truth
Locate the current approved source files.
Do not rely only on memory.
Step 3: Review Recent Outputs
Check recent outputs produced from the Brain, skill, or library.
Examples:
ads
emails
reports
content
scripts
page output
client deliverables
developer handoffs
Step 4: Compare Output Against Source Truth
Check whether outputs still match approved context and standards.
Step 5: Identify Drift Signals
Look for stale, generic, inaccurate, duplicated, unsupported, unsafe, or inconsistent behaviour.
Step 6: Classify Drift Severity
Classify as:
No Drift
Minor Drift
Moderate Drift
Major Drift
Critical Drift
Step 7: Decide Audit Outcome
Choose a clear outcome.
No audit should end in uncertainty.
Step 8: Apply Correction Or Route
Depending on the outcome, refresh, split, merge, park, retire, escalate, or update.
Step 9: Record Learning
Add useful lessons to the appropriate log, registry, context file, or skill update.
Step 10: Schedule Next Review
Set next review timing if the object remains active.
Drift Severity Levels
No Drift
The object remains current and useful.
Action:
keep active
next normal review
Minor Drift
Small corrections needed.
Examples:
one outdated phrase
minor voice mismatch
small format issue
Action:
refresh relevant section
keep active
Moderate Drift
Repeated issues appear.
Examples:
frequent user correction
missing new standard
outdated objections
wrong output format recurring
Action:
update skill or context
review related outputs
Major Drift
System behaviour is unreliable.
Examples:
wrong offer promise
stale buyer profile
incorrect proof
wrong Brain routing
conflicting skills
Action:
pause use
repair before further high-value output
human review required
Critical Drift
Output could create serious risk.
Examples:
client context leakage
unsupported claims in ads
developer instructions from stale state
financial recommendation from outdated assumptions
compliance-sensitive false proof
Action:
stop use
escalate to HeadOffice
human review required
possible retirement or rebuild
Audit Outcomes
Every audit must end with one or more clear outcomes.
Current
Object remains valid.
Refresh
Update part of the object.
Split
Divide a broad object into smaller clearer objects.
Merge
Combine overlapping objects.
Park
Keep for later but remove from active use.
Retire
Remove from active use permanently.
Escalate
Send to HeadOffice or relevant Brain for review.
Rebuild
Object is too broken and needs full reconstruction.
Archive
Move old material out of active context.
Audit Outcome Rules
No audit should end with “maybe.”
If confidence is low, use:
Human Review Required
Park For Review
Escalate To HeadOffice
Do not keep uncertain material active without marking it.
Rewrite Versus Polish Rule
MWMS uses the Rewrite Versus Polish Rule to detect skill and output decay.
If the human reviewer only polishes small details, the skill or context may be healthy.
If the human reviewer must rewrite the structure, logic, voice, source grounding, or output format, the skill or context needs review.
Polishing signals normal refinement.
Rewriting signals system decay.
Examples of polishing:
small wording change
minor tone adjustment
one heading adjustment
minor formatting correction
Examples of rewriting:
wrong structure
wrong page style
wrong Brain logic
wrong offer
wrong buyer
wrong context
wrong output format
missing key rules
invented proof
generic AI filler
Context Library Audit Questions
Ask:
Is this library still active?
Is the source-of-truth location clear?
Are any files duplicated?
Are draft files clearly marked?
Are archived files inactive?
Is Retired Language current?
Is the buyer profile still accurate?
Is the offer profile still accurate?
Is the methodology still accurate?
Are objections still current?
Is proof still approved?
Is customer language still fresh?
Are compliance notes current?
Are skills reading the correct library?
Are outputs still matching the library?
Skill Audit Questions
Ask:
Is the skill still used?
Does the task still repeat?
Does the skill still match the current MWMS process?
Does the trigger still work?
Does it trigger when it should not?
Does it require current context?
Does it define forbidden actions?
Does it define validation?
Does it define handoff?
Does it respect tool permissions?
Does it require human review?
Does it overlap another skill?
Does it conflict with another skill?
Does it need refresh, merge, split, park, or retirement?
Voice Audit Questions
Ask:
Does output still sound like the approved voice?
Is AI over-polishing?
Are banned phrases appearing?
Are founder phrases being preserved where useful?
Is tone consistent across Brains?
Is copy becoming generic?
Is humour, directness, or formality drifting?
Is the voice still appropriate for the buyer?
Is the voice file still current?
Offer Audit Questions
Ask:
Does output still describe the offer accurately?
Is the promise correct?
Are inclusions correct?
Is pricing current where relevant?
Is the buyer still correct?
Is risk reversal current?
Are limitations clear?
Are old bonuses or features appearing?
Are new offer details missing?
Is the methodology still represented correctly?
Proof Audit Questions
Ask:
Is proof approved?
Is proof still current?
Is proof being used accurately?
Are claims supported?
Are testimonials allowed?
Are case studies current?
Are compliance-sensitive claims flagged?
Is AI inventing proof?
Is proof being overstated?
Customer Language Audit Questions
Ask:
Are customer phrases still current?
Have new objections appeared?
Have new anxieties appeared?
Have desired outcomes changed?
Are old phrases overused?
Is AI inventing customer language?
Is customer language being used strategically?
Does copy still reflect buyer reality?
AI Employee Audit Questions
Ask:
Does the AI Employee still have a clear role?
Does it have the right context?
Does it use the right skills?
Does it respect tool boundaries?
Does it produce the correct output?
Does it route output correctly?
Does it know when to escalate?
Does it avoid forbidden actions?
Does it require too much correction?
Does it create useful outcomes?
Audit Record Template
Each audit should be recorded using the following structure.
Audit Name:
Audit Object:
Owning Brain:
Audit Type:
Audit Date:
Reviewer:
Current Status:
Source Of Truth Checked:
Recent Outputs Reviewed:
Drift Signals Found:
Drift Severity:
Audit Outcome:
Required Corrections:
Related Files Or Skills Affected:
Human Review Required:
Next Review Date:
Learning Captured:
Notes:
Minimum Audit Record
For quick audits, use:
Audit Object:
Date:
Status:
Drift Found:
Outcome:
Action Required:
Next Review:
Kaizen Connection
This framework connects directly to the MWMS Kaizen Loop.
Every audit should support:
Reflect
What happened?
Reduce
What can be simplified or removed?
Refine
What should be improved?
Record
What learning should be captured?
AI Brain audit work should not only fix individual files.
It should improve the system’s ability to avoid the same failure next time.
Human Review Rule
Human review is required when an audit identifies:
Major Drift
Critical Drift
client-facing risk
compliance risk
paid traffic risk
financial risk
developer risk
MCR source-of-truth risk
client context leakage risk
unsupported proof
wrong offer promise
human-visible public output risk
AI Employees may identify drift, but high-risk correction requires human review.
Client Brain Audit Rule
Future AIBS client systems must include recurring audit logic.
Client Brain audits should check:
client offer accuracy
client voice accuracy
client context separation
client permissions
client approval rules
client reporting accuracy
client skill performance
client proof usage
client compliance constraints
client data sensitivity
Client AI systems should not be sold as set-and-forget.
They must include maintenance and audit expectations.
Governance Role
HeadOffice owns the MWMS AI Brain Audit And Decay Prevention Framework.
HeadOffice is responsible for:
defining audit rules
setting review cadence
classifying drift severity
ensuring high-risk drift is escalated
ensuring audits produce clear outcomes
preventing stale context from staying active
ensuring skills are refreshed or retired
ensuring client systems remain isolated
ensuring AI Employees improve through Kaizen
ensuring audit findings update relevant files, standards, or skills
Individual Brains may run their own audits, but HeadOffice governs cross-Brain, high-risk, MCR, AI Employee, and future client-system audit behaviour.
Relationship To Other MWMS Standards
This framework supports and must align with:
MWMS Document Structure Standard
MWMS AI Agent Memory And Context Framework
MWMS AI Agent Skill Library Framework
MWMS AI Skill Builder And Audit Protocol
MWMS Offer Context Library Standard
MWMS Context Library Governance And Folder Map Standard
MWMS AI Context Activation And Usage Protocol
MWMS Client IP Excavation Framework
MWMS AI Output Validation Standard
MWMS Messy Input Normalization Framework
MWMS AI Employee Role Card Standard
MWMS AI Employee Capability Stack Framework
MWMS AI Employee Evaluation Scorecard Standard
MWMS Agentic Reporting Standard
MWMS AI Agent Outcome Measurement Framework
MWMS Brain Routing Rule
MWMS MCR Promotion To Brain Protocol
MWMS Page Naming Standard
MWMS Architecture Registry
HeadOffice Kaizen Continuous Improvement Loop
Content Brain VOC Grounded AI Copy Framework
Compliance Brain Claims Risk Framework
AI Business Systems Brain Canon
This framework provides the audit and decay-prevention layer for context, skills, Brains, AI Employees, and future client systems.
Drift Protection
This framework protects MWMS from:
stale context
stale skills
generic AI output
outdated voice
wrong offer information
unsupported proof
old language resurfacing
folder decay
client context leakage
wrong Brain routing
governance erosion
manual corrections never becoming system improvements
AI Employees becoming less useful over time
skills remaining active after they are outdated
context libraries becoming bloated or duplicated
future client AI systems becoming unsafe or inaccurate
Any AI system that has not been reviewed after major change or repeated correction should be treated as a drift risk.
Architectural Intent
The architectural intent of the MWMS AI Brain Audit And Decay Prevention Framework is to keep MWMS intelligent over time.
The value of MWMS is not only in creating Brains, skills, context libraries, and AI Employees.
The value is in keeping them current, useful, aligned, and governed.
The long-term goal is that every active AI Brain, context library, skill, and client system can answer:
Is this still true?
Is this still useful?
Is this still current?
Is this still source-grounded?
Is this still aligned with MWMS standards?
Is this still safe to use?
Is this still producing good outputs?
Does it require polishing or rewriting?
Should it be refreshed, merged, split, parked, retired, or rebuilt?
When MWMS can answer these questions consistently, the ecosystem becomes more resilient, more accurate, more scalable, and safer for future client delivery.
Change Log
v1.0 — Initial Draft
Created the MWMS AI Brain Audit And Decay Prevention Framework as the audit and maintenance framework for preventing decay across MWMS Brains, AI Employees, context libraries, skill systems, offer files, voice systems, customer language banks, proof libraries, folder structures, and future AIBS client systems.
This framework defines decay types, audit triggers, audit cadence, audit objects, audit workflow, drift severity levels, audit outcomes, rewrite-versus-polish rule, audit questions, audit records, Kaizen connection, human review requirements, client Brain audit rules, governance role, drift protection, and architectural intent.
Change Impact Declaration
Pages Created:
MWMS AI Brain Audit And Decay Prevention Framework
Pages Updated:
None
Pages Deprecated:
None
Registries Requiring Update:
MWMS Architecture Registry
HeadOffice Page Registry
AI Business Systems Brain Page Registry
Content Brain Page Registry
Offer Brain Page Registry
Canon Version Update Required:
No
Change Log Entry Required:
Yes
Employee Impact Check
Employees impacted:
HeadOffice Manager Employee
AI Manager
AI Employee Router
Context Library Builder
Client IP Excavator
Skill Auditor
Offer Strategist Employee
Content Planner Employee
Creative Strategist Employee
Sales Strategist Employee
Research Analyst Employee
AI Business Systems Architect Employee
Required behaviour updates:
AI Employees must treat Brains, context libraries, skills, and client systems as living systems that require review.
AI Employees must flag repeated human rewriting as a decay signal.
AI Employees must identify stale context, stale skills, old language, unsupported proof, wrong offer details, and client context leakage risks.
AI Employees must route moderate, major, and critical drift to the correct review pathway.
AI Employees must capture useful audit findings as Kaizen learning and update relevant context, skill, or governance records after approval.
END MWMS AI BRAIN AUDIT AND DECAY PREVENTION FRAMEWORK v1.0