Document Type: Specification
Status: Draft
Version: v1.0
Authority: Content Brain under HeadOffice governance
Applies To: Content refresh tracking, content improvement workflows, SEO refresh planning, affiliate support content updates, authority content maintenance, 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 Refresh Queue Specification defines the future queue structure used to track existing content that needs review, improvement, updating, strengthening, republishing, repurposing, or retirement.
This specification exists to prevent older content from becoming outdated, inaccurate, weak, thin, misaligned, untrusted, or disconnected from current MWMS strategy.
The Content Refresh Queue will eventually provide a structured view of:
content needing review
content needing SEO refresh
content needing factual updates
content needing affiliate offer updates
content needing trust improvement
content needing internal link improvement
content needing compliance sensitivity review
content needing conversion support improvement
content needing repurposing
content needing retirement or merge review
content with declining performance
content with unclear performance signals
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 refresh queue design
future mwmscontentbrain.site operational planning
existing content review
SEO content refresh
affiliate support content refresh
authority content refresh
comparison content refresh
review support content refresh
FAQ content refresh
trust support content refresh
internal linking updates
content performance review
content retirement review
content merge review
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
Published content is not finished forever.
Content must remain accurate, useful, trusted, aligned, and connected to current system purpose.
The Content Refresh Queue should answer:
which content needs review
why the content needs refresh
what triggered the review
what type of refresh is required
who owns the next action
what risk exists
what Brain is affected
what performance signal caused the issue
what outcome is expected after refresh
whether the content should be updated, merged, repurposed, redirected, or retired
If the queue cannot answer these questions, the refresh system is not mature enough.
Governance Role
The Content Refresh Queue is an operational visibility system.
It does not create authority.
It does not approve offers.
It does not approve campaign changes.
It does not approve compliance-sensitive claims.
It does not authorise live edits by itself.
It only tracks refresh needs and makes status visible.
Content Brain may use the queue to manage refresh work, 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 refresh queue.
The MCR version defines:
queue purpose
queue scope
field requirements
status model
refresh triggers
risk 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 Refresh Queue.
The future queue may appear as:
a WordPress admin table
a custom Content Brain page
a dashboard panel
a content refresh task board
a status-based refresh 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, content maintenance tracking, refresh prioritisation, status tracking, and content improvement visibility
Source Of Truth: MCR
Future Use: Content refresh 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.
Refresh Queue Function
The Content Refresh Queue should track the movement of existing content through the refresh lifecycle.
The queue should support:
content review visibility
refresh trigger visibility
refresh priority visibility
content owner visibility
risk visibility
review requirement visibility
approval visibility
blocked work visibility
merge or retire decision visibility
republishing visibility
signal feedback visibility
The queue should not become a dumping ground for vague “fix this later” notes.
Every refresh queue item must have a clear trigger, purpose, owner, and next action.
Refresh Queue Item Definition
A refresh queue item is a single content improvement task.
A refresh queue item may represent:
SEO article refresh
authority article update
pillar page update
topic cluster update
affiliate support article update
pre-sell article update
comparison article update
review support content update
FAQ update
trust page update
YouTube description update
email content update
newsletter content update
social content update
internal linking update
outdated claim review
content merge review
content retirement review
content repurposing opportunity
content performance review
Each queue item should move through a clear status model.
Required Queue Fields
Each Content Refresh Queue item should include the following fields.
Core Fields
Refresh Item ID
Content Title
Content URL
Content Type
Current Status
Refresh Priority
Refresh Owner
Review Owner
Approval Owner
Created Date
Updated Date
Last Published Date
Last Reviewed Date
Target Review Date
Target Completion Date
Notes
Trigger Fields
Refresh Trigger
Trigger Source
Trigger Date
Triggering Brain
Supporting Brain
Performance Signal
Manual Observation
SEO Signal
Affiliate Signal
Compliance Signal
Data Signal
Research Signal
Content Quality Signal
Internal Linking Signal
Offer Change Signal
Purpose Fields
Refresh Purpose
Business Reason
Reader Benefit
SEO Reason
Affiliate Support Reason
Authority Reason
Trust Reason
Conversion Support Reason
Sales Support Reason
Compliance Reason
Internal Linking Reason
Repurposing Reason
Retirement Reason
Content Relationship Fields
Related Offer
Related Campaign
Related Topic Cluster
Related Pillar Page
Related Supporting Page
Related Existing Brief
Related Original Request
Related Content Production Queue Item
Related Research Signal
Related Newsletter Signal
Related Brain Request
Source Of Truth
Refresh Work Fields
Refresh Type
Required Action
Current Problem
Recommended Fix
Sections To Update
Sections To Remove
Sections To Add
Internal Links To Add
Internal Links To Remove
External Sources To Update
CTA To Review
Claims To Review
Proof To Add
Trust Elements To Add
Brief Update Needed
Draft Update Needed
Publishing Readiness Needed
Risk Fields
Risk Level
Compliance Sensitivity
Claims Risk
Affiliate Status
Offer Status
Needs Compliance Review
Needs Human Review
Needs Research Verification
Needs Affiliate Brain Review
Needs Conversion Brain Review
Needs Data Brain Review
Needs HeadOffice Review
Output Fields
Updated Draft Location
Final Updated Content Location
Published URL
Handoff Destination
Approval Notes
Review Notes
Redirect Needed
Merge Target
Retirement Decision
Republishing Date
Feedback Fields
Performance Signal To Watch After Refresh
Review Date After Refresh
Feedback Destination Brain
Expected Improvement
Observed Outcome
Refresh Result
Repurposing Trigger
Lessons Learned
Signal Feedback Notes
Refresh Trigger Types
The queue should classify why content entered refresh review.
Recommended trigger types:
performance_decline
ranking_decline
traffic_decline
content_outdated
offer_changed
vendor_page_changed
compliance_risk_found
claim_risk_found
research_update_found
new_competitor_content
internal_linking_gap
thin_content_risk
trust_gap_found
information_gain_gap
audience_question_found
conversion_friction_found
affiliate_support_gap
manual_review_request
scheduled_review
repurposing_opportunity
merge_opportunity
retirement_review
Refresh Type Model
The queue should support the following refresh types.
Light Refresh
Small update to improve clarity, wording, formatting, dates, or links.
Used when:
content is mostly correct
risk is low
only minor updates are needed
SEO Refresh
Update content to improve search usefulness, intent alignment, headings, topical coverage, internal links, and information gain.
Used when:
ranking has declined
search intent has shifted
content is underperforming
competitor content is stronger
Trust Refresh
Update content to improve credibility, transparency, proof, expectation setting, and reader confidence.
Used when:
content feels thin
claims need better support
trust signals are weak
affiliate recommendation needs clearer framing
Affiliate Refresh
Update content connected to an affiliate offer, VSL, comparison, pre-sell journey, FAQ, or campaign support asset.
Used when:
offer changed
vendor page changed
claim risk changed
traffic source changed
Affiliate Brain requested support
funnel support is weak
Compliance Sensitivity Refresh
Review and update content where legal, platform, health, finance, income, safety, or claims risk may exist.
Used when:
risk-sensitive language appears
claims need review
rules may have changed
human approval is required
Conversion Support Refresh
Update content to improve message match, objection handling, clarity, proof, FAQ support, or funnel support.
Used when:
Conversion Brain flags friction
Ads Brain detects mismatch
Affiliate Brain reports pre-sell weakness
reader path is unclear
Internal Linking Refresh
Update links to improve topic structure, reader navigation, authority flow, and contextual support.
Used when:
new supporting content exists
links are missing
links are outdated
money-page linking is excessive
topic cluster structure is weak
Repurposing Refresh
Update content so it can be reused in another format.
Used when:
content has value but needs adaptation
asset can become email, video description, social post, FAQ, or support material
Merge Review
Review whether content should be merged with another page.
Used when:
content overlaps another page
topic duplication exists
thin content exists
two pages target the same intent
Retirement Review
Review whether content should be unpublished, redirected, archived, or removed from active use.
Used when:
content is outdated
content is no longer useful
offer is dead
risk is too high
page creates confusion
Status Model
The Content Refresh Queue should use a simple status model first.
Recommended status values:
new
classified
refresh_briefing
ready_for_update
updating
in_review
needs_revision
ready_for_approval
approved
ready_for_handoff
handed_off
republished
monitoring
merge_review
retirement_review
blocked
closed
rejected
Status Definitions
New
The content has entered the refresh queue but has not yet been classified.
Required next action:
classify refresh trigger
identify owner
define next action
Classified
The refresh item has a trigger, content type, priority, and basic reason.
Required next action:
define refresh type and review requirements
Refresh Briefing
A refresh brief or update plan is being created.
Required next action:
complete refresh instructions
Ready For Update
The refresh task is clear enough to begin.
Required next action:
begin update work
Updating
The content is being updated, rewritten, restructured, or improved.
Required next action:
complete update
In Review
The updated content is under quality, SEO, trust, compliance sensitivity, affiliate, conversion, or publishing readiness review.
Required next action:
complete required reviews
Needs Revision
The updated content requires changes before approval or handoff.
Required next action:
revise based on review notes
Ready For Approval
The updated 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, republishing, or use.
Required next action:
move to destination or handoff
Ready For Handoff
The refreshed content is ready to transfer to another operator, Brain, or publishing environment.
Required next action:
create handoff note
Handed Off
The refreshed content has been sent to the next owner or destination.
Required next action:
confirm receipt or next use
Republished
The refreshed content is live or active.
Required next action:
monitor defined signal
Monitoring
The content is being watched after refresh.
Required next action:
review performance after enough data exists
Merge Review
The item requires review for possible merging with another page.
Required next action:
identify merge target and review impact
Retirement Review
The item requires review for possible removal, redirect, archiving, or deactivation.
Required next action:
decide whether to retire, redirect, merge, or keep
Blocked
The item cannot progress.
Required next action:
resolve blocker
Common blockers:
missing source material
unclear offer status
unclear owner
unclear destination
compliance risk
research gap
data gap
approval required
technical access issue
Closed
The item is complete and no further action is required.
Required next action:
record outcome where useful
Rejected
The refresh 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 minor formatting, optional improvements, or low-impact refresh.
Medium Priority
Relevant and useful.
Should be completed when capacity allows.
High Priority
Important to active SEO structure, affiliate support, authority content, or near-term production.
Critical Priority
Required for active funnel support, major compliance risk, serious content inaccuracy, major trust issue, or HeadOffice priority.
Critical priority should be used sparingly.
Ownership Model
Every refresh queue item must have clear ownership.
Minimum ownership fields:
Refresh Owner
Review Owner
Approval Owner
Next Owner
Refresh Owner
The person, AI Employee, or process responsible for completing the update.
Review Owner
The person or Brain responsible for reviewing the updated content.
Approval Owner
The person or authority responsible for approving handoff, republishing, or use.
Next Owner
The person or system responsible for the next action.
A refresh queue item without a next owner is structurally weak.
Request Source Model
Refresh requests may originate from:
Content Brain
HeadOffice
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 performance review
SEO review
scheduled content audit
repurposing opportunity
Each item must record its request source.
If the request source is unclear, status should remain new or blocked.
Review Requirements
Refresh queue items should not move to Approved until relevant reviews are complete.
Possible reviews:
Refresh 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 refresh item needs every review.
The required reviews depend on content type, risk level, trigger, and destination.
Approval Rules
Approval is required before:
republishing refreshed content
editing live funnel pages
editing active affiliate support pages
using new health claims
using new finance claims
using new income claims
using new legal claims
adding testimonials
adding guarantees
adding scarcity or urgency language
updating affiliate recommendation content
pushing refreshed content into paid campaign support environments
changing internal linking structure at scale
retiring or redirecting important pages
The queue may track approval status.
The queue does not grant approval by itself.
Blocking Rules
A refresh queue item should be marked blocked when progress cannot continue.
Common blocking reasons:
unclear trigger
unclear purpose
unclear owner
missing source material
missing research evidence
missing performance data
missing offer status
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 refreshed content item is handed off, the handoff note should include:
content title
content URL
content type
refresh trigger
refresh type
source request
requesting Brain
intended use
target destination
approval status
risk level
review notes
internal links changed
claims changed
feedback signal to watch
next owner
handoff date
Content refresh handoff must preserve context.
A handoff without context creates rework and risk.
Feedback Rules
Every meaningful refreshed content asset should define at least one signal to watch after update.
Possible signals:
ranking movement
organic traffic
clicks
time on page
scroll depth
internal link clicks
VSL click assist
email clicks
YouTube description clicks
engagement
conversion assist
reader questions
affiliate support performance
trust improvement signal
refresh effectiveness
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 Refresh Queue should support useful views.
Status View
Groups items by status.
Useful for:
refresh workflow
bottleneck review
update management
Priority View
Groups items by priority.
Useful for:
deciding what to update first
protecting high-risk or high-value content
Trigger View
Groups items by refresh trigger.
Useful for:
seeing why content is entering refresh
spotting repeated content problems
Content Type View
Groups items by content type.
Useful for:
batching similar refresh work
planning workload
Brain Source View
Groups items by requesting Brain.
Useful for:
seeing which Brains need refresh support
understanding cross-brain demand
Risk View
Groups items by risk level or compliance sensitivity.
Useful for:
review planning
avoiding unsafe republishing
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
Merge Or Retirement View
Shows items under merge review or retirement review.
Useful for:
site cleanup
SEO consolidation
risk reduction
content pruning
Future Data Model
This specification does not activate a database table.
If built later, a future data model may include:
content_refresh_items
content_refresh_events
content_refresh_briefs
content_refresh_reviews
content_refresh_handoffs
content_refresh_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
content_url
content_type
refresh_trigger
trigger_source
requesting_brain
supporting_brain
refresh_owner
review_owner
approval_owner
priority
status
target_destination
refresh_purpose
risk_level
compliance_sensitivity
affiliate_status
offer_status
updated_draft_location
published_url
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 refresh triggers repeat
which views matter
which bottlenecks repeat
which UI would save time
Only after manual use should a plugin or UI be considered.
Minimum Viable Refresh Queue
The minimum useful refresh queue should track:
Content Title
Content URL
Content Type
Refresh Trigger
Refresh Type
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 Refresh Queue is a strong future plugin or UI candidate.
Possible future features:
Add Refresh Item
Classify Refresh Trigger
Create Refresh Brief
Attach Updated Draft
Assign Owner
Set Priority
Change Status
Mark Blocked
Request Review
Approve For Handoff
Mark Republished
Create Repurposing Task
Create Merge Review
Create Retirement Review
Record Signal Feedback
Filter By Trigger
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 Refresh Queue Specification
Destination: Later Plugin Or UI
Reason: Repeated structured interaction, content maintenance tracking, refresh prioritisation, status tracking, and content improvement visibility
Source Of Truth: MCR
Future Use: Content refresh 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 Refresh Queue Specification
Document Type: Specification
Parent Page: Content Brain
Status: Draft
Destination: Later Plugin Or UI
Reason: Future content refresh tracking system
Source Of Truth: MCR
Future Use: Content refresh 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 refresh responsibilities as existing content moves through review and improvement.
Operating Model = role and boundaries
Refresh Queue Specification = future maintenance tracking surface
Relationship To Content Brain Workflow Map
The Content Brain Workflow Map defines the movement of content work.
The Content Refresh Queue tracks refresh movement for existing content.
Workflow Map = process
Refresh Queue = maintenance visibility layer
Relationship To Content Brain Content Production Queue Specification
The Content Production Queue tracks new content production.
The Content Refresh Queue tracks improvement of existing content.
Production Queue = new content work
Refresh Queue = existing content improvement work
The two queues should remain separate to prevent new production work and maintenance work from becoming confused.
Relationship To Content Brain Content Brief Template
The Content Brief Template defines the planning document before drafting.
Refresh tasks may require a shorter refresh brief or update plan.
Brief Template = new content planning control
Refresh Queue = existing content update control
Relationship To Content Brain Publishing Readiness Checklist
The Publishing Readiness Checklist defines the gate before publishing or handoff.
Refreshed content should pass publishing readiness before republishing where risk exists.
Publishing Readiness Checklist = review gate
Refresh Queue = status visibility
Relationship To Content Brain Affiliate Funnel Support Map
Affiliate-related refresh items should record:
related offer
offer status
affiliate support role
funnel stage
claim risk
approval owner
vendor page changes
Affiliate Funnel Support Map = affiliate content use case
Refresh Queue = tracking system for update tasks
Relationship To Content Brain SEO Testing And Refresh Framework
The SEO Testing And Refresh Framework defines how SEO refresh decisions are interpreted.
The Content Refresh Queue tracks those decisions operationally.
SEO Testing And Refresh Framework = decision logic
Content Refresh Queue = workflow tracking surface
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 Queue Specification
Content Brain SEO Testing And Refresh Framework
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:
refresh work being tracked without purpose
refresh work entering the queue without trigger
refresh queue items having no owner
refresh queue items having no next action
refresh queue items staying blocked without reason
refresh queue items being approved without review
refreshed content being republished without approval
affiliate content being refreshed without offer status
compliance-sensitive content being refreshed without risk flag
outdated claims remaining live
dead offers remaining promoted
thin content being left active without review
the refresh queue becoming a dumping ground
the refresh queue replacing Brain authority
the refresh queue granting approval by itself
the refresh queue being built as a plugin before manual workflow proves the need
the refresh queue interfering with M’s active build areas
mwmscontentbrain.site becoming a duplicate of MCR
Architectural Intent
The Content Brain Content Refresh Queue Specification exists to make future content maintenance visible, controlled, and scalable.
Its role is to define the future refresh queue before implementation so that Content Brain does not become a one-time publishing system that forgets older content.
The queue should help MWMS know:
what content needs review
why it needs review
who owns the refresh
what risk exists
what update is required
what is blocked
what should be merged
what should be retired
what should be republished
what signal should be watched after refresh
The long-term intent is to support a practical operational refresh queue on mwmscontentbrain.site while preserving MCR as the source of truth.
Final Rule
The Content Refresh Queue must track improvement work.
It must not create authority.
If a refresh item has no trigger, no purpose, no owner, no next action, and no feedback path, it should not enter the queue.
If the queue does not improve content maintenance 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 Refresh Queue Specification defining the future content refresh queue structure, refresh triggers, refresh types, 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 Refresh 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