MWMS Opportunity System Operating Protocol

MWMS Opportunity System Operating Protocol

Document Type: Protocol
Status: Active
Version: v2.1
Authority: HeadOffice
Applies To: Affiliate Brain, Research Brain, Experimentation Brain, Finance Brain, Data Brain, Ads Brain, Conversion Brain, HeadOffice Brain, mwmsbrain.site operations, mwmsheadofficebrain.site visibility, Supabase task systems, Brain Room, and future plugin/UI execution systems
Parent: HeadOffice Brain
Last Reviewed: 2026-05-11


Purpose

The MWMS Opportunity System Operating Protocol defines the operational execution flow of the MWMS Opportunity System.

Its purpose is to:

  • enforce a consistent system workflow
  • ensure all opportunities move through MWMS correctly
  • prevent structural drift in execution
  • align all Brains to a single operating model
  • ensure decisions, testing, capital, and learning remain connected
  • ensure all execution is measurement-driven and forecast-controlled
  • define how mwmsbrain.site operates the opportunity workflow
  • define how Supabase stores request, task, result, and lineage records
  • define how HeadOffice maintains oversight
  • protect MCR as the Source of Truth
  • prevent Brain-site feedback from directly rewriting MCR canon

This is the active operating system layer for MWMS opportunity execution.

The previous version already established the full execution model, including Measurement Planning, Forecast Based Testing, Action Driven Reporting, Forecast Comparison, and Measurement Driven Decision Logic. This v2.1 update strengthens the connection between MCR, mwmsbrain.site, structured Brain Requests, Supabase execution, and HeadOffice review.


Scope

This protocol applies to:

  • all opportunity intake
  • all opportunity evaluation
  • all research requests
  • all measurement planning
  • all test forecasting
  • all test creation and execution
  • all test result interpretation
  • all capital allocation decisions
  • all learning capture
  • all cross-Brain system flow
  • all mwmsbrain.site opportunity operations
  • all Supabase task and event records connected to opportunity movement
  • all Brain Room messages that trigger opportunity work
  • all plugin/UI screens that execute opportunity workflows
  • all HeadOffice visibility and review actions connected to opportunity progression

It governs how MWMS operates in real use.

It does not define:

  • page naming rules
  • document structure rules
  • individual Brain internal frameworks
  • plugin implementation details
  • Supabase schema implementation details
  • final MCR canon editing rules

Those remain governed by:

  • MWMS Page Naming Standard
  • MWMS Document Structure Standard
  • 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
  • each relevant Brain Canon

Core Principle

All opportunities must move through a structured system flow.

No opportunity may bypass any required stage.

No stage may operate in isolation.

The system must function as a continuous loop.

All decisions must follow:

Question → Information → Action

All execution must follow:

Forecast → Test → Compare → Decide

All cross-Brain movement must follow:

Brain Request → Task Execution → Result Return → HeadOffice Visibility

All proposed system improvements must follow:

Brain Feedback → HeadOffice Review → MCR Decision

The prohibited path is:

Brain Site → Direct MCR Update

mwmsbrain.site is the operational environment.

MCR remains the Source of Truth.

HeadOffice remains the approval layer for any proposed MCR change.


Source Of Truth Rule

The Opportunity System may create:

  • opportunity records
  • Brain Requests
  • task records
  • result summaries
  • test records
  • signal records
  • learning records
  • feedback records
  • dashboard views
  • operational recommendations

But these outputs do not directly become canon.

MCR remains the Source of Truth for:

  • system architecture
  • Brain structure
  • governance rules
  • operating protocols
  • standards
  • copy maps
  • authority rules
  • approved page logic

If opportunity execution reveals that an MCR page needs improvement, the system must create a HeadOffice review item.

Only HeadOffice may approve a change to MCR.


Operational Environment Rule

The Opportunity System operates primarily through:

  • mwmsbrain.site
  • Supabase request and task records
  • WordPress Brain-site workspaces
  • plugin/UI screens
  • Brain Room where applicable
  • mwmsheadofficebrain.site for HeadOffice visibility and reporting

The Brain site is the work layer.

Supabase is the structured record and execution layer.

HeadOffice is the review and control layer.

MCR is the Source of Truth.


MWMS Opportunity System Flow

The mandatory system flow is:

Opportunity Intake

Offer Evaluation

Research Request Where Required

Measurement Planning

Test Forecasting

Testing Handoff

Test Execution

Action Driven Reporting

Forecast Comparison

Capital Control

Learning Capture

System Feedback

HeadOffice Review Where Required

MCR Decision Where Required

This flow is mandatory.

No opportunity may skip required validation stages.


Stage Definitions


1. Opportunity Intake

Owned By: Affiliate Brain
Operational Surface: mwmsbrain.site
Likely System Layer: Affiliate intake screen / opportunity intake workflow
Record Type: Opportunity record / Brain Request where cross-Brain action is required

Responsibilities

Affiliate Brain must:

  • capture opportunity data
  • ensure structured input
  • filter obvious exclusions
  • identify missing information
  • classify initial opportunity type
  • connect intake to offer, niche, source, and traffic assumptions
  • decide whether further research is required

Output

The required output is:

  • valid opportunity record
  • initial intake status
  • initial Affiliate Brain classification
  • reject/proceed/research-required decision

Rule

No opportunity may proceed without a structured intake record.


2. Offer Evaluation

Owned By: Affiliate Brain
Operational Surface: mwmsbrain.site
Likely System Layer: Offer Intelligence screen / offer evaluation workflow
Record Type: Offer evaluation record / Brain Request if routed onward

Responsibilities

Affiliate Brain must:

  • assess commercial viability
  • apply scoring and evaluation frameworks
  • evaluate payout and economics
  • evaluate offer strength
  • evaluate funnel quality
  • evaluate traffic fit
  • evaluate compliance sensitivity
  • determine test readiness
  • determine whether Research Brain input is required

Output

The required output is one of:

  • reject
  • park
  • request research
  • proceed to measurement planning
  • proceed to Experimentation Brain for test candidate assessment

Rule

No offer may move to testing simply because it looks promising.

It must pass structured offer evaluation.


3. Research Request Where Required

Owned By: Research Brain
Triggered By: Affiliate Brain / HeadOffice / Ads Brain / Data Brain
Operational Surface: mwmsbrain.site
Record Type: Brain Request and research task

Responsibilities

Research Brain must:

  • investigate market signal
  • validate offer claims and evidence
  • review source quality
  • assess audience and problem fit
  • assess competitor and market pressure
  • identify compliance or risk issues
  • classify signal strength
  • return a research verdict

Output

The required output is:

  • research verdict
  • evidence summary
  • confidence level
  • risk notes
  • recommended next step
  • returned result to originating Brain

Rule

Research Brain does not send informal notes.

Research Brain returns structured results through the Brain Request chain.


4. Measurement Planning

Owned By: Data Brain
Operational Surface: mwmsbrain.site / future Data Brain UI
Record Type: Measurement plan / task record

Responsibilities

Data Brain must:

  • define what must be measured
  • define tracking requirements
  • define decision logic
  • identify required events
  • identify data quality risks
  • confirm whether tracking is ready

Required Structure

Measurement planning must use:

LayerQuestion
QuestionWhat must be learned?
InformationWhat data is required?
ActionWhat decision will be made?

Output

The required output is:

  • structured measurement plan
  • event requirements
  • tracking readiness status
  • decision logic

Rule

No measurement plan → no test

No tracking should exist without a defined question, required information, and intended action.


5. Test Forecasting

Owned By: Experimentation Brain
Operational Surface: mwmsbrain.site / future Experimentation UI
Record Type: Forecast record / test candidate record

Responsibilities

Experimentation Brain must:

  • define expected performance
  • set acceptable ranges
  • define success thresholds
  • define failure thresholds
  • define minimum signal expectations
  • define test duration expectations
  • define interpretation logic before the test begins

Output

The required output is:

  • test forecast
  • expected performance range
  • success/failure thresholds
  • test interpretation plan

Rule

No forecast → no test

No expectation means no valid optimization.


6. Testing Handoff

Owned By: Affiliate Brain → Experimentation Brain
Operational Surface: mwmsbrain.site
Record Type: Brain Request / test candidate record

Responsibilities

Affiliate Brain and Experimentation Brain must:

  • convert opportunity into test candidate
  • define test parameters
  • confirm hypothesis
  • confirm assets required
  • confirm measurement readiness
  • confirm finance sensitivity
  • ensure readiness before launch

Output

The required output is:

  • structured test candidate
  • linked opportunity record
  • linked offer evaluation
  • linked measurement plan
  • linked forecast
  • test readiness decision

Rule

Testing handoff must be structured.

No verbal or informal handoff is valid.


7. Test Execution

Owned By: Experimentation Brain
Supported By: Ads Brain, Data Brain, Affiliate Brain
Operational Surface: mwmsbrain.site / Ads platform / future plugin UI
Record Type: Test task / execution task / event log

Responsibilities

Experimentation Brain must:

  • run controlled experiments
  • maintain test discipline
  • ensure valid data collection
  • prevent mid-test structural changes
  • preserve test assumptions
  • monitor for invalidation conditions

Ads Brain may support:

  • campaign setup
  • creative delivery
  • platform execution
  • traffic control
  • campaign signal capture

Data Brain may support:

  • tracking validation
  • data quality checks
  • signal collection

Output

The required output is:

  • test data
  • test status
  • data quality notes
  • anomalies if any
  • result-ready record

Rules

  • no mid-test structural changes
  • no uncontrolled budget expansion
  • tracking must be validated before launch
  • no test may proceed without defined forecast and measurement plan

8. Action Driven Reporting

Owned By: Data Brain
Operational Surface: mwmsbrain.site / mwmsheadofficebrain.site reporting
Record Type: Report record / dashboard output

Responsibilities

Data Brain must transform raw data into decision-ready output.

Report Must Show

FieldMeaning
ResultWhat happened?
CauseWhy did it happen?
ActionWhat should be done?

Output

The required output is:

  • action driven report
  • decision-ready summary
  • recommended next action
  • uncertainty notes
  • data quality notes

Rule

Reports that do not lead to action are invalid.


9. Forecast Comparison

Owned By: Experimentation Brain
Operational Surface: mwmsbrain.site
Record Type: Forecast comparison record / test result record

Responsibilities

Experimentation Brain must:

  • compare actual vs expected performance
  • classify variance
  • identify whether results are meaningful
  • decide whether signal is weak, emerging, strong, or validated
  • define next test/stop/scale interpretation

Output

The required output is one of:

  • Above Forecast
  • Within Range
  • Below Forecast
  • Inconclusive
  • Invalid Test

Rule

All test decisions must be based on forecast comparison.


10. Capital Control

Owned By: Finance Brain
Operational Surface: mwmsbrain.site / mwmsheadofficebrain.site visibility
Record Type: Finance review request / capital decision record

Responsibilities

Finance Brain must:

  • control budget
  • enforce spend limits
  • approve or reject scaling
  • contain losses
  • classify capital exposure
  • define budget ceilings
  • define pacing rules
  • protect survivability

Output

The required output is a capital decision.

Decision Options

  • Reject
  • Pause
  • Retest
  • Optimize
  • Controlled Scale
  • Escalate

Rule

No scaling may occur without Finance Brain approval where capital exposure is material.


11. Learning Capture

Owned By: Research Brain
Supported By: Experimentation Brain, Data Brain, Affiliate Brain
Operational Surface: mwmsbrain.site / future Research intelligence surface
Record Type: Learning record / signal record

Responsibilities

Research Brain must:

  • capture insights
  • classify signals
  • store learning
  • identify patterns
  • connect learning to the opportunity, offer, test, audience, and market context
  • classify whether learning should influence future evaluation

Output

The required output is:

  • structured signal intelligence
  • learning summary
  • reusable insight
  • confidence rating
  • recommended future use

Rule

No test may close without learning capture.


12. System Feedback

Owned By: All Brains
Oversight: HeadOffice
Operational Surface: mwmsbrain.site / mwmsheadofficebrain.site
Record Type: Feedback record / HeadOffice review request

Responsibilities

All Brains may identify:

  • workflow friction
  • missing fields
  • unclear operating instructions
  • dashboard gaps
  • plugin/UI issues
  • data quality problems
  • repeated task failures
  • missing Brain handoff logic
  • MCR page improvement suggestions

Output

The required output is:

  • structured feedback
  • HeadOffice review request where required
  • decision to approve, reject, park, or investigate

Rule

System feedback does not directly update MCR.

Any proposed MCR change must pass through HeadOffice review.


System Ownership Map

Brain / LayerOwnership
Affiliate BrainIntake and Evaluation
Research BrainResearch, Evidence, Learning, Signal Capture
Data BrainMeasurement Planning and Reporting
Experimentation BrainForecasting, Testing, Result Classification
Ads BrainCampaign Execution Support and Platform Signals
Finance BrainCapital Control
Conversion BrainLanding Page / Funnel Improvement Support where required
HeadOfficeSystem Oversight, Review, Escalation, MCR Decision
mwmsbrain.siteOperational execution environment
mwmsheadofficebrain.siteHeadOffice reporting and oversight environment
SupabaseRequest, task, event, result, and lineage records
MCRSource of Truth

Mandatory System Rules


Flow Integrity Rule

No opportunity may:

  • skip stages
  • jump directly to testing
  • bypass measurement planning
  • bypass forecasting
  • bypass finance control where capital exposure is material
  • bypass learning capture
  • bypass HeadOffice review where MCR change is suggested

Stage Completion Rule

Each stage must produce:

  • defined output
  • structured data
  • valid transition to next stage
  • owner of next action
  • status update

Request Structure Rule

Cross-Brain movement must use structured Brain Requests.

If one Brain needs another Brain to act, it must create or update a governed request.

Informal notes are not valid system handoff.


Supabase Lineage Rule

Supabase must preserve lineage between:

  • opportunity
  • intake
  • offer
  • Brain Request
  • task
  • event
  • result
  • escalation
  • learning
  • feedback

Tasks do not replace Brain Requests.

Tasks are execution children.


Measurement Rule

No tracking without:

  • defined question
  • defined data
  • defined action

Forecast Rule

No test may run without:

  • defined expectation
  • defined acceptable range
  • defined success/failure threshold

Reporting Rule

No report is valid unless it:

  • explains result
  • explains cause
  • leads to action

Controlled Loss Rule

All losses must be:

  • bounded
  • intentional
  • interpretable

Uncontrolled loss is not acceptable.


Scaling Rule

Scaling may only occur when:

  • test results are validated
  • forecast expectations are met or exceeded
  • finance approval is granted
  • capital exposure is acceptable
  • HeadOffice visibility exists where required

Learning Rule

Every test must produce:

  • structured learning
  • classified signals
  • reusable insight where possible

MCR Protection Rule

No opportunity workflow, Brain site, plugin/UI system, task executor, or Supabase automation may directly update MCR canon.

If operational work suggests an MCR change, the system must route the suggestion to HeadOffice.


System Surfaces

The MWMS Opportunity System is implemented through the following surfaces.


Intake Layer

  • Affiliate Brain Opportunity Intake Workflow
  • Affiliate Brain Intake Screen Specification
  • mwmsbrain.site intake surface
  • future plugin/UI intake screen

Evaluation Layer

  • Affiliate Brain Offer Intelligence Screen Specification
  • Affiliate Brain Offer Intelligence
  • Affiliate Brain Evaluation Field Schema
  • Affiliate Brain Offer Intelligence Page Template

Research Layer

  • Research Brain Offer Opportunity Research Task Specification
  • Research Brain Offer Source Validation Framework
  • Research Brain Offer Evidence Standards
  • Research Brain Research Verdict Framework
  • Research Brain Research Affiliate Handoff Protocol

Measurement Layer

  • Data Brain Measurement Planning Framework
  • Data Brain Event Measurement Framework
  • Data Brain Measurement Integrity Framework
  • Data Brain Custom Event Design Framework

Forecast Layer

  • Experimentation Brain Forecast Based Optimization Framework
  • Experimentation Brain Forecast Comparison logic
  • Experimentation Brain Experiment Validity Framework

Testing Layer

  • Affiliate Brain To Experimentation Brain Handoff Specification
  • Experimentation Brain Test Candidate Screen Specification
  • Experimentation Brain Test Result And Decision Workflow
  • Experimentation Brain Stage Progression Protocol

Result And Decision Layer

  • Experimentation Brain Test Result And Decision Workflow
  • HeadOffice Action Driven Reporting Standard
  • Data Brain Action Driven Reporting outputs
  • HeadOffice Cross Brain Performance And Control Dashboard Specification

Capital Control Layer

  • Finance Brain Test Budget And Capital Control Specification
  • Finance Brain Capital Allocation Ladder
  • Finance Brain Financial Risk Escalation Logic
  • Finance Brain Risk Adjusted Testing Allocation Framework

Learning Layer

  • Research Brain Test Learning And Signal Capture Framework
  • Research Brain Research Signal Logging Structure
  • Research Brain Intelligence Database
  • Research Brain Signal Classification logic

Oversight Layer

  • HeadOffice Cross Brain Performance And Control Dashboard Specification
  • HeadOffice Active Command Dashboard
  • HeadOffice Weekly System Movement Dashboard
  • HeadOffice System Signal Overview Framework
  • mwmsheadofficebrain.site reporting surface

Brain Site Operating Requirement

mwmsbrain.site must not be treated as ready simply because the site exists.

For the Opportunity System to work, mwmsbrain.site must have access to:

  • operational workflows
  • intake screens
  • offer evaluation screens
  • Brain Request creation logic
  • task views
  • result return views
  • status progression
  • HeadOffice visibility hooks
  • Supabase request/task/event records
  • approved working copies from MCR
  • plugin/UI surfaces where required

A Brain site without operational content is only a container.

A Brain site becomes useful when MCR-approved workflows are copied, transformed, or built into working execution surfaces.


HeadOffice Visibility Rule

HeadOffice must be able to see:

  • opportunity intake volume
  • opportunity status
  • current Brain owner
  • current stage
  • active blockers
  • Research Brain requests
  • Experimentation Brain requests
  • Finance Brain reviews
  • capital exposure
  • test status
  • learning capture status
  • system feedback requiring review
  • MCR update suggestions
  • closed decisions

HeadOffice visibility does not mean HeadOffice manually controls every action.

It means HeadOffice can see, review, and intervene when system-level authority is required.


Governance Role

This protocol ensures:

  • all Brains operate in alignment
  • execution remains structured
  • decision-making is measurement-driven
  • capital is protected
  • learning compounds over time
  • system intelligence improves
  • mwmsbrain.site has a clear operating model
  • Supabase supports lineage and task execution
  • HeadOffice maintains oversight
  • MCR remains protected as Source of Truth

Relationship To Other MWMS Pages

This protocol operates alongside:

  • MWMS Architecture Registry
  • 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 Build Order
  • MWMS Opportunity System Implementation Brief For M
  • MWMS Opportunity Intake Phase One Acceptance Checklist
  • MWMS Opportunity Intake Phase One Developer Build Pack
  • MWMS Opportunity System Phase Two Developer Build Pack
  • MWMS Supabase Task Schema Standard
  • MWMS Plugin Build Instruction Standard
  • HeadOffice Cross Brain Performance And Control Dashboard Specification

Drift Protection

The system must prevent:

  • opportunities bypassing system flow
  • testing without forecasts
  • data without purpose
  • reporting without action
  • isolated Brain operation
  • disconnected decision-making
  • uncontrolled testing
  • missing learning capture
  • capital mismanagement
  • Brain Requests without lineage
  • Supabase tasks without request context
  • plugin/UI actions bypassing governance
  • mwmsbrain.site becoming an ungoverned authority layer
  • Brain feedback directly updating MCR
  • MCR Source of Truth being replaced by operational records

Architectural Intent

This protocol transforms MWMS from:

a structured architecture

into:

a governed execution system

It ensures:

  • consistent execution
  • controlled testing
  • forecast-driven decisions
  • disciplined scaling
  • continuous learning
  • structured Brain Requests
  • HeadOffice visibility
  • Supabase-backed lineage
  • safe Brain-site operation
  • protected MCR authority

This is the operational core of MWMS.


Final Rule

Every opportunity must move through the approved system flow.

Every cross-Brain movement must use structured requests.

Every task must preserve lineage.

Every test must include measurement, forecast, comparison, decision, capital control, and learning capture.

Every proposed MCR change must go through HeadOffice.

No Brain site, plugin/UI system, task executor, automation, or Supabase process may directly update MCR canon.


Change Log

v2.0 — 2026-04-25

Upgraded protocol to include:

  • Measurement Planning
  • Forecast Based Testing
  • Action Driven Reporting
  • Forecast Comparison Layer
  • Measurement Driven Decision Logic

Pages Updated:

  • MWMS Opportunity System Operating Protocol

Pages Created:

  • None

Registries Requiring Update:

  • None

v2.1 — 2026-05-11

Expanded protocol to align with:

  • 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
  • Operational Environment Rule
  • Research Request Where Required stage
  • Brain Site Operating Requirement
  • Supabase Lineage Rule
  • MCR Protection Rule
  • HeadOffice Visibility Rule
  • System Feedback to HeadOffice review path
  • clearer mwmsbrain.site and mwmsheadofficebrain.site roles
  • stronger protection against Brain-site direct updates to MCR

Change Impact Declaration

Pages Updated:
MWMS Opportunity System Operating Protocol

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 operational expansion recorded in the current MWMS System Change Log.