Document Type: Specification
Status: Specification
Version: v1.2
Authority: MWMS HeadOffice
Applies To: HeadOffice UI architecture and dashboard surfaces
Parent: HeadOffice Brain
Last Reviewed: 2026-04-16
Purpose
This document defines the Signals Dashboard used to provide HeadOffice visibility into active cross-brain strategic signals with minimal friction.
Its purpose is to surface recent and meaningful signal activity in a clean executive interface without turning HeadOffice into an execution layer.
The dashboard exists to help HeadOffice quickly observe:
emerging patterns
signal freshness
cross-brain strategic movement
system stability
learning velocity
scaling readiness
governance risk
improvement opportunities
The Signals Dashboard is a governed visibility surface.
It is not an execution console.
It is not a general-purpose admin tool.
It is not a substitute for specialist Brain dashboards.
Scope
This specification applies to:
HeadOffice signal visibility surfaces
cross-brain strategic signal monitoring
admin-only signal dashboard access
refresh behaviour for signal visibility
table structure and sorting rules for signal review
signal grouping logic
signal severity visibility
signal freshness visibility
This document governs the structure and behaviour of the HeadOffice UI Signals Dashboard.
It does not govern:
direct operational execution
signal generation logic by itself
Supabase schema design by itself
cron configuration by itself
authority changes across Brains
WordPress Admin implementation details beyond the approved dashboard specification
raw specialist analysis inside individual Brains
Those remain governed by HeadOffice, the existing Supabase connector patterns, and related MWMS architecture and build specifications.
Definition / Rules
Core Role
The Signals Dashboard exists to provide HeadOffice with a lightweight, high-visibility interface for observing active strategic signals across MWMS.
It is a visibility surface.
It is not an execution console.
It must help HeadOffice answer:
What is changing?
What is unstable?
What is improving?
What requires review?
What may require escalation?
What is fresh, stale, or growing in importance?
Signal visibility improves governance quality.
Signal overload reduces decision clarity.
The dashboard must remain narrow, interpretable, and governance-safe.
Signal Layer Intent
The Signals Dashboard is not a raw data table.
It is a structured signal interpretation surface.
Signals shown at HeadOffice level should help identify:
structural issues
capital risk patterns
experimentation readiness patterns
content intelligence patterns
product stability patterns
sales progression patterns
partnership leverage patterns
automation reliability patterns
external change signals
Kaizen improvement signals
HeadOffice sees signal summaries.
Specialist Brains retain detailed analysis authority.
Data Source
The dashboard reads from:
Supabase public.head_office_signals
Default retrieval rule:
ordered by last_seen desc
limit 50
Where implementation allows, the signal table may also support signal grouping or filtering by signal family without changing the visibility-only purpose of the surface.
UI Components
The dashboard should contain the following components.
Header Strip
The dashboard header strip must display:
total active signals count
last refresh time, derived from the most recent created_at or max last_seen
signals requiring review count
signals escalated count
signals marked stable count
Purpose:
Provide immediate executive awareness of current signal state.
The header strip should remain lightweight and readable.
Actions
The dashboard must provide the following actions:
Button: Refresh Signals Now
Action: executes
select public.fn_head_office_refresh_signals();
Button: View in Supabase
Optional external link if approved in the final UI layer
Optional future action:
Button: View Escalated Signals
This may be added only if it remains visibility-focused and does not convert the dashboard into an execution tool.
Signal Table
The dashboard table must contain the following columns:
signal_type
signal_family
pattern_key
pattern_value
occurrences
first_seen
last_seen
status
severity
source_brain
recommended_review_layer
These additional fields improve interpretability across the wider MWMS ecosystem now that more Brains and signal pathways exist.
Signal Families
Where implementation supports grouping, signal families may include:
Governance
Financial
Experimentation
Content
Product
Sales
Partnership
Automation
External Change
Kaizen
This grouping improves HeadOffice-level interpretability.
It must not replace the underlying signal record structure.
Sorting Rules
Default sort:
last_seen desc
Secondary optional sort:
severity desc
occurrences desc
Any additional sorting must preserve quick visibility into recent and meaningful signal movement.
Access Rules
Access is:
admin-only
restricted to the HeadOffice authority layer
No execution-layer user should receive direct control over this dashboard unless separately approved by governance.
Acceptance Test
The dashboard is considered valid when all of the following conditions are met:
when refreshed, the table updates within 15 seconds
new signals appear automatically from cron within 15 minutes
no duplicate (signal_type, pattern_key, pattern_value) rows ever appear
signals are ordered consistently by freshness
signal status remains interpretable across refresh cycles
signal source remains visible where supported
These conditions protect trust in the dashboard.
Operational Boundary
The Signals Dashboard may display signal visibility and allow governed refresh actions.
It must not:
become a general-purpose Supabase editor
allow unrestricted data mutation
bypass HeadOffice authority boundaries
drift into operational execution tooling
expose signal-management actions beyond the approved spec
collapse specialist Brain dashboards into one uncontrolled interface
replace governance escalation pathways
This dashboard is for observation and awareness.
Execution remains elsewhere.
Recommended Signal Coverage
The Signals Dashboard should support visibility into the following signal domains.
Governance Signals
Examples:
authority conflicts
routing violations
structural drift alerts
governance override signals
SIT-related warnings
Purpose:
Provide rapid visibility into structural stability risks.
Financial Signals
Examples:
capital pressure signals
exposure concentration signals
runway sensitivity signals
financial stability warnings
Purpose:
Ensure HeadOffice can see capital-related pressure without bypassing Finance Brain.
Experimentation Signals
Examples:
confidence shifts
test instability
signal-strength concerns
readiness to progress
Purpose:
Provide visibility into learning quality and validation discipline.
Content Signals
Examples:
content feedback loops
authority growth patterns
signal freshness from content systems
topic or audience feedback signals
Purpose:
Reflect the newer Content Brain layer now interacting with Research, Customer, and Data systems.
Product Signals
Examples:
product stability
feature pressure
feedback integration patterns
capability reliability concerns
Purpose:
Provide visibility into delivery-side structural health.
Sales Signals
Examples:
sales progression stability
expectation alignment concerns
offer-fit friction patterns
qualification instability
Purpose:
Reflect the newer Sales Brain interaction layer.
Partnership Signals
Examples:
partner performance patterns
distribution leverage patterns
partner dependency exposure
collaboration instability
Purpose:
Provide visibility into external leverage and ecosystem dependency.
Automation Signals
Examples:
trigger failures
workflow interruption patterns
dependency coordination alerts
automation reliability instability
Purpose:
Provide visibility into Layer 6 infrastructure health without entering execution tooling.
External Change Signals
Examples:
law change alerts
platform policy shifts
technology environment changes
AI capability shifts
strategic environment changes
Purpose:
Connect HeadOffice Change Intelligence to dashboard-level visibility.
Kaizen Signals
Examples:
repeated friction patterns
duplication patterns
clarity improvement opportunities
workflow simplification opportunities
Purpose:
Make continuous improvement visible without turning the dashboard into a task board.
Relationship to Other Pages
This UI specification reads from and depends on:
MWMS Brain Interaction Map
MWMS Request Routing Map
HeadOffice External Change Intelligence Framework
HeadOffice Change Impact Triage Model
HeadOffice Change Routing Protocol
HeadOffice Strategic Change Review Framework
HeadOffice Kaizen Continuous Improvement Loop
Operations Brain frameworks
Automation Brain frameworks
Finance Brain Canon
Experimentation Brain Canon
Content Brain Canon
Product Brain Canon
Sales Brain Canon
Partnership Brain Canon
These dependencies provide the signal sources or interpretation layers reflected in the dashboard.
Recommended Visual Layout
Top Row
Header Strip
Second Row
Signal Table
Third Row
Optional signal-family filter row
Optional severity summary strip
Bottom Row
Refresh action area
Optional Supabase visibility link
The layout should remain minimal, fast, and executive-oriented.
This dashboard must not become visually cluttered.
Future Expansion
Future versions may include:
signal-family filter controls
severity badges
cross-brain source badges
AI-generated executive summaries
stale-signal indicators
escalated-signal visibility strip
trend arrows for repeating patterns
These upgrades require separate structural approval.
They must preserve the visibility-only purpose of the dashboard.
Final Rule
The Signals Dashboard must remain a clean HeadOffice visibility surface for cross-brain strategic signals.
It must improve awareness without weakening governance boundaries or turning the interface into an operational tool.
Visibility is permitted.
Execution remains governed elsewhere.
Drift Protection
The system must prevent:
the Signals Dashboard drifting into a general admin utility page
duplicate signal rows undermining trust in the interface
unrestricted access outside the HeadOffice authority layer
sorting and freshness logic becoming inconsistent
implementation convenience weakening the original visibility-only intent
the dashboard absorbing functionality beyond the approved specification
signal overload reducing interpretability
The Signals Dashboard must remain minimal, structured, and governance-safe.
Architectural Intent
HeadOffice UI Signals Dashboard (Spec) exists to define a simple, fast, executive signal-monitoring surface for HeadOffice so emerging cross-brain patterns can be seen without friction.
Its role is to provide a governed observation layer over active strategic signals while keeping the interface narrow, trustworthy, and aligned with the broader HeadOffice UI architecture.
This version expands the original concept so the dashboard can reflect the broader MWMS ecosystem now that additional Brains and interaction layers exist, including:
Content Brain
Product Brain
Sales Brain
Partnership Brain
Automation Brain
External Change Intelligence
Kaizen Continuous Improvement Loop
The dashboard strengthens awareness without collapsing authority boundaries.
Change Log
Version: v1.2
Date: 2026-04-16
Author: MWMS HeadOffice
Change:
Expanded the HeadOffice Signals Dashboard specification to reflect broader MWMS signal coverage.
Added support for signal-family visibility across:
Governance
Financial
Experimentation
Content
Product
Sales
Partnership
Automation
External Change
Kaizen
Added recommended fields:
signal_family
severity
source_brain
recommended_review_layer
Strengthened dashboard role as a governed interpretation surface rather than a raw signal table.
Aligned the specification with newer MWMS structures including:
HeadOffice Change Intelligence layer
Kaizen Continuous Improvement Loop
Content Brain
Product Brain
Sales Brain
Partnership Brain
Automation Brain
Preserved the original visibility-only purpose and governance-safe design intent.
END – HEADOFFICE UI – SIGNALS DASHBOARD (SPEC) v1.2