MWMS Newsletter Content Production Framework
System: MWMS
Document Type: Framework
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Version: v1.1
Primary Location: MCR
Future Operational Destination: Content Brain, Research Brain, HeadOffice Brain, Creative Brain, Compliance Brain, Data Brain, Automation Brain, Sales Brain, Affiliate Brain, AIBS Brain
Parent Page: Content Brain
Owner: Martyn
Developer Boundary: No Development Action Authorized By This Page
Source Of Truth: MCR
Last Reviewed: 2026-07-19
Source Origin: AI Automations By Jack Newsletter Automation Material Combined With Existing MWMS Content Production, Repurposing, Editorial Consistency, AI Content Quality, Publishing Readiness, Source Visibility, Newsletter Intelligence Governance, And Durable Email Campaign, Copy, Design, Planning, And Deliverability Intelligence Absorbed From Sam Piliero The Facebook Ads Blueprint Bonus Email Marketing Module By Max Sturtevant
Primary Brain: Content Brain
Supporting Brains: Research Brain, HeadOffice Brain, Creative Brain, Compliance Brain, Data Brain, Automation Brain, Sales Brain, Affiliate Brain, AIBS Brain, Ecommerce Brain, Customer Brain, Conversion Brain, Finance Brain
Purpose
The purpose of the MWMS Newsletter Content Production Framework is to define how MWMS turns approved source material, current intelligence, company knowledge, research, offers, customer insights, seasonal priorities, campaign plans, and existing content assets into high quality reader facing newsletters and scheduled email campaigns.
This framework governs newsletter and campaign email production.
It does not govern the HeadOffice Newsletter Intelligence system.
The HeadOffice Newsletter Intelligence system exists to inspect newsletters and external signals for internal MWMS intelligence, routing, parking, review, decision, and task creation.
The MWMS Newsletter Content Production Framework exists to create publishable newsletter and campaign email content for an external audience.
This framework ensures that newsletter production is:
source grounded
editorially controlled
factually checked
aligned with audience needs
consistent with house voice
structured for fast consumption
clear about why the information matters
traceable to original evidence
safe from copyright and compliance drift
planned around clear campaign roles
separated from behavioural lifecycle flows
designed for mobile readability
built around clear message hierarchy
human approved before sending
measurable after publication
interpreted beyond open rate alone
Without this framework, MWMS risks creating newsletters and campaign emails that are:
generic
thin
duplicative
factually weak
over automated
poorly sourced
too similar to the original publisher
missing a clear reader benefit
inconsistent in voice
assembled from unrelated summaries
unable to distinguish fact from opinion
built around vanity metrics
visually cluttered
misaligned with lifecycle messaging
sent too frequently
sent to unsuitable segments
designed around tools rather than communication goals
published without review
The purpose of the framework is not to automate newsletters for the sake of automation.
The purpose is to create a reliable editorial and campaign production system that uses automation to reduce repetitive work while preserving human judgement, customer relevance, message clarity, and commercial discipline.
Scope
This framework applies to:
newsletters
email digests
industry updates
curated intelligence newsletters
company newsletters
authority newsletters
affiliate newsletters
AIBS client newsletters
topic specific newsletters
editorial briefings
weekly summaries
daily summaries
campaign support newsletters
product update newsletters
thought leadership newsletters
repurposed content newsletters
news driven newsletter sections
multi story newsletter issues
single topic newsletter issues
scheduled campaign emails
seasonal campaign emails
promotional campaign emails
educational campaign emails
launch campaign emails
retention support campaigns
reactivation support campaigns
product announcement emails
community engagement emails
offer support emails
This framework applies to the following stages:
newsletter strategy
campaign role definition
audience and segment definition
send calendar planning
source discovery
candidate capture
source retrieval
source cleaning
candidate summarisation
editorial review
approval or rejection
newsletter angle selection
campaign angle selection
fact checking
title creation
subject line creation
preview text creation
opening creation
body copy creation
TLDR creation
key point creation
why this matters interpretation
commentary creation
section planning
image direction
CTA selection
issue assembly
email design planning
mobile readability review
frequency pressure review
final editorial review
platform handoff
human controlled sending
performance feedback
This framework does not authorize:
autonomous sending
automatic publication
unreviewed factual claims
copyright infringement
unsupported commentary
fabricated quotes
fabricated sources
fabricated statistics
automatic use of every discovered story
replacement of human editorial judgement
replacement of Research Brain where deeper research is required
replacement of HeadOffice Newsletter Intelligence governance
replacement of Ecommerce Brain lifecycle flow governance
tool-specific Klaviyo procedures as Canon
tool-specific Figma procedures as Canon
one universal email template
one universal campaign frequency
one universal subject line formula
one universal open-rate benchmark
Core Principle
The core principle is:
Automation may accelerate newsletter and campaign production, but editorial judgement controls what is included, what is said, how it is framed, how it is designed, who receives it, when it is sent, and whether it is sent.
The system must not treat every discovered article as newsletter worthy.
The system must not assume that a source is reliable merely because it appears in an RSS feed.
The system must not assume that a generated summary is accurate merely because it sounds confident.
The system must not confuse speed with quality.
The system must not confuse sending frequency with audience value.
The system must not confuse open rate with commercial success.
A strong newsletter or campaign email must answer:
Why should this reader care?
What happened or what is being offered?
What does it mean?
Why does it matter now?
What should the reader think, do, watch, or understand next?
What is the single most important action?
Does the message fit the reader’s current relationship with MWMS?
Newsletter Production Boundary
The MWMS Newsletter Content Production Framework begins only when a source, topic, signal, offer, campaign, promotion, product, or approved content asset is being considered for reader facing production.
It may receive inputs from:
Research Brain
HeadOffice Newsletter Intelligence
Content Opportunity Queue
Content Production Queue
Ecommerce Brain
Customer Brain
Conversion Brain
Ads Brain
Finance Brain
approved internal documents
approved company updates
approved external news sources
approved affiliate sources
approved client materials
approved performance data
approved seasonal plans
approved promotion calendars
approved product priorities
It must not absorb the internal routing role of HeadOffice Newsletter Intelligence.
It must not absorb the behavioural trigger and lifecycle flow role of Ecommerce Brain Lifecycle Messaging Architecture Framework.
HeadOffice Newsletter Intelligence Flow
External newsletter or signal
↓
Internal intelligence extraction
↓
Classification
↓
Parking or routing
↓
Brain review
↓
Decision
↓
Task or system action
Content Brain Newsletter Production Flow
Approved source, topic, campaign, offer, or product priority
↓
Candidate or campaign review
↓
Audience and role definition
↓
Editorial approval
↓
Source and claim validation
↓
Newsletter or campaign production
↓
Copy and design review
↓
Frequency and segment review
↓
Publishing readiness
↓
Human controlled send
↓
Performance feedback
Ecommerce Brain Lifecycle Flow
Behavioural event
↓
Customer state qualification
↓
Lifecycle flow entry
↓
Sequence logic
↓
Exit and suppression
↓
Lifecycle measurement
Campaign and lifecycle systems may interact.
They must not be merged into one uncontrolled sending system.
Core Newsletter Production Model
MWMS uses the following newsletter production model:
1. Newsletter Strategy Layer
2. Audience And Purpose Layer
3. Campaign Role And Calendar Layer
4. Source Intake Layer
5. Candidate Review Layer
6. Source Validation Layer
7. Editorial Angle Layer
8. Newsletter Component Production Layer
9. Copy And Message Hierarchy Layer
10. Voice And Consistency Layer
11. Evidence And Attribution Layer
12. Email Design And Section Architecture Layer
13. CTA And Conversion Layer
14. Issue Assembly Layer
15. Frequency And Segment Governance Layer
16. Quality And Publishing Readiness Layer
17. Distribution Handoff Layer
18. Performance Feedback Layer
1. Newsletter Strategy Layer
Every newsletter must have a defined strategic role.
Possible roles include:
authority building
audience education
current intelligence
community engagement
offer support
product support
affiliate support
lead nurturing
sales support
client retention
brand positioning
market commentary
thought leadership
relationship development
seasonal support
launch support
The newsletter must not exist only because a sending schedule exists.
Strategy Questions
Before production, define:
What is the newsletter for?
Who is it for?
What recurring reader need does it serve?
What makes it worth opening?
What makes it different from generic news summaries?
What action or belief should it support?
What business objective does it connect to?
What content sources are approved?
What editorial boundaries apply?
What sending frequency is realistic?
What relationship stage does it support?
What other communication is the audience already receiving?
2. Audience And Purpose Layer
Every issue or campaign must define:
primary audience
recipient segment
reader awareness level
reader sophistication
reader problem
reader interest
reader urgency
reader relationship to the brand
customer versus prospect status
issue purpose
campaign purpose
intended outcome
Possible issue outcomes include:
inform
explain
reframe
warn
recommend
educate
convert
retain
reactivate
prepare
engage
support
reassure
Reader Relevance Rule
A story should not be included merely because it is new.
A campaign should not be sent merely because an offer exists.
It should be included or sent because it is relevant to the reader and supports the newsletter or campaign purpose.
Segment Suitability Rule
The system must confirm that the message fits the selected recipients.
Segment suitability may consider:
subscription status
customer status
purchase history
declared interest
engagement history
geography
product eligibility
offer eligibility
recent communication pressure
active lifecycle flow
current support issue
consent type
The broadest possible audience is not automatically the best audience.
3. Campaign Role And Calendar Layer
Scheduled campaign emails must have a declared role.
Possible campaign roles include:
editorial newsletter
educational campaign
product announcement
promotion
seasonal event
launch
event reminder
community update
affiliate recommendation
customer education
reactivation support
relationship building
content distribution
Campaign and lifecycle messaging must remain separate.
Campaigns respond to planned commercial, educational, seasonal, editorial, or product priorities.
Lifecycle flows respond to customer behaviour and customer state.
Campaign Planning Fields
Every scheduled campaign should define:
campaign name
campaign role
campaign objective
primary audience
segment
offer or content focus
business reason
customer benefit
send window
campaign phase
subject line direction
primary message
primary CTA
supporting proof
promotion terms where applicable
inventory or capacity constraint
lifecycle conflict check
frequency pressure check
measurement standard
approval owner
Campaign Calendar
The campaign calendar should coordinate:
editorial issues
product launches
seasonal events
promotions
content releases
community events
affiliate priorities
customer education
retention initiatives
major operational constraints
The calendar must not become a licence to send low-value messages.
Seasonal Campaign Phases
Where relevant, a seasonal or promotional campaign may include:
preparation
pre-event education
early access
launch
main event
reminder
final call
extension where genuine
post-event follow-up
Each phase must have a distinct role.
The system must not use false extension or false scarcity.
Campaign And Lifecycle Conflict Rule
Before sending a campaign, check:
Is the recipient in checkout abandonment?
Is the recipient in onboarding?
Is the recipient dealing with a refund or complaint?
Is the recipient receiving replenishment messaging?
Has the recipient recently purchased the promoted product?
Is the campaign offer contradictory to another active message?
Would the campaign create excessive total pressure?
Campaign sending must respect lifecycle relevance and suppression logic.
4. Source Intake Layer
Newsletter production may begin from:
RSS feeds
trusted publications
approved websites
company announcements
platform updates
research papers
official documentation
internal intelligence
existing MWMS content
client approved content
interviews
podcasts
webinars
sales insights
support insights
performance data
approved campaign briefs
approved offer records
approved product records
Source Intake Requirements
Every source candidate should record:
source title
publisher
author where available
source URL
publication date
retrieved date
content type
topic
summary
why it may matter
source authority level
freshness status
duplication status
candidate status
The source URL must remain attached through the production process.
Source retrieval may include:
web page retrieval
RSS ingestion
manual submission
API retrieval
internal document selection
approved database record
The system may convert HTML into readable text for analysis.
The readable text must not replace the original source record.
5. Candidate Review Layer
Every candidate must be reviewed before newsletter drafting.
Candidate Review Fields
Candidate Title
One Line Summary
Editorial Overview
Source URL
Publisher
Publication Date
Reader Relevance
Newsletter Fit
Freshness
Duplication Status
Evidence Quality
Potential Angle
Risk Notes
Decision
Allowed Candidate Decisions
Approve
Reject
Hold
Monitor
Need More Evidence
Need Research Brain Review
Candidate Approval Rule
Only approved candidates may proceed into production.
The approval gate exists to prevent:
low quality stories
irrelevant stories
duplicate stories
outdated stories
weakly sourced claims
content that does not fit the audience
content that does not fit the issue
stories selected only because automation found them
Human Editorial Control
Human review remains required at the candidate stage.
The system may recommend approval or rejection.
It must not silently publish based on its own recommendation.
6. Source Validation Layer
Before drafting, the source must be validated.
Validation Questions
Is the source authoritative enough for the claim?
Is the publication date current enough?
Is the information still accurate?
Is the source primary or secondary?
Does the article cite evidence?
Is the headline misleading?
Does the body support the headline?
Are statistics traceable?
Are quotes authentic?
Are there conflicting reports?
Does the story require multiple source verification?
Is the source legally safe to summarise?
Is the content accessible enough to verify?
Primary Source Preference
Where available, MWMS should prefer:
official announcements
official documentation
original research
direct statements
regulatory notices
company filings
first party reports
Secondary sources may be used when they add:
context
analysis
interpretation
industry reaction
comparison
Multiple Source Verification
Multiple source verification should be required when:
the claim is commercially significant
the claim is controversial
the claim may have changed
the source is weak
the topic is politically sensitive
the topic is legally sensitive
the topic is financially sensitive
the topic affects health or safety
the story relies on anonymous claims
different sources conflict
Single Source Use
A single source may be sufficient when:
the source is clearly primary
the claim is narrow
the information is directly verifiable
the risk is low
the newsletter labels the information accurately
Source Failure Rule
If the source cannot be validated, the story must not proceed as fact.
Possible actions:
reject
hold
request more evidence
rewrite as unconfirmed
route to Research Brain
7. Editorial Angle Layer
A newsletter should not merely repeat the source.
A campaign should not merely repeat the offer.
It should choose a clear angle.
Possible angles include:
what changed
why it matters
what most people missed
what this means for the reader
what to watch next
what action to take
what risk is emerging
what opportunity is emerging
how this connects to a larger trend
how this affects a specific market
how this affects MWMS users or clients
what problem the offer solves
why the timing matters
what objection must be resolved
Angle Selection Questions
What is the most useful interpretation?
What is genuinely new?
What is the consequence?
What is the practical implication?
What should the reader not overlook?
What does the evidence support?
What remains uncertain?
What single message should the reader remember?
Editorial Value Rule
The newsletter must add value beyond compression.
A campaign must add value beyond announcing a sale.
That value may come from:
context
comparison
interpretation
prioritisation
application
implication
connection
decision support
education
clarity
proof
friction reduction
8. Newsletter Component Production Layer
A newsletter issue or campaign may contain one or more structured components.
Possible components include:
newsletter title
subject line
preview text
opening note
story headline
one line summary
TLDR
key points
why this matters
editorial commentary
what to watch
recommended action
primary offer
proof
objection handling
source link
CTA
closing note
The course derived structure of title, TLDR, key points, and why this matters is approved as one useful pattern.
It is not mandatory for every issue.
Newsletter Title
The title should:
represent the issue accurately
avoid clickbait
create interest
match the audience
fit the editorial angle
Subject Line
The subject line should:
be clear
be specific
earn attention honestly
avoid unsupported urgency
avoid spam style phrasing
match the issue content
match the body promise
fit the recipient relationship
Subject Line Testing
Subject line testing may compare:
clarity
specificity
curiosity
benefit
news value
problem recognition
time relevance
Testing must not reward deceptive opens.
A winning subject line must still match the email content.
Preview Text
Preview text should:
support the subject line
add context
avoid repeating the subject line
set expectation
reinforce the main reason to open
Subject line and preview text must work as one message pair.
One Line Summary
The one line summary should:
state the core development
be understandable quickly
avoid unsupported interpretation
remain concise
TLDR
The TLDR should:
summarise the essential meaning
be short
remain accurate
avoid filler
avoid overstating certainty
Key Points
Key points should:
identify the most important facts
use full sentences where useful
avoid duplication
remain traceable to evidence
avoid inserting new unsupported claims
Why This Matters
The why this matters section should:
interpret significance
connect to the reader
distinguish fact from editorial judgement
state uncertainty where required
avoid pretending opinion is proven fact
Editorial Commentary
Editorial commentary may:
explain implications
connect stories
offer a viewpoint
recommend attention
identify a likely consequence
Commentary must be labelled through tone and structure so it is not mistaken for source fact.
What To Watch
What to watch may include:
upcoming decisions
pending releases
policy changes
market response
implementation risk
follow up evidence
CTA
The CTA may direct the reader to:
read the source
read a related MWMS article
book a call
reply
download an asset
watch a video
review an offer
join a community
continue to the next section
make a purchase
The CTA must fit the issue purpose.
9. Copy And Message Hierarchy Layer
Every email must have a clear message hierarchy.
A recommended hierarchy is:
1. Subject Line
2. Preview Text
3. Opening
4. Primary Message
5. Proof Or Explanation
6. Offer Or Recommendation
7. Primary CTA
8. Supporting Sections
9. Closing
10. Footer And Compliance
Not every email requires every component.
The hierarchy must make the main message obvious.
Opening Rule
The opening should:
confirm relevance
establish context
move quickly into value
avoid unnecessary preamble
avoid generic filler
Primary Message Rule
The primary message should:
state the main idea
match the subject line promise
use customer language where available
avoid competing themes
support one primary objective
Proof And Explanation
Proof may include:
evidence
examples
customer outcomes
demonstration
source references
comparison
logic
product detail
Proof must be accurate and compliant.
CTA Hierarchy
Every email should have one primary CTA.
Secondary CTAs may be used only where they do not compete with the primary action.
CTA text should describe the next step clearly.
Copy Review Questions
Is the promise clear?
Does the opening earn continued attention?
Is the main message obvious?
Is the proof sufficient?
Is the offer understandable?
Is the CTA clear?
Does any section repeat another section?
Does the copy sound like MWMS?
Does the message fit the audience’s current state?
Does the copy create false urgency?
10. Voice And Consistency Layer
Newsletter content must follow approved voice rules.
The system should use:
Voice Architecture
Editorial Consistency Framework
Customer Language Bank
Retired Language
Brand Positioning
Audience Context
Newsletter voice should remain:
recognisable
consistent
human
clear
specific
credible
Voice Drift Risks
The system must prevent:
generic AI phrasing
repetitive transitions
empty enthusiasm
forced humour
robotic summaries
excessive headings
over formal language
fake conversational tone
copying the source’s voice too closely
different sections sounding like different brands
Specialist Generation Roles
The system may use separate specialist stages for:
candidate summary
editorial overview
title
subject line
preview text
opening
body copy
TLDR
key points
why this matters
CTA
image direction
issue assembly
All specialist stages must operate from the same approved source or campaign packet.
They must not invent independent evidence.
Cross Output Consistency
Before approval, check that:
title matches the story
subject line matches the issue
preview text supports the subject line
opening matches the body
TLDR matches the source
key points do not conflict
why this matters follows from the facts
CTA matches the content
image direction matches the story
offer terms match approved records
No component may introduce unsupported facts.
11. Evidence And Attribution Layer
Every newsletter story must preserve source traceability.
Minimum Evidence Fields
publisher
source title
source URL
publication date
retrieved date
primary or secondary source status
supporting sources where required
Evidence Visibility
The final newsletter may include:
source link
read more link
source note
publication attribution
footnote
reference section
The exact display may vary by format.
The underlying source record must remain preserved.
Fact And Commentary Separation
The system must distinguish:
reported fact
source claim
MWMS interpretation
prediction
recommendation
opinion
uncertainty
The newsletter must not present predictions or interpretations as established facts.
Copyright Safe Summarisation
The system must:
summarise in original language
avoid copying long passages
avoid reproducing article structure too closely
avoid using publisher images without permission
preserve attribution
link to the source where appropriate
use only short necessary quotations
respect licensing and access restrictions
A newsletter summary should add independent editorial value.
It should not substitute for the original article.
12. Email Design And Section Architecture Layer
Design exists to improve comprehension, trust, attention, and action.
Design must not be treated as decoration.
Every visual section should support at least one of:
message clarity
reading flow
brand recognition
proof
product understanding
CTA visibility
trust
Design Principles
Email design should prioritise:
clear hierarchy
readable typography
sufficient spacing
mobile compatibility
obvious CTA placement
consistent section structure
limited visual competition
brand consistency
fast comprehension
accessible contrast
image relevance
Section Architecture
Possible email sections include:
header
opening text
hero message
feature section
proof section
benefit section
product section
comparison section
testimonial section
editorial section
quick hits
CTA section
footer
A section should not exist merely because a template includes it.
Each section must have a defined communication role.
One Message Per Section
Each section should communicate one main idea.
Sections that combine too many messages reduce clarity.
Visual Hierarchy
The design should make it obvious:
what to read first
what the main message is
what supports the main message
what action to take
Mobile First Rule
The email must remain understandable and actionable on a small screen.
Mobile review should check:
headline length
body width
font readability
button size
spacing
image scaling
section order
link visibility
CTA visibility
footer readability
Image Governance
Images may support:
product understanding
proof
context
brand
visual interest
Images must not:
replace essential text
create misleading evidence
hide the offer terms
make the email unreadable when images are blocked
overwhelm the copy
Email should remain understandable when images fail to load.
Design Simplicity Rule
Effective email design does not require maximum visual complexity.
Simple layouts may outperform complex layouts where they improve:
clarity
speed
trust
mobile readability
CTA focus
Tool Neutrality
Figma, Klaviyo, Canva, and similar tools may be used operationally.
Their interface steps are not permanent Canon.
The design architecture must survive changes in tools.
13. CTA And Conversion Layer
Every CTA must have a purpose.
Possible purposes include:
engagement
traffic
education
lead generation
sales
reply generation
community participation
content discovery
offer progression
CTA Selection Questions
What is the reader ready for?
What action fits the issue?
What action supports the newsletter strategy?
Is the CTA too strong for the relationship stage?
Does the CTA continue the story naturally?
Is the CTA visible?
Does the CTA match the subject line promise?
The newsletter should not force a sales CTA into every story.
Value delivery remains the primary requirement.
CTA Design
The primary CTA should be:
easy to identify
easy to understand
large enough for mobile use
visually distinct
consistent with the message
honest about the next step
Repeated CTA placement may be used in longer emails where it supports usability.
Repeated placement must not create pressure or clutter.
14. Issue Assembly Layer
The issue should be assembled into a coherent editorial experience.
Possible Issue Structure
Subject Line
Preview Text
Opening Note
Primary Story
Secondary Stories
Quick Hits
What To Watch
CTA
Closing Note
Source Links
Possible Campaign Structure
Subject Line
Preview Text
Opening
Primary Message
Proof
Offer Or Recommendation
Primary CTA
Supporting Detail
Final CTA
Closing
Footer
Issue Assembly Rules
The issue should:
have a clear hierarchy
avoid repeating the same point
avoid too many stories
balance depth and speed
maintain consistent formatting
preserve source links
preserve voice
fit mobile reading
make the main story obvious
make the primary action obvious
Issue Types
Single Story Deep Dive
Multi Story Digest
Weekly Roundup
Daily Brief
Company Update
Offer Support Issue
Educational Sequence Issue
Client Intelligence Issue
Affiliate Support Issue
Product Announcement
Seasonal Campaign
Launch Campaign
The structure must match the issue type.
15. Frequency And Segment Governance Layer
Newsletter and campaign frequency must be governed across all active communications.
The system must account for:
scheduled newsletters
promotional campaigns
lifecycle flows
transactional emails
SMS
push notifications
support messages
community messages
The system must not evaluate one email in isolation where total pressure is high.
Frequency Review Questions
How many messages has the recipient recently received?
Are the messages repetitive?
Is the recipient in an active lifecycle flow?
Is the recipient receiving transactional communication?
Does the campaign conflict with customer state?
Is the promotion relevant?
Has engagement materially declined?
Are unsubscribe or complaint signals rising?
Frequency must be calibrated by evidence.
One universal sending frequency must not become Canon.
Suppression may be required because of:
recent purchase
recent high message volume
active support issue
refund
complaint
inactive consent
hard bounce
spam complaint
current onboarding
current checkout recovery
current replenishment flow
irrelevant product eligibility
recipient preference
16. Quality And Publishing Readiness Layer
Every issue must pass quality review.
Required Review Areas
audience fit
newsletter purpose
campaign role
segment suitability
source validity
factual accuracy
editorial value
copy hierarchy
voice consistency
copyright safety
claim safety
CTA fit
design clarity
mobile readability
formatting
link validation
image rights
source visibility
frequency pressure
lifecycle conflict
human approval
Quality Questions
Does the issue tell the reader something useful?
Does it add value beyond the source?
Are the facts supported?
Are interpretations clearly separated?
Does the issue sound human?
Does it fit the brand?
Is anything repetitive?
Is anything overstated?
Is anything missing?
Does the CTA fit?
Are links working?
Are sources preserved?
Is the design readable?
Does the message work without images?
Does the subject line match the body?
Does the preview text support the subject line?
Is the audience suitable?
Is the timing justified?
Is the issue ready to send?
Publishing Decision Types
Ready
Ready With Minor Edits
Needs Source Review
Needs Editorial Revision
Needs Copy Revision
Needs Design Revision
Needs Compliance Review
Needs Voice Revision
Needs CTA Revision
Needs Segment Review
Needs Frequency Review
Hold
Reject
Human Approval Rule
No newsletter or campaign may be sent without human approval.
The approval should confirm:
content
sources
claims
voice
subject line
preview text
CTA
links
formatting
images
recipient group
send timing
frequency pressure
lifecycle conflicts
17. Distribution Handoff Layer
This framework governs content preparation.
It does not authorize autonomous sending.
A platform ready handoff should include:
approved campaign role
approved audience
approved subject line
approved preview text
approved issue body
approved links
approved images
approved CTA
source references
recipient segment
suppression requirements
send date
send time
approval record
version
The email platform may include:
Mailchimp
ConvertKit
Beehiiv
Substack
ActiveCampaign
HubSpot
Klaviyo
client approved platform
future MWMS platform
The platform is an implementation choice.
The content and approval record remain governed by MWMS.
Tool-specific upload procedures must remain outside Canon.
18. Performance Feedback Layer
Newsletter and campaign production should improve through evidence.
Possible performance signals include:
delivery rate
bounce rate
open rate
click rate
click distribution
reply rate
unsubscribe rate
spam complaint rate
conversion rate
booking rate
revenue contribution
contribution margin
refund rate
cancellation rate
content section engagement
topic performance
subject line performance
preview text performance
CTA performance
segment performance
mobile performance
Performance Interpretation Rule
No single metric should control editorial or campaign decisions.
Open rate is directional evidence only.
It may be affected by privacy protections, image loading behaviour, platform measurement, and recipient device conditions.
Examples:
High opens and low clicks may indicate:
strong subject line
weak body relevance
weak CTA
misaligned expectation
Low opens and strong clicks among openers may indicate:
weak subject line
strong content
Small list performance must not be over interpreted.
High revenue with high complaints may be strategically weak.
High clicks with poor customer quality may be commercially weak.
Platform-attributed revenue must not automatically be treated as incremental profit.
Performance should be interpreted using:
audience size
segment quality
send frequency
offer
margin
refunds
complaints
customer quality
conversion lag
comparison baseline
Feedback Routing
Performance feedback should inform:
Content Brain Content Signal Feedback Framework
Editorial Consistency Framework
Content Opportunity Queue
Content Production Queue
Ecommerce Brain where campaign and lifecycle interactions matter
Customer Brain where relationship quality matters
Conversion Brain where landing or offer progression matters
Finance Brain where contribution and margin matter
Offer Brain where CTA performance matters
Sales Brain where lead quality matters
Affiliate Brain where offer performance matters
AIBS Brain where client outcomes matter
Newsletter Candidate Record Standard
Each candidate should include:
Candidate ID
Source Title
Publisher
Author
Source URL
Publication Date
Retrieved Date
Topic
One Line Summary
Editorial Overview
Reader Relevance
Newsletter Fit
Freshness Status
Duplication Status
Evidence Quality
Potential Angle
Risk Notes
Decision
Decision Reason
Approved By
Approval Date
Newsletter Production Record Standard
Each produced story, issue, or campaign should include:
Production ID
Candidate ID Where Relevant
Newsletter
Campaign Name Where Relevant
Issue Type
Campaign Role
Audience
Segment
Purpose
Editorial Angle
Source Packet
Title
Subject Line
Preview Text
Opening
TLDR
Key Points
Why This Matters
Commentary
What To Watch
Offer Where Relevant
Proof
CTA
Image Direction
Section Plan
Source Links
Voice Version
Prompt Version
Model Version Where Relevant
Frequency Review Status
Lifecycle Conflict Status
Design Review Status
Mobile Review Status
Compliance Status
Status
Reviewer
Approval Date
Publication Date
Performance Record Link
Candidate Discovery And Approval Workflow
Step 1: Define Newsletter Or Campaign Strategy
Confirm audience, purpose, frequency, format, campaign role, segment, and business objective.
Step 2: Collect Candidate Sources Or Approved Campaign Inputs
Use approved feeds, sources, internal assets, research, intelligence, offers, products, and campaign briefs.
Step 3: Retrieve Source Material
Preserve the original source and convert to readable text where required.
Step 4: Create Candidate Summary Or Campaign Brief
Generate:
one line summary
editorial overview
why it may matter
source metadata
campaign objective where relevant
Step 5: Check Freshness And Duplication
Confirm whether:
the story is current
the story already exists in the queue
the same event appears in multiple sources
the issue has already covered it
the campaign duplicates recent messaging
Step 6: Review Candidate Or Campaign
Human chooses:
approve
reject
hold
monitor
need more evidence
Step 7: Validate Source, Offer, And Claims
Check evidence, authority, date, conflicts, pricing, eligibility, terms, and attribution.
Step 8: Select Editorial Or Campaign Angle
Choose the reader relevant interpretation or commercial message.
Step 9: Define Message Hierarchy
Set:
subject line direction
preview text role
opening
primary message
proof
offer where relevant
primary CTA
supporting sections
Step 10: Create Newsletter Or Campaign Components
Create approved components such as:
title
subject line
preview text
opening
TLDR
key points
why this matters
commentary
proof
CTA
image direction
section plan
Step 11: Run Cross Output Consistency Check
Confirm every component reflects the same evidence, angle, offer, and audience.
Step 12: Apply Voice And Editorial Review
Check house voice, clarity, humanity, and consistency.
Step 13: Apply Evidence And Compliance Review
Check claims, sources, copyright, images, terms, and attribution.
Step 14: Apply Design And Mobile Review
Check hierarchy, section structure, readability, image dependence, CTA visibility, and mobile usability.
Step 15: Apply Segment And Frequency Review
Check audience suitability, lifecycle conflict, communication pressure, and suppression.
Step 16: Assemble Issue Or Campaign
Create the complete message in the approved format.
Step 17: Run Publishing Readiness Check
Check links, layout, mobile readability, CTA, source visibility, segment, timing, and final approval.
Step 18: Handoff To Email Platform
Prepare the approved issue for human controlled sending.
Step 19: Capture Performance
Record issue, campaign, segment, and component level signals.
Step 20: Feed Learning Back
Update content signals, topic priorities, voice guidance, design guidance, audience rules, and future test decisions.
Automation Role
Automation may support:
source monitoring
candidate creation
HTML cleaning
metadata extraction
duplicate checks
one line summaries
editorial overviews
campaign brief preparation
draft component generation
section planning
issue assembly
link checks
formatting checks
mobile checks
frequency checks
lifecycle conflict checks
performance data capture
Automation must not control:
final candidate approval
final source judgement
final editorial interpretation
final compliance approval
final segment approval
final send approval
Automation Design Principle
The automation should be divided into controlled stages.
Recommended Structure
Stage One: Candidate Intelligence
Source discovery
↓
Source retrieval
↓
Text cleaning
↓
Metadata capture
↓
One line summary
↓
Editorial overview
↓
Candidate queue
↓
Human approval
Stage Two: Approved Content Or Campaign Production
Approved candidate or campaign brief
↓
Source and claim validation
↓
Audience and campaign role
↓
Subject line
↓
Preview text
↓
Opening
↓
Primary message
↓
TLDR
↓
Key points
↓
Why this matters
↓
Proof
↓
CTA
↓
Image direction
↓
Section plan
↓
Cross output validation
↓
Issue assembly
↓
Design and mobile review
↓
Segment and frequency review
↓
Human approval
Stage Three: Distribution And Feedback
Approved issue
↓
Platform handoff
↓
Human controlled send
↓
Performance capture
↓
Content and campaign feedback
Supabase Position
For future MWMS implementation, Supabase should remain the operational source of truth for:
candidate records
source metadata
approval state
production state
campaign state
issue state
source links
version history
review records
segment decisions
frequency review
lifecycle conflict review
performance records
Airtable, Google Docs, and similar tools may be used for testing or temporary workflows.
They must not silently replace the approved source of truth.
Research Brain Relationship
Research Brain should be used when:
the story requires deeper verification
multiple sources conflict
the claim is material
the topic is unfamiliar
the source is weak
the story requires original research
the newsletter requires a broader evidence packet
Content Brain should not recreate Research Brain inside newsletter production.
HeadOffice Relationship
HeadOffice may provide approved intelligence items to Content Brain.
Content Brain may use those items as newsletter candidates.
HeadOffice retains responsibility for internal intelligence routing.
Content Brain retains responsibility for external newsletter production.
An item may exist in both systems with different records and purposes.
Ecommerce Brain Relationship
Ecommerce Brain governs lifecycle messaging architecture.
Content Brain governs scheduled newsletter and campaign content production.
Content Brain must respect Ecommerce Brain controls for:
lifecycle stage
active flow
suppression
customer state
recent purchase
abandonment
onboarding
replenishment
reactivation
Content Brain must not create campaign messages that conflict with lifecycle communication.
Repurposing Relationship
The Content Brain Content Repurposing Framework applies when:
an approved article becomes a newsletter section
a video becomes a newsletter issue
a webinar becomes an email series
a newsletter becomes social content
a newsletter becomes a video script
a newsletter becomes an article brief
Repurposing must preserve:
source meaning
evidence
voice
audience fit
CTA logic
The Newsletter Content Production Framework remains responsible for final newsletter quality.
AI Content Quality Relationship
The Content Brain AI Content Quality Governance Framework applies to:
hallucination prevention
source grounding
quality thresholds
human review
voice quality
unsupported claim detection
repetition control
generic AI pattern detection
The newsletter framework does not replace those controls.
Editorial Consistency Relationship
The Content Brain Editorial Consistency Framework applies to:
house voice
format consistency
recurring section logic
tone
sentence style
editorial identity
issue to issue continuity
Publishing Readiness Relationship
The Content Brain Publishing Readiness Checklist applies before distribution.
Newsletter specific checks from this framework must be included in the final approval.
Compliance And Risk Rules
The system must prevent:
false claims
misleading summaries
fabricated facts
fabricated quotes
copied article sections
unlicensed image use
unsupported health claims
unsupported financial claims
unsupported legal claims
deceptive urgency
hidden affiliate relationships
misleading AI generated imagery
unapproved personal data use
automatic sending without approval
sending after consent withdrawal
misleading subject lines
false scarcity
false promotion extensions
contradictory offer terms
Newsletter content must comply with:
applicable marketing rules
email consent rules
affiliate disclosure rules
copyright rules
privacy rules
brand rules
client approval rules
platform rules
Human Review Thresholds
Human review is always required before sending.
Additional specialist review is required when:
the issue includes regulated claims
the issue includes financial guidance
the issue includes medical guidance
the issue includes legal interpretation
the issue includes political claims
the issue includes controversial allegations
the issue includes material commercial recommendations
the issue includes affiliate claims
the issue includes client confidential information
the issue includes AI generated images of real events or people
the campaign includes unusual pricing or promotion terms
the campaign targets a sensitive or restricted audience
Common Failure Modes
MWMS must prevent:
publishing every discovered article
confusing freshness with importance
summarising without adding value
using weak sources
using only one source for a disputed claim
losing the source URL
creating inconsistent component outputs
inventing why this matters
repeating source language too closely
copying article structure
generic AI voice
too many stories in one issue
weak subject line and strong content mismatch
strong subject line and weak content mismatch
preview text repeating the subject line
forced CTA
multiple competing CTAs
dead links
unlicensed images
AI images presented as evidence
publishing before human review
using open rate alone as a success measure
sending promotional campaigns without segment review
sending campaigns that conflict with lifecycle flows
overusing discounting
using visually complex templates that reduce readability
building emails that fail when images are blocked
allowing tool convenience to define architecture
allowing HeadOffice intelligence intake and Content Brain production to merge into one uncontrolled workflow
Drift Protection
This framework protects MWMS from:
newsletter automation becoming content spam
source discovery becoming automatic publication
internal intelligence records being treated as publishable content
content production bypassing Research Brain
editorial judgement being replaced by AI
source evidence being lost
news summaries becoming copyright substitutes
opinion being presented as fact
reader relevance being ignored
newsletter voice becoming generic
performance data overriding editorial standards
platform convenience replacing governance
campaign calendars becoming excuses for low-value sending
subject line optimisation becoming deceptive
design complexity replacing communication clarity
open rate becoming the primary success metric
campaign messaging overriding lifecycle relevance
Klaviyo, Figma, or any other tool becoming permanent architecture
Any newsletter produced without audience clarity, source validation, editorial value, evidence traceability, voice control, message hierarchy, segment suitability, frequency review, and human approval should be treated as a drift risk.
Any newsletter automation that sends without a final human controlled gate should be treated as a critical drift risk.
Governance Role
Content Brain owns the MWMS Newsletter Content Production Framework.
HeadOffice governs cross Brain alignment and internal intelligence boundaries.
Research Brain governs deeper research and disputed evidence.
Creative Brain governs visual direction and creative presentation.
Compliance Brain governs claims, copyright, disclosures, consent, and sensitive content.
Data Brain governs metadata, source records, approval records, and performance data.
Automation Brain governs workflow reliability, retries, logging, and failure handling when implementation is authorized.
Sales Brain governs sales aligned CTAs and lead quality feedback.
Affiliate Brain governs affiliate offer use and disclosure.
Ecommerce Brain governs lifecycle messaging state, suppression, and conflict rules.
Customer Brain governs customer relevance and relationship quality.
Conversion Brain governs landing and post-click progression.
Finance Brain governs contribution, margin, and promotion economics.
AIBS Brain governs future client newsletter production systems.
Relationship To Other MWMS Standards
This framework supports and must align with:
Content Brain Canon
Content Brain Architecture
Content Brain Operating Model
Content Brain Workflow Map
Content Brain Content Production System Framework
Content Brain Content Repurposing Framework
Content Brain Editorial Consistency Framework
Content Brain AI Content Quality Governance Framework
Content Brain Publishing Readiness Checklist
Content Brain Content Signal Feedback Framework
Content Brain Content Opportunity Queue Specification
Content Brain Content Production Queue Specification
Content Brain VOC Grounded AI Copy Framework
Content Brain Information Gain Framework
Content Brain E E A T Content Trust Framework
Ecommerce Brain Lifecycle Messaging Architecture Framework
MWMS Source Visibility And Evidence Display Standard
MWMS Prompt Architecture And Automation Output Reliability Framework
MWMS Missing Context And Evidence Gap Handling Rule
HeadOffice Newsletter Intelligence Operating Protocol
HeadOffice Newsletter Intelligence Intake Framework
HeadOffice Newsletter Intelligence Output Validation Protocol
MWMS Full Newsletter Intelligence Extraction Protocol
MWMS n8n Operating And Deployment Standard
MWMS AI Output Validation Standard
Architectural Intent
The architectural intent of the MWMS Newsletter Content Production Framework is to make newsletter and scheduled campaign production a controlled Content Brain capability.
The long term system should be able to:
discover candidate sources
preserve source evidence
create candidate summaries
support human editorial selection
validate approved sources
plan campaign roles
coordinate campaign calendars
generate consistent newsletter components
maintain brand voice
separate fact from commentary
build clear message hierarchy
assemble complete issues
create modular email sections
support mobile readability
check segment suitability
check lifecycle conflict
check frequency pressure
route for approval
handoff to an email platform
capture performance
improve future production
The system should reduce repetitive production work without reducing editorial responsibility.
The long term goal is not a fully autonomous newsletter.
The long term goal is a high quality human controlled newsletter and campaign production system with strong automation support.
Final Standard
The MWMS final standard is:
No newsletter candidate becomes publishable content without human approval.
No newsletter story proceeds without a preserved source record.
No factual claim proceeds without enough evidence.
No AI generated component may introduce unsupported information.
No campaign may be sent without a declared role and suitable segment.
No campaign may ignore lifecycle conflicts or communication pressure.
No design may reduce message clarity.
No issue may be sent without final human approval.
A valid newsletter production record must define:
audience
segment
purpose
campaign role where relevant
source
source date
editorial angle
title
subject line
preview text
opening
primary message
TLDR
key points
why this matters
commentary where used
proof where used
CTA
section plan
source links
image status
design status
mobile status
voice status
compliance status
frequency review status
lifecycle conflict status
approval status
publication status
performance status
That is the MWMS Newsletter Content Production standard.
Change Log
Version: v1.1
Date: 2026-07-19
Author: HeadOffice
Change:
Expanded the MWMS Newsletter Content Production Framework using durable intelligence absorbed from Sam Piliero The Facebook Ads Blueprint bonus Email Marketing module by Max Sturtevant.
Added:
Campaign Role And Calendar Layer
campaign and lifecycle separation
campaign role definition
campaign planning fields
campaign calendar governance
seasonal campaign phases
campaign and lifecycle conflict review
segment suitability
subject line and preview text pairing
subject line testing governance
copy and message hierarchy
opening rule
primary message rule
proof and explanation
CTA hierarchy
email design and section architecture
one message per section
visual hierarchy
mobile first review
image dependence protection
design simplicity rule
tool neutrality
frequency and segment governance
expanded publishing readiness
expanded distribution handoff
expanded performance interpretation
open rate caution
margin and customer quality interpretation
campaign production records
design and mobile review
segment and frequency review
lifecycle conflict review
Ecommerce Brain relationship
Customer Brain relationship
Conversion Brain relationship
Finance Brain relationship
Rejected From Canon:
Klaviyo-specific setup procedures
Figma-specific design procedures
fixed email template rules
fixed campaign frequency
fixed subject line formulas
universal open-rate targets
universal click-rate targets
platform interface instructions
tool-specific upload procedures
visual complexity as a quality proxy
Previous Version: v1.0
Previous Review Date: 2026-06-27
Change Impact Declaration
Pages Created:
None
Pages Updated:
MWMS Newsletter Content Production Framework
Pages Deprecated:
None
Registries Requiring Update:
Content Brain Page Registry
Content Brain Copy Map
MWMS Architecture Registry
MCR Page Registry
MCR Copy Map
MWMS Course Absorption Decision Registry
Content Brain Architecture Only If Specialist Framework Relationships Are Maintained
Content Brain Workflow Map Only If Newsletter And Campaign Production Is Added To The Visible Workflow
Canon Version Update Required:
No
System Map Update Required:
Review Content Brain System Map, Ecommerce Brain relationship, Newsletter production relationship, and campaign messaging relationship
Change Log Entry Required:
Yes
Supabase Impact:
None
Plugin Impact:
None
Automation Impact:
None
AI Coordination Impact:
None
Employee Impact Check
Employees impacted:
Content Planner Employee
Content Writer Employee
Newsletter Editor Employee
Research Employee
Source Verification Employee
Editorial Quality Employee
Creative Direction Employee
Compliance Reviewer Employee
Automation Architect Employee
Data Operations Employee
Sales Support Employee
Affiliate Content Employee
AIBS Client Content Employee
Ecommerce Lifecycle Employee Where Future Employee Architecture Exists
Customer Intelligence Employee Where Future Employee Architecture Exists
Required behaviour updates:
AI Employees must not treat every discovered source as approved newsletter content.
AI Employees must preserve original source metadata and URLs.
AI Employees must not draft newsletter content until the candidate or campaign brief is approved.
AI Employees must use validated source and campaign packets.
AI Employees must separate reported fact, source claim, interpretation, prediction, and recommendation.
AI Employees must not reproduce source articles or article structure too closely.
AI Employees must maintain approved house voice.
AI Employees must preserve subject line, preview text, opening, body, proof, and CTA consistency.
AI Employees must use one primary message and one primary CTA unless approved otherwise.
AI Employees must not use design complexity as a substitute for communication clarity.
AI Employees must perform mobile readability checks.
AI Employees must check segment suitability.
AI Employees must check active lifecycle conflicts.
AI Employees must check communication pressure.
AI Employees must not create misleading AI images.
AI Employees must not treat open rate as the sole success metric.
AI Employees must not send newsletters autonomously.
AI Employees must route every issue and campaign for final human editorial approval.
END OF FULL FILE OUTPUT