Document Type: Framework
Status: Active
Authority: HeadOffice
Applies To: HeadOffice, All Brains via routing
Parent: HeadOffice
Version: v1.1
Last Reviewed: 2026-04-29
Purpose
The HeadOffice Newsletter Intelligence Intake Framework defines how newsletter intelligence enters the MWMS system in a structured, controlled, and usable format.
This framework ensures that:
• newsletters are captured consistently
• extracted intelligence is structured before use
• extraction layers are clearly assigned
• insights are visible to HeadOffice
• routing decisions are prepared correctly
• action types are assigned before movement
• priority is visible before review
• ideas do not bypass governance
• system stability is preserved
Without a structured intake framework:
• insights are lost
• ideas become fragmented
• routing becomes inconsistent
• system noise increases
• execution becomes reactive
• Brain Room becomes overloaded
• Supabase records become inconsistent
This framework converts newsletter insights into controlled system inputs.
Scope
This framework applies to:
• all newsletter-derived insights
• all intelligence extracted using the MWMS Full Newsletter Intelligence Extraction Protocol
• HeadOffice intake processes
• structured extraction capture
• pre-routing classification
• parking decisions
• priority assessment
This framework governs:
• how insights are captured
• how insights are structured
• how insights are recorded
• how insights are prepared for routing
• how priority is assigned before review
This framework does not govern:
• Brain-level analysis
• execution decisions
• campaign actions
• financial approvals
• Supabase implementation code
• Brain Room UI behaviour
Core Principle
No newsletter insight may enter the MWMS system without being structured through the intake framework.
Raw information is not allowed.
All intelligence must be:
• structured
• classified by extraction layer
• assigned an action type
• assigned confidence
• assigned urgency
• assigned priority
• visible
• traceable
Intake Structure
All newsletter insights must be captured using the following format.
Newsletter Intelligence Entry Template
Newsletter Source:
Date Captured:
Newsletter Title:
Insight Title:
Extracted Insight:
Extraction Layer:
Why It Matters:
Primary Brain:
Supporting Brains:
Action Type:
Confidence Level:
Urgency Level:
Priority Level:
Parking State:
Suggested Routing:
Suggested Review Timing:
Related MWMS Pages:
Signal Type:
Notes:
Field Definitions
Newsletter Source
Name of the newsletter or publication.
Date Captured
Date the insight was captured.
Newsletter Title
Title or topic of the newsletter.
Insight Title
Short title for the extracted insight.
Extracted Insight
Clear, single-signal statement of the intelligence found.
Extraction Layer
Primary system-level classification from the MWMS Full Newsletter Intelligence Extraction Protocol.
Valid extraction layers include:
• business_relevant_insight
• tool_and_technology_intelligence
• platform_and_algorithm_change
• strategic_trend_signal
• tool_adoption_and_replacement_signal
• compliance_and_policy_intelligence
• market_psychology_signal
• monetisation_opportunity_signal
• sentiment_and_hype_signal
• cross_publication_echo_detection
• affiliate_opportunity_sync
• temporal_pulse_mapping
• creator_and_thought_leader_signal
• knowledge_crosslinking
• policy_drift_watcher
Why It Matters
Short explanation of why the insight matters to MWMS.
Primary Brain
Main Brain responsible for review if the item requires routing.
Supporting Brains
Secondary Brains that may be affected or may assist review.
Action Type
Required decision category.
Allowed values:
• park
• review
• build_later
• reject
Confidence Level
Low, medium, or high confidence in the signal.
Urgency Level
Low, medium, or high urgency.
Priority Level
Derived from confidence plus urgency.
Parking State
Where the item sits before review or action.
Allowed values:
• holding_area
• intelligence_log
• deferred_review
• routing_preparation
• rejected
Suggested Routing
Target Brain or system if review is required.
Suggested Review Timing
Immediate, soon, later, or monitor_only.
Related MWMS Pages
Relevant pages connected to the insight.
Signal Type
Optional secondary descriptive tag.
Signal Type must not replace Extraction Layer.
Notes
Operator notes, context, or reasoning.
Extraction Layer Classification
Extraction Layer is the primary classification layer.
It determines:
• what kind of intelligence the insight represents
• how the signal should be understood
• which downstream system may need to review it
• how the dashboard should filter it
• how Supabase stores it
Signal Type is secondary only.
The system must not use Signal Type as the main classification field.
Priority Logic
Priority must be derived from confidence level and urgency level.
High Priority:
• confidence_level = high
• urgency_level = high
Review Priority:
• confidence_level = high and urgency_level = medium
• confidence_level = medium and urgency_level = high
Monitor Priority:
• confidence_level = medium and urgency_level = medium
• confidence_level = high and urgency_level = low
Low Priority:
• confidence_level = low
• urgency_level = low
Priority ensures HeadOffice can identify what needs attention first.
Action Decision Layer
Each insight must be assigned one action type.
Park
Stored for future use. No immediate review required.
Review
Requires Brain-level evaluation.
Build Later
Has system value but should not be built now.
Reject
No meaningful MWMS value.
Action Type controls whether the insight moves forward.
Routing Preparation
Before routing:
• insight must be structured
• extraction layer must be assigned
• confidence level must be defined
• urgency level must be defined
• priority level must be derived
• action type must be assigned
• Brain ownership must be identified
Routing must not occur without preparation.
This aligns with the Brain Routing Rule, where routing must occur before execution and must respect Brain authority boundaries.
Parking Integration
Insights must integrate with:
• Intelligence Holding Area
• Intelligence Log
• Deferred Review Register
• Routing Preparation
• Rejected
Routing depends on action type and parking state.
Parked or rejected insights must not enter Brain Room unless later reclassified.
Brain Room Eligibility
An insight may enter Brain Room only if:
• action_type = review
OR
• strategic relevance is high
OR
• escalation is required
Brain Room must not receive:
• unstructured insights
• parked low-priority items
• rejected items
• raw newsletter notes
This protects Brain Room from noise.
HeadOffice Responsibility
HeadOffice is responsible for:
• intake discipline
• structure enforcement
• extraction layer consistency
• action type assignment
• priority assignment
• routing preparation
• visibility of all insights
HeadOffice ensures no insight:
• bypasses structure
• bypasses extraction layer classification
• bypasses action assignment
• bypasses governance
• enters Brain Room without eligibility
System Flow
Newsletter received
↓
Extraction using protocol
↓
Structured intake entry created
↓
Extraction Layer assigned
↓
Action Type assigned
↓
Confidence and urgency assigned
↓
Priority derived
↓
Parking State assigned
↓
Routing prepared if required
↓
Supabase record created
↓
Dashboard visibility
↓
Brain Room review if eligible
↓
Decision
↓
Task if required
Relationship To Other MWMS Systems
Works with:
• MWMS Full Newsletter Intelligence Extraction Protocol
• HeadOffice Newsletter Intelligence Operating Protocol
• HeadOffice Newsletter Intelligence Supabase Schema Specification
• HeadOffice Newsletter Intelligence Dashboard Specification
• HeadOffice Newsletter Intelligence Brain Room Integration Specification
• HeadOffice External Change Intelligence Framework
• HeadOffice Change Impact Triage Model
• HeadOffice Change Routing Protocol
• Strategic Change Review Framework
• MCR Intelligence Holding Area
• MCR Intelligence Log
• MCR Deferred Review Register
This framework is the entry point for newsletter intelligence.
Drift Protection
The system must prevent:
• unstructured insight capture
• missing extraction layer
• signal type replacing extraction layer
• missing Brain assignment
• missing action type
• missing confidence level
• missing urgency level
• missing priority level
• random idea storage
• duplicate insights
• premature routing
• low-value Brain Room threads
• bypassing governance
Unstructured intake leads to system instability.
Architectural Intent
This framework ensures newsletters become:
structured system inputs
not random ideas.
It enables:
• clean routing
• consistent intelligence capture
• scalable knowledge growth
• priority visibility
• controlled Brain Room discussion
• system discipline
HeadOffice controls intake so the system remains stable.
Change Log
Version: v1.1
Date: 2026-04-29
Author: HeadOffice
Change:
Updated intake framework to align with the upgraded Newsletter Intelligence system. Added Extraction Layer as the primary classification field, retained Signal Type only as an optional secondary tag, rebuilt the intake template, added priority logic, aligned action type and parking state rules, added Brain Room eligibility rules, and updated the system flow to match the current end-to-end architecture.
Version: v1.0
Date: 2026-04-28
Author: HeadOffice
Change:
Initial creation of HeadOffice Newsletter Intelligence Intake Framework defining structured intake template, classification logic, action assignment, and routing preparation for all newsletter-derived intelligence entering MWMS.
Change Impact Declaration
Pages Created:
None
Pages Updated:
HeadOffice Newsletter Intelligence Intake Framework
Pages Deprecated:
None
Registries Requiring Update:
None
Canon Version Update Required:
No
Change Log Entry Required:
No
END HEADOFFICE NEWSLETTER INTELLIGENCE INTAKE FRAMEWORK