Document Type: Architecture
Status: UI Architecture
Version: v1.1
Authority: MWMS HeadOffice
Applies To: HeadOffice UI and MWMS visibility layer
Parent: HeadOffice Brain
Last Reviewed: 2026-03-15
Purpose
This document defines the locked navigation and page architecture for the HeadOffice interface inside MWMS.
Its purpose is to ensure that HeadOffice presents as:
• system governance + executive visibility
and not as:
• page list + admin utilities
This document exists to prevent UI drift, preserve ecosystem clarity, and create a professional internal control surface for MWMS.
HeadOffice must feel like a governance console.
It must not feel like a collection of disconnected WordPress admin pages.
Scope
This architecture applies to:
• HeadOffice navigation structure
• HeadOffice page families
• dashboard and reporting-page placement
• Brain-page visibility architecture
• governance-safe UI structure across the MWMS visibility layer
This document governs how HeadOffice pages are organised, grouped, and surfaced inside the MWMS interface.
It does not govern:
• live operational execution
• Brain authority by itself
• campaign actions
• capital approval
• experiment validation authority
• detailed component styling rules already governed elsewhere
Those remain governed by HeadOffice, the relevant Brain canons, and companion UI standards.
Definition / Rules
Core UI Principle
HeadOffice exists to provide:
• executive visibility
• governance oversight
• system health awareness
• structural monitoring
• controlled drill-down into brain-level reporting
HeadOffice does not exist to act as:
• a direct execution layer
• a plugin utility menu
• a miscellaneous page list
• an operational workspace for campaign execution
The interface must express authority, clarity, restraint, and structure.
HeadOffice UI Layer Model
The HeadOffice UI is locked into 3 primary layers.
- Global Dashboard
The Global Dashboard is the executive home page of HeadOffice.
Its purpose is to provide immediate visibility into:
• overall system state
• pipeline movement
• brain health
• governance alerts
• capital exposure
• system changes
This is the first page a user should understand when entering HeadOffice.
It is the primary command visibility surface.
- Brain Reporting Pages
Each Brain must have its own reporting page beneath HeadOffice.
These pages provide structured visibility into that Brain’s domain without collapsing authority boundaries.
Each Brain page must:
• expose the state of that Brain clearly
• provide executive summary cards
• surface risks and alerts
• show lifecycle or activity state relevant to that Brain
• remain observational unless separate authority explicitly permits otherwise
These pages are not freeform.
They follow a standard page architecture.
- Governance / Architecture Pages
HeadOffice must also provide pages for structural system understanding.
These pages exist to display reference architecture, authority logic, and governance structure across MWMS.
They are not operational dashboards.
They are ecosystem visibility and system reference pages.
Examples include:
• Brain Interaction Map
• Decision Authority Matrix
• System Data Flow Map
• Strategic Vision & Horizon
• HeadOffice Canon
• Override Logs
• System Alerts
Locked Navigation Structure
The HeadOffice left-side navigation is locked to the following structure.
HeadOffice
• Dashboard
Brains
• Affiliate Brain
• Ads Brain
• Finance Brain
• Experimentation Brain
• SIT Brain
• AIBS Brain
• Revenue Pipeline
Reports
• Weekly Changes
• Brain Health
• Capital Exposure
• Task Calendar
System Architecture
• Brain Interaction Map
• Decision Authority Matrix
• System Data Flow Map
• Strategic Vision & Horizon
Governance
• HeadOffice Canon
• System Alerts
• Override Logs
This structure is the current approved HeadOffice navigation model.
No additional pages should be inserted into the top level unless structurally approved.
Navigation Intent
The navigation must reflect the real governance logic of MWMS.
Dashboard
The Dashboard is the top-level executive overview.
It must answer:
• What is happening across MWMS right now?
• Where are the major alerts?
• What is moving in the pipeline?
• Which brains need attention?
Brains
The Brains section exists to group all brain-specific visibility pages in one consistent area.
This reinforces the idea that HeadOffice oversees multiple specialised systems.
The Brains menu must remain clean and limited to Brain-level reporting surfaces.
Revenue Pipeline
The Revenue Pipeline is a major system view and deserves its own direct navigation item.
It must not be buried under reports.
It is one of the primary executive views across MWMS.
Reports
The Reports section contains recurring visibility and rollup views.
These are read-oriented reporting surfaces rather than ecosystem maps or governance references.
System Architecture
The System Architecture section exists to expose the structural design of MWMS.
These pages explain how the system is designed, how brains interact, and how authority flows.
Governance
The Governance section exists for oversight controls, constitutional references, and escalation visibility.
It is where the user should find the pages that govern behaviour rather than merely describe it.
Standard Page Families
All HeadOffice pages belong to one of the following families.
- Dashboard Pages
Purpose:
Provide high-level executive visibility.
Examples:
• Dashboard
• Revenue Pipeline
• Brain Health
• Capital Exposure
- Brain Pages
Purpose:
Provide domain-specific reporting for a single Brain.
Examples:
• Affiliate Brain
• Ads Brain
• Finance Brain
• Experimentation Brain
• SIT Brain
• AIBS Brain
- Architecture Pages
Purpose:
Provide system design visibility and ecosystem reference structure.
Examples:
• Brain Interaction Map
• Decision Authority Matrix
• System Data Flow Map
• Strategic Vision & Horizon
- Governance Pages
Purpose:
Provide governance reference, alerts, and oversight logging.
Examples:
• HeadOffice Canon
• System Alerts
• Override Logs
Global Dashboard Standard
The Global Dashboard must become the executive home page of HeadOffice.
It should present the system in this general sequence:
Top band
Executive summary / system status bar.
Recommended fields:
• Active Brains
• Alerts Open
• Opportunities In Pipeline
• Capital Exposure State
• Active Testing Count
Second band
Revenue pipeline overview.
Recommended fields:
• Intake
• Evaluation
• Approved for Test
• Testing
• Iteration
• Scaling
• Paused / Retired
Third band
Brain health and governance alert visibility.
Recommended sections:
• Brain Health
• Governance Alerts
Fourth band
System changes and capital visibility.
Recommended sections:
• Weekly System Changes
• Capital Exposure
This page should feel like the executive overview of MWMS.
It must not feel like a report index.
Revenue Pipeline Page Standard
The Revenue Pipeline page is a major HeadOffice page.
Its purpose is to unify visibility across:
• Affiliate Brain
• Ads Brain
• Experimentation Brain
• Finance Brain
• lifecycle progression
• system-level capital exposure
• structural risk
It should show the movement of opportunities from intake through testing and into scaling or retirement.
Recommended section order:
Top row
• Pipeline stage summary
Second row
• Opportunity Intake Panel
• Affiliate Evaluation Panel
Third row
• Testing Readiness Panel
• Campaign Architecture Panel
Fourth row
• Active Experiment Panel
• Iteration Panel
Fifth row
• Scaling Pipeline Panel
• Capital Exposure Panel
Bottom row
• Governance Alerts Panel
This page must remain observational.
It may visualise multiple Brain outputs but may not execute their functions.
Brain Page Standard
Each Brain page must follow a common pattern so the interface feels unified and professional.
The pages should look similar enough to feel systemised, but distinct enough to avoid confusion.
This distinction is mandatory.
Shared layout pattern
Every Brain page should contain:
• Brain Header
• Status / Window Controls
• Executive Summary Cards
• Main Visibility Panels
• Risk / Alert Panel
• Report / Drill-down Links
Brain Header
Must clearly identify:
• Brain name
• current system status
• selected time window where relevant
Status / Window Controls
Should allow visibility across standard reporting windows where relevant, such as:
• 7 days
• 30 days
• 90 days
These controls should remain visually consistent across Brain pages.
Executive Summary Cards
Should surface the top indicators for that Brain.
These are not generic.
They must be chosen according to the Brain’s actual domain.
Main Visibility Panels
These panels are where the page becomes Brain-specific.
The panel structure should align to the Brain’s function and lifecycle role.
Risk / Alert Panel
Every Brain page should surface structural warnings, governance issues, or operational concerns relevant to that Brain.
Report / Drill-down Links
Each Brain page may expose deeper reports, but these links should be placed consistently.
Similar but Distinct Rule
All Brain pages must follow one shared design system.
However, they must not become visually interchangeable.
This is the locked rule:
Similarity requirement
All Brain pages must share:
• common spacing rhythm
• card styles
• heading treatment
• summary row behaviour
• grid logic
• status badge logic
• alert box language style
Distinction requirement
Each Brain page must still feel meaningfully different through:
• page title and role language
• Brain-specific summary metrics
• domain-relevant panel names
• lifecycle context
• risk language specific to that Brain
• appropriate iconography or visual cues if later approved
The goal is:
standardised system feel
without creating
page confusion
Brain-Specific Intent
Affiliate Brain page
Should emphasise:
• opportunity intake
• evaluation queue
• viability analysis
• classification
• readiness for test handoff
Ads Brain page
Should emphasise:
• campaign health
• experiment activity
• creative intelligence
• iteration state
• scaling readiness
Finance Brain page
Should emphasise:
• active exposure
• risk distribution
• scaling approval state
• survivability visibility
• capital protection signals
Experimentation Brain page
Should emphasise:
• experiment validation
• statistical discipline
• registry state
• test sequencing
• contamination or quality warnings
SIT Brain page
Should emphasise:
• structural violations
• rule enforcement
• system integrity status
• drift indicators
• blocked actions or escalation points
AIBS Brain page
Should emphasise:
• automation system status
• workflow health
• uptime
• orchestration visibility
• operational stability alerts
Visual Direction Lock
HeadOffice must visually evolve toward a professional internal system dashboard.
The intended visual direction is:
• clean
• modern
• restrained
• executive
• systemised
• readable at a glance
It must not present as:
• cluttered plugin admin
• arbitrary utility pages
• inconsistent page design
• decorative marketing UI
Required visual qualities
• strong information hierarchy
• larger, cleaner section titles
• consistent card padding
• meaningful use of status colour
• generous spacing
• clear grouping of information
• minimal visual noise
Status colour use
Status colours should be reserved for meaning.
Recommended pattern:
• Green = healthy
• Amber = watch
• Red = risk
• Blue = informational / neutral emphasis
Colour must never substitute for structure.
WordPress Constraint Rule
This architecture is currently implemented inside WordPress for speed and practicality.
Therefore:
• the UI may be built within WordPress admin constraints
• the visual system should still aim above default plugin-page quality
• temporary WordPress limitations do not permit design drift
• structural professionalism remains the target
The interface must feel like a governance console even while living inside WordPress.
Page Naming Rule
Page names visible in navigation should remain short, clear, and executive-friendly.
Avoid:
• overly technical menu labels
• internal draft language
• implementation language
• phase names in top-level menu items unless structurally necessary
Prefer:
• Dashboard
• Revenue Pipeline
• Brain Health
• System Alerts
Detailed phase information may remain inside page content where appropriate.
Menu Discipline Rule
The left-side navigation must remain disciplined.
No page should be added merely because it exists as a document or internal spec.
A page earns a navigation position only if it serves one of the locked UI roles:
• executive dashboard
• brain reporting surface
• architecture reference
• governance surface
This prevents navigation sprawl.
Future Expansion Rule
Future Brains may be added to the Brains menu only after structural approval.
Potential future additions may include:
• Research Brain
• Product Brain
• PPL Brain
• Opportunity Brain
• Compliance Brain
When added, they must inherit the same Brain page standard defined here.
Final Rule
HeadOffice UI must present MWMS as a governed system.
It must communicate:
• authority
• structure
• visibility
• restraint
• professionalism
The interface is not a loose collection of pages.
It is the executive visibility layer of the MWMS ecosystem.
Navigation must remain disciplined.
Page architecture must remain standardised.
Brain pages must feel unified but distinct.
HeadOffice governs the system through visibility, not through UI chaos.
Drift Protection
The system must prevent:
• navigation expanding into uncontrolled page sprawl
• HeadOffice pages collapsing into generic WordPress admin lists
• top-level menu items being created without structural purpose
• Brain pages losing the shared-but-distinct design logic
• dashboard surfaces drifting into execution areas
• temporary WordPress constraints being used to justify messy architecture
HeadOffice navigation and page architecture must remain deliberate, governed, and system-readable.
Architectural Intent
HeadOffice UI – Navigation & Page Architecture exists to define the structural blueprint of the HeadOffice visibility layer so MWMS is presented as a coherent governance console rather than a loose page collection.
Its role is to lock navigation structure, page families, dashboard placement, Brain-page logic, and menu discipline so the system remains readable, scalable, and governance-safe as the ecosystem grows.
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, core UI principle, three-layer UI model, locked navigation structure, navigation intent, page-family model, Global Dashboard standard, Revenue Pipeline page standard, Brain Page standard, similar-but-distinct rule, Brain-specific intent, visual direction lock, WordPress constraint rule, page naming rule, menu discipline rule, future expansion rule, and final governance logic. Corrected the review date formatting and added Document Type, Scope, Definition / Rules structure, Drift Protection, and Architectural Intent sections.
Version: v1.0
Date: 2026-03-10
Author: MWMS HeadOffice
Change: Initial structural lock for HeadOffice navigation, page families, dashboard architecture, Revenue Pipeline placement, and standardised-but-distinct Brain page rules.
END – HEADOFFICE UI – NAVIGATION & PAGE ARCHITECTURE v1.1