Document Type: Standard
Status: UI Design Standard
Version: v1.1
Authority: MWMS HeadOffice
Applies To: HeadOffice Global Dashboard
Parent: HeadOffice UI – Navigation & Page Architecture
Last Reviewed: 2026-03-15
Purpose
This document defines the structural layout of the HeadOffice Global Dashboard.
The dashboard is the executive visibility surface of the MWMS ecosystem.
It provides immediate awareness of:
• system health
• pipeline flow
• brain activity
• governance alerts
• capital exposure
• recent system changes
The dashboard must present this information in a way that can be understood within seconds.
It is not a report index.
It is the system command visibility layer.
Scope
This standard applies to:
• the HeadOffice Global Dashboard
• executive visibility layout across MWMS
• dashboard information hierarchy
• governance-safe presentation of system state
• layout rules for major HeadOffice dashboard bands and panels
This document governs how the HeadOffice dashboard should be structurally arranged as an executive observation surface.
It does not govern:
• live operational control
• direct system execution
• record editing
• automation triggering
• capital approval authority
• brain-specific detailed reporting pages
Those remain governed by HeadOffice, Finance Brain, SIT, and the relevant Brain-specific systems.
Definition / Rules
Dashboard Design Principles
The HeadOffice dashboard must follow four core design principles.
1 – Immediate System Awareness
The user should understand the state of the entire system within seconds of opening the page.
The dashboard must surface:
• system status
• risk areas
• pipeline flow
• brain health
without requiring navigation to secondary pages.
2 – Executive Simplicity
The dashboard must remain readable at a glance.
It must not attempt to display every metric or report.
Instead it surfaces high-level signals and directs the user to deeper reporting pages when required.
3 – Structured Information Hierarchy
Information must flow from highest importance to lowest importance.
The dashboard must be visually structured in horizontal bands.
Each band represents a different level of system visibility.
4 – Governance Visibility
The dashboard must always highlight:
• structural alerts
• governance violations
• capital risk
• pipeline bottlenecks
HeadOffice exists to protect system integrity.
Risk must be visible.
Dashboard Layout Structure
The dashboard layout is divided into four primary bands.
These bands must appear in this order.
Band 1 – Executive Status Bar
The first section of the dashboard displays high-level system indicators.
Purpose:
Provide instant system awareness.
Recommended indicators:
• Active Brains
• Open Alerts
• Opportunities In Pipeline
• Capital Exposure State
• Active Testing Count
Example layout:
Active Brains Alerts Open Pipeline Live Capital Risk Active Tests
6 3 14 Amber 8
These values represent system state signals, not detailed metrics.
Band 2 – Revenue Pipeline Overview
The second section visualises the movement of opportunities through the MWMS lifecycle.
Purpose:
Allow HeadOffice to see where opportunities are accumulating or slowing.
Recommended stages:
• Intake
• Evaluation
• Approved For Test
• Testing
• Iteration
• Scaling
• Paused / Retired
Example layout:
Revenue Pipeline
Intake Evaluation Approved Testing Iteration Scaling
12 8 5 6 3 2
This section provides pipeline health awareness.
It must not become a detailed operational table.
Detailed pipeline data belongs on the Revenue Pipeline page.
Band 3 – Brain Health + Governance Alerts
The third band focuses on system stability and structural risk.
It is divided into two panels.
Brain Health Panel
Purpose:
Provide a quick overview of the status of each Brain in the system.
Example layout:
Brain Health
Affiliate Brain Healthy
Ads Brain Watch
Finance Brain Healthy
Experimentation Brain Healthy
SIT Brain Healthy
AIBS Brain Stable
Statuses should use simple state labels:
• Healthy
• Watch
• Risk
• Degraded
These states are informational and should not trigger automation.
Governance Alerts Panel
Purpose:
Surface structural issues detected by governance systems.
Examples of alerts:
• Experiment running without validation
• Scaling requested without finance approval
• Capital exposure above threshold
• Lifecycle stage violation
• SIT structural enforcement alert
These alerts must be visible immediately when they exist.
Band 4 – System Changes + Capital Visibility
The final band provides visibility into recent activity and financial exposure.
Weekly System Changes Panel
Purpose:
Display summarised activity across MWMS.
Example fields:
• Signals Logged
• Completions
• Failures
• Retries
• Missing Executor Events
This panel is derived from system rollup views.
It should provide a quick sense of system activity.
Capital Exposure Panel
Purpose:
Provide high-level visibility into financial exposure governed by Finance Brain.
Example fields:
• Active Exposure
• Exposure By Offer
• Scaling Requests Pending Approval
• Risk Distribution
This panel must remain informational only.
Capital approval remains the responsibility of Finance Brain.
Dashboard Navigation Links
Each dashboard section may provide clear drill-down links.
Examples:
• Revenue Pipeline → Revenue Pipeline Page
• Brain Health → Brain Pages
• Weekly Changes → Weekly System Changes Report
• Capital Exposure → Finance Brain Page
Links must remain minimal and purposeful.
The dashboard is not a navigation directory.
Dashboard Behaviour Rules
The dashboard must remain:
• read-only
• observational
• summarised
It must not:
• execute system actions
• modify records
• trigger automation
• override brain decisions
HeadOffice observes.
Brains operate.
Visual Direction
The dashboard must visually communicate clarity and control.
Required qualities:
• clean card layout
• strong section titles
• clear information grouping
• consistent spacing
• restrained colour usage
• readable typography
Colour should be used only for meaningful state indicators.
Recommended states:
• Green — Healthy
• Amber — Watch
• Red — Risk
• Blue — Informational
WordPress Constraint Rule
The dashboard is currently implemented within WordPress admin.
However, the interface must still aim for the experience of a professional internal system console.
The dashboard must not resemble:
• default plugin settings pages
• cluttered admin utilities
• unstructured page lists
Even within WordPress constraints the UI must feel deliberate and disciplined.
Final Rule
The HeadOffice dashboard is the executive visibility layer of MWMS.
It exists to answer three questions immediately:
• What is happening in the system?
• Where are the risks?
• Where should attention go?
If a user cannot answer those questions within seconds, the dashboard has failed its purpose.
HeadOffice governs the system through visibility, not through operational control.
Drift Protection
The system must prevent:
• the dashboard becoming a report dump instead of an executive surface
• detailed operational tables replacing high-level visibility
• governance alerts being hidden beneath lower-priority information
• observational panels drifting into execution controls
• navigation clutter turning the dashboard into a directory page
• WordPress constraints being used as an excuse for messy layout structure
The dashboard must remain fast to read, governance-safe, and executive in character.
Architectural Intent
HeadOffice UI – Dashboard Layout Standard exists to define the top-level visual structure of the HeadOffice Global Dashboard so system-wide state can be understood quickly and consistently.
Its role is to ensure that MWMS leadership can see health, flow, risk, and exposure at a glance through a disciplined layout that preserves governance boundaries and avoids operational clutter.
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, dashboard design principles, four-band layout, navigation guidance, behaviour rules, visual direction, WordPress constraint rule, and executive-visibility intent. Added standard document header, Scope, Definition / Rules structure, Drift Protection, and Architectural Intent sections.
Version: v1.0
Date: 2026-03-13
Author: MWMS HeadOffice
Change: Initial creation of HeadOffice UI – Dashboard Layout Standard defining the structural layout of the HeadOffice Global Dashboard.
END – HEADOFFICE UI – DASHBOARD LAYOUT STANDARD v1.1