System: MWMS
Document Type: Framework
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Version: v1.0
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-06-27
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, And Newsletter Intelligence Governance
Primary Brain: Content Brain
Supporting Brains: Research Brain, HeadOffice Brain, Creative Brain, Compliance Brain, Data Brain, Automation Brain, Sales Brain, Affiliate Brain, AIBS 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, and existing content assets into high quality reader facing newsletters.
This framework governs newsletter 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 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
human approved before sending
measurable after publication
Without this framework, MWMS risks creating newsletters 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
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 production system that uses automation to reduce repetitive work while preserving human judgement.
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
This framework applies to the following stages:
source discovery
candidate capture
source retrieval
source cleaning
candidate summarisation
editorial review
approval or rejection
newsletter angle selection
fact checking
title creation
subject line creation
preview text creation
TLDR creation
key point creation
why this matters interpretation
commentary creation
image direction
CTA selection
issue assembly
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
Core Principle
The core principle is:
Automation may accelerate newsletter production, but editorial judgement controls what is included, what is said, how it is framed, 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.
A strong newsletter must answer:
Why should this reader care?
What happened?
What does it mean?
Why does it matter now?
What should the reader think, do, watch, or understand next?
Newsletter Production Boundary
The MWMS Newsletter Content Production Framework begins only when a source, topic, signal, offer, 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
approved internal documents
approved company updates
approved external news sources
approved affiliate sources
approved client materials
approved performance data
It must not absorb the internal routing role of HeadOffice Newsletter Intelligence.
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 or topic
↓
Candidate review
↓
Editorial approval
↓
Source validation
↓
Newsletter production
↓
Editorial quality review
↓
Publishing readiness
↓
Human controlled send
↓
Performance feedback
Core Newsletter Production Model
MWMS uses the following newsletter production model:
- Newsletter Strategy Layer
- Audience And Purpose Layer
- Source Intake Layer
- Candidate Review Layer
- Source Validation Layer
- Editorial Angle Layer
- Newsletter Component Production Layer
- Voice And Consistency Layer
- Evidence And Attribution Layer
- Image And Visual Direction Layer
- CTA And Conversion Layer
- Issue Assembly Layer
- Quality And Publishing Readiness Layer
- Distribution Handoff Layer
- Performance Feedback Layer
- 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
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?
- Audience And Purpose Layer
Every issue must define:
primary audience
reader awareness level
reader sophistication
reader problem
reader interest
reader urgency
reader relationship to the brand
issue purpose
intended outcome
Possible issue outcomes include:
inform
explain
reframe
warn
recommend
educate
convert
retain
reactivate
prepare
Reader Relevance Rule
A story should not be included merely because it is new.
It should be included because it is relevant to the reader and supports the newsletter’s purpose.
- 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
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.
- 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.
- 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
- Editorial Angle Layer
A newsletter should not merely repeat the source.
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
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?
Editorial Value Rule
The newsletter must add value beyond compression.
That value may come from:
context
comparison
interpretation
prioritisation
application
implication
connection
decision support
- Newsletter Component Production Layer
A newsletter issue 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
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
Preview Text
Preview text should:
support the subject line
add context
avoid repeating the subject line
set expectation
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
The CTA must fit the issue purpose.
- 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
TLDR
key points
why this matters
CTA
image direction
issue assembly
All specialist stages must operate from the same approved source packet.
They must not invent independent evidence.
Cross Output Consistency
Before approval, check that:
title matches the story
subject line matches the issue
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
No component may introduce unsupported facts.
- 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.
- Image And Visual Direction Layer
Images are optional.
A newsletter must not use an image merely because automation can generate one.
Possible image sources include:
approved brand assets
licensed stock assets
original graphics
charts
screenshots where permitted
approved product images
AI generated images
Image Direction Requirements
The image should:
support the story
fit the brand
avoid misleading representation
avoid implying documentary evidence when it is illustrative
fit the newsletter format
fit the required aspect ratio
AI Generated Image Rules
AI generated images must not:
misrepresent a real event
fabricate evidence
imitate a real photograph in a misleading context
show unsupported product results
create false authority
violate brand or likeness rules
Where appropriate, the image should be labelled or handled as illustrative AI generated content.
Image prompts should be generated from the approved editorial angle, not from unverified source text alone.
Image Rights
The system must record:
asset source
license status
creator where required
usage rights
AI generation status
approval status
- 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?
The newsletter should not force a sales CTA into every story.
Value delivery remains the primary requirement.
- 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
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
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
The structure must match the issue type.
- Quality And Publishing Readiness Layer
Every issue must pass quality review.
Required Review Areas
audience fit
newsletter purpose
source validity
factual accuracy
editorial value
voice consistency
copyright safety
claim safety
CTA fit
mobile readability
formatting
link validation
image rights
source visibility
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 issue ready to send?
Publishing Decision Types
Ready
Ready With Minor Edits
Needs Source Review
Needs Editorial Revision
Needs Compliance Review
Needs Voice Revision
Needs CTA Revision
Hold
Reject
Human Approval Rule
No newsletter may be sent without human approval.
The approval should confirm:
content
sources
claims
voice
CTA
links
formatting
images
recipient group
send timing
- Distribution Handoff Layer
This framework governs content preparation.
It does not authorize autonomous sending.
A platform ready handoff should include:
approved subject line
approved preview text
approved issue body
approved links
approved images
approved CTA
source references
recipient segment
send date
send time
approval record
version
The email platform may include:
Mailchimp
ConvertKit
Beehiiv
Substack
ActiveCampaign
HubSpot
client approved platform
future MWMS platform
The platform is an implementation choice.
The content and approval record remain governed by MWMS.
- Performance Feedback Layer
Newsletter production should improve through evidence.
Possible performance signals include:
open rate
click rate
click distribution
reply rate
unsubscribe rate
spam complaint rate
conversion rate
booking rate
revenue contribution
content section engagement
topic performance
subject line performance
CTA performance
Performance Interpretation Rule
No single metric should control editorial decisions.
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.
Feedback Routing
Performance feedback should inform:
Content Brain Content Signal Feedback Framework
Editorial Consistency Framework
Content Opportunity Queue
Content Production Queue
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 or issue should include:
Production ID
Candidate ID
Newsletter
Issue Type
Audience
Purpose
Editorial Angle
Source Packet
Title
Subject Line
Preview Text
TLDR
Key Points
Why This Matters
Commentary
What To Watch
CTA
Image Direction
Source Links
Voice Version
Prompt Version
Model Version Where Relevant
Status
Reviewer
Approval Date
Publication Date
Performance Record Link
Candidate Discovery And Approval Workflow
Step 1: Define Newsletter Strategy
Confirm audience, purpose, frequency, format, and business objective.
Step 2: Collect Candidate Sources
Use approved feeds, sources, internal assets, research, and intelligence.
Step 3: Retrieve Source Material
Preserve the original source and convert to readable text where required.
Step 4: Create Candidate Summary
Generate:
one line summary
editorial overview
why it may matter
source metadata
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
Step 6: Review Candidate
Human chooses:
approve
reject
hold
monitor
need more evidence
Step 7: Validate Source
Check evidence, authority, date, conflicts, and attribution.
Step 8: Select Editorial Angle
Choose the reader relevant interpretation.
Step 9: Create Newsletter Components
Create approved components such as:
title
subject line
preview text
TLDR
key points
why this matters
commentary
CTA
image direction
Step 10: Run Cross Output Consistency Check
Confirm every component reflects the same evidence and angle.
Step 11: Apply Voice And Editorial Review
Check house voice, clarity, humanity, and consistency.
Step 12: Apply Evidence And Compliance Review
Check claims, sources, copyright, images, and attribution.
Step 13: Assemble Issue
Create the complete issue in the approved format.
Step 14: Run Publishing Readiness Check
Check links, layout, mobile readability, CTA, source visibility, and final approval.
Step 15: Handoff To Email Platform
Prepare the approved issue for human controlled sending.
Step 16: Capture Performance
Record issue level and component level signals.
Step 17: Feed Learning Back
Update content signals, topic priorities, voice guidance, and future test decisions.
Automation Role
Automation may support:
source monitoring
candidate creation
HTML cleaning
metadata extraction
duplicate checks
one line summaries
editorial overviews
draft component generation
issue assembly
link checks
formatting checks
performance data capture
Automation must not control:
final candidate approval
final source judgement
final editorial interpretation
final compliance 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 Production
Approved candidate
↓
Source validation
↓
Title
↓
Subject line
↓
Preview text
↓
TLDR
↓
Key points
↓
Why this matters
↓
Commentary
↓
CTA
↓
Image direction
↓
Cross output validation
↓
Issue assembly
↓
Human approval
Stage Three: Distribution And Feedback
Approved issue
↓
Platform handoff
↓
Human controlled send
↓
Performance capture
↓
Content feedback
Supabase Position
For future MWMS implementation, Supabase should remain the operational source of truth for:
candidate records
source metadata
approval state
production state
issue state
source links
version history
review records
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.
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
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
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
forced CTA
dead links
unlicensed images
AI images presented as evidence
publishing before human review
using open rate alone as a success measure
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
Any newsletter produced without audience clarity, source validation, editorial value, evidence traceability, voice control, 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.
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
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 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
generate consistent newsletter components
maintain brand voice
separate fact from commentary
assemble complete issues
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 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 issue may be sent without final human approval.
A valid newsletter production record must define:
audience
purpose
source
source date
editorial angle
title
subject line
preview text
TLDR
key points
why this matters
commentary where used
CTA
source links
image status
voice status
compliance status
approval status
publication status
performance status
That is the MWMS Newsletter Content Production standard.
Change Log
Version: v1.0
Date: 2026-06-27
Author: HeadOffice
Change:
Created the MWMS Newsletter Content Production Framework as a new Content Brain framework.
Established the formal boundary between:
HeadOffice Newsletter Intelligence for internal intelligence intake, routing, parking, decisions, and tasks
and
Content Brain Newsletter Production for reader facing newsletter creation, editorial review, distribution handoff, and performance learning
Absorbed the strongest non duplicative intelligence from the AI Automations By Jack newsletter automation material.
Added:
Newsletter Production Boundary
fifteen layer newsletter production model
newsletter strategy layer
audience and purpose layer
source intake layer
candidate review layer
source validation layer
editorial angle layer
newsletter component production layer
voice and consistency layer
evidence and attribution layer
image and visual direction layer
CTA and conversion layer
issue assembly layer
quality and publishing readiness layer
distribution handoff layer
performance feedback layer
candidate record standard
production record standard
candidate discovery and approval workflow
three stage automation model
Supabase source of truth position
Research Brain boundary
HeadOffice boundary
repurposing relationship
AI content quality relationship
editorial consistency relationship
publishing readiness relationship
copyright safe summarisation
fact and commentary separation
AI generated image governance
cross output consistency checks
human controlled sending requirement
performance feedback routing
drift protection
governance role
architectural intent
Final operating position:
Automation may support discovery, summarisation, production, assembly, and feedback.
Human editorial judgement controls inclusion, interpretation, approval, and sending.
Change Impact Declaration
Pages Created:
MWMS Newsletter Content Production Framework
Pages Updated:
None
Pages Deprecated:
None
Registries Requiring Update:
Content Brain Page Registry
Content Brain Copy Map
Content Brain Architecture Only If Specialist Framework Relationships Are Maintained
Content Brain Workflow Map Only If Newsletter Production Is Added To The Visible Workflow
Canon Version Update Required:
No
Change Log Entry Required:
Yes
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
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 is approved.
AI Employees must use validated source 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 run cross output consistency checks.
AI Employees must not create misleading AI images.
AI Employees must not send newsletters autonomously.
AI Employees must route every issue for final human editorial approval.
END OF FULL FILE OUTPUT