Document Type: Specification
Status: Draft
Version: v1.0
Authority: Content Brain under HeadOffice governance
Applies To: Content Brain production tracking, content workflow visibility, future mwmscontentbrain.site operational use, and future Content Brain plugin or UI planning
Parent: Content Brain
Last Reviewed: 2026-05-06
Purpose
The Content Brain Content Production Queue Specification defines the future queue structure used to track Content Brain work from request to completion.
This specification exists to prevent content work from becoming scattered, invisible, duplicated, forgotten, or disconnected from MWMS system purpose.
The Content Production Queue will eventually provide a structured view of:
new content requests
brief creation
drafting
review
approval
handoff
publishing readiness
refresh needs
repurposing needs
blocked content work
completed content assets
signal feedback requirements
This page is a planning specification only.
It does not activate a plugin, create a database table, build a screen, or interfere with M’s current build work.
Scope
This specification applies to:
future Content Brain production queue design
future mwmscontentbrain.site operational planning
content request tracking
content production status tracking
content brief status tracking
content handoff tracking
content publishing readiness tracking
content review visibility
content ownership visibility
content bottleneck visibility
future plugin or UI planning
This specification does not govern:
live plugin development
Supabase implementation
Brain-to-Brain request automation
HeadOffice reporting implementation
Affiliate Brain wiring
Research Brain wiring
Finance Brain wiring
Ads Brain campaign execution
final compliance approval
live publishing authority
M’s current build work
Those remain governed by the relevant Brain, Canon, protocol, standard, or implementation layer.
Core Principle
Content work must be visible before it can be managed.
A queue exists to make Content Brain work trackable, reviewable, and prioritised.
The Content Production Queue should answer:
what content is requested
why it exists
who requested it
which Brain it supports
what stage it is in
who owns the next action
what is blocking progress
where the content will be used
whether it passed review
what signal should be watched after use
If the queue cannot answer these questions, the production system is not mature enough.
Governance Role
The Content Production Queue is an operational visibility system.
It does not create authority.
It does not approve offers.
It does not approve campaigns.
It does not approve compliance-sensitive claims.
It does not authorise publishing by itself.
It only tracks content work and makes status visible.
Content Brain may use the queue to manage production, but authority remains with the relevant owner, Brain, or human approval path.
Relationship To MCR
MCR remains the source of truth.
This specification belongs in MCR because it defines the structure and future implementation logic of the queue.
The MCR version defines:
queue purpose
queue scope
field requirements
status model
ownership model
review rules
future UI candidate logic
drift protection
mwmscontentbrain.site may later operationalise this queue as a working screen or plugin feature.
Relationship To mwmscontentbrain.site
mwmscontentbrain.site is the likely future home of the operational Content Production Queue.
The future queue may appear as:
a WordPress admin table
a custom Content Brain page
a dashboard panel
a content task board
a status-based queue
a Supabase-backed workflow surface
a manual content tracker first
A simple manual version should be used before any plugin or UI build.
MCR To Brain Classification
Destination: Later Plugin Or UI
Reason: Repeated structured interaction and status tracking
Source Of Truth: MCR
Future Use: Content production tracking screen or queue inside mwmscontentbrain.site
Future Plugin Or UI: Yes
This page should be listed in the Content Brain Copy Map as a future plugin or UI candidate.
Queue Function
The Content Production Queue should track the movement of content work across the production lifecycle.
The queue should support:
request intake visibility
briefing visibility
drafting visibility
review visibility
approval visibility
handoff visibility
blocked work visibility
completion visibility
performance follow-up visibility
The queue should not become a dumping ground.
Every queue item must have a clear purpose and owner.
Queue Item Definition
A queue item is a single content production task.
A queue item may represent:
new article
SEO article
authority page
topic cluster article
affiliate support article
pre-sell article
comparison article
FAQ page
trust support content
YouTube description
email draft
newsletter content
social content set
content refresh
repurposing task
internal linking plan
content performance review
publishing readiness review
Each queue item should move through a clear status model.
Required Queue Fields
Each Content Production Queue item should include the following fields.
Core Fields
Queue Item ID
Content Title
Working Title
Content Type
Request Source
Requesting Brain
Supporting Brain
Owner
Approval Owner
Priority
Status
Created Date
Updated Date
Target Destination
Due Date where relevant
Notes
Purpose Fields
Business Purpose
Audience
Awareness Stage
Reader Intent
Funnel Role
SEO Role
Authority Role
Affiliate Support Role
Sales Support Role
Conversion Support Role
Trust Role
Source And Relationship Fields
Related Offer
Related Campaign
Related Topic Cluster
Related Existing Page
Related Content Brief
Related Workflow Stage
Related Research Signal
Related Newsletter Signal
Related Brain Request
Source Of Truth
Production Fields
Brief Status
Draft Status
Review Status
Publishing Readiness Status
Handoff Status
Refresh Status
Repurposing Status
Blocked Reason
Next Action
Next Owner
Risk Fields
Risk Level
Compliance Sensitivity
Claims Risk
Affiliate Status
Needs Compliance Review
Needs Human Review
Needs Research Verification
Needs Affiliate Brain Review
Needs Conversion Brain Review
Needs Data Brain Review
Output Fields
Draft Location
Brief Location
Final Content Location
Handoff Destination
Published URL where relevant
Internal Links Needed
External Sources Needed
CTA Type
Review Notes
Approval Notes
Feedback Fields
Performance Signal To Watch
Review Date
Feedback Destination Brain
Refresh Trigger
Repurposing Trigger
Signal Feedback Notes
Outcome
Lessons Learned
Status Model
The Content Production Queue should use a simple status model first.
Recommended status values:
new
classified
briefing
ready_for_draft
drafting
in_review
needs_revision
ready_for_approval
approved
ready_for_handoff
handed_off
published
monitoring
refresh_needed
repurpose_needed
blocked
closed
rejected
Status Definitions
New
The request has entered the queue but has not yet been classified.
Required next action:
classify request
identify source
define owner
Classified
The request has a content type, purpose, source, and basic priority.
Required next action:
create or attach brief
Briefing
The content brief is being created.
Required next action:
complete Content Brain Content Brief Template
Ready For Draft
The brief is complete enough for production.
Required next action:
begin draft
Drafting
The content asset is being written or prepared.
Required next action:
complete first draft or asset
In Review
The content is under quality, SEO, trust, compliance sensitivity, affiliate, or publishing readiness review.
Required next action:
complete required reviews
Needs Revision
The content requires changes before approval or handoff.
Required next action:
revise based on review notes
Ready For Approval
The content has passed review and requires approval from the correct owner.
Required next action:
approval owner reviews
Approved
The content has been approved for handoff, publishing, or use.
Required next action:
move to destination or handoff
Ready For Handoff
The content is ready to transfer to another operator, Brain, or publishing environment.
Required next action:
create handoff note
Handed Off
The content has been sent to the next owner or destination.
Required next action:
confirm receipt or next use
Published
The content is live or active.
Required next action:
monitor defined signal
Monitoring
The content is being watched for performance, engagement, or learning signals.
Required next action:
review signal when enough data exists
Refresh Needed
The content requires updating or improvement.
Required next action:
create refresh task or move to refresh queue
Repurpose Needed
The content should be adapted into another format.
Required next action:
create repurposing task
Blocked
The item cannot progress.
Required next action:
resolve blocker
Common blockers:
missing source material
unclear offer status
unclear audience
missing approval owner
compliance risk
research gap
data gap
no destination
MCR structure unclear
Closed
The item is complete and no further action is required.
Required next action:
record outcome where useful
Rejected
The item should not proceed.
Required next action:
record reason
Priority Model
The queue should use a simple priority model.
Priority values:
Low
Medium
High
Critical
Low Priority
Useful but not urgent.
May be future content, optional support, or low-impact refresh.
Medium Priority
Relevant and useful.
Should be completed when capacity allows.
High Priority
Important to active system work, affiliate support, content structure, or near-term production.
Critical Priority
Required for active funnel support, major publishing need, risk control, or HeadOffice priority.
Critical priority should be used sparingly.
Ownership Model
Every queue item must have clear ownership.
Minimum ownership fields:
Request Owner
Production Owner
Review Owner
Approval Owner
Next Owner
Request Owner
The person or Brain that requested the content.
Production Owner
The person, AI Employee, or process responsible for producing the asset.
Review Owner
The person or Brain responsible for reviewing the asset.
Approval Owner
The person or authority responsible for approving handoff, publishing, or use.
Next Owner
The person or system responsible for the next action.
A queue item without a next owner is structurally weak.
Request Source Model
Content requests may originate from:
HeadOffice
Content Brain
Research Brain
Affiliate Brain
Ads Brain
Conversion Brain
Sales Brain
Customer Brain
Data Brain
Compliance Brain
manual operator request
approved newsletter intelligence
approved opportunity signal
approved campaign support need
content refresh review
repurposing opportunity
Each item must record its request source.
If the request source is unclear, status should remain new or blocked.
Content Type Model
The queue should support the following content types:
SEO Article
Authority Article
Pillar Page
Topic Cluster Article
Affiliate Support Article
Pre Sell Article
Comparison Article
Review Support Content
FAQ Content
Trust Support Content
YouTube Description
Email Draft
Newsletter Content
Social Content Set
Short Form Script Seed
Refresh Task
Repurposing Task
Internal Linking Plan
Publishing Readiness Review
Performance Review
Sales Support Asset
Conversion Support Asset
Review Requirements
Queue items should not move to Approved until relevant reviews are complete.
Possible reviews:
Brief Review
Quality Review
Accuracy Review
SEO Review
Trust Review
Compliance Sensitivity Review
Affiliate Status Review
Conversion Support Review
Internal Linking Review
Publishing Readiness Review
Data Signal Review
Human Approval Review
Not every content asset needs every review.
The required reviews depend on content type, risk level, and destination.
Approval Rules
Approval is required before:
publishing new content
editing live funnel pages
editing active affiliate support pages
using health claims
using finance claims
using income claims
using legal claims
using testimonials
using guarantees
using scarcity or urgency language
publishing affiliate recommendation content
pushing content into paid campaign support environments
changing internal linking structure at scale
The queue may track approval status.
The queue does not grant approval by itself.
Blocking Rules
A queue item should be marked blocked when progress cannot continue.
Common blocking reasons:
unclear source
unclear purpose
unclear audience
missing brief
missing offer status
missing source material
missing research evidence
missing approval owner
compliance risk
claim risk
unclear destination
dependency on another Brain
manual review required
operator decision required
The blocked status must include:
blocked reason
next action
next owner
Handoff Rules
When a queue item is handed off, the handoff note should include:
content title
content type
source request
requesting Brain
intended use
target destination
approval status
risk level
review notes
internal links needed
feedback signal to watch
next owner
handoff date
Content handoff must preserve context.
A handoff without context creates rework and risk.
Feedback Rules
Every meaningful content asset should define at least one signal to watch.
Possible signals:
traffic
ranking movement
clicks
time on page
scroll depth
internal link clicks
VSL click assist
email clicks
YouTube description clicks
engagement
conversion assist
reader questions
content refresh need
repurposing opportunity
Feedback may route to:
Research Brain
Affiliate Brain
Ads Brain
Conversion Brain
Sales Brain
Compliance Brain
Data Brain
HeadOffice
Content Brain
Queue Views
The future Content Production Queue should support useful views.
Status View
Groups items by status.
Useful for:
daily workflow
bottleneck review
production management
Priority View
Groups items by priority.
Useful for:
deciding what to work on first
protecting high-value content tasks
Brain Source View
Groups items by requesting Brain.
Useful for:
seeing which Brains need content support
understanding cross-brain demand
Content Type View
Groups items by content type.
Useful for:
planning production workload
batching similar tasks
Risk View
Groups items by risk level or compliance sensitivity.
Useful for:
review planning
avoiding risky publication
Destination View
Groups items by final destination.
Useful for:
publishing planning
handoff management
Blocked View
Shows only blocked items.
Useful for:
operator review
dependency removal
HeadOffice visibility where needed
Future Data Model
This specification does not activate a database table.
If built later, a future data model may include:
content_queue_items
content_queue_events
content_briefs
content_assets
content_reviews
content_handoffs
content_signal_feedback
This naming is conceptual only.
Any future Supabase or WordPress implementation must follow MWMS Supabase Naming Standard and MWMS Brain-to-Brain Request Protocol where relevant.
Future Minimal Table Concept
If this becomes a database-backed queue later, a simple first table may include:
id
created_at
updated_at
content_title
working_title
content_type
request_source
requesting_brain
supporting_brain
owner
approval_owner
priority
status
target_destination
business_purpose
audience
intent
risk_level
compliance_sensitivity
affiliate_status
brief_location
draft_location
final_location
blocked_reason
next_action
next_owner
feedback_signal
review_date
notes_json
This is not an implementation instruction.
It is a future planning concept only.
First Manual Version
The first version of this queue should be manual.
A manual queue may use:
WordPress page table
simple spreadsheet
Notion-style board
Google Sheet
MCR tracking page
mwmscontentbrain.site page later
Manual use should prove:
which fields are actually needed
which statuses are useful
which views matter
which bottlenecks repeat
which UI would save time
Only after manual use should a plugin or UI be considered.
Minimum Viable Queue
The minimum useful queue should track:
Content Title
Content Type
Request Source
Requesting Brain
Purpose
Priority
Status
Owner
Next Action
Approval Owner
Risk Level
Destination
Feedback Signal
This is enough to start without overbuilding.
Future Plugin Or UI Candidate
The Content Production Queue is a strong future plugin or UI candidate.
Possible future features:
Add Content Request
Create Brief
Attach Draft
Assign Owner
Set Priority
Change Status
Mark Blocked
Request Review
Approve For Handoff
Mark Published
Create Refresh Task
Create Repurposing Task
Record Signal Feedback
Filter By Brain
Filter By Status
Filter By Priority
Filter By Risk
This should not be built yet.
Manual workflow must prove the need first.
Relationship To Content Brain Copy Map
This page should be listed in the Content Brain Copy Map as:
Page Title: Content Brain Content Production Queue Specification
Destination: Later Plugin Or UI
Reason: Repeated structured interaction and status tracking
Source Of Truth: MCR
Future Use: Content production tracking screen inside mwmscontentbrain.site
Future Plugin Or UI: Yes
Relationship To Content Brain Page Registry
This page should be added to the Content Brain Page Registry as:
Page Title: Content Brain Content Production Queue Specification
Document Type: Specification
Parent Page: Content Brain
Status: Draft
Destination: Later Plugin Or UI
Reason: Future production tracking system
Source Of Truth: MCR
Future Use: Content production queue planning
Relationship To Content Brain Operating Model
The Content Brain Operating Model defines Content Brain’s role and responsibilities.
This specification defines a future system for tracking those responsibilities as content work moves through production.
Operating Model = role and boundaries
Production Queue Specification = future tracking surface
Relationship To Content Brain Workflow Map
The Content Brain Workflow Map defines the movement of content work.
The Content Production Queue tracks that movement.
Workflow Map = process
Production Queue = visibility layer
Relationship To Content Brain Content Brief Template
The Content Brief Template defines the planning document before drafting.
The Production Queue should link to or track the brief status.
Brief Template = content planning control
Production Queue = production tracking control
Relationship To Content Brain Publishing Readiness Checklist
The Publishing Readiness Checklist defines the gate before publishing or handoff.
The Production Queue should track whether that checklist has been completed.
Publishing Readiness Checklist = review gate
Production Queue = status visibility
Relationship To Content Brain Affiliate Funnel Support Map
Affiliate-related content items in the queue should record:
related offer
offer status
affiliate support role
funnel stage
claim risk
approval owner
Affiliate Funnel Support Map = affiliate content use case
Production Queue = tracking system for those tasks
Relationship To Other MWMS Documents
This page must align with:
Content Brain Copy Map
Content Brain Page Registry
Content Brain Operating Model
Content Brain Workflow Map
Content Brain Content Brief Template
Content Brain Publishing Readiness Checklist
Content Brain Affiliate Funnel Support Map
Content Brain Content Production System Framework
Content Brain SEO Content Brief Standard
Content Brain Content Optimization Framework
Content Brain Content Repurposing Framework
Content Brain Content Signal Feedback Framework
Content Brain Information Gain Framework
Content Brain E E A T Content Trust Framework
MWMS MCR To Brain Copy Rule
MWMS Brain Interaction Map
MWMS Brain To Brain Request Protocol
MWMS Supabase Naming Standard
MWMS Supabase Task Schema Standard
MWMS Document Structure Standard
MWMS Page Naming Standard
MWMS AI Output Standard Full File Delivery Rule
Drift Protection
The system must prevent:
content work being tracked without purpose
content work entering the queue without source
queue items having no owner
queue items having no next action
queue items staying blocked without reason
queue items being approved without review
queue items being published without approval
affiliate content being queued without offer status
compliance-sensitive content being queued without risk flag
the queue becoming a dumping ground
the queue replacing Brain authority
the queue granting approval by itself
the queue being built as a plugin before manual workflow proves the need
the queue interfering with M’s active build areas
mwmscontentbrain.site becoming a duplicate of MCR
Architectural Intent
The Content Brain Content Production Queue Specification exists to make future content production visible, controlled, and scalable.
Its role is to define the future queue before implementation so that Content Brain does not become a chaotic content factory.
The queue should help MWMS know:
what content is being produced
why it is being produced
who requested it
who owns it
what stage it is in
what review is required
what is blocked
what is ready
what was handed off
what signal should be watched
The long-term intent is to support a practical operational queue on mwmscontentbrain.site while preserving MCR as the source of truth.
Final Rule
The Content Production Queue must track work.
It must not create authority.
If a content item has no source, no purpose, no owner, no next action, and no feedback path, it should not enter the queue.
If the queue does not improve visibility, it should not be built yet.
Change Log
Version: v1.0
Date: 2026-05-06
Author: HeadOffice
Change: Initial creation of Content Brain Content Production Queue Specification defining the future content production queue structure, queue fields, status model, priority model, ownership model, review requirements, handoff rules, feedback rules, future views, minimal queue structure, future plugin or UI candidate logic, and drift protection.
Change Impact Declaration
Pages Created:
Content Brain Content Production Queue Specification
Pages Updated:
None
Pages Deprecated:
None
Registries Requiring Update:
Content Brain Page Registry
Content Brain Copy Map
Canon Version Update Required:
No
Change Log Entry Required:
No