System: MWMS
Document Type: Standard
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Primary Location: MCR
Future Operational Destination: AI Business Systems Brain, Offer Brain, Content Brain, Sales Brain, Conversion Brain, Creative Brain, Customer Brain, Research Brain, Affiliate Brain, Ads Brain, Compliance Brain, Future AIBS Client Systems
Parent Page: Offer Brain
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 Proof Library And Claims Control Standard.
This standard establishes how MWMS captures, structures, governs, reviews, approves, restricts, and applies proof across offer systems, content systems, sales systems, ad systems, affiliate systems, client systems, and future AI Business Systems.
MWMS must not allow AI Employees to invent credibility.
AI-generated output must not fabricate:
testimonials
case studies
customer quotes
performance numbers
revenue claims
health claims
income claims
client results
before-and-after stories
social proof
expert endorsements
vendor claims
market statistics
Proof is one of the highest-risk areas in AI-assisted business output.
When AI lacks approved proof, it may create plausible but unsupported claims.
This standard exists to ensure that MWMS separates:
approved proof
unapproved proof
draft proof
restricted proof
expired proof
source material
claims requiring review
claims that must never be used
The goal is to make every AI Employee clear on what credibility signals can safely be used and what must be flagged before publication.
Scope
This standard applies to all MWMS work where proof, credibility, claims, testimonials, examples, evidence, results, or trust signals may appear in AI-generated or AI-assisted output.
This includes:
AI Business Systems Brain
Offer Brain
Content Brain
Sales Brain
Conversion Brain
Creative Brain
Customer Brain
Research Brain
Affiliate Brain
Ads Brain
Compliance Brain
HeadOffice Brain
AI Manager
AI Employee Router
future AIBS client systems
This standard applies before creating:
sales pages
landing pages
VSL scripts
VEO3 scripts
ad scripts
affiliate bridge pages
email sequences
webinars
lead magnets
case studies
client reports
offer evaluations
comparison pages
sales scripts
social proof sections
client-facing assets
public-facing content
This standard does not authorize development work, plugin changes, Supabase changes, WordPress changes, automation wiring, publishing, compliance approval, legal approval, or M developer action.
Core Definition
A Proof Library is a governed context file or folder that stores approved credibility assets that may be used to support an offer, claim, message, client system, campaign, or business asset.
Claims Control defines the rules for how those proof assets may be used.
Proof may include:
testimonials
case studies
customer quotes
screenshots
before-and-after examples
internal examples
campaign results
performance data
research findings
third-party references
press mentions
certifications
expert credentials
process demonstrations
client feedback
vendor-approved claims
A proof asset is not automatically approved just because it exists.
A proof asset must be reviewed, classified, and governed before AI Employees use it in high-value or public-facing output.
Core Principle
The core principle of this standard is:
AI must use approved proof only and must never invent credibility.
If proof is missing, the AI Employee must say proof is missing.
If proof is uncertain, the AI Employee must flag it.
If proof is sensitive, the AI Employee must route it for review.
If proof is restricted, the AI Employee must follow the restriction.
Credibility must be earned from source evidence, not manufactured by AI.
Proof Library
Purpose
The Proof Library stores the evidence MWMS may use to support claims, trust, credibility, and buyer confidence.
It prevents AI Employees from guessing what proof exists.
It also prevents approved proof from being scattered across emails, chat history, screenshots, folders, testimonials, sales pages, and old campaign assets without governance.
Proof Library Fields
Each proof item should include the following fields where relevant.
Proof Name
Short name for the proof asset.
Proof Type
Examples:
testimonial
case study
customer quote
internal example
screenshot
data point
certification
vendor claim
research reference
client feedback
process demonstration
Source
Where the proof came from.
Examples:
customer email
survey
sales call
campaign report
vendor page
client screenshot
platform analytics
internal MWMS build
Approval Status
Possible values:
Approved
Draft
Unverified
Restricted
Expired
Rejected
Needs Review
Claim Supported
The specific claim the proof supports.
Example:
This supports the claim that structured context improves AI output consistency.
Claim Not Supported
The claims this proof does not support.
Example:
This does not support income claims or guaranteed results.
Usage Permission
Defines where the proof may be used.
Examples:
internal only
client report only
public-facing allowed
sales page allowed
ad use not allowed
affiliate use not allowed
client approval required
Compliance Sensitivity
Defines risk.
Examples:
low
medium
high
regulated
platform-sensitive
financial
health
income
privacy-sensitive
Required Wording
Defines exact or preferred wording if needed.
Restricted Wording
Defines what must not be said.
Evidence Location
Defines where the original proof can be found.
Review Date
Defines when proof was reviewed.
Next Review Date
Defines when proof should be checked again.
Notes
Additional limitations or context.
Proof Types
MWMS recognizes several proof types.
Testimonials
Direct feedback from customers, clients, users, or buyers.
Rules:
must be real
must not be invented
must not be altered beyond clarity without permission
must not imply typical results unless approved
must follow platform and legal requirements
Case Studies
Structured examples showing a before, process, and after.
Rules:
must be evidence-based
must not exaggerate outcome
must preserve context
must not imply universal results
must include limitations where needed
Customer Quotes
Short phrases from real customers or prospects.
Rules:
must be accurate
must not be fabricated
must not be presented as testimonial if not approved
must be anonymized where necessary
Screenshots
Visual proof from tools, platforms, messages, dashboards, or results.
Rules:
must not expose private information
must be current where relevant
must not be misleadingly cropped
must be approved before public use
Performance Data
Metrics from campaigns, systems, sales, traffic, or operations.
Rules:
must include context
must not be cherry-picked misleadingly
must not imply future guarantee
must be current enough
must be reviewed before public or paid traffic use
Internal Examples
Examples from MWMS internal builds, pages, workflows, or systems.
Rules:
can support process credibility
must not imply client results
must not be overstated
must be clearly positioned as internal example where needed
Vendor Claims
Claims provided by affiliate vendors or third-party offer owners.
Rules:
must be vendor-approved
must not be blindly repeated
must be checked for platform compliance
must not be exaggerated by MWMS
must be adapted carefully for affiliate content
Research References
External facts, studies, reports, or third-party sources.
Rules:
must be current where relevant
must be cited where required
must not be distorted
must not be used to support claims beyond what the source shows
Process Demonstration
Proof that a method, system, or workflow exists and can be shown.
Rules:
must be accurate
can demonstrate capability
must not imply guaranteed outcome
Proof Approval Statuses
MWMS uses the following proof statuses.
Approved
Proof may be used according to its usage permission.
Draft
Proof may be reviewed internally but should not be used publicly.
Unverified
Proof exists but has not been confirmed.
Restricted
Proof may be used only under defined conditions.
Expired
Proof is outdated and should not be used unless historical context is required.
Rejected
Proof should not be used.
Needs Review
Proof requires human, compliance, client, or Brain review before use.
AI Employees must check proof status before using proof.
Claims Control
Claims Control defines what AI Employees may say based on available proof.
A claim is any statement that asserts:
result
benefit
capability
performance
comparison
credibility
authority
safety
income
health
time saving
cost saving
client outcome
buyer transformation
Claims may appear in:
headlines
bullets
ads
sales pages
landing pages
emails
webinars
VSL scripts
client reports
social proof sections
case studies
offer summaries
Claims Control Rule
No claim should be stronger than the proof supporting it.
If proof is weak, the claim must be modest.
If proof is missing, the claim must be removed, softened, or flagged.
Claim Categories
MWMS recognizes several claim categories.
Capability Claims
Examples:
MWMS can structure business context for AI use.
This system helps organize offer intelligence.
Result Claims
Examples:
This improves output consistency.
This can reduce repeated explanation.
This can improve content relevance.
Performance Claims
Examples:
increased CTR
reduced cost
improved conversion
higher engagement
Income Claims
Examples:
make more money
increase revenue
earn monthly retainers
scale to a specific revenue level
Health Claims
Examples:
improves health
reduces pain
boosts energy
supports sleep
Compliance Claims
Examples:
Google-compliant
privacy-safe
risk-free
platform-approved
Comparison Claims
Examples:
better than prompt packs
safer than automation-first setup
more structured than generic AI tools
Authority Claims
Examples:
used by clients
based on proven method
expert-approved
trusted by brands
Claim Risk Rules
Rule 1: Income, Health, Finance, And Compliance Claims Are High Risk
These require stronger review.
Rule 2: Specific Numbers Require Specific Proof
Do not use percentages, revenue figures, conversion rates, or time savings unless supported.
Rule 3: Typicality Must Not Be Implied Without Support
Do not make one result sound normal unless proof supports typicality.
Rule 4: Vendor Claims Require Review
Affiliate vendor claims must not be blindly copied.
Rule 5: Process Claims Are Safer Than Outcome Guarantees
It is usually safer to claim what the system does than to guarantee what the buyer will achieve.
Rule 6: Internal Proof Must Be Labelled Correctly
Internal MWMS examples should not be presented as client results.
Rule 7: AI Must Not Fill Proof Gaps
If proof is missing, say so.
Proof Usage Rules For AI Employees
AI Employees must:
check the Proof Library before using proof
use only approved proof
match proof to claim
avoid unsupported numbers
avoid invented testimonials
avoid fake case studies
avoid exaggerated outcomes
respect usage restrictions
flag proof gaps
route sensitive claims for review
use modest wording when proof is limited
AI Employees must not:
create fake quotes
create fake customers
create fake before-and-after results
turn internal examples into external proof
treat unverified notes as approved proof
use screenshots without privacy review
use outdated proof as current proof
copy affiliate vendor claims blindly
Proof Gap Handling
When proof is missing, AI Employees may use the following labels.
Proof Missing
No supporting proof is available.
Proof Needed
The claim needs evidence before use.
Human Review Required
The proof or claim needs review.
Compliance Review Required
The claim is sensitive.
Client Approval Required
Client-owned proof requires approval.
Use Process Explanation Instead
The asset should explain method rather than claim results.
Remove Claim
The claim should not be used.
Proof-Safe Language
When proof is limited, use cautious wording.
Examples:
designed to help
intended to support
can help organize
may reduce
helps clarify
supports the process of
provides a structure for
gives the team a way to
Avoid when unsupported:
guaranteed
proven to
will definitely
double your
always
risk-free
compliance-proof
instant results
works for everyone
Proof Review Workflow
MWMS uses the following proof review workflow.
Step 1: Gather Proof Source
Collect testimonial, screenshot, data, case study, example, or reference.
Step 2: Classify Proof Type
Assign proof type.
Step 3: Identify Claim Supported
Define exactly what claim the proof supports.
Step 4: Identify Claim Not Supported
Define what should not be claimed from this proof.
Step 5: Assign Approval Status
Approved, Draft, Restricted, Expired, Rejected, or Needs Review.
Step 6: Define Usage Permission
Internal, public, client-facing, ads, sales page, affiliate, or restricted.
Step 7: Check Sensitivity
Identify compliance, privacy, paid traffic, health, income, or client risk.
Step 8: Add To Proof Library
Store in correct context library.
Step 9: Use In Outputs
AI Employees may use approved proof according to restrictions.
Step 10: Audit Over Time
Review proof after changes, age, platform policy shifts, or new risk.
Proof Library Audit
Proof libraries must be reviewed periodically.
Audit questions:
Is this proof still accurate?
Is this proof still approved?
Is this proof still current?
Is this proof being used correctly?
Are claims stronger than proof?
Are any testimonials outdated?
Are screenshots privacy-safe?
Are vendor claims still allowed?
Are any proof items expired?
Are any proof gaps repeatedly appearing?
Does Compliance Brain need review?
Audit outcomes:
Current
Refresh
Restrict
Expire
Reject
Needs Review
Remove From Active Use
Client Proof Rules
Future AIBS client proof requires strict control.
Client proof must:
remain inside the client library
be approved by the client before public use
not be reused for another client
not be generalized into MWMS proof without permission
respect client privacy
respect client industry compliance
Client-specific proof must not become general MWMS proof unless deliberately approved and generalized.
Affiliate Proof Rules
Affiliate proof requires caution.
MWMS must not:
invent vendor results
invent customer results
imply personal ownership of vendor results
repeat vendor claims without review
create unsupported income, health, finance, or performance claims
use fake testimonials
Affiliate proof should be reviewed by Affiliate Brain and Compliance Brain before public use.
Paid Traffic Proof Rules
Paid traffic assets require stronger proof control.
AI Employees must check:
claim support
platform policy risk
testimonial rules
before-and-after rules
income or health sensitivity
urgency and scarcity claims
landing page consistency
ad-to-page message match
Paid traffic proof must be conservative.
Common Failure Modes
MWMS must prevent:
invented testimonials
invented case studies
unsupported results
fake customer quotes
vendor claims copied blindly
old proof used as current proof
private screenshots exposed
internal examples presented as client results
claim stronger than proof
proof used outside its permission
paid traffic claims without review
client proof used without approval
AI filling proof gaps with plausible language
Governance Role
Offer Brain owns the MWMS Proof Library And Claims Control Standard.
Compliance Brain governs claim-sensitive use.
HeadOffice governs cross-Brain source-of-truth discipline and escalation.
Research Brain supports external evidence review.
Customer Brain supports customer evidence interpretation.
Sales Brain uses proof in sales assets.
Content Brain uses proof in content and trust-building assets.
Creative Brain uses proof in scripts and ad concepts.
Affiliate Brain governs affiliate proof use.
Ads Brain governs paid traffic proof use.
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 Right-Fit Client And Offer Profile Standard
MWMS Differentiation And Objection Library Standard
MWMS Voice Architecture And Brand Language Standard
MWMS Client IP Excavation Framework
MWMS Offer Context Library Standard
MWMS Context Library Governance And Folder Map Standard
MWMS AI Context Activation And Usage Protocol
MWMS AI Context Pack Template Standard
MWMS Context-Driven Asset Builder Framework
MWMS Context-Grounded Lead Magnet Funnel Framework
MWMS Context-Grounded Evergreen Webinar Framework
MWMS AI Brain Readiness Review Checklist
MWMS AI Brain Audit And Decay Prevention Framework
Content Brain VOC Grounded AI Copy Framework
Research Brain Voice Of Customer Extraction Framework
Sales Brain Objection Resolution Framework
Conversion Brain Landing Page Structure Framework
Creative Brain Belief Shift Framework
Affiliate Brain Compliance Framework
Ads Brain Claims And Policy Review Framework
AI Business Systems Brain Canon
This standard provides the proof and claim control layer for offer, content, sales, creative, affiliate, ads, and client systems.
Drift Protection
This standard protects MWMS from:
invented proof
unsupported claims
fake testimonials
fake case studies
exaggerated results
stale proof
expired claims
private proof misuse
client proof leakage
affiliate claim risk
paid traffic disapproval risk
AI Employees making claims stronger than evidence
Any public-facing, client-facing, paid traffic, affiliate, health, finance, or income-related output created without proof review should be treated as a claims drift risk.
Architectural Intent
The architectural intent of the MWMS Proof Library And Claims Control Standard is to make credibility safe, reusable, and governed across AI systems.
MWMS needs AI Employees that can use proof effectively without inventing it.
The long-term goal is that every serious claim can answer:
What proof supports this?
Where is the proof stored?
Is the proof approved?
What exact claim does it support?
What claim does it not support?
Where can this proof be used?
What wording is allowed?
What wording is restricted?
Does this require human, client, or compliance review?
When MWMS can answer these questions consistently, AI-generated sales, content, affiliate, and client outputs become more trustworthy, safer, and easier to scale.
Change Log
v1.0 — Initial Draft
Created the MWMS Proof Library And Claims Control Standard as the proof governance and claims control standard for MWMS context libraries, offer systems, content systems, sales systems, creative systems, affiliate systems, ads systems, compliance systems, and future AIBS client systems.
This standard defines Proof Library fields, proof types, proof approval statuses, claims control, claim categories, claim risk rules, proof usage rules, proof gap handling, proof-safe language, proof review workflow, proof audits, client proof rules, affiliate proof rules, paid traffic proof rules, failure modes, governance role, drift protection, and architectural intent.
Change Impact Declaration
Pages Created:
MWMS Proof Library And Claims Control Standard
Pages Updated:
None
Pages Deprecated:
None
Registries Requiring Update:
MWMS Architecture Registry
Offer Brain Page Registry
Content Brain Page Registry
Sales Brain Page Registry
Creative Brain Page Registry
Conversion Brain Page Registry
Affiliate Brain Page Registry
Ads Brain Page Registry
Compliance Brain Page Registry
AI Business Systems Brain Page Registry
Canon Version Update Required:
No
Change Log Entry Required:
Yes
Employee Impact Check
Employees impacted:
Offer Strategist Employee
Content Planner Employee
Creative Strategist Employee
Sales Strategist Employee
Conversion Strategist Employee
Customer Research Employee
Research Analyst Employee
Affiliate Offer Evaluator Employee
Ads Strategist Employee
Compliance Reviewer Employee
Context Library Builder
Client IP Excavator
AI Business Systems Architect Employee
Required behaviour updates:
AI Employees must check approved proof before making claims in offer, content, sales, creative, affiliate, ads, compliance-sensitive, public-facing, or client-facing outputs.
AI Employees must not invent testimonials, case studies, customer quotes, results, statistics, screenshots, vendor claims, income claims, health claims, or performance claims.
AI Employees must match claims to proof strength and must flag proof gaps before producing high-risk outputs.
AI Employees must respect proof usage permissions, client approval requirements, affiliate restrictions, paid traffic risks, and compliance review requirements.
AI Employees must update or request review of Proof Libraries when proof becomes stale, restricted, expired, unsupported, or risky.
END MWMS PROOF LIBRARY AND CLAIMS CONTROL STANDARD v1.0