Document Type: Specification
Status: Specification
Version: v1.1
Authority: MWMS HeadOffice
Applies To: HeadOffice UI architecture and dashboard surfaces
Parent: HeadOffice Brain
Last Reviewed: 2026-03-15
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, monitor signal freshness, and maintain awareness of cross-brain strategic movement.
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
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
• WP Admin implementation details beyond the approved dashboard specification
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.
Data Source
The dashboard reads from:
Supabase public.head_office_signals
Default retrieval rule:
• ordered by last_seen desc
• limit 50
UI Components (v0)
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
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
Table
The dashboard table must contain the following columns:
• signal_type
• pattern_key
• pattern_value
• occurrences
• first_seen
• last_seen
• status
Sorting Rules
Default sort:
• last_seen desc
Access Rules
Access is:
• admin-only
• restricted to the HeadOffice authority layer
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
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
Implementation Note
Once this specification page exists, the next implementation step is:
M implements a WordPress Admin screen that matches this specification using the existing Supabase connector pattern already present in MWMS.
This implementation step remains separate from the page specification itself.
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.
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 v0 specification
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.
Change Log
Version: v1.1
Date: 2026-03-15
Author: MWMS HeadOffice
Change: Rebuilt page to align with the locked MWMS document standard for this cleanup pass. Preserved the original purpose, data source, UI components, action buttons, table fields, sorting rules, access rules, acceptance tests, and implementation handoff intent. Added Document Type, Parent, Scope, Definition / Rules structure, Operational Boundary, Final Rule, Drift Protection, and Architectural Intent sections.
Version: v1.0
Date: 2026-03-13
Author: MWMS HeadOffice
Change: Initial creation of HeadOffice UI – Signals Dashboard (Spec) defining the minimal strategic signal visibility dashboard for HeadOffice.
END – HEADOFFICE UI – SIGNALS DASHBOARD (SPEC) v1.1