MWMS Context Library Governance And Folder Map Standard

System: MWMS
Document Type: Standard
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, Course Absorption System, Content Brain, Offer Brain, Sales Brain, Creative Brain, 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 Context Library Governance And Folder Map Standard.

This standard establishes how MWMS organizes, stores, separates, updates, archives, and governs context libraries, skills, project folders, client libraries, and reusable AI source files.

MWMS depends on context.

But context becomes dangerous when it becomes messy.

A poorly governed context library can cause AI Employees to:

read the wrong files

use outdated instructions

mix client information

duplicate source-of-truth files

apply the wrong offer context

resurrect retired language

confuse draft material with approved material

treat project files as permanent context

use stale customer language

produce inconsistent output across Brains

This standard exists to prevent context chaos as MWMS scales.

MWMS must not rely on random folders, scattered documents, duplicated files, or ungoverned context dumps.

Each serious offer, client, Brain, skill system, or AI workflow must have a clear folder structure and authority model.

Scope

This standard applies to all MWMS context libraries, offer libraries, client libraries, skill folders, project folders, source-of-truth files, and reusable AI context packs.

This includes:

HeadOffice Brain

AI Business Systems Brain

AI Manager

AI Employee Router

Brain Room

Course Absorption System

Newsletter Intelligence

Opportunity System

Content Brain

Offer Brain

Creative Brain

Sales Brain

Conversion Brain

Customer Brain

Research Brain

Affiliate Brain

Ads Brain

future AIBS client systems

This standard applies to:

internal MWMS context libraries

offer-specific context libraries

client-specific context libraries

AI Employee context folders

skill folders

project folders

archive folders

retired language files

raw source material folders

output asset folders

audit folders

This standard does not authorize development work, plugin changes, Supabase changes, WordPress changes, automation wiring, or changes to M’s active build areas.

Core Definition

A Context Library is a governed collection of source files that AI Employees may use to understand a business, offer, client, Brain, workflow, or task.

A Folder Map is the approved structure that defines where those files live and how they are separated.

Context Library Governance defines:

where source files live

which folder is source of truth

which files are active

which files are archived

which files are project-only

which files belong to a client

which files belong to MWMS

which skills may read which context

which files must not be duplicated

which files must be updated when things change

which files must be retired or parked

Core Principle

The core principle of this standard is:

Context must be easy to find, hard to confuse, and safe to reuse.

A context file should have one clear source-of-truth location.

A client library should stay separate from MWMS internal context.

A project folder should not become permanent memory by accident.

A skill should read from the right library, not carry duplicated context inside itself.

MWMS must design folders so that future AI Employees, humans, and client systems can understand what each file is, where it belongs, and whether it is safe to use.

Primary Folder Layers

MWMS uses three primary folder layers for context-based work.

  1. Context Library

The Context Library stores durable source-of-truth context.

Examples:

Offer Context Library

Client Context Library

MWMS Brain Context Library

Business Context Library

AI Employee Context Pack

This folder contains files that should remain useful beyond one task or project.

  1. Skills Folder

The Skills Folder stores reusable procedural skills.

A skill defines how to do work.

It does not replace context files.

Examples:

Course Absorption Skill

Newsletter Signal Filtering Skill

Offer Evaluation Skill

Voice Checker Skill

Client Report Drafting Skill

Developer Handoff Precision Skill

Skills should read from approved context where possible.

  1. Project Folder

The Project Folder stores temporary work.

Examples:

campaign project

launch project

newsletter batch

course absorption block

client sprint

one-off report

ad test

funnel build

Project folders may contain temporary working files, drafts, exports, notes, and outputs.

Project folders must not become permanent context unless files are promoted deliberately.

Standard Folder Structure

The recommended base structure for MWMS context work is:

Context Area/
Context Library/
Skills/
Projects/
Archive/

For an offer or client, the recommended structure is:

Offer Or Client Name/
01 Raw Material/
02 IP Excavation/
03 Context Library/
04 Skills Or Employees/
05 Output Assets/
06 Audits/
07 Archive/

For internal MWMS Brain work, the recommended structure is:

Brain Name/
01 Source Material/
02 Canon Context/
03 Working Drafts/
04 Skills/
05 Outputs/
06 Audits/
07 Archive/

These structures may be simplified for low-risk work.

They should not be simplified for future AIBS client systems.

File Authority Rules

Rule 1: One Source Of Truth

Each active context file must have one approved source-of-truth location.

Do not maintain multiple live copies of the same context file.

Duplicated context creates drift.

Rule 2: Project Files Are Not Automatically Source Truth

A file created inside a project folder is not source of truth unless promoted.

Project work must be reviewed before it becomes library context.

Rule 3: Draft Files Are Not Active Context

Draft context files must not be treated as approved by AI Employees.

Use clear naming:

Draft

Under Review

Approved

Retired

Archived

Rule 4: Archive Is Not Active Context

Archived files are preserved for reference.

They should not be used by AI Employees unless the task specifically asks for historical comparison.

Rule 5: Retired Language Must Remain Visible

Retired Language files should remain easy for AI Employees to check.

Retired language prevents old claims, taglines, phrases, or positioning from creeping back into outputs.

Rule 6: Client Context Must Stay Separate

Client context must never be mixed with MWMS internal context or another client’s context.

Client context separation is mandatory.

Rule 7: Skills Must Reference Context, Not Duplicate It

A skill should read from the approved context library where possible.

Do not copy large context files into each skill.

The library stores what is true.

The skill defines what to do.

Naming Convention Rules

Files should use clear names that describe their role.

Good file names:

Right-Fit Client Profile

Offer Profile

Voice Architecture

Differentiation Profile

Objection Library

Methodology Map

Expert Thinking Rules

Customer Language Bank

Proof Library

Brand Visual Style

Retired Language

Compliance Notes

Bad file names:

Notes

Stuff

AI Things

Marketing

Copy Ideas

Final Final

New Doc

Random

MWMS file names should be readable by humans and AI Employees.

Version Naming

Use version markers when files are being refined.

Examples:

Voice Architecture v1

Voice Architecture v2

Offer Profile Draft

Offer Profile Approved

Sales Page Copy PRE-RESTYLE

Campaign Context May 2026

Do not use confusing version names.

Avoid:

final

final2

realfinal

latest maybe

new new

MWMS must keep version naming clear.

Multi-Offer Folder Patterns

MWMS recognizes three approved multi-offer patterns.

Pattern A: Shared Core With Offer Subfolders

Use when offers share the same brand, voice, and general methodology.

Structure:

Business Context Library/
Shared/
Offer A/
Offer B/

Shared may contain:

Voice Architecture

Brand Visual Style

Retired Language

Core Expert Thinking Rules

Brand-Level Differentiation

Offer folders may contain:

Right-Fit Client Profile

Offer Profile

Objection Library

Offer-Specific Differentiation

Proof Library

Campaign Context

Use this pattern when the offers are related but not identical.

Pattern B: Separate Libraries

Use when offers belong to separate brands, different voices, different markets, or different business models.

Structure:

Context Library – Brand A/
Context Library – Brand B/

This prevents context contamination.

Use this pattern when brand voice, buyer, or offer logic differs enough that shared context would confuse AI output.

Pattern C: One Library With Offer-Tagged Files

Use when offers have heavy overlap and only minor differences.

Structure:

Business Context Library/
Voice Architecture
Right-Fit Client Profile – Offer A
Right-Fit Client Profile – Offer B
Offer Profile – Offer A
Offer Profile – Offer B
Objection Library – Offer A
Objection Library – Offer B

Use carefully.

If AI Employees start mixing offers, upgrade to Pattern A or Pattern B.

Client Folder Standard

Future AIBS client systems require strict folder separation.

Recommended client structure:

Client Name/
Their Library/
Their Skills/
Working/
Outputs/
Audits/
Archive/

Their Library may include:

Client Voice Architecture

Client Offer Profile

Client Right-Fit Client Profile

Client Objection Library

Client Methodology Map

Client Expert Thinking Rules

Client Customer Language Bank

Client Proof Library

Client Compliance Notes

Their Skills may include:

Client Content Skill

Client Report Skill

Client Voice Checker Skill

Client Offer Copy Skill

Client Support Reply Skill

Working may include:

current drafts

campaign work

temporary analysis

in-progress outputs

Outputs may include:

approved deliverables

sent reports

published assets

final files

Audits may include:

context audit

skill audit

output quality review

client approval review

Archive may include:

completed projects

old versions

retired materials

Client Privacy Rules

Client context must be isolated.

MWMS must not:

mix client files with MWMS internal files

reuse one client’s language for another client

copy client stances into MWMS content

store client confidential information in general MWMS context

mount or load unrelated client context

allow client-specific skills to influence other client outputs

Client context is client-owned unless contract, approval, or governance says otherwise.

Project Folder Rules

Projects are temporary work containers.

Examples:

Q2 Launch

Newsletter May Batch

VEO3 Campaign Set

Client Onboarding Sprint

Offer Audit

Course Absorption Block

Ad Testing Sprint

Project folders may include:

briefs

drafts

temporary source files

exports

output versions

test files

review notes

Project folders must be cleared, archived, or promoted after the project ends.

Project Completion Outcomes

At the end of a project, each useful file must be classified.

Possible outcomes:

Promote To Context Library

Keep As Output Asset

Archive

Delete If Safe

Park For Later

Merge Into Existing Context

No project folder should remain messy forever.

Raw Material Folder Rules

Raw material folders store source material before it is processed.

Examples:

course files

client notes

emails

sales pages

voice memos

survey exports

customer interviews

screenshots

transcripts

Raw material is source evidence.

It is not automatically approved context.

Raw material must be extracted, reviewed, and transformed before becoming active context.

Output Asset Folder Rules

Output Asset folders store created deliverables.

Examples:

landing pages

emails

ad scripts

VEO3 scripts

lead magnets

webinar outlines

reports

sales pages

client deliverables

Output assets are not automatically context files.

If an output asset contains useful durable rules or language, extract that value into the context library rather than treating the whole output as context.

Archive Rules

Archive folders preserve old material without keeping it active.

Archive when:

project is complete

file is outdated

offer is retired

skill is retired

campaign is finished

old language should be preserved for reference

duplicate file is no longer active

client engagement is complete

Archive files should not be deleted unless deletion is approved.

Archive files should not be read by default for active output generation.

Retired Language Rules

Every active offer or brand library should have a Retired Language file when language changes over time.

Retired Language may include:

old taglines

old positioning

banned phrases

outdated claims

compliance-sensitive wording

language that no longer reflects the offer

phrases the founder dislikes

old campaign slogans

words that make copy sound generic

Retired Language is active context.

It exists to prevent old language from returning.

Update Trigger Rules

Context libraries must be updated when important changes occur.

Update triggers include:

new offer created

offer retired

offer repositioned

buyer changes

pricing changes

voice changes

methodology changes

new objections appear

new proof appears

compliance constraints change

customer language changes

AI output starts sounding wrong

old language resurfaces

skills require repeated correction

client feedback changes direction

campaign data reveals new learning

sales conversations reveal repeated friction

Do not let known context drift sit unresolved.

Context drift compounds.

Monthly Folder Check

For active libraries, MWMS should perform a light folder check monthly.

The monthly check asks:

Are files in the right folders?

Are there duplicates?

Are old project files still active?

Are draft files clearly marked?

Are retired files archived?

Is Retired Language visible?

Are client files isolated?

Are any files named poorly?

Are any folders becoming cluttered?

This check should be quick.

It prevents later cleanup pain.

Quarterly Library Audit

Each active context library should receive a deeper quarterly audit.

The quarterly audit asks:

Is each context file still true?

Is each context file still current?

Does the buyer profile still match the offer?

Does the offer profile still match reality?

Does voice still match current usage?

Are objections still current?

Is proof still approved?

Is old language creeping back?

Are skills reading the correct files?

Are there conflicting files?

Should the library be refreshed, split, merged, parked, or retired?

Quarterly library audits should align with AI Skill Audit cycles where possible.

Audit Outcomes

Each library audit must end with one of the following outcomes:

Current

Minor Refresh Required

Major Refresh Required

Split Library

Merge Library

Park Library

Retire Library

Archive Old Files

Human Review Required

No audit should end without a decision.

Context Promotion Rules

Files should be promoted into active context only after review.

Promotion requirements:

source material reviewed

content extracted

file structured

specificity checked

human-reviewed where required

destination clear

source-of-truth location defined

duplicates checked

status assigned

Do not promote rough notes directly into active context.

Context Demotion Rules

Files should be demoted when no longer reliable.

Demotion outcomes:

Move To Archive

Move To Retired

Park For Review

Replace With Updated Version

Merge Into Current File

Delete If Safe And Approved

Demotion should be deliberate, not accidental.

Common Failure Modes

MWMS must prevent:

folders multiplying without rules

duplicated context files

client files mixed with MWMS files

draft files used as approved context

project files becoming accidental memory

old language returning

archive files used as active source

skills carrying duplicated context

AI Employees reading the wrong offer folder

multiple Brains using different versions of the same offer

context libraries becoming bloated

no audit cadence

unclear file authority

unclear source-of-truth location

wrong client context loaded

Governance Role

HeadOffice owns the MWMS Context Library Governance And Folder Map Standard.

HeadOffice is responsible for:

defining folder structure

preventing context duplication

protecting source-of-truth discipline

governing archive rules

governing context promotion and demotion

requiring client context isolation

ensuring skills read from correct context

ensuring folder checks and audits occur

protecting MCR from messy context transfer

protecting future AIBS client systems

Individual Brains may maintain their own libraries, but they must align with this standard.

AI Business Systems Brain governs future client-library packaging.

Offer Brain governs offer-specific interpretation.

Content Brain governs content-use context.

Sales Brain governs sales-use context.

Creative Brain governs creative-use context.

Compliance Brain governs claims-risk context.

Relationship To Other MWMS Standards

This standard 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 Client IP Excavation Framework

MWMS Course Absorption Operating Rule

MWMS Messy Input Normalization Framework

MWMS AI Output Validation Standard

MWMS Brain Routing Rule

MWMS MCR Promotion To Brain Protocol

MWMS Page Naming Standard

MWMS Architecture Registry

MWMS AI Employee Role Card Standard

MWMS AI Employee Capability Stack Framework

MWMS AI Tool Permission And Access Framework

Content Brain VOC Grounded AI Copy Framework

Research Brain Voice Of Customer Extraction Framework

AI Business Systems Brain Canon

This standard governs the folder and source-of-truth structure that makes those standards usable at scale.

Drift Protection

This standard protects MWMS from:

context sprawl

folder chaos

duplicate files

stale source truth

client context leakage

wrong offer context usage

draft context activation

archive context misuse

project file confusion

skill-context duplication

retired language returning

AI Employees reading the wrong files

manual re-explaining of the same context

MCR being polluted with ungoverned working material

future AIBS client systems becoming unsafe or confusing

Any context folder that does not have clear active, draft, archive, and source-of-truth separation should be treated as a drift risk.

Architectural Intent

The architectural intent of the MWMS Context Library Governance And Folder Map Standard is to make context durable, findable, governed, and safe to reuse.

MWMS will increasingly depend on AI Employees that need to know what to read before acting.

Those AI Employees cannot rely on scattered documents.

They need a clean folder architecture that answers:

Where is the source truth?

Which files are active?

Which files are draft?

Which files are archived?

Which files belong to this client?

Which files belong to this offer?

Which files should skills read?

Which files must not be used?

Which files need updating?

What has been retired?

What can be safely reused?

When MWMS can answer these questions consistently, AI work becomes more reliable, more scalable, easier to govern, and safer for future client systems.

Change Log

v1.0 — Initial Draft

Created the MWMS Context Library Governance And Folder Map Standard as the governance standard for organizing, separating, updating, archiving, and maintaining context libraries, skills folders, project folders, raw material folders, output folders, client libraries, retired language files, and future AIBS context structures.

This standard defines primary folder layers, file authority rules, naming conventions, multi-offer patterns, client folder standards, privacy rules, project folder rules, raw material rules, archive rules, retired language rules, update triggers, folder checks, quarterly audits, promotion and demotion rules, failure modes, governance role, drift protection, and architectural intent.

Change Impact Declaration

Pages Created:

MWMS Context Library Governance And Folder Map Standard

Pages Updated:

None

Pages Deprecated:

None

Registries Requiring Update:

MWMS Architecture Registry

HeadOffice Page Registry

AI Business Systems Brain Page Registry

Offer Brain Page Registry

Content 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

Offer Strategist Employee

Content Planner Employee

Creative Strategist Employee

Sales Strategist Employee

AI Business Systems Architect Employee

Course Absorption Agent

Required behaviour updates:

AI Employees must not treat random folders, project files, or draft files as approved context.

AI Employees must respect one source-of-truth file locations and avoid duplicating context across skills or folders.

AI Employees must keep client context isolated from MWMS internal context and other client systems.

AI Employees must check Retired Language where relevant to avoid resurrecting outdated claims, phrases, positioning, or brand wording.

AI Employees must route useful project outputs through review before promoting them into active context libraries.

END MWMS CONTEXT LIBRARY GOVERNANCE AND FOLDER MAP STANDARD v1.0