MWMS MCR

MWMS Opportunity System Implementation Brief For M

Document Type: Protocol
Status: Active
Version: v2.1
Authority: HeadOffice
Applies To: M, mwmsbrain.site system implementation, Supabase task/event/result records, plugin/UI build work, Brain Room where relevant
Parent: HeadOffice Brain
Last Reviewed: 2026-05-11

Purpose

The MWMS Opportunity System Implementation Brief For M provides a clear, simplified implementation brief for M to build the first usable MWMS Opportunity System layer on mwmsbrain.site.

Its purpose is to:

  • define exactly where M starts
  • remove ambiguity from the build process
  • prevent overbuilding or building out of order
  • ensure alignment with MWMS architecture
  • accelerate development speed
  • preserve MCR as Source of Truth
  • protect Supabase lineage
  • ensure correct system foundations for later stages
  • prevent plugin/UI code from becoming hidden canon
  • ensure HeadOffice can see the operational chain

This is not a design document.

This is a build execution guide for M.

This page now sits underneath the broader:

MWMS Opportunity System Implementation Control Brief

The Control Brief governs the shared build relationship between Martyn and M.

This page governs M’s technical implementation lane. The prior version already defined Phase 1 as a simple Affiliate Brain Intake System and warned not to build measurement, forecasting, dashboards, automation, AI integrations, or cross-Brain linking too early.

Scope

This protocol applies to:

  • mwmsbrain.site development
  • M’s developer implementation lane
  • UI surface implementation
  • WordPress plugin work
  • basic workflow wiring
  • early-stage system deployment
  • Supabase records connected to opportunity intake
  • status handling
  • manual testing
  • safe save points
  • HeadOffice visibility foundations

It defines:

  • starting point
  • build sequence
  • Phase 1 boundaries
  • what to build
  • what not to build yet
  • success criteria
  • M’s technical responsibilities
  • MCR protection rules
  • Supabase lineage rules
  • when to route missing requirements back to HeadOffice

It does not define:

  • full system architecture
  • long-term roadmap
  • deep automation
  • forecasting systems
  • reporting systems
  • Finance Brain logic
  • advanced Research Brain logic
  • MCR canon editing
  • final dashboard architecture

Core Principle

Build the simplest usable system first.

Do not build the full MWMS vision in one pass.

Start with:

one working flow
one usable interface
one real interaction
one stable save point

The first build must prove that Martyn can create, save, view, and update an opportunity record on mwmsbrain.site.

M Build Lane Rule

M owns the technical implementation lane.

M may work on:

  • mwmsbrain.site plugin work
  • WordPress admin screens
  • simple intake forms
  • queue list display
  • status actions
  • Supabase record handling where required
  • event logging where required
  • safe save points
  • technical debugging
  • implementation testing

M must not directly change:

  • MCR canon pages
  • HeadOffice governance pages
  • copy maps unless instructed
  • page registries unless instructed
  • system standards
  • Brain authority rules
  • MCR Source of Truth logic

If M discovers missing rules, missing fields, unclear workflow, or technical conflict, M must report it back as a blocker or HeadOffice review item.

M must not solve MCR gaps by inventing unapproved canon logic inside code.

Source Of Truth Rule

MCR remains the Source of Truth.

mwmsbrain.site is the operational execution site.

Supabase stores structured operational records.

Plugin/UI systems provide working interfaces.

HeadOffice reviews operational feedback.

No plugin, UI screen, Brain Room feature, Supabase process, task executor, or Brain site may directly update MCR.

The approved path for proposed system changes is:

M identifies issue → HeadOffice review → MCR decision if required

The prohibited path is:

M changes plugin logic → plugin becomes hidden canon

Starting Point

The non-negotiable starting point is:

Affiliate Brain Intake System

This includes:

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

Do not start anywhere else.

Phase 1 exists to create structured input only.

It is not the full Opportunity System.

Measurement Awareness Rule

Measurement Planning and Forecasting exist in MWMS, but they are not part of Phase 1.

Do not build:

  • Measurement Planning UI
  • Forecasting systems
  • tracking logic
  • experiment planning
  • reporting logic
  • Finance review logic
  • advanced scoring

At this stage:

Only create structured opportunity input.

Measurement, forecasting, testing, reporting, and Finance control will be layered later.

What To Build — Phase 1 Only

1. Opportunity Intake Queue

The Opportunity Intake Queue must include:

  • list of opportunities
  • status grouping
  • ability to open a record
  • basic filters
  • clear record title
  • last updated date where possible
  • simple status visibility

Minimum status groups:

  • New
  • Under Review
  • Rejected
  • Escalated

Optional later statuses may be added only after approval.

The queue must be simple and stable.

2. Opportunity Intake Record Screen

The Opportunity Intake Record Screen must include the following fields.

Core Fields

  • Product Name
  • Product Link
  • Platform
  • Vendor Name
  • Discovery Source
  • Date Found

Basic Research Fields

  • Competitors Found
  • Ads Found
  • Notes

Allowed values for Competitors Found:

  • Yes
  • No
  • Unknown

Allowed values for Ads Found:

  • Yes
  • No
  • Unknown

Fit Fields

  • Fits MWMS
  • Exclusion Flag

Allowed values for Fits MWMS:

  • Yes
  • No
  • Unsure

Allowed values for Exclusion Flag:

  • None
  • Compliance Concern
  • Low Quality Offer
  • Poor Fit
  • Insufficient Information
  • Other

Workflow Fields

  • Status
  • Review Notes

Minimum status values:

  • New
  • Under Review
  • Rejected
  • Escalated

3. Status Actions

Phase 1 must include simple status actions:

  • Reject
  • Move To Under Review
  • Escalate

Each status action must:

  • update the record reliably
  • be visible immediately after save
  • preserve the existing record data
  • show the current state clearly

4. Basic Save And View Behaviour

The system must allow Martyn to:

  • create a new opportunity
  • fill in basic fields
  • save the record
  • see the record in the queue
  • open the record again
  • edit the record
  • change the status
  • reject or escalate the record

This is the core Phase 1 workflow.

What Not To Build Yet

Do not build the following in Phase 1:

  • Offer Intelligence screens
  • Measurement Planning UI
  • Forecasting systems
  • Experimentation Brain workflows
  • Finance Brain logic
  • Research Brain signal systems
  • dashboards
  • automation
  • AI integrations
  • advanced scoring
  • cross-Brain linking
  • HeadOffice reporting dashboards
  • MCR update automation
  • Brain-to-Brain automation
  • advanced Supabase task routing
  • full Brain Room integration unless specifically assigned

These come later.

Phase 1 is about stable intake only.

How To Interpret MCR Pages

MCR pages are:

logic definitions

They are not always direct UI designs.

M must:

  • translate structure into simple UI
  • not attempt to replicate full documents inside screens
  • extract only what is needed for the current screen
  • preserve the intent of MCR logic
  • ask/report if the MCR instruction is unclear
  • avoid inventing unapproved system logic

M should build simple operational surfaces, not copy full MCR pages into plugin UI.

First Milestone

Definition Of Done — Phase 1

The Phase 1 system is usable when Martyn can:

  • create a new opportunity
  • fill in basic fields
  • save the record
  • see it in the queue
  • open it again
  • change its status
  • reject it
  • escalate it
  • confirm the data is preserved
  • confirm the screen is stable

The system does not need to be beautiful.

It needs to work reliably.

Build Approach

Step 1 — Create Basic Database Structure

Create or confirm the basic database structure for:

  • Opportunity Intake Record

The structure must support:

  • core fields
  • basic research fields
  • fit fields
  • workflow fields
  • created date
  • updated date
  • status

If using Supabase, field names must follow MWMS naming rules:

  • lowercase
  • snake_case
  • stable descriptive names

Step 2 — Build Simple Form UI

Build a simple WordPress admin form for opportunity intake.

The form must be:

  • clear
  • stable
  • low-friction
  • easy to save
  • easy to edit
  • not overcomplicated

Step 3 — Build Queue List

Build a simple queue list showing opportunity records.

The list should show:

  • Product Name
  • Platform
  • Discovery Source
  • Status
  • Date Found
  • Last Updated where possible

The user must be able to open a record from the queue.

Step 4 — Add Status Actions

Add simple status actions:

  • Reject
  • Move To Under Review
  • Escalate

Status must update reliably.

Step 5 — Test Manually

Manually test:

  • create record
  • save record
  • reload record
  • edit record
  • change status
  • view queue
  • reject record
  • escalate record

Do not move to later features until this works.

Supabase Lineage Requirement

Phase 1 may be simple, but it must not block future lineage.

Where Supabase is used, the structure should avoid painting the system into a corner.

At minimum, the intake record should be able to later connect to:

  • opportunity_id
  • offer_id
  • brain_request_id
  • task_id
  • event_id
  • result_id
  • feedback_id

Phase 1 does not need to fully build all of these.

But it must not be built in a way that prevents them later.

Event Logging Requirement

Where practical, Phase 1 should prepare for simple event logging.

Useful events may include:

  • opportunity_created
  • opportunity_updated
  • status_changed
  • opportunity_rejected
  • opportunity_escalated

If event logging is not ready yet, M must note this as:

Not yet wired

Do not fake event logging.

Brain Request Boundary

Phase 1 does not need full cross-Brain automation.

However, escalation must be designed so it can later become a Brain Request.

For now:

  • Escalate may simply mark the record as Escalated
  • Later, Escalate can create a structured Brain Request
  • This must not be built as a dead-end status

The system should remain expandable.

HeadOffice Visibility Foundation

Phase 1 does not require the full HeadOffice dashboard.

However, the data must support later HeadOffice visibility.

At minimum, HeadOffice should later be able to see:

  • number of opportunities
  • number New
  • number Under Review
  • number Rejected
  • number Escalated
  • latest updated records
  • items needing review

Do not build the full dashboard yet.

Just avoid blocking it.

Development Rules

M must:

  • prioritize speed over perfection
  • build simple, clean UI
  • avoid over-engineering
  • keep fields minimal
  • ensure stability before adding features
  • preserve data
  • follow MCR-approved logic
  • keep technical changes traceable
  • report unclear requirements
  • maintain safe save points

M must not:

  • add advanced features early
  • build hidden authority logic
  • bypass HeadOffice rules
  • create automatic MCR updates
  • build Finance/Experimentation/Research layers early
  • create duplicate registries
  • hard-code future assumptions that are not approved

System Behaviour Expectations

The system should:

  • save reliably
  • update status immediately
  • display records clearly
  • allow fast entry
  • require minimal clicks
  • preserve existing data
  • avoid confusing screens
  • make the next action obvious

This is a working tool, not a theory page.

Controlled Loss Alignment

This phase supports the MWMS Controlled Loss Principle by:

  • ensuring structured opportunity entry
  • preventing random testing
  • improving early filtering
  • reducing wasted research
  • reducing wasted testing
  • creating a record before spend occurs

No opportunity should move toward paid testing without first becoming structured.

Safe Save Point Requirement

At the end of each meaningful development session, M must provide a save point.

The save point should include:

  • what was changed
  • what works
  • what does not work yet
  • what files were touched
  • what database tables or fields were touched
  • what still needs testing
  • what the next step is
  • whether any MCR instruction is missing or unclear

This protects continuity and prevents rebuild confusion.

Blocker Reporting Rule

If M cannot proceed because of missing or unclear instruction, M should not guess.

M should report the blocker clearly.

A blocker report should state:

  • what M was trying to build
  • what is unclear
  • what decision is needed
  • whether it affects MCR
  • whether it affects Supabase
  • whether it affects plugin/UI
  • what safe temporary option exists, if any

HeadOffice or Martyn then decides the next step.

Governance Role

This document ensures:

  • development starts correctly
  • M builds in the right order
  • architecture is respected
  • unnecessary complexity is avoided
  • future system layers can be added cleanly
  • MCR remains Source of Truth
  • Supabase lineage is protected
  • HeadOffice visibility is preserved
  • Phase 1 produces a real working intake system

Relationship To Other MWMS Pages

This protocol is governed by:

  • MWMS Opportunity System Implementation Control Brief
  • MWMS Opportunity System Operating Protocol
  • MWMS Opportunity System Build Order
  • MWMS Opportunity Intake Phase One Developer Build Pack
  • MWMS Opportunity Intake Phase One Acceptance Checklist
  • 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

This protocol is derived from:

  • Affiliate Brain Offer Intake Form
  • Affiliate Brain Opportunity Intake Workflow
  • Affiliate Brain Intake Screen Specification

Drift Protection

The system must prevent:

  • building later phases early
  • adding unnecessary features
  • overcomplicating the intake system
  • introducing measurement logic too early
  • deviating from the defined starting point
  • turning plugin logic into unapproved canon
  • bypassing MCR authority
  • creating disconnected Supabase records
  • losing future lineage
  • building hidden cross-Brain communication
  • creating direct Brain site to MCR updates
  • losing HeadOffice visibility

Architectural Intent

This document ensures MWMS begins as:

a working system

not:

a theoretical system

It establishes:

  • real usage
  • real data
  • real workflow
  • real operator interaction
  • stable intake
  • future lineage readiness
  • HeadOffice visibility foundations

before expansion.

The architectural intent is:

Build narrow. Make it work. Preserve lineage. Then expand.

Final Rule

M must build the Affiliate Brain Intake System first.

Do not build later phases early.

Do not automate cross-Brain flows yet.

Do not create hidden authority inside plugin code.

Do not update MCR directly.

Build the first stable operational surface on mwmsbrain.site, preserve future lineage, and report anything unclear back to HeadOffice.

Change Log

v2.0 — 2026-04-25

Updated Implementation Brief to:

  • align with updated Opportunity System Flow
  • clarify Phase 1 boundaries
  • prevent early measurement and forecasting build
  • ensure correct system layering
  • improve developer clarity

Pages Updated:

  • MWMS Opportunity System Implementation Brief For M

Pages Created:

  • None

Registries Requiring Update:

  • None

v2.1 — 2026-05-11

Updated to align with:

  • MWMS Opportunity System Implementation Control Brief
  • 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 Opportunity System Operating Protocol

Added:

  • M Build Lane Rule
  • Source Of Truth Rule
  • Supabase Lineage Requirement
  • Event Logging Requirement
  • Brain Request Boundary
  • HeadOffice Visibility Foundation
  • Safe Save Point Requirement
  • Blocker Reporting Rule
  • no direct Brain site to MCR update rule
  • stronger Phase 1 scope protection

Change Impact Declaration

Pages Updated:
MWMS Opportunity System Implementation Brief For M

Pages Created:
None

Pages Deprecated:
None

Registries Requiring Update:
None

Canon Version Update Required:
No

Monthly Change Log Entry Required:
Optional — only required if HeadOffice wants this implementation brief update recorded in the current MWMS System Change Log.