MWMS MCR

MWMS Opportunity System Build Order

Document Type: Protocol
Status: Active
Version: v2.1
Authority: HeadOffice
Applies To: MWMS Opportunity System implementation across Affiliate Brain, Research Brain, Experimentation Brain, Finance Brain, Data Brain, Ads Brain, Conversion Brain, HeadOffice Brain, mwmsbrain.site, mwmsheadofficebrain.site, Supabase, plugin/UI systems, Brain Room, M, and Martyn
Parent: HeadOffice Brain
Last Reviewed: 2026-05-11

Purpose

The MWMS Opportunity System Build Order defines the required build sequence for implementing the MWMS Opportunity System.

Its purpose is to ensure:

  • correct implementation order
  • dependency alignment between components
  • avoidance of wasted development effort
  • early creation of usable system value
  • structured progression from intake to full system control
  • alignment with measurement-driven decision logic
  • clear separation between Martyn’s MCR/HeadOffice build lane and M’s technical build lane
  • protection of MCR as Source of Truth
  • controlled progression from manual operation to plugin/UI/Supabase execution
  • prevention of premature dashboards, automation, Finance logic, AI integrations, and cross-Brain automation

This document converts MWMS architecture into a practical build plan.

The previous version established the major build phases: Intake, Evaluation, Measurement and Forecast, Testing, Result and Learning, Capital Control, and System Oversight. It also introduced the Measurement First Rule and defined the recommended first build target as the Affiliate Brain Intake System.

Scope

This protocol applies to:

  • mwmsbrain.site system build
  • mwmsheadofficebrain.site visibility build
  • M’s technical implementation work
  • Martyn’s MCR and HeadOffice structure work
  • UI surface implementation
  • operational workflow deployment
  • Supabase request, task, event, result, and feedback records
  • cross-Brain system wiring
  • Brain Room integration where relevant
  • plugin/UI build sequencing
  • HeadOffice visibility and review surfaces

It defines:

  • build phases
  • component dependencies
  • implementation order
  • minimum viable system
  • what must be built first
  • what must wait
  • who owns which build lane
  • how MCR connects to mwmsbrain.site
  • when HeadOffice visibility becomes required
  • how future phases should be introduced

It does not define:

  • code implementation
  • full database schema
  • API logic
  • detailed UI design
  • final Supabase table definitions
  • internal Brain analysis logic
  • final MCR canon editing rules

Those remain governed by the relevant Brain Canons, implementation briefs, developer build packs, Supabase standards, plugin standards, and HeadOffice governance.

Core Principle

Build the system in the order that creates usable flow earliest.

Do not build downstream systems before upstream inputs exist.

Each step must produce a usable system increment.

The correct sequence is:

Entry → Structure → Evaluation → Measurement → Forecast → Test → Report → Finance → Learning → Oversight

The first priority is not to build the full MWMS vision.

The first priority is to create a working operational path on mwmsbrain.site that can later expand safely.

Source Of Truth Rule

MCR remains the Source of Truth.

The Build Order does not authorise any Brain site, plugin, UI, Supabase process, automation, or AI employee to directly update MCR.

The approved direction is:

MCR → Build Order → Developer Build Pack → mwmsbrain.site / plugin/UI / Supabase execution

The approved feedback path is:

Operational Feedback → HeadOffice Review → MCR Decision

The prohibited path is:

mwmsbrain.site / plugin / Supabase / Brain Room → Direct MCR Update

If live use shows that the Build Order, operating protocol, or MCR pages need improvement, the issue must route to HeadOffice.

Build Lane Rule

The Opportunity System now has two active build lanes.

Martyn Build Lane

Martyn owns:

  • MCR structure
  • HeadOffice standards
  • Opportunity System protocols
  • implementation control briefs
  • copy maps
  • page registry updates
  • operating logic
  • build sequencing
  • acceptance criteria
  • HeadOffice review paths
  • MCR update decisions where approved

Martyn should not directly interfere with M’s active plugin/Supabase/code work unless agreed.

M Build Lane

M owns:

  • mwmsbrain.site technical implementation
  • WordPress plugin/UI build
  • Supabase wiring where required
  • intake screens
  • queue screens
  • status actions
  • request/task/event/result handling where assigned
  • safe save points
  • technical debugging
  • implementation testing

M must not directly change MCR canon.

M must not invent hidden system authority inside code.

M must report missing requirements back to HeadOffice/Martyn.

HeadOffice Authority Lane

HeadOffice owns:

  • build priority
  • escalation review
  • approval of MCR changes
  • cross-Brain visibility requirements
  • decision on whether feedback becomes canon
  • conflict resolution between Martyn’s structural lane and M’s implementation lane

System Build Philosophy

MWMS must be built:

  • from entry point outward
  • from simplest usable flow to full system
  • from manual operation to automation
  • from structure to execution
  • from data collection to decision control
  • from local intake to cross-Brain request flow
  • from operational records to HeadOffice visibility

Avoid:

  • building isolated components
  • building future systems before current usage exists
  • over-engineering early stages
  • building without measurement planning
  • building dashboards before data flow works
  • building Finance controls before test flow exists
  • building automation before manual flow is stable
  • building direct MCR update pathways

Measurement First Rule

System build must follow:

Plan → Build → Report → Forecast → Optimize

This means:

  • measurement planning must exist before tracking logic becomes meaningful
  • forecasting must exist before testing
  • reporting must exist before decision layers
  • optimization must be based on forecast comparison
  • testing without a question, data requirement, and action logic is invalid

However, this does not mean Measurement Planning is built in Phase 1.

Phase 1 is intake only.

Measurement and forecasting are introduced only after upstream intake and evaluation are stable.

Build Phases Overview

The MWMS Opportunity System build phases are:

  1. Phase 1 — Intake System
  2. Phase 2 — Evaluation System
  3. Phase 3 — Measurement And Forecast System
  4. Phase 4 — Testing System
  5. Phase 5 — Result And Learning System
  6. Phase 6 — Capital Control System
  7. Phase 7 — System Oversight
  8. Phase 8 — Automation And AI Employee Expansion

Phase 8 is future only and must not be built before the manual and governed workflow is stable.

Phase 1 — Intake System

Priority: Highest
Primary Owner: M
Structural Owner: Martyn / HeadOffice
Operational Site: mwmsbrain.site
Source Of Truth: MCR
Status: First build priority

Components

Phase 1 includes only:

  • Affiliate Brain Intake Queue
  • Opportunity Intake Record Screen
  • Intake Status System

Purpose

Create the system entry point.

Phase 1 gives MWMS a practical place to capture opportunities before any deeper evaluation, testing, or spend occurs.

Outcome

Martyn can:

  • enter opportunities
  • store structured data
  • see opportunities in a queue
  • reopen records
  • update records
  • change status
  • reject or escalate opportunities

Dependency

None.

This is the first operational build.

Must Not Include

Phase 1 must not include:

  • Offer Intelligence
  • Measurement Planning UI
  • Forecasting systems
  • Testing workflows
  • Finance logic
  • Research Brain signal systems
  • Dashboards
  • Automation
  • AI integrations
  • Advanced scoring
  • Cross-Brain linking
  • Direct MCR update logic

Acceptance Gate

Phase 1 cannot be accepted until it passes:

MWMS Opportunity Intake Phase One Acceptance Checklist

Phase 2 — Evaluation System

Primary Owner: M
Structural Owner: Martyn / HeadOffice
Operational Site: mwmsbrain.site
Source Of Truth: MCR
Dependency: Phase 1 accepted

Components

Phase 2 may include:

  • Offer Intelligence Queue
  • Offer Intelligence Record Screen
  • Evaluation Decision Panel
  • basic viability fields
  • reject / park / proceed decision
  • link to Phase 1 opportunity record

Purpose

Enable structured opportunity evaluation.

Outcome

The system can:

  • evaluate opportunities
  • classify commercial viability
  • assess basic offer fit
  • prepare for measurement and forecasting
  • decide whether Research Brain review is required

Dependency

Phase 1 must be complete and accepted.

No evaluation system should be built before the intake system works.

Must Not Include

Phase 2 must not include:

  • full Experimentation workflow
  • Finance controls
  • scaling logic
  • automation
  • advanced AI scoring
  • full dashboards
  • direct MCR update logic

Phase 3 — Measurement And Forecast System

Primary Owners: Data Brain and Experimentation Brain
Technical Owner: M
Structural Owner: Martyn / HeadOffice
Operational Site: mwmsbrain.site
Source Of Truth: MCR
Dependency: Phase 2 accepted

Components

Phase 3 may include:

  • Measurement Planning Interface
  • KIA planning structure
  • Tracking Requirement Definition Layer
  • Forecast Definition Panel
  • Decision Trigger Mapping
  • success and failure threshold fields
  • test readiness logic

Purpose

Ensure all tests are measurable and predictable before execution.

Required Logic

All measurement planning must follow:

Question → Information → Action

All forecasting must define:

  • expected performance
  • acceptable range
  • success threshold
  • failure threshold
  • decision trigger

Outcome

The system can:

  • define what data is needed
  • define what will be measured
  • define expected performance
  • define decision logic before testing
  • prevent tests without measurement clarity

Dependency

Phase 2 must be complete.

Rule

No system may proceed to testing without:

  • measurement plan
  • forecast
  • decision logic

Phase 4 — Testing System

Primary Owner: Experimentation Brain
Supporting Owner: Ads Brain
Technical Owner: M
Structural Owner: Martyn / HeadOffice
Operational Site: mwmsbrain.site
Source Of Truth: MCR
Dependency: Phase 3 accepted

Components

Phase 4 may include:

  • Affiliate → Experimentation Handoff Object
  • Test Candidate Queue
  • Test Candidate Record Screen
  • Test Setup Panel
  • test status logic
  • linked forecast
  • linked measurement plan
  • controlled test execution fields

Purpose

Enable controlled test creation and execution.

Outcome

The system can:

  • convert approved opportunities into test candidates
  • define experiment structure
  • preserve measurement and forecast context
  • execute structured experiments
  • prevent uncontrolled test changes

Dependency

Phase 3 must be complete.

Testing must not be built before measurement and forecasting exist.

Phase 5 — Result And Learning System

Primary Owners: Experimentation Brain, Data Brain, Research Brain
Technical Owner: M
Structural Owner: Martyn / HeadOffice
Operational Site: mwmsbrain.site
Visibility Site: mwmsheadofficebrain.site later
Source Of Truth: MCR
Dependency: Phase 4 accepted

Components

Phase 5 may include:

  • Test Result Classification System
  • Action Driven Reporting Layer
  • Forecast Comparison Engine
  • Learning Capture Interface
  • Signal Capture System
  • result return logic
  • reusable insight records

Purpose

Turn test outcomes into structured decisions and reusable learning.

Outcome

The system can:

  • classify results
  • compare actual performance against forecast
  • generate clear actions
  • capture reusable intelligence
  • support Research Brain learning and signal capture
  • support future HeadOffice reporting

Dependency

Phase 4 must be complete.

Phase 6 — Capital Control System

Primary Owner: Finance Brain
Technical Owner: M
Structural Owner: Martyn / HeadOffice
Operational Site: mwmsbrain.site
Visibility Site: mwmsheadofficebrain.site later
Source Of Truth: MCR
Dependency: Phase 4 functional and Phase 5 result logic sufficiently stable

Components

Phase 6 may include:

  • Budget Tier System
  • Spend Limit Enforcement
  • Capital Escalation Logic
  • Loss Containment Rules
  • Finance review panel
  • capital decision record
  • controlled scale approval logic

Purpose

Protect capital and enforce financial discipline.

Outcome

The system can:

  • control spend
  • limit risk
  • enforce scaling discipline
  • approve or block capital movement
  • contain losses
  • support HeadOffice visibility

Dependency

Phase 4 must be functional.

Finance controls should not be built as isolated features before testing and result logic exists.

Phase 7 — System Oversight

Primary Owner: HeadOffice
Technical Owner: M
Structural Owner: Martyn / HeadOffice
Operational Visibility Site: mwmsheadofficebrain.site
Supporting Site: mwmsbrain.site
Source Of Truth: MCR
Dependency: Prior phases producing reliable data

Components

Phase 7 may include:

  • HeadOffice Cross Brain Dashboard
  • HeadOffice Active Command Dashboard
  • Alert System
  • Control Actions
  • System Movement View
  • opportunity status overview
  • active blockers
  • test and capital posture
  • feedback requiring review
  • MCR update suggestion visibility

Purpose

Provide full system visibility and control.

Outcome

HeadOffice can:

  • monitor the entire system
  • see cross-Brain movement
  • identify blockers
  • review escalations
  • monitor capital exposure
  • review system feedback
  • decide whether MCR changes are required
  • intervene when needed

Dependency

Earlier phases should produce reliable data before full dashboard build.

Do not build dashboards before the underlying workflow and records are stable.

Phase 8 — Automation And AI Employee Expansion

Primary Owner: HeadOffice
Technical Owner: M or future developer
Structural Owner: Martyn / HeadOffice
Operational Site: mwmsbrain.site and future Brain sites
Visibility Site: mwmsheadofficebrain.site
Source Of Truth: MCR
Dependency: Manual workflow proven and stable

Components

Phase 8 may include:

  • AI employee orchestration
  • automated request routing
  • automated task creation
  • automated result summaries
  • automated feedback classification
  • automated dashboard alerts
  • controlled automation triggers
  • Brain Room AI-assisted workflows

Purpose

Add automation only after the manual workflow is proven.

Rule

Automation must not be used to hide unclear workflow logic.

Automation must follow approved MCR rules, structured Brain Requests, Supabase lineage, and HeadOffice visibility.

Build Order Summary

The required build order is:

  1. Intake System
  2. Evaluation System
  3. Measurement And Forecast System
  4. Testing System
  5. Result And Learning System
  6. Capital Control System
  7. System Oversight
  8. Automation And AI Employee Expansion

This order must not be skipped without HeadOffice approval.

Minimum Viable System

The first true Minimum Viable System is achieved after:

Phase 1 + Phase 2 + Phase 3 + Phase 4

This allows:

  • opportunity entry
  • structured evaluation
  • measurement planning
  • forecasting
  • test setup
  • controlled experiment execution

However, the first usable operational increment is achieved after:

Phase 1 accepted

Phase 1 is not the full system.

Phase 1 is the first working door into the system.

Recommended First Build Target

Start with:

Affiliate Brain Intake System

Then:

Evaluation System

Then:

Measurement And Forecast System

Then:

Testing System

Do not start with dashboards.

Do not start with automation.

Do not start with Finance scaling logic.

Do not start with AI employees.

Do not start with direct Brain-to-MCR sync.

Development Guidance For M

M should:

  • build UI surfaces matching approved screen specifications
  • implement status transitions
  • ensure record linkage between systems where required
  • preserve future Supabase lineage
  • enforce stage progression logic only when the relevant phase is reached
  • avoid over-building features early
  • prioritize usability over completeness
  • ensure every stage produces structured output
  • provide safe save points
  • report missing instructions or blockers
  • avoid creating unapproved canon logic in code

M should not:

  • build later phases early
  • create automatic MCR updates
  • bypass structured Brain Requests
  • create hidden authority in plugin/UI systems
  • create disconnected Supabase records
  • build dashboards before workflow data exists
  • automate before manual workflow is stable

Development Guidance For Martyn

Martyn should:

  • keep MCR as Source of Truth
  • maintain build order clarity
  • update operating protocols where required
  • create or update developer briefs before implementation
  • protect M’s active build lane
  • avoid giving M conflicting instructions
  • classify pages as MCR Only, Copy To Brain, or Later Plugin/UI
  • keep HeadOffice visibility requirements clear
  • update acceptance checklists when phase scope changes
  • route operational feedback through HeadOffice review

Martyn should not:

  • change build direction without updating the relevant control page
  • create competing manual systems for the same plugin/UI function unless temporary and labelled
  • interfere with M’s code lane without a defined handoff
  • allow Brain-site feedback to become direct MCR change without review

Phase Gate Rule

No phase should begin until the previous phase has:

  • working operational surface
  • accepted functional behaviour
  • stable save point
  • clear remaining gaps
  • no hidden scope expansion
  • no direct MCR update path
  • future lineage not blocked

HeadOffice may approve exceptions, but exceptions must be recorded.

System Evolution Strategy

After initial build:

  • expand features gradually
  • refine based on usage
  • introduce automation later
  • integrate AI after stable workflows exist
  • improve forecasting accuracy over time
  • improve reporting clarity
  • improve HeadOffice visibility once data is real
  • use operational feedback to improve MCR only through HeadOffice review

Controlled Loss Alignment

This build order supports the MWMS Controlled Loss Principle by:

  • ensuring structured input
  • enforcing disciplined testing
  • requiring forecasting before spend
  • controlling capital before scaling
  • capturing learning early
  • preventing random opportunity decisions
  • avoiding premature capital exposure
  • keeping system expansion bounded

Governance Role

This protocol ensures:

  • MWMS is built in correct sequence
  • system integrity is maintained
  • development remains aligned with architecture
  • operational readiness is achieved step-by-step
  • decisions are measurement-driven
  • scaling is controlled
  • Martyn and M do not build over each other
  • MCR remains protected
  • mwmsbrain.site becomes useful in controlled stages
  • mwmsheadofficebrain.site receives visibility only when underlying data is reliable

Relationship To Other MWMS Pages

This protocol operates alongside:

  • MWMS Opportunity System Implementation Control Brief
  • MWMS Opportunity System Implementation Brief For M
  • MWMS Opportunity Intake Phase One Developer Build Pack
  • MWMS Opportunity Intake Phase One Acceptance Checklist
  • MWMS Opportunity System Operating Protocol
  • Affiliate Brain Opportunity Intake Workflow
  • Affiliate Brain Offer Intelligence Screen Specification
  • Affiliate Brain To Experimentation Brain Handoff Specification
  • Experimentation Brain Test Candidate Screen Specification
  • Experimentation Brain Test Result And Decision Workflow
  • Finance Brain Test Budget And Capital Control Specification
  • Research Brain Test Learning And Signal Capture Framework
  • HeadOffice Cross Brain Performance And Control Dashboard Specification
  • MWMS MCR To Brain Copy Rule
  • MWMS MCR Brain Wiring Map
  • MWMS Brain Connector Architecture
  • MWMS Brain To Brain Request Protocol
  • MWMS Standard Cross Brain Flow
  • MWMS Supabase Task Schema Standard
  • MWMS Plugin Build Instruction Standard

Drift Protection

The system must prevent:

  • building components out of order
  • skipping measurement planning
  • testing without forecasts
  • implementing automation before manual flow works
  • building isolated features
  • ignoring dependencies
  • building dashboards before data flow exists
  • building Finance scaling logic too early
  • building AI employees before request lineage works
  • building Brain-site to MCR direct updates
  • creating hidden plugin authority
  • accepting incomplete phase work
  • allowing Martyn and M to build overlapping systems without coordination

Architectural Intent

This protocol converts MWMS from:

designed system

into:

buildable and executable system

It ensures:

  • development follows logic
  • system becomes usable quickly
  • complexity grows in controlled stages
  • decisions improve over time
  • operational surfaces appear only when needed
  • HeadOffice visibility is built on real system movement
  • MCR remains Source of Truth
  • automation is added only after manual workflow stability

The architectural intent is:

Build the doorway first, then the rooms, then the control tower, then automation.

Final Rule

Build in order.

Start with the Affiliate Brain Intake System.

Do not build evaluation before intake works.

Do not build measurement before evaluation works.

Do not build testing before measurement and forecasting work.

Do not build Finance controls before test flow and result logic exist.

Do not build dashboards before real data exists.

Do not build automation before manual workflow is stable.

Do not allow any Brain site, plugin, UI, Supabase process, Brain Room feature, automation, or AI employee to directly update MCR.

All proposed MCR changes must route through:

HeadOffice Review → MCR Decision

Change Log

v2.0 — 2026-04-25

Upgraded build order to include:

  • Measurement Planning Layer
  • Forecast Definition Layer
  • Action Driven Reporting
  • Forecast Comparison Logic
  • Decision Driven System Build

Pages Updated:

  • MWMS Opportunity System Build Order

Pages Created:

  • None

Registries Requiring Update:

  • None

v2.1 — 2026-05-11

Updated Build Order to align with:

  • MWMS Opportunity System Implementation Control Brief
  • MWMS Opportunity System Implementation Brief For M
  • MWMS Opportunity Intake Phase One Developer Build Pack
  • MWMS Opportunity Intake Phase One Acceptance Checklist
  • MWMS Opportunity System Operating Protocol
  • MWMS MCR To Brain Copy Rule
  • MWMS MCR Brain Wiring Map
  • MWMS Brain Connector Architecture
  • MWMS Brain To Brain Request Protocol
  • MWMS Standard Cross Brain Flow

Added:

  • Source Of Truth Rule
  • Build Lane Rule
  • Phase 8 Automation And AI Employee Expansion
  • Development Guidance For M
  • Development Guidance For Martyn
  • Phase Gate Rule
  • no direct Brain site to MCR update rule
  • mwmsheadofficebrain.site visibility role
  • stronger dashboard and automation delay rules
  • clearer distinction between first usable increment and full Minimum Viable System

Change Impact Declaration

Pages Updated:
MWMS Opportunity System Build Order

Pages Created:
None

Pages Deprecated:
None

Registries Requiring Update:
None

Canon Version Update Required:
No

Monthly Change Log Entry Required:
Optional — recommended if HeadOffice wants this build-order update recorded in the current MWMS System Change Log.