Brain Name: Content Brain
Document Type: Operational Architecture Overview
Status: Active Architecture Reference
Version: v1.2
Authority: HeadOffice
Applies To: Content Brain operational structure, mwmscontentbrain.site page hierarchy, manual workflow layer, content planning, content briefing, publishing readiness, affiliate content support, SEO content support, internal linking, repurposing, refresh, legacy page handling, cross-brain integration readiness, future build-readiness planning, and future plugin or UI planning boundaries
Parent: Content Brain
Last Reviewed: 2026-06-02
Operational Copy Notice
This page is the operational architecture overview for Content Brain on mwmscontentbrain.site.
MCR remains the source of truth.
If this page conflicts with MCR, the MCR version overrides it.
This page does not replace:
Content Brain Canon
Content Brain Architecture in MCR
Content Brain Page Registry
Content Brain Copy Map
Content Brain Migration Execution Checklist
mwmscontentbrain.site First Operational Layer Build Checklist
Content Brain Cross-Brain Integration Map
This page explains how the live Content Brain site is structured for operator use.
The Content Brain Cross-Brain Integration Map explains how Content Brain connects to the wider MWMS ecosystem.
Together, these two pages define:
how Content Brain is structured internally
how Content Brain should be used manually
how Content Brain connects with other Brains
how Content Brain should become build-ready later
This page should be used as the live-site architecture reference.
It should not be used to override MCR.
Current Status Notice
Content Brain now has:
a clean first operational layer
a defined set of active reference frameworks
a defined legacy/reference layer
a Page Registry
a Cross-Brain Integration Map
manual-first workflow discipline
future build-readiness direction
Content Brain is not yet a plugin/UI system.
Content Brain is not yet automated.
Content Brain is currently an operational knowledge and workflow structure that should be used manually until repeated workflow patterns prove what should be systemised later.
Purpose
Content Brain Architecture defines how Content Brain is organised on mwmscontentbrain.site.
It clarifies:
which pages form the active operator layer
which pages are supporting reference frameworks
which pages are legacy references
which pages support governance and registry control
how Content Brain should connect with other Brains
how manual workflow should operate before system build
how future build candidates should be identified
The purpose is to prevent:
page drift
workflow confusion
duplicate pages
legacy pages becoming active again
random content production
premature system build
M being handed unclear build instructions
Content Brain becoming disconnected from the wider MWMS ecosystem
The architecture exists to keep Content Brain clean, understandable, useful, and integration-ready.
Core Architectural Principle
Content Brain is a communication-structure Brain.
It is not only a content-writing Brain.
Content Brain turns intelligence into structured content assets.
Content Brain should support:
reader understanding
search usefulness
affiliate support
ad message match
conversion readiness
trust formation
internal linking
repurposing
refresh
publishing readiness
content optimization
cross-brain handoff quality
system learning
Content Brain should not take authority from other Brains.
It should translate approved, review-ready, or clearly exploratory intelligence into useful content structures.
Current Live-Site Structure
Content Brain currently has these major structural layers:
Active Brain Homepage
Active First Operational Layer
Active Integration Map
Active Reference Frameworks
Legacy Reference Pages
Older Legacy Pages Awaiting Future Update
Governance And Registry Pages
Each layer has a different role.
Operators should not treat all pages equally.
The active first operational layer is used first.
Reference frameworks support deeper reasoning.
Legacy pages are retained for historical logic, future merge value, or cleanup review.
Governance and registry pages protect structure.
The integration map defines cross-brain relationships.
Active Brain Homepage
Content Brain
Status: Active
Parent: Top Level
Role: Main Content Brain homepage and operational index.
The homepage should:
explain what Content Brain does
point operators to the first operational layer
avoid old naming
avoid version numbers in page titles
avoid legacy pages being treated as current workflow pages
reinforce manual-first operation
support the wider Content Brain structure
The homepage should remain Top Level.
All major child pages should sit under Parent: Content Brain.
Active First Operational Layer
The first operational layer contains the current active operator pages.
These pages are used for normal Content Brain work.
Content Brain Workflow
Role:
classify content work
route requests
park unclear work
protect workflow discipline
prevent vague inputs becoming production work
Use when deciding what should happen next with any content-related request.
Content Brain Content Briefs
Role:
structure general content briefs
define audience
define intent
define content purpose
define approval owner
define handoff destination
define signal to watch
Use when a content asset needs a proper brief before production.
Content Brain SEO Content Briefs
Role:
structure search-focused content briefs
define search intent
define SERP relevance
define information gain
define topic coverage
define internal link needs
Use when content has SEO or search-intent relevance.
Content Brain Affiliate Content Packs
Role:
structure affiliate offer support content
plan product education assets
plan pre-sell support
plan FAQ, trust, YouTube, VEO3, email, and bridge support where relevant
Use when Content Brain supports an affiliate product or offer.
Content Brain Affiliate Funnel Support
Role:
map content to affiliate funnel stages
support problem awareness
support solution awareness
support product education
support trust
support comparison
support objection handling
support VSL preparation
Use when content supports movement through an affiliate funnel.
Content Brain Publishing Readiness
Role:
check whether content is ready for use
check claim safety
check approval ownership
check handoff destination
check next step
check whether content should be held
Use before content is published, handed off, repurposed, refreshed, or used.
Content Brain Internal Linking
Role:
plan internal links
connect pages
support topic clusters
support reader journey
avoid orphan content
strengthen page relationships
Use when content needs page connection planning.
Content Brain Repurposing
Role:
reuse approved content safely
preserve meaning
avoid claim strengthening
adapt content to new formats
protect audience-stage fit
Use when turning one approved asset into another format.
Content Brain Refresh
Role:
review existing content
improve outdated content
merge weak content
retire unnecessary content
update claim-sensitive content
fix intent mismatch
Use when a page needs improvement, correction, consolidation, or retirement review.
Active Integration Map
Content Brain Cross-Brain Integration Map
Status: Active Integration Map
Parent: Content Brain
Role: Defines how Content Brain connects to the wider MWMS ecosystem.
This page maps Content Brain relationships with:
HeadOffice Brain
Research Brain
Search Intelligence Brain
Affiliate Brain
Ads Brain
Experimentation Brain
Conversion Brain
Compliance Brain
Data Brain
Finance Brain
Strategy Brain
SIT Brain
The integration map defines:
inputs from other Brains
outputs to other Brains
authority boundaries
future wiring candidates
future AI Employee candidates
manual-first integration rules
M build handoff rules
Content Brain Cross-Brain Integration Map should be treated as the companion page to this Architecture page.
This Architecture page explains how Content Brain is structured internally.
The Integration Map explains how Content Brain connects externally.
Active Reference Frameworks
Active Reference Frameworks support the operator layer.
They are not the first workflow layer.
They should be used when deeper logic is needed.
Content Brain Content Optimization Framework
Role:
defines signal-informed content improvement
supports refresh
supports publishing readiness
supports content performance review
supports content learning loops
Use when content needs improvement based on signals, review, or weakness.
Content Brain Content Production System Framework
Role:
defines structured content production
supports brief-to-draft-to-review-to-handoff workflow
supports future Content Production Queue planning
Use when defining deeper production discipline.
Content Brain Conversion Support Framework
Role:
defines how content supports decision readiness and commercial environments
supports trust, objections, CTA fit, message match, and conversion-support content
Use when content needs to support conversion conditions without becoming hard-sell content.
Content Brain E E A T Content Trust Framework
Role:
defines experience, expertise, authority, trustworthiness, transparency, and claim-safety standards
supports SEO, affiliate content, publishing readiness, and sensitive-topic review
Use when trust, credibility, or claim safety matters.
Content Brain Information Gain Framework
Role:
defines how content adds useful value beyond competitors, generic AI output, and thin SEO pages
supports SEO, affiliate support, refresh, and publishing readiness
Use when checking whether a page deserves to exist or adds enough value.
Content Brain Intent Alignment Framework
Role:
defines reader intent, awareness stage, content depth, CTA fit, and next-step alignment
supports content briefs, SEO briefs, refresh, repurposing, and publishing readiness
Use when checking whether content matches why the reader arrived.
Content Brain Topic Architecture Framework
Role:
defines topic structure, topic selection, topic expansion, duplication prevention, and authority logic
supports SEO planning, content briefs, internal linking, and topic cluster logic
Use when deciding whether a topic should exist and where it belongs.
Content Brain Topic Cluster And Hub Architecture Framework
Role:
defines hub pages, spoke pages, keyword clusters, topic clusters, URL clusters, and internal linking architecture
supports SEO authority, topic depth, affiliate ecosystems, and internal linking
Use when building connected page ecosystems.
Legacy Reference Layer
Legacy Reference pages are not active workflow pages.
They contain historical logic that may later be merged, retired, or converted into future fields.
They should not override active operational pages.
Current legacy reference pages include:
Content Brain Affiliate Conversion Support Model
Content Brain Offer Influence Model
Content Brain Pre Sell Structure Model
Content Brain Research Signal Feedback Model
Content Brain Knowledge Structure Model
Content Brain Performance Measurement Model
Content Brain Signal Interpretation Framework
Content Brain Strategy Framework
Content Brain Topic Authority Map
Content Brain Topic Cluster Architecture
Content Brain Employee Registry
These pages should be used only for:
historical review
future merge planning
legacy cleanup
possible future system field extraction
They should not be used as current operator standards.
Older Legacy Pages Awaiting Future Update
These pages remain under Content Brain and should be left alone until each receives a future update:
Content Asset Classification Framework
Content Audience Education Ladder
Content Authority Development Model
Content Behaviour Influence Model
Current decision:
do not rename yet
do not delete yet
do not treat as active operator pages
update later if useful
rename only when updating the full page
These pages should not override newer operational pages.
Governance And Registry Pages
Content Brain Canon
Role:
defines governing principles, identity, role, and long-term boundaries of Content Brain.
This may need future review after the integration-ready direction becomes fully stable.
Content Brain Architecture
Role:
defines the live-site operational structure of Content Brain.
This page is the architecture overview.
Content Brain Page Registry
Role:
tracks the current page structure on mwmscontentbrain.site.
The Page Registry should be updated when:
new active operational pages are created
new integration maps are created
page statuses change
legacy pages are retired
pages are renamed
new active reference frameworks are created
Content Brain Structural Layers
Content Brain now uses this structural model:
Homepage
First Operational Layer
Integration Map
Reference Frameworks
Legacy Reference Layer
Governance And Registry Layer
This structure creates a clean distinction between:
what operators use daily
what supports deeper reasoning
what is retained for history
what defines governance
what prepares future wiring
Current Operator Flow
For normal Content Brain work, the operator should use this flow:
Start with Content Brain Workflow.
If content needs a general brief, use Content Brain Content Briefs.
If content is SEO-focused, use Content Brain SEO Content Briefs.
If content supports an affiliate offer, use Content Brain Affiliate Content Packs.
If content supports an affiliate funnel stage, use Content Brain Affiliate Funnel Support.
Before publishing or handoff, use Content Brain Publishing Readiness.
If page relationships are needed, use Content Brain Internal Linking.
If approved content can be reused, use Content Brain Repurposing.
If existing content needs improvement, use Content Brain Refresh.
If deeper logic is needed, consult the relevant Active Reference Framework.
If cross-brain relationships matter, consult Content Brain Cross-Brain Integration Map.
If page status is unclear, consult Content Brain Page Registry.
Cross-Brain Architecture Position
Content Brain sits between intelligence and communication output.
It receives intelligence and requirements from other Brains.
It produces structured content outputs.
Broad cross-brain flow:
HeadOffice sets priority.
Research Brain identifies problems, evidence, audience language, and market signals.
Search Intelligence Brain identifies search demand, SERP intent, and topic opportunities.
Affiliate Brain identifies offer status, pre-sell needs, and affiliate content support needs.
Ads Brain identifies message match and campaign support content needs.
Experimentation Brain identifies testable variants and hypotheses.
Conversion Brain identifies friction, objections, and decision-support needs.
Compliance Brain defines claim boundaries and risk review needs.
Data Brain validates signals and performance context.
Finance Brain defines resource and capital constraints.
Strategy Brain defines positioning direction.
SIT Brain protects source-of-truth and system integrity.
Content Brain turns approved or review-ready inputs into structured content outputs.
HeadOffice reviews priority, visibility, and system coherence.
The detailed version of this relationship is defined in:
Content Brain Cross-Brain Integration Map
Content Brain Inputs
Content Brain may receive:
research insights
audience language
search opportunities
affiliate support needs
ad support needs
conversion friction notes
experiment variant requests
claim boundaries
data signals
finance constraints
strategy direction
SIT governance rules
HeadOffice priorities
manual operator requests
Inputs must be classified before becoming work.
Vague inputs should be parked.
Inputs with unclear authority should be routed back to the correct Brain.
Content Brain Outputs
Content Brain may produce:
content briefs
SEO content briefs
affiliate content packs
affiliate funnel support plans
publishing readiness reviews
internal linking plans
repurposing plans
refresh plans
optimization notes
topic architecture notes
topic cluster plans
trust support assets
FAQ assets
comparison assets
pre-sell assets
YouTube support assets
VEO3 support assets
email support assets
landing support assets
signal-to-watch definitions
cross-brain handoff notes
Each output should have:
source Brain
purpose
approval owner
handoff destination
risk status
signal to watch where relevant
Authority Boundaries
Content Brain must not own:
research verdicts
search validation
offer approval
affiliate opportunity approval
ad campaign approval
conversion architecture
compliance interpretation
data reliability
budget decisions
experiment verdicts
technical wiring
plugin UI
Supabase schema
Brain Room routing
automation execution
Content Brain supports these areas.
It does not replace the authority of the responsible Brain.
Manual-First Architecture
Content Brain is currently manual-first.
Manual-first means:
operators use the pages directly
repeatable workflows are observed
useful fields become clear
handoff friction becomes visible
status paths become clear
build candidates are identified only after repeated use
Manual-first is not the final goal.
Manual-first is the proving layer before system build.
This protects MWMS from building the wrong systems too early.
Future Build Candidate Architecture
Future build candidates may include:
Content Opportunity Queue
Content Production Queue
Content Refresh Queue
Content Repurposing Queue
Content Operations Dashboard
Content Brief Generator
SEO Brief Generator
Affiliate Content Pack Generator
Affiliate Funnel Support Planner
Internal Linking Planner
Publishing Readiness Checklist UI
Content Signal Feedback Dashboard
Cross-Brain Handoff Router
Content Brain AI Employee Router
Content Brain Task Status Dashboard
Content Brain Integration Log
These are not active build tasks yet.
They are future candidates.
Each candidate must pass build-readiness criteria before M receives a technical spec.
Build-Readiness Criteria
A Content Brain workflow becomes build-ready only when:
the manual workflow is repeated
the source Brain is clear
the output type is clear
the status path is clear
required fields are clear
approval owner is clear
risk rules are clear
handoff destination is clear
signal-to-watch is useful
operator value is proven
HeadOffice agrees it should be systemised
M has a clean spec to build from
Do not build from vague ideas.
Build from proven workflow.
M Build Handoff Rule
M should eventually wire proven Content Brain logic.
M should not be expected to invent Content Brain logic from scattered page ideas.
A future build handoff should include:
workflow name
purpose
input fields
output fields
status values
source Brain
destination Brain
approval rules
risk rules
handoff rules
parking rules
dashboard needs
data needs
user role needs
manual workflow evidence
priority level
Until this exists, the workflow should remain manual.
Naming Architecture
Live-site page titles should follow these rules:
Use full Content Brain prefix for current active pages.
Do not use version numbers in page titles.
Do not use “Operational Copy” in live-site page titles.
Do not use shortened names for active operator pages.
Do not keep old map, checklist, or framework names as active operator pages if they have been replaced.
Do not rename older legacy pages until they are being updated.
New active operational pages sit under Parent: Content Brain.
Content Brain homepage remains Top Level.
Parent Page Architecture
Content Brain homepage:
Top Level
All main Content Brain child pages:
Parent: Content Brain
Do not allow active operational pages to sit at root level.
Do not allow Content Brain pages to be placed under the wrong Brain.
Do not create duplicate versions under different parents.
Status Architecture
Use these status labels consistently:
Active
Active Operational Page
Active Integration Map
Active Reference Framework
Active Operational Registry
Active Architecture Reference
Governance Reference
Legacy Reference
Legacy Role Reference
Retired
Parked
Do not use Active Framework for old pages that are no longer active operator standards.
Do not treat legacy pages as active workflow pages.
Legacy Handling Architecture
Legacy pages should be handled carefully.
Default rule:
keep as Legacy Reference unless clearly replaced and useless
Do not delete unless:
replacement page is confirmed
historical logic has no future value
page creates active operator confusion
page is not needed for future merge or audit
Do not rename older legacy pages until full update is being performed.
Legacy pages should not drive current workflow.
Integration Architecture
Content Brain should become integration-ready.
Integration-ready means Content Brain clearly defines:
what it receives
what it produces
which Brain owns what
which inputs are valid
which outputs are valid
which requests should be parked
which risks should be escalated
which workflows may be built later
which workflows should remain manual
Content Brain Cross-Brain Integration Map is the main integration reference.
This Architecture page should point to it, not duplicate all its detail.
Drift Protection
This architecture must prevent:
Content Brain becoming a random article factory
legacy pages overriding active pages
duplicate page creation
wrong parent placement
title drift
status drift
old framework confusion
premature plugin or UI build
Content Brain taking authority from other Brains
M being handed vague build tasks
manual workflow evidence being skipped
mwmscontentbrain.site replacing MCR source-of-truth authority
Content Brain should remain clean enough that future wiring is straightforward.
Recommended Operator Use
When working in Content Brain:
check the Page Registry if page status is unclear
use the active first operational layer first
use reference frameworks only when deeper reasoning is needed
use the Integration Map for cross-brain relationships
use legacy pages only for historical logic or future merge review
do not create new pages without structural role
do not update architecture without considering the registry
do not update the registry without checking the page list
do not build technical systems from this architecture alone
Recommended Next Actions
Immediate status:
Content Brain first operational layer is built.
Active reference frameworks are updated.
Legacy review has started.
Cross-Brain Integration Map has been created.
Page Registry has been updated.
Content Brain Architecture now references the Integration Map.
Next optional actions:
Review Content Brain Canon later to decide whether the integration-ready direction should be reflected there.
Review the four older non-prefixed legacy pages later if they are still worth retaining.
Begin using the active first operational layer manually on real Content Brain work.
Record repeated workflows that may become future build candidates.
Architectural Intent
Content Brain Architecture exists to keep Content Brain structurally clear.
The architecture supports the move from:
page cleanup
to manual workflow
to cross-brain integration readiness
to future build-ready specifications
to future M wiring
The long-term intent is for Content Brain to become:
clean
manual-first
workflow-proven
cross-brain aware
integration-ready
build-ready later
Content Brain should eventually work smoothly with other Brains, but only after the manual workflow proves the shape of the system.
Final Rule
Content Brain Architecture defines the live operational structure.
It does not replace MCR.
It does not authorize premature build work.
It should support clean manual use now and clean system wiring later.
If Content Brain is structurally unclear, do not build.
If Content Brain is manually proven, create build-ready specs.
M should wire proven logic, not vague ideas.
Change Log
Version: v1.2
Date: 2026-06-02
Author: HeadOffice
Change: Updated Content Brain Architecture to reference the newly created Content Brain Cross-Brain Integration Map and the updated Content Brain Page Registry v1.3. Reframed the page as an Active Architecture Reference, added current structural layers, active integration map layer, active reference framework layer, legacy reference layer, governance layer, cross-brain architecture position, inputs and outputs, authority boundaries, manual-first architecture, future build candidate architecture, build-readiness criteria, M build handoff rule, naming architecture, status architecture, integration architecture, and updated recommended next actions.
Version: v1.1
Date: 2026-05-24
Author: HeadOffice
Change: Updated live-site Content Brain Architecture after first operational layer build. Clarified manual workflow-only structure, active operational pages, legacy handling, and no premature plugin/UI boundaries.
Version: v1.0
Date: 2026-03-29
Author: HeadOffice
Change: Initial architecture definition for Content Brain.
Change Impact Declaration
Pages Created:
None
Pages Updated:
Content Brain Architecture
Pages Renamed:
None
Pages Deprecated:
None
Registries Requiring Update:
No immediate registry update required unless architecture page status changes are tracked separately in Content Brain Page Registry.
Canon Version Update Required:
No immediate canon update required.
Change Log Entry Required:
No separate change log entry required unless HeadOffice decides to track architecture updates in Content Brain Canon later.
END CONTENT BRAIN ARCHITECTURE v1.2