Document Type: Specification
Status: Active
Authority: HeadOffice
Applies To: HeadOffice, Supabase, Brain Room, Newsletter Intelligence System, Future Dashboard UI
Parent: HeadOffice
Version: v1.1
Last Reviewed: 2026-04-29
Purpose
The HeadOffice Newsletter Intelligence Supabase Schema Specification defines the required database structure for storing newsletter-derived intelligence inside MWMS.
This specification ensures newsletter insights are:
structured
searchable
filterable
traceable
routeable
dashboard-ready
Brain Room ready
future automation ready
Without a structured Supabase schema, newsletter intelligence remains trapped in conversation, documents, or manual notes.
That creates:
lost insights
weak routing
poor dashboard visibility
broken lineage
manual rework
future automation limits
This schema creates the system record layer for HeadOffice Newsletter Intelligence.
Scope
This specification applies to:
newsletter intelligence records
newsletter source records
extracted insight records
extraction layer classification
parking states
routing states
Brain assignments
review outcomes
dashboard filtering
future Brain Room integration
future task creation
This specification governs the data structure only.
It does not govern:
newsletter extraction rules
Brain Room UI behaviour
task executor logic
Brain-level decision making
plugin implementation code
campaign execution
Those are governed by separate MWMS pages.
Core Principle
Newsletter intelligence must become structured data before it becomes conversation, routing, task work, or dashboard output.
Supabase is the system record.
Brain Room is the working discussion layer.
Tasks are the execution layer.
The extraction layer is the system classification layer.
Every insight must preserve its extraction layer so MWMS can understand why the signal matters and where it belongs.
Required Tables
The first implementation requires three tables:
newsletter_sources
newsletter_intelligence_items
newsletter_intelligence_events
Table 1 — newsletter_sources
Purpose:
Stores the origin of each newsletter signal.
Required fields:
id
source_name
source_type
publisher_name
source_url
status
notes
created_at
updated_at
Field definitions:
id
Unique UUID primary key.
source_name
Name of newsletter or publication.
source_type
Newsletter, report, platform update, vendor update, compliance notice, other.
publisher_name
Publisher or organisation behind the newsletter.
source_url
Optional source link.
status
active, paused, ignored.
notes
Free text notes.
created_at
Record creation timestamp.
updated_at
Last updated timestamp.
Table 2 — newsletter_intelligence_items
Purpose:
Stores each extracted newsletter insight as a structured record.
Required fields:
id
source_id
date_captured
newsletter_title
insight_title
extracted_insight
extraction_layer
why_it_matters
signal_type
primary_brain
supporting_brains_json
confidence_level
urgency_level
action_type
parking_state
routing_status
strategic_relevance
risk_flag
compliance_flag
review_timing
related_pages_json
notes
created_by
created_at
updated_at
Field definitions:
id
Unique UUID primary key.
source_id
Foreign key to newsletter_sources.id.
date_captured
Date the insight was captured.
newsletter_title
Title or topic of newsletter.
insight_title
Short title for the extracted insight.
extracted_insight
Clear statement of the intelligence signal.
extraction_layer
Required system-level classification from the MWMS Full Newsletter Intelligence Extraction Protocol.
This field defines which intelligence layer the insight belongs to.
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
MWMS relevance explanation.
signal_type
Optional descriptive tag used for secondary filtering.
Examples:
tool
platform
compliance
strategy
execution
psychology
opportunity
trend
risk
finance
data
automation
signal_type must not replace extraction_layer.
primary_brain
Main Brain responsible for review.
This field is required for any item where action_type = review or build_later.
supporting_brains_json
JSON array of supporting Brains.
confidence_level
low, medium, high.
urgency_level
low, medium, high.
action_type
park, review, build_later, reject.
parking_state
holding_area, intelligence_log, deferred_review, routing_preparation, rejected.
routing_status
not_routed, routed, under_review, completed, escalated.
strategic_relevance
low, medium, high.
risk_flag
Boolean field showing whether risk review may be needed.
compliance_flag
Boolean field showing whether compliance review may be needed.
review_timing
immediate, soon, later, monitor_only.
related_pages_json
JSON array of related MWMS pages.
notes
Free text operator notes.
created_by
User or system that created the record.
created_at
Record creation timestamp.
updated_at
Last updated timestamp.
Table 3 — newsletter_intelligence_events
Purpose:
Stores append-only event history for each newsletter intelligence item.
Required fields:
id
intelligence_item_id
event_type
event_summary
event_payload_json
created_by
created_at
Field definitions:
id
Unique UUID primary key.
intelligence_item_id
Foreign key to newsletter_intelligence_items.id.
event_type
created, classified, parked, deferred, routed, reviewed, escalated, rejected, updated.
event_summary
Short description of what happened.
event_payload_json
Structured event metadata.
created_by
User or system creating event.
created_at
Event timestamp.
Status Values
action_type values:
park
review
build_later
reject
parking_state values:
holding_area
intelligence_log
deferred_review
routing_preparation
rejected
routing_status values:
not_routed
routed
under_review
completed
escalated
confidence_level values:
low
medium
high
urgency_level values:
low
medium
high
review_timing values:
immediate
soon
later
monitor_only
strategic_relevance values:
low
medium
high
Extraction Layer Values
extraction_layer values:
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
Extraction layer values must remain aligned with the MWMS Full Newsletter Intelligence Extraction Protocol.
If the protocol changes, this schema specification must be reviewed.
Required Relationships
newsletter_intelligence_items.source_id
references newsletter_sources.id
newsletter_intelligence_events.intelligence_item_id
references newsletter_intelligence_items.id
Each insight must have:
one source
one extraction layer
one action type
one parking state
one routing status
one event trail
If action_type = review or build_later, each insight must also have:
one primary Brain
zero or more supporting Brains
Structured Extraction Alignment
The newsletter_intelligence_items table must support the mandatory Working Intelligence Map structure used by the operating protocol.
Required mapping:
Newsletter Source
→ newsletter_sources.source_name
Insight
→ newsletter_intelligence_items.extracted_insight
Extraction Layer
→ newsletter_intelligence_items.extraction_layer
Affected Brain
→ newsletter_intelligence_items.primary_brain and supporting_brains_json
Action Type
→ newsletter_intelligence_items.action_type
Confidence
→ newsletter_intelligence_items.confidence_level
Urgency
→ newsletter_intelligence_items.urgency_level
Notes
→ newsletter_intelligence_items.notes
This alignment prevents mismatch between extraction output and database storage.
Dashboard Readiness
This schema must support dashboard filtering by:
source
date
newsletter title
extraction layer
signal type
primary Brain
supporting Brain
confidence
urgency
action type
parking state
routing status
risk flag
compliance flag
strategic relevance
review timing
This supports the future HeadOffice Newsletter Intelligence Dashboard.
The dashboard must prioritise extraction_layer over signal_type for system-level classification.
Brain Room Readiness
Each newsletter_intelligence_items record must be able to connect later to:
Brain Room thread
Brain Room message
Brain request
task record
review outcome
decision record
Future fields may include:
brain_room_thread_id
brain_room_message_id
brain_request_id
task_id
decision_record_id
These should not be required in the first schema unless implementation timing requires them.
First Implementation Principle
Build the smallest useful schema first.
Phase 1 must support:
save newsletter source
save extracted insight
classify extraction layer
classify insight
park insight
route insight
record event history
display in dashboard later
Phase 1 must not build:
automation
AI extraction
full Brain Room integration
task executor logic
advanced scoring
cross-brain automation
Governance Role
HeadOffice owns this schema because newsletter intelligence is a cross-Brain intake and routing layer.
Specialist Brains may review routed insights, but they do not own the original newsletter intelligence record.
HeadOffice remains responsible for:
intake visibility
classification consistency
extraction layer discipline
routing traceability
parking state discipline
strategic escalation
system-level review
Relationship To Other MWMS Systems
This specification works with:
MWMS Full Newsletter Intelligence Extraction Protocol
HeadOffice Newsletter Intelligence Operating Protocol
HeadOffice Newsletter Intelligence Intake Framework
HeadOffice Newsletter Insight Parking System
HeadOffice Newsletter Brain Routing Review Framework
HeadOffice Newsletter Intelligence Dashboard Specification
MWMS Supabase Naming Standard
MWMS Supabase Task Schema Standard
MWMS Brain To Brain Request Protocol
MWMS System Data Flow Map
Drift Protection
The system must prevent:
newsletter insights stored only in chat
newsletter insights without source
newsletter insights without extraction layer
newsletter insights without classification
newsletter insights without parking state
newsletter insights without routing status
routing without event history
manual dashboard records disconnected from Supabase
duplicate uncontrolled storage locations
signal_type being used as a replacement for extraction_layer
If insight lineage cannot be traced, the schema is incomplete.
If extraction layer cannot be filtered, the schema is incomplete.
Architectural Intent
This schema turns newsletter intelligence into a durable MWMS system record.
It allows HeadOffice to move from:
manual reading
to structured intelligence capture
to dashboard visibility
to Brain Room discussion
to task-based execution
Supabase provides the memory layer.
Brain Room provides the collaboration layer.
Tasks provide the execution layer.
Extraction layer provides the classification layer.
This specification establishes the foundation for that flow.
Change Log
Version: v1.1
Date: 2026-04-29
Author: HeadOffice
Change:
Updated schema to align with HeadOffice Newsletter Intelligence Operating Protocol v1.1. Added extraction_layer as a required field, defined valid extraction layer values, clarified the difference between extraction_layer and signal_type, tightened primary_brain requirements for review and build_later items, added structured extraction alignment mapping, and updated dashboard readiness and drift protection requirements.
Version: v1.0
Date: 2026-04-28
Author: HeadOffice
Change:
Initial creation of HeadOffice Newsletter Intelligence Supabase Schema Specification defining source, insight, and event tables for structured newsletter intelligence storage, dashboard readiness, routing readiness, and future Brain Room integration.
Change Impact Declaration
Pages Created:
None
Pages Updated:
HeadOffice Newsletter Intelligence Supabase Schema Specification
Pages Deprecated:
None
Registries Requiring Update:
None
Canon Version Update Required:
No
Change Log Entry Required:
No
END HEAD OFFICE NEWSLETTER INTELLIGENCE SUPABASE SCHEMA SPECIFICATION