MWMS Offer Context Library 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, Offer Brain, Content Brain, Sales Brain, Creative Brain, Conversion Brain, Customer Brain, AI Manager, AI Employee Router, 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 Offer Context Library Standard.

This standard establishes how MWMS stores, structures, governs, updates, and uses the core context files required for an offer, client system, Brain, campaign, product, service, or internal MWMS business system.

MWMS must not rely on scattered notes, repeated prompts, vague memory, or one-off explanations when creating AI-generated business outputs.

A serious AI system needs a stable context library.

The Offer Context Library is the reusable intelligence layer that tells MWMS AI Employees:

who the offer is for

what the offer does

why the offer is different

how the founder or business speaks

what the buyer believes

what objections must be handled

what proof exists

what methodology supports the transformation

what language must be avoided

what visual and brand rules apply

This standard exists to ensure that every serious MWMS offer or future AIBS client system has one clear source of truth for offer-specific context.

Without this standard, MWMS risks:

AI Employees using incomplete context

different Brains producing inconsistent output

old language reappearing after being retired

ads, content, funnels, and sales assets drifting apart

client systems becoming messy

offer positioning becoming diluted

duplicate files creating conflicting instructions

future AI Employees starting from zero every time

The Offer Context Library turns extracted business intelligence into reusable operational context.

Scope

This standard applies to all MWMS offers, client systems, Brain systems, campaigns, products, services, and strategic assets that require reusable AI context.

This includes:

AI Business Systems Brain

HeadOffice Brain

Offer Brain

Content Brain

Creative Brain

Conversion Brain

Customer Brain

Sales Brain

Research Brain

Affiliate Brain

Ads Brain

Product Brain

Strategy Brain

AI Manager

AI Employee Router

Course Absorption System

client Brain creation

offer intelligence pages

affiliate offer systems

VEO3 script systems

landing page systems

email systems

webinar systems

lead magnet systems

future AIBS client systems

This standard applies after Client IP Excavation has produced enough approved source intelligence.

It does not authorize technical development, database work, plugin changes, automation wiring, Supabase changes, WordPress changes, or M developer action.

Core Definition

An Offer Context Library is a structured set of source-of-truth context files that describe one offer, client system, product, service, Brain, or business package in a way AI Employees can reliably use.

The library is not a folder of random notes.

It is a governed context layer.

It may include:

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

Campaign Context

Compliance Notes

The Offer Context Library answers:

Who is this for?

What problem does it solve?

What transformation does it promise?

How does it work?

Why is it different?

What does the buyer already believe?

What must the buyer stop believing?

What objections matter?

What proof can be used?

What language should AI preserve?

What language should AI avoid?

What should AI never invent?

Core Principle

The core principle of this standard is:

One offer needs one governed context source.

MWMS must avoid scattered, duplicated, or conflicting context.

If multiple AI Employees are creating outputs for the same offer, they must read from the same approved context library.

The context library becomes the source layer for:

ads

content

emails

funnels

landing pages

sales scripts

VEO3 scripts

webinars

lead magnets

client reports

AI Employee instructions

campaign briefs

offer evaluations

The stronger and cleaner the context library, the more consistent and useful MWMS outputs become.

Context Library Relationship To IP Excavation

The Offer Context Library is built after Client IP Excavation.

Client IP Excavation produces the foundation:

Contrarian Stances

Methodology And Process

Expert Thinking

The Offer Context Library turns those foundation files into operational files that AI Employees can use repeatedly.

The relationship is:

IP Excavation extracts the raw intelligence.

Offer Context Library organizes the intelligence.

AI Skills and Employees use the intelligence.

Business assets are created from the intelligence.

MWMS must not skip from raw source material directly to asset creation when the work is important.

The context library is the middle layer that protects quality.

Required Library Files

The standard MWMS Offer Context Library should include the following files where applicable.

Not every offer requires every file at the start.

However, serious MWMS offers and future AIBS client systems should move toward a complete library over time.

  1. Right-Fit Client Profile

Purpose:

Defines the specific buyer, customer, client, user, or audience the offer is designed to serve.

This file should include:

buyer type

current situation

stage of awareness

core problem

top-of-mind pain

desired outcome

emotional state

practical constraints

buying triggers

false beliefs

decision criteria

who this is not for

language the buyer uses

trust barriers

urgency level

This file prevents AI from writing for a vague audience.

Used by:

Content Brain

Sales Brain

Ads Brain

Conversion Brain

Customer Brain

Research Brain

Offer Brain

  1. Offer Profile

Purpose:

Defines what the offer is, what it includes, what problem it solves, and what transformation it creates.

This file should include:

offer name

offer type

price or pricing model where relevant

delivery model

included components

main promise

core transformation

problem solved

before state

after state

mechanism

limitations

eligibility

proof points

risk reversal

next step

This file prevents AI from misrepresenting the offer.

Used by:

Offer Brain

Sales Brain

Content Brain

Ads Brain

Affiliate Brain

Conversion Brain

AI Business Systems Brain

  1. Voice Architecture

Purpose:

Defines how the founder, business, brand, or offer should sound.

This file should include:

tone

rhythm

sentence style

phrases to use

phrases to avoid

banned words

preferred emotional register

humour level

directness level

formality level

story style

CTA style

examples of strong voice

examples of weak voice

This file prevents AI from sounding generic, corporate, or unlike the business.

Used by:

Content Brain

Creative Brain

Sales Brain

Ads Brain

VEO3 script systems

Email systems

Client report systems

  1. Differentiation Profile

Purpose:

Defines why the offer, business, method, or system is different from alternatives.

This file should include:

main differentiator

category contrast

old way versus new way

market misconceptions

competitor differences

positioning angle

unique mechanism

buyer advantage

sacrifice or trade-off

what the offer refuses to do

why the difference matters

This file prevents AI from creating interchangeable messaging.

Used by:

Strategy Brain

Offer Brain

Creative Brain

Ads Brain

Content Brain

Sales Brain

  1. Objection Library

Purpose:

Captures the objections, hesitations, doubts, risks, and decision blockers that prevent the buyer from acting.

This file should include:

price objections

timing objections

trust objections

complexity objections

self-doubt objections

past failure objections

comparison objections

implementation objections

platform/tool objections

decision-maker objections

reframe for each objection

proof needed for each objection

language to avoid

This file prevents AI from ignoring buyer resistance.

Used by:

Sales Brain

Conversion Brain

Content Brain

Ads Brain

Offer Brain

Customer Brain

  1. Methodology Map

Purpose:

Captures the process, system, framework, or mechanism behind the offer.

This file should include:

first step

core steps

sequence

pillars

named framework

what each step does

what each step prevents

why the order matters

where buyers usually get stuck

expected transformation

delivery logic

This file prevents AI from treating the offer as a vague promise.

Used by:

AI Business Systems Brain

Offer Brain

Sales Brain

Content Brain

Product Brain

AI Employee workflows

  1. Expert Thinking Rules

Purpose:

Captures the diagnostic logic and judgment the expert applies when making decisions.

This file should include:

first diagnostic checks

pattern recognition signals

decision branches

if/then rules

quality thresholds

rejection criteria

escalation conditions

stuck-state logic

unexpected advice patterns

strategic judgment rules

This file helps AI Employees act more like trained operators instead of basic assistants.

Used by:

HeadOffice Brain

AI Manager

AI Employee Router

Research Brain

Experimentation Brain

Offer Brain

Ads Brain

Conversion Brain

  1. Customer Language Bank

Purpose:

Stores real customer wording that can improve copy, content, ads, emails, sales scripts, and onboarding.

This file should include:

customer phrases

buyer metaphors

emotional wording

problem wording

desired outcome wording

objections in customer words

trust concerns

comparison language

before-state language

after-state language

This file prevents AI from inventing buyer reality.

Used by:

Content Brain

Creative Brain

Conversion Brain

Sales Brain

Customer Brain

Research Brain

  1. Proof Library

Purpose:

Stores approved proof that may be used in business outputs.

This file should include:

testimonials

case studies

results

before/after examples

demonstrations

screenshots

data points

third-party references

media mentions

customer quotes

proof restrictions

claims that require caution

This file prevents AI from inventing credibility.

Used by:

Sales Brain

Conversion Brain

Affiliate Brain

Content Brain

Ads Brain

Compliance Brain

  1. Brand Visual Style

Purpose:

Defines the visual style rules that should influence AI-generated or AI-assisted creative assets.

This file should include:

brand colours

font style

image style

layout preferences

thumbnail style

banner style

visual tone

acceptable imagery

unacceptable imagery

product image rules

human image rules

platform-specific visual rules

This file supports visual consistency.

Used by:

Creative Brain

Content Brain

Ads Brain

AI Studio workflows

VEO3 support systems

  1. Retired Language

Purpose:

Stores language, claims, phrases, slogans, framings, or positioning that should no longer be used.

This file should include:

retired phrases

old taglines

outdated claims

old positioning

banned hype words

compliance-sensitive terms

brand language that has changed

reasons for retirement where useful

This file prevents AI from resurrecting old language.

Used by:

Content Brain

Creative Brain

Sales Brain

Ads Brain

Compliance Brain

AI Employee validation systems

  1. Compliance Notes

Purpose:

Stores offer-specific or market-specific compliance constraints.

This file should include:

claims restrictions

platform policy limits

industry risk areas

medical or financial sensitivity

testimonial rules

before/after restrictions

pricing disclosure rules

affiliate disclaimer needs

data privacy concerns

jurisdiction-specific notes

This file helps prevent risky output.

Used by:

Compliance Brain

Ads Brain

Affiliate Brain

Content Brain

Sales Brain

HeadOffice Brain

Optional Context Files

Some offers or clients may require additional files.

Possible optional files include:

Campaign Context

Launch Context

Email Style Guide

Sales Call Notes

FAQ Library

Audience Segment Profiles

Competitor Contrast Notes

Client Approval Rules

Client Reporting Preferences

Tool Stack Notes

Workflow Constraints

Persona Notes

Positioning History

These should only be added when useful.

MWMS must not create context files for the sake of documentation volume.

Folder Structure Standard

Each serious offer or client should use a dedicated context folder.

Recommended structure:

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

Inside 03 Offer Context Library:

03 Offer Context Library/
Right-Fit Client Profile.docx
Offer Profile.docx
Voice Architecture.docx
Differentiation Profile.docx
Objection Library.docx
Methodology Map.docx
Expert Thinking Rules.docx
Customer Language Bank.docx
Proof Library.docx
Brand Visual Style.docx
Retired Language.docx
Compliance Notes.docx

For smaller internal MWMS uses, the structure may be simplified.

For future AIBS client systems, the structure should remain strict.

One Source Of Truth Rule

Each context file must exist in one approved source location.

MWMS must avoid duplicating the same context file across multiple folders.

Duplicated context creates:

conflicting instructions

stale copies

wrong AI output

unclear authority

maintenance burden

If another workflow needs the file, it should reference the approved source file.

Do not copy the contents into multiple disconnected files unless a deliberate versioning decision has been made.

File Versus Skill Rule

A context file stores what is true.

A skill defines what to do with what is true.

Example:

Voice Architecture stores the voice rules.

A Voice Checker Skill reads the Voice Architecture file and checks whether a draft follows the rules.

MWMS must not copy all voice rules into every skill.

Skills should read context files where possible.

This prevents drift.

The rule is:

The library file holds the truth. The skill performs the task.

Multi-Offer Library Patterns

MWMS recognizes three patterns for multiple offers.

Pattern A: Shared Core With Offer Subfolders

Use when multiple offers share the same brand, voice, and general methodology, but differ in buyer, offer details, or objections.

Structure:

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

Shared may include:

Voice Architecture

Brand Visual Style

Retired Language

Expert Thinking Rules

Offer subfolders may include:

Right-Fit Client Profile

Offer Profile

Objection Library

Differentiation Profile

Proof Library

Pattern B: Separate Libraries

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

Structure:

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

This prevents cross-brand contamination.

Pattern C: One Library With Offer-Tagged Files

Use when offers have heavy overlap and only minor differences.

Structure:

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

This should be used carefully.

If confusion appears, move to Pattern A or Pattern B.

Client Library Rule

Future AIBS client libraries must be isolated.

Client context must not be mixed with MWMS internal context.

Client context must not be mixed with another client’s context.

Client folders should include:

Client Name/
Their Library/
Their Skills/
Working/
Audits/
Reports/

Client context must remain permissioned, limited, and source-specific.

This protects:

client privacy

client IP

MWMS IP

output accuracy

trust

future legal and operational safety

Context Update Triggers

The Offer Context Library is not a one-time setup.

It must be updated when important things change.

Update triggers include:

new offer launch

offer repositioned

offer retired

price changed

buyer profile changed

new objections appear

new proof becomes available

voice changes

old language is retired

methodology changes

compliance risk changes

customer language changes

campaign data reveals new insight

sales calls reveal repeated friction

content keeps sounding wrong

AI output keeps resurrecting old language

When a trigger occurs, the relevant context files should be updated promptly.

Do not batch major context updates for months.

Misalignment compounds.

Dependency Map

Some changes affect only one file.

Other changes affect multiple files.

Price or payment change:

Update Offer Profile.

Positioning change:

Update Offer Profile, Differentiation Profile, Right-Fit Client Profile, Contrarian Stances if relevant, and Retired Language if old framing must stop.

Voice change:

Update Voice Architecture and Retired Language.

New buyer insight:

Update Right-Fit Client Profile, Customer Language Bank, Objection Library if relevant.

New objection:

Update Objection Library, Sales Brain usage notes, Conversion Brain usage notes, and Content Brain usage notes if relevant.

Methodology change:

Update Methodology Map, Expert Thinking Rules, Offer Profile, and any related skills.

New proof:

Update Proof Library, Offer Profile, Sales assets, and Compliance Notes if risk exists.

Compliance change:

Update Compliance Notes, Retired Language, Offer Profile, Ads Brain usage notes, and any affected copy systems.

Context Library Audit

Each important Offer Context Library should be reviewed periodically.

Minimum review:

quarterly for active offers

after major campaign results

after major customer research

after product or offer changes

before major launch

before automation or AI Employee deployment

Review questions:

Is this still true?

Is this still current?

Is this still the right buyer?

Is this still the right offer?

Is this still how we speak?

Is this still how we differentiate?

Are objections current?

Are proof points approved?

Is old language creeping back?

Are any files duplicated?

Do AI outputs still match the library?

Audit Outcomes

Each audit should produce one of the following outcomes:

Current

Update Required

Partial Drift Detected

Major Drift Detected

Retire Library

Split Library

Merge Library

Park For Future Review

No audit should end without a clear outcome.

Usage Rules For AI Employees

AI Employees must use the Offer Context Library when producing important outputs for that offer.

Important outputs include:

ads

VEO3 scripts

landing pages

sales pages

emails

lead magnets

webinars

content briefs

client reports

sales scripts

objection handling

offer evaluations

funnel assets

AI Employee instructions

AI Employees should not rely only on general memory when an approved context library exists.

Required behaviour:

check relevant context files

preserve approved language

avoid retired language

do not invent proof

do not change offer promise

do not change buyer profile without approval

flag stale or missing context

route unresolved issues to human review

Human Review Rule

The Offer Context Library should be human-reviewed before becoming active.

The human reviewer should check:

accuracy

specificity

source grounding

missing evidence

unsupported claims

voice match

buyer match

offer match

compliance risk

wrong assumptions

outdated language

Once approved, the library becomes active context for that offer.

Draft context files should not be treated as approved source of truth.

Common Failure Modes

MWMS must prevent:

duplicated context files

stale context

wrong offer context used

wrong client context used

old language resurrected

skills hard-coding context instead of reading source files

AI inventing proof

AI changing offer promise

AI writing for the wrong buyer

AI using generic brand voice

AI ignoring objections

AI using outdated positioning

AI blending multiple offers

AI treating draft files as approved

context libraries becoming cluttered with unused files

Context Library Quality Standards

A strong Offer Context Library should be:

specific

current

source-grounded

offer-specific

buyer-aware

AI-readable

easy to update

not duplicated

not bloated

human-reviewed

connected to relevant Brains

A weak Offer Context Library is:

generic

outdated

duplicated

unclear

over-polished

not tied to a buyer

not tied to an offer

missing proof

missing objections

missing real language

too broad for AI Employees to use well

Governance Role

HeadOffice owns the MWMS Offer Context Library Standard.

HeadOffice is responsible for:

defining library structure

preventing duplicate context sources

ensuring source-of-truth discipline

requiring review before activation

protecting client context separation

ensuring context libraries align with MWMS governance

ensuring outdated libraries are updated, parked, split, merged, or retired

Individual Brains may use context libraries for their own outputs, but HeadOffice governs cross-Brain structure and authority.

Offer Brain governs offer-specific interpretation.

Content Brain governs content usage.

Sales Brain governs sales usage.

Creative Brain governs creative angle usage.

Compliance Brain governs claims and risk usage.

AI Business Systems Brain governs future client system application.

Relationship To Other MWMS Standards

This standard supports and must align with:

MWMS Document Structure Standard

MWMS Client IP Excavation Framework

MWMS AI Agent Memory And Context Framework

MWMS AI Agent Skill Library Framework

MWMS Course Absorption Operating Rule

MWMS Messy Input Normalization Framework

MWMS AI Output Validation Standard

MWMS AI Employee Role Card Standard

MWMS AI Employee Capability Stack Framework

MWMS Brain Routing Rule

MWMS MCR Promotion To Brain Protocol

MWMS Page Naming Standard

MWMS Architecture Registry

Content Brain VOC Grounded AI Copy Framework

Research Brain Voice Of Customer Extraction Framework

Offer Brain Offer Structure Framework

Creative Brain Belief Shift Framework

Sales Brain Objection Resolution Framework

Conversion Brain Customer Anxiety And FUD Research Framework

Compliance Brain Claims Risk Framework

AI Business Systems Brain Canon

This standard provides the structured context layer that allows those systems to produce more accurate, consistent, and offer-specific outputs.

Drift Protection

This standard protects MWMS from:

scattered context

duplicate files

stale offer knowledge

wrong buyer targeting

old language returning

AI-generated generic copy

AI Employees starting from zero

skills hard-coding outdated rules

client context contamination

offer context contamination

draft files being treated as approved

unsupported claims entering business assets

content, ads, sales, and conversion systems drifting apart

Any major AI-generated business output that does not use the relevant approved context library should be treated as a potential drift risk.

Architectural Intent

The architectural intent of the MWMS Offer Context Library Standard is to create a stable, reusable, governed context layer for every serious offer, client system, and MWMS business asset.

MWMS is building a governed AI business ecosystem.

That ecosystem cannot rely on repeated prompting.

It needs durable context.

The long-term goal is that every important offer or client system can answer:

Who is this for?

What does it promise?

How does it work?

Why is it different?

What does the buyer believe?

What must the buyer understand?

What objections matter?

What proof is approved?

How should AI speak?

What language is retired?

What context must AI Employees read?

What must never be invented?

When MWMS can answer those questions consistently, AI Employees can create better outputs with less rework, less drift, and stronger business alignment.

Change Log

v1.0 — Initial Draft

Created the MWMS Offer Context Library Standard as the source-of-truth structure for storing and governing offer-specific and client-specific AI context across MWMS.

This standard defines the required context library files, optional files, folder structure, one source of truth rule, file versus skill rule, multi-offer patterns, client library isolation, update triggers, dependency map, audit rules, AI Employee usage rules, quality standards, governance role, drift protection, and architectural intent.

Change Impact Declaration

Pages Created:

MWMS Offer Context Library 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

Sales Brain Page Registry

Creative Brain Page Registry

Canon Version Update Required:

No

Change Log Entry Required:

Yes

Employee Impact Check

Employees impacted:

HeadOffice Manager Employee

Offer Strategist Employee

Content Planner Employee

Creative Strategist Employee

Sales Strategist Employee

Conversion Strategist Employee

Research Analyst Employee

AI Business Systems Architect Employee

Context Library Builder

Client IP Excavator

AI Employee Router

Required behaviour updates:

AI Employees must use the approved Offer Context Library when producing important outputs for a specific offer or client system.

AI Employees must not invent proof, buyer language, claims, testimonials, founder beliefs, or offer details when the library does not contain them.

AI Employees must preserve approved voice, differentiation, methodology, objections, and customer language where relevant.

AI Employees must avoid retired language and flag missing or stale context before producing high-value outputs.

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

END MWMS OFFER CONTEXT LIBRARY STANDARD v1.0