HeadOffice Newsletter Intelligence Brain Room Integration Specification

Document Type: Specification
Status: Active
Authority: HeadOffice
Applies To: HeadOffice, Brain Room, Supabase, All Brains (via request routing)
Parent: HeadOffice
Version: v1.1
Last Reviewed: 2026-04-29


Purpose

The HeadOffice Newsletter Intelligence Brain Room Integration Specification defines how structured newsletter intelligence records are connected to the Brain Room system for discussion, evaluation, prioritised review, and controlled decision-making.

This specification ensures:

• every insight is discussed in context
• Brain-level review is structured and traceable
• no intelligence is lost between intake and action
• decisions are recorded against the original insight
• Brain collaboration remains controlled
• execution never occurs without lineage
• Brain Room is protected from overload
• high-priority signals are processed first

Without integration:

• insights stay isolated in records
• discussion becomes disconnected from data
• decisions are lost in chat
• routing becomes unclear
• execution lacks traceability

This specification connects:

system record → conversation → decision → action


Scope

This specification applies to:

• newsletter intelligence records
• Brain Room threads
• Brain Room messages
• Brain request creation
• review conversations
• decision tracking
• priority handling
• routing discipline

This specification governs:

• how insights enter Brain Room
• how threads are created
• how Brain requests are structured
• how outcomes are stored
• how priority is enforced

This specification does not govern:

• Supabase schema design
• Brain decision logic
• task execution logic
• plugin UI implementation


Core Principle

All Brain Room discussions must be anchored to a structured intelligence record.

No free-floating discussions are allowed.

Conversation must attach to data.

Only relevant and prioritised insights enter Brain Room.


System Relationship

Supabase = system record
Brain Room = collaboration layer
Tasks = execution layer

Flow:

newsletter insight created
→ stored in Supabase
→ evaluated for eligibility
→ sent to Brain Room
→ reviewed by correct Brain
→ decision returned
→ decision stored back to record
→ optional task created


Thread Creation Gate (Critical Control Layer)

A Brain Room thread must ONLY be created if:

• action_type = review
OR
• strategic_relevance = high
OR
• escalation required

Thread creation must NOT occur for:

• parked insights
• rejected insights
• low-value signals
• unclassified insights

This prevents Brain Room overload.


Integration Trigger Points

Brain Room interaction may be triggered when:

• action_type = review
• parking_state = routing_preparation
• routing_status = not_routed
• routing_status = routed but awaiting evaluation
• escalation required
• strategic_relevance = high

Only structured insights may trigger Brain Room interaction.


Thread Creation Logic

Each newsletter intelligence item may create one Brain Room thread.

Thread Rules:

• one thread per intelligence item
• thread must reference intelligence_item_id
• thread must include structured intelligence data
• thread must include routing context
• thread must include priority


Thread Data Mapping

Brain Room Thread Fields:

thread_id
intelligence_item_id
thread_title
thread_summary
primary_brain
supporting_brains
priority
status
created_at


Thread Title Format

Must follow naming standard:

Newsletter Insight [Short Title]

Example:

Newsletter Insight AI Cost Collapse Signal


Initial Thread Message (Structured Intelligence Required)

Each thread must begin with a structured message using the Working Intelligence Map format.

Required Fields:

• Insight
• Extraction Layer
• Why It Matters
• Primary Brain
• Supporting Brains
• Action Type
• Confidence
• Urgency
• Priority
• Notes


Priority Definition

Priority must be derived from:

confidence_level + urgency_level

Priority levels:

High Priority
Review Priority
Monitor Priority
Low Priority

Priority must be visible in thread and request.


Classification Rules

• Extraction Layer = PRIMARY classification
• Signal Type = optional secondary tag
• Action Type = decision gate
• Priority = execution driver


Brain Request Creation

After thread creation, a Brain request must be generated.


Brain Request Structure

request_id
thread_id
intelligence_item_id
target_brain
request_type
request_summary
priority
status
created_at


Request Types

review
interpretation
validation
risk_assessment
strategy_review
execution_recommendation


Primary Brain Assignment

Each request must have one Primary Brain.

The Primary Brain is responsible for:

• interpreting the insight
• producing the main response
• determining next action


Supporting Brain Participation

Supporting Brains:

• may contribute insight
• must not override Primary Brain
• may be triggered sequentially


Brain Response Capture

All Brain responses must be stored as:

• Brain Room messages
AND
• linked back to the intelligence record


Response Fields

response_id
intelligence_item_id
thread_id
brain_name
response_summary
decision_type
recommendation
confidence
created_at


Decision Types

no_action
monitor
update_framework
escalate
create_task
reject
build_later


Decision Recording Rule

Every final outcome must be recorded in:

newsletter_intelligence_items

Fields to update:

routing_status
action_type
notes
strategic_relevance
updated_at


Event Logging Requirement

Every Brain Room interaction must create an event:

thread_created
request_sent
brain_response
decision_recorded
task_created
escalation

This ensures full traceability.


Task Creation Integration (Future Step)

If decision_type = create_task:

→ create task in task system
→ link task_id to intelligence record

This connects:

insight → decision → execution


Escalation Logic

Escalation to HeadOffice occurs when:

• multiple Brains conflict
• decision unclear
• high-risk signal detected
• high strategic relevance
• system architecture impact

Escalation must:

• create new Brain Room message
• notify HeadOffice
• update routing_status = escalated


Status Lifecycle

routing_status transitions:

not_routed
→ routed
→ under_review
→ completed

or:

→ escalated


Visibility Rules

HeadOffice must be able to see:

• all active threads
• all pending requests
• all Brain responses
• all decisions
• all escalations
• all high-priority signals

No hidden discussion layers allowed.


First Implementation Scope

Phase 1 must support:

manual thread creation
manual request creation
manual Brain response entry
decision recording
event logging
priority tagging

Phase 1 must NOT include:

AI auto-routing
auto-response generation
multi-agent automation
full task automation


Governance Role

HeadOffice ensures:

• only valid insights enter Brain Room
• routing discipline is enforced
• Brain authority is maintained
• discussion is structured
• priority is respected
• decisions are recorded
• no execution occurs without traceability


Relationship To Other MWMS Systems

Works with:

HeadOffice Newsletter Intelligence Supabase Schema Specification
HeadOffice Newsletter Intelligence Operating Protocol
MWMS Full Newsletter Intelligence Extraction Protocol
HeadOffice Newsletter Intelligence Intake Framework
HeadOffice Newsletter Insight Parking System
HeadOffice Newsletter Brain Routing Review Framework
MWMS Brain To Brain Request Protocol
MWMS System Data Flow Map


Drift Protection

The system must prevent:

discussion without linked data
decisions without records
routing without requests
duplicate threads
untracked Brain responses
task creation without insight origin
chat-based decision loss
signal_type replacing extraction_layer
low-value signals entering Brain Room
priority signals being buried

If discussion is not traceable, system integrity is broken.

If priority is not visible, system efficiency is broken.


Architectural Intent

This specification ensures that:

every insight becomes a structured conversation
every conversation becomes a prioritised decision
every decision is recorded
every action has lineage

It transforms MWMS into:

a structured intelligence-to-action system
not an idea discussion environment


Change Log

Version: v1.1
Date: 2026-04-29
Author: HeadOffice

Change:
Updated Brain Room integration to align with Newsletter Intelligence Operating Protocol v1.1 and Supabase Schema v1.1. Added extraction_layer as primary classification, introduced priority logic, enforced action_type gating, added thread creation control layer, implemented structured Working Intelligence Map in thread messages, and strengthened anti-overload and traceability rules.


Version: v1.0
Date: 2026-04-28
Author: HeadOffice

Change:
Initial creation of HeadOffice Newsletter Intelligence Brain Room Integration Specification defining thread creation, Brain request structure, response capture, decision recording, and system integration with Supabase intelligence records.


END HEADOFFICE NEWSLETTER INTELLIGENCE BRAIN ROOM INTEGRATION SPECIFICATION