MWMS MCR

MWMS Opportunity System Phase Three Developer Build Pack

Document Type: Protocol
Status: Active
Version: v1.0
Authority: HeadOffice
Applies To: M, mwmsbrain.site Phase 3 build execution, Data Brain measurement workflow, Experimentation Brain forecast workflow, Supabase measurement and forecast records, plugin/UI implementation, future Brain Request expansion
Parent: HeadOffice Brain
Last Reviewed: 2026-05-12

Purpose

The MWMS Opportunity System Phase Three Developer Build Pack defines the controlled build requirements for Phase 3 of the MWMS Opportunity System.

Phase 3 begins only after Phase 2 has been accepted.

Phase 1 captures the opportunity.

Phase 2 evaluates the opportunity.

Phase 3 defines what must be measured and what performance is expected before any test is created.

Its purpose is to:

  • give M a clear developer-ready build instruction for Phase 3
  • prevent measurement and forecasting from being guessed later
  • define the first measurement and forecast layer after offer evaluation
  • connect measurement and forecast records back to Phase 1 and Phase 2 records
  • ensure no testing happens without measurement logic
  • ensure no optimization happens without forecast expectations
  • prevent early testing, Finance logic, dashboards, automation, or AI integrations
  • preserve future Supabase lineage
  • protect MCR as Source of Truth
  • prevent plugin/UI code from becoming hidden authority
  • prepare clean input for Phase 4 Testing System

This is the Phase 3 execution pack M should follow after Phase 2 is complete and accepted.

Scope

This protocol applies to:

  • mwmsbrain.site Phase 3 build
  • Data Brain measurement planning workflow
  • Experimentation Brain forecast preparation workflow
  • Measurement Planning Interface
  • Forecast Definition Panel
  • Tracking Requirement Definition Layer
  • Decision Trigger Mapping
  • link between Phase 1 intake record, Phase 2 evaluation record, and Phase 3 measurement/forecast record
  • Supabase records where used
  • plugin/UI implementation
  • manual testing
  • safe save points
  • future Experimentation Brain handoff expansion

It defines:

  • required Phase 3 features
  • required Phase 3 fields
  • required measurement logic
  • required forecast logic
  • required decision trigger logic
  • required system behaviour
  • completion criteria
  • what must not be built yet
  • future compatibility requirements
  • safe save point requirements

It does not include:

  • Test Candidate Queue
  • Test Candidate Record Screen
  • Test Execution workflow
  • Ads Brain execution logic
  • Finance controls
  • dashboards
  • automation
  • AI integrations
  • full Brain-to-Brain automation
  • full Experimentation Brain workflow
  • MCR update automation

Core Principle

Phase 3 must turn an evaluated opportunity into a measurable and forecastable test candidate.

The goal is not to run the test.

The goal is to define:

What are we trying to learn, what data do we need, what action will we take, and what performance do we expect?

Phase 3 must answer:

  • What question must this opportunity answer before testing?
  • What information must be collected?
  • What action will be taken based on the result?
  • What performance is expected?
  • What result would count as weak, acceptable, or strong?
  • What decision trigger moves the opportunity forward or stops it?

Phase 3 should remain simple, practical, and expandable.

Phase 3 Build Target

System Name

MWMS Measurement And Forecast Planning System

Components To Build

Phase 3 includes only:

  1. Measurement Planning Queue
  2. Measurement Planning Record Screen
  3. KIA Planning Panel
  4. Tracking Requirement Definition Layer
  5. Forecast Definition Panel
  6. Decision Trigger Mapping
  7. Link To Phase 1 And Phase 2 Records

Do not add additional modules during Phase 3.

Dependency Rule

Phase 3 must not begin until Phase 2 has passed:

MWMS Opportunity System Phase Two Acceptance Checklist

Phase 3 depends on:

  • Phase 1 opportunity records being stable
  • Phase 2 evaluation records being stable
  • evaluation records linking correctly to intake records
  • evaluation decisions working
  • Ready For Measurement Planning status working
  • no data loss
  • no direct MCR update pathway
  • safe save point provided

If Phase 2 is unstable, Phase 3 must wait.

Source Of Truth Rule

MCR remains the Source of Truth.

This build pack gives M permission to build the approved Phase 3 operational surface on mwmsbrain.site.

It does not give permission to:

  • change MCR canon
  • create new MCR rules inside code
  • create direct Brain site to MCR updates
  • build automatic MCR editing
  • create hidden source-of-truth logic inside plugin/UI systems

If M discovers a missing rule, field, workflow, or conflict, M must report it back to Martyn/HeadOffice.

The correct path is:

M identifies issue → HeadOffice review → MCR decision if required

The prohibited path is:

M changes plugin logic → plugin becomes hidden canon

1. Measurement Planning Queue

Required Features

The Measurement Planning Queue must:

  • display Phase 2 evaluation records marked Ready For Measurement Planning
  • show linked Phase 1 opportunity record
  • show linked Phase 2 evaluation record
  • allow opening or creating a measurement/forecast record
  • show current measurement status
  • show current forecast status
  • allow filtering or grouping by measurement status where practical
  • make unplanned records clear

Required Fields In Queue

The queue should show:

  • Product Name
  • Platform
  • Vendor Name
  • Evaluation Status
  • Measurement Status
  • Forecast Status
  • Date Found
  • Last Updated where possible

Optional if easy:

  • Decision
  • Commercial Potential
  • Research Needed
  • Compliance Sensitivity

Required Measurement Status Groups

The queue must support these measurement statuses:

  • Not Started
  • In Planning
  • Measurement Ready
  • Needs More Information
  • Blocked

Required Forecast Status Groups

The queue must support these forecast statuses:

  • Not Started
  • Draft Forecast
  • Forecast Ready
  • Needs More Information
  • Blocked

Required Actions

The queue should support:

  • Open Measurement Record
  • Create Measurement Record From Evaluation Record where needed
  • Change Measurement Status where practical
  • Change Forecast Status where practical

Do not overcomplicate the queue.

The main requirement is that Martyn can find opportunities that are ready for measurement and forecast planning.

2. Measurement Planning Record Screen

Required Purpose

The Measurement Planning Record Screen is where Martyn defines what must be learned before testing.

It should not attempt to become a full testing system, Ads system, Finance system, or dashboard.

It is a practical planning screen.

Required Link To Phase 1 And Phase 2 Records

Each measurement record must connect back to:

Opportunity Intake Record → Offer Evaluation Record → Measurement And Forecast Record

The measurement screen should show or reference:

  • Product Name
  • Product Link
  • Platform
  • Vendor Name
  • Discovery Source
  • Date Found
  • Intake Status
  • Evaluation Status
  • Evaluation Decision
  • Decision Reason
  • Next Step

The Phase 3 record must not become disconnected from Phase 1 or Phase 2.

3. KIA Planning Panel

Required Purpose

The KIA Planning Panel defines the minimum decision logic before any test is created.

KIA means:

Question → Information → Action

This panel ensures MWMS does not collect data without purpose.

Required KIA Fields

Question

  • Primary Test Question
  • Secondary Question if needed
  • Hypothesis
  • What Must Be Learned

Information

  • Required Data
  • Required Event Or Metric
  • Required Tracking Check
  • Required Baseline
  • Data Quality Concern
  • Minimum Useful Signal

Action

  • Decision If Positive
  • Decision If Negative
  • Decision If Inconclusive
  • Stop Condition
  • Progression Condition
  • Retest Condition

Required Behaviour

The KIA panel must:

  • allow incomplete planning records to save
  • preserve all planning fields
  • make the primary question visible
  • make required data visible
  • make intended action visible
  • avoid requiring tracking setup in Phase 3
  • avoid triggering test creation automatically

4. Tracking Requirement Definition Layer

Required Purpose

This layer defines what tracking would be required before testing.

It does not build tracking.

It does not connect Google Ads.

It does not alter GTM.

It does not create conversion actions.

It only records requirements.

Required Tracking Fields

  • Primary Metric
  • Secondary Metric
  • Conversion Event Required
  • Tracking Requirement Notes
  • Existing Tracking Available
  • Tracking Readiness Status
  • Data Source
  • Attribution Concern
  • Measurement Risk Notes

Allowed values for Existing Tracking Available:

  • Yes
  • No
  • Unsure

Allowed values for Tracking Readiness Status:

  • Ready
  • Not Ready
  • Needs Review
  • Unknown

Allowed values for Data Source:

  • Google Ads
  • Google Analytics
  • Supabase
  • Platform Report
  • Manual Review
  • Other
  • Unknown

Required Behaviour

This layer must:

  • store tracking requirements clearly
  • avoid creating tracking automatically
  • identify whether tracking is ready or not
  • allow tracking concerns to be written down
  • support later Data Brain and Ads Brain work

5. Forecast Definition Panel

Required Purpose

The Forecast Definition Panel defines expected performance before testing.

It prevents testing without a performance expectation.

It should not become a statistical engine yet.

It should be a simple planning screen.

Required Forecast Fields

  • Expected Outcome
  • Expected Conversion Rate or Signal Range
  • Minimum Acceptable Result
  • Strong Result Threshold
  • Failure Threshold
  • Test Budget Assumption
  • Test Duration Assumption
  • Expected Traffic Requirement
  • Forecast Confidence
  • Forecast Notes

Allowed values for Forecast Confidence:

  • Low
  • Emerging
  • Moderate
  • Strong
  • Unknown

Required Behaviour

The Forecast Definition Panel must:

  • allow a draft forecast to be saved
  • allow forecast fields to be edited
  • preserve forecast assumptions
  • make thresholds visible
  • avoid launching tests automatically
  • avoid controlling spend
  • avoid creating Finance logic

6. Decision Trigger Mapping

Required Purpose

Decision Trigger Mapping defines what happens after results are compared later.

Phase 3 does not compare results yet.

It only defines the planned decision rules.

Required Decision Trigger Fields

  • If Above Forecast Then
  • If Within Range Then
  • If Below Forecast Then
  • If Inconclusive Then
  • If Tracking Fails Then
  • If Compliance Concern Appears Then
  • Required Review Before Testing
  • Required Review Before Scaling

Allowed values for decision fields may include:

  • Stop
  • Retest
  • Optimize
  • Proceed To Test Setup
  • Request Research
  • Request Tracking Review
  • Request HeadOffice Review
  • Park
  • Reject

Required Behaviour

Decision trigger mapping must:

  • save planned decision rules
  • preserve conditional logic as text or structured values
  • avoid executing the decision automatically
  • prepare for Phase 4 and Phase 5
  • keep decision logic visible before testing starts

7. Link To Phase 1 And Phase 2 Records

Required Behaviour

Phase 3 must preserve the relationship:

Opportunity Intake Record → Offer Evaluation Record → Measurement And Forecast Record

At minimum, the measurement/forecast record should store or reference:

  • opportunity_id
  • evaluation_id
  • product_name
  • platform
  • vendor_name
  • evaluation_status
  • measurement_status
  • forecast_status

If Supabase is used, use stable naming that can later support:

  • opportunity_id
  • evaluation_id
  • measurement_id
  • forecast_id
  • brain_request_id
  • task_id
  • event_id
  • result_id
  • feedback_id

The measurement/forecast record must not become an isolated object.

8. Measurement And Forecast Decision Panel

Required Purpose

The Phase 3 Decision Panel allows Martyn to classify whether the planning record is ready for Phase 4.

It must be simple.

It must not create a test automatically.

Required Decision Actions

Save Draft

Sets:

  • Measurement Status = In Planning
  • Forecast Status = Draft Forecast

Used when planning is incomplete but worth continuing.

Mark Measurement Ready

Sets:

  • Measurement Status = Measurement Ready

Used when the measurement question, data, and action logic are sufficiently clear.

Mark Forecast Ready

Sets:

  • Forecast Status = Forecast Ready

Used when forecast assumptions and thresholds are sufficiently clear.

Needs More Information

Sets:

  • Measurement Status = Needs More Information

Used when planning cannot continue without more detail.

Block Planning

Sets:

  • Measurement Status = Blocked

Used when measurement or forecast planning cannot proceed.

Ready For Test Setup

Sets:

  • Measurement Status = Measurement Ready
  • Forecast Status = Forecast Ready

Used when the record is ready for Phase 4.

This action does not create the Phase 4 test.

It only prepares the pathway.

Required Behaviour

Decision actions must:

  • save reliably
  • update measurement status
  • update forecast status where relevant
  • preserve all record data
  • remain linked to the original opportunity and evaluation records
  • avoid triggering unapproved automation
  • avoid creating automatic MCR updates
  • avoid launching tests

System Behaviour Requirements

The Phase 3 system must:

  • open measurement/forecast records reliably
  • save KIA planning fields correctly
  • preserve the link to Phase 1 and Phase 2 records
  • update measurement status reliably
  • update forecast status reliably
  • display measurement records in the queue
  • support multiple measurement/forecast records
  • allow basic planning decisions
  • avoid confusing screens
  • avoid unnecessary complexity
  • avoid later-phase features

This system should feel like a practical planning tool.

User Flow

Step 1

Martyn opens the Measurement Planning Queue.

Step 2

Martyn selects an opportunity that has passed Phase 2 and is marked Ready For Measurement Planning.

Step 3

Martyn opens or creates a measurement/forecast record.

Step 4

Martyn fills in:

  • Question
  • Information
  • Action
  • Tracking Requirements
  • Forecast Assumptions
  • Decision Triggers

Step 5

Martyn chooses one decision:

  • Save Draft
  • Mark Measurement Ready
  • Mark Forecast Ready
  • Needs More Information
  • Block Planning
  • Ready For Test Setup

Step 6

The measurement and forecast statuses update.

Step 7

The record remains linked to the original intake and evaluation records.

Completion Criteria

Phase 3 is complete when:

  • Phase 2 evaluation records marked Ready For Measurement Planning can be linked to measurement records
  • measurement/forecast records can be created
  • measurement/forecast records can be saved
  • measurement/forecast records appear in the measurement queue
  • measurement/forecast records can be reopened
  • KIA planning fields persist after reload
  • tracking requirement fields persist after reload
  • forecast definition fields persist after reload
  • decision trigger fields persist after reload
  • measurement status updates correctly
  • forecast status updates correctly
  • records remain linked to Phase 1 and Phase 2 records
  • multiple measurement/forecast records work correctly
  • no Phase 4 testing features were added early
  • no testing, Finance, dashboard, automation, AI, or direct MCR update features were added
  • safe save point is provided

Testing Requirements

M must verify:

  • Phase 2 Ready For Measurement Planning records are available for Phase 3
  • measurement/forecast record creation works
  • measurement/forecast record save works
  • measurement/forecast record reopen works
  • measurement queue displays records
  • KIA fields save and persist
  • tracking requirement fields save and persist
  • forecast fields save and persist
  • decision trigger fields save and persist
  • measurement status updates work
  • forecast status updates work
  • multiple measurement/forecast records behave correctly
  • records remain linked to Phase 1 and Phase 2 records
  • no later-phase features were added
  • no direct MCR update pathway exists

Testing should be manual and simple.

Do not build a full testing framework for Phase 3.

What Not To Build

Do not include:

  • Test Candidate Queue
  • Test Candidate Record Screen
  • Test Execution workflow
  • Ads Brain campaign execution
  • Finance logic
  • Dashboards
  • Automation
  • AI integrations
  • Advanced scoring
  • Full Experimentation Brain automation
  • Full Brain Request routing
  • HeadOffice dashboard reporting
  • MCR update automation
  • Sync from Brain site back to MCR
  • Duplicate registries inside mwmsbrain.site

These are later phases.

Phase 3 must stay narrow.

Build Constraints

M must:

  • keep UI simple
  • avoid unnecessary features
  • minimize clicks
  • prioritize clarity
  • avoid premature structure complexity
  • avoid overengineering
  • maintain future expandability
  • preserve MCR authority
  • avoid hidden canon logic in code
  • keep measurement linked to evaluation and intake
  • create a stable third surface before adding future features

Future Compatibility Rule

Even though Phase 3 is simple, the system must allow future expansion.

The system should later be able to connect to:

  • Phase 4 Test Candidate Queue
  • Experimentation Brain test setup
  • Ads Brain execution support
  • Finance Brain review
  • Brain Requests
  • task records
  • event records
  • result records
  • feedback records
  • HeadOffice visibility
  • dashboards

This does not mean building those features now.

It means avoiding hard-coded limitations that would block them later.

Supabase Future Lineage Rule

If Supabase is used in Phase 3, the structure must not block future lineage.

Phase 3 records should be able to later connect to:

  • opportunity_id
  • evaluation_id
  • measurement_id
  • forecast_id
  • brain_request_id
  • task_id
  • event_id
  • result_id
  • feedback_id

Phase 3 does not need to fully implement these relationships.

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

Tasks remain subordinate to future Brain Requests.

Event Logging Preparation

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

Useful future events include:

  • measurement_record_created
  • measurement_record_updated
  • measurement_status_changed
  • forecast_status_changed
  • measurement_ready
  • forecast_ready
  • ready_for_test_setup
  • planning_blocked

If event logging is not wired yet, M should note:

Event logging not yet wired

Do not fake logs.

Do not silently create unusable event records.

Brain Request Preparation

Phase 3 does not require full Brain Request automation.

However, the system should be designed so:

  • Ready For Test Setup can later create an Experimentation Brain Request
  • Tracking Review can later create a Data Brain or Ads Brain request
  • HeadOffice Review can later create a HeadOffice review request

For Phase 3:

  • Ready For Test Setup may only set status to ready
  • Tracking Review may only be recorded as needed
  • Full cross-Brain routing comes later

Do not build Phase 4 or full routing inside Phase 3.

Safe Save Point Requirement

At the end of a meaningful Phase 3 development session, M must provide a safe save point.

The save point should include:

  • what was built
  • what works
  • what does not work yet
  • what files were touched
  • what database tables or fields were touched
  • whether Supabase was changed
  • whether event logging was changed
  • what was tested
  • what still needs testing
  • next recommended step
  • any missing MCR instruction or blocker

This protects continuity.

Blocker Reporting Rule

If M hits uncertainty, M should not guess.

M should report the blocker clearly.

A blocker report should include:

  • what M was trying to build
  • what is unclear
  • what decision is needed
  • whether it affects UI
  • whether it affects Supabase
  • whether it affects MCR
  • whether it affects future phases
  • suggested safe temporary option if one exists

HeadOffice or Martyn then decides.

Dependencies

This build pack is governed by:

  • MWMS Opportunity System Implementation Control Brief
  • MWMS Opportunity System Implementation Brief For M
  • MWMS Opportunity System Build Order
  • MWMS Opportunity System Operating Protocol
  • MWMS Opportunity System Phase Two Acceptance Checklist
  • MWMS Opportunity System Phase Two Developer Build Pack
  • 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 build pack is derived from:

  • Data Brain Measurement Planning Framework
  • Data Brain Event Measurement Framework
  • Data Brain Measurement Integrity Framework
  • Experimentation Brain Forecast Based Optimization Framework
  • Experimentation Brain Experiment Validity Framework
  • Affiliate Brain Offer Intelligence Screen Specification
  • Affiliate Brain To Experimentation Brain Handoff Specification

Controlled Loss Alignment

This phase supports the MWMS Controlled Loss Principle by:

  • preventing testing before measurement logic exists
  • preventing optimization without forecast expectations
  • reducing wasted ad spend
  • clarifying success and failure before exposure
  • defining stop conditions before testing
  • preventing vague “let’s test it” decisions
  • protecting capital from unclear experiments

Governance Role

This document ensures:

  • Phase 3 build is executed correctly
  • development remains focused
  • measurement happens before testing
  • forecasting happens before test execution
  • system integrity is maintained
  • unnecessary complexity is avoided
  • future phases can be layered cleanly
  • MCR remains Source of Truth
  • M’s build lane stays clear
  • mwmsbrain.site becomes more practically useful
  • HeadOffice can later observe measurement and forecast movement

Relationship To Other MWMS Pages

This protocol operates alongside:

  • MWMS Opportunity System Implementation Control Brief
  • MWMS Opportunity System Implementation Brief For M
  • MWMS Opportunity System Build Order
  • MWMS Opportunity System Operating Protocol
  • MWMS Opportunity System Phase Two Developer Build Pack
  • MWMS Opportunity System Phase Two Acceptance Checklist
  • 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
  • Data Brain Measurement Planning Framework
  • Data Brain Event Measurement Framework
  • Data Brain Measurement Integrity Framework
  • Experimentation Brain Forecast Based Optimization Framework
  • Experimentation Brain Experiment Validity Framework

Drift Protection

The system must prevent:

  • building Phase 4 early
  • adding unnecessary features
  • deviating from Phase 3 scope
  • incomplete measurement implementation
  • early introduction of test execution logic
  • early introduction of Finance logic
  • hidden canon logic in code
  • MCR direct updates from Brain site
  • uncontrolled cross-Brain automation
  • disconnected measurement records
  • fake event logs
  • future lineage dead ends
  • measurement records disconnected from evaluation records
  • forecast records disconnected from measurement records
  • testing without forecast expectations
  • testing without KIA logic

Architectural Intent

This build pack ensures MWMS moves from:

evaluating opportunities

to:

planning measurement and forecasting expected outcomes

without jumping too early into testing, Finance, dashboards, or automation.

It provides:

  • measurement clarity
  • KIA planning
  • forecast assumptions
  • decision triggers
  • structured planning state
  • clean link back to intake and evaluation
  • future expansion path

before expansion into test setup.

The architectural intent is:

Define the question before the data. Define the data before the test. Define the forecast before the spend.

Final Rule

Phase 3 is only the Measurement And Forecast Planning System.

Build:

  • Measurement Planning Queue
  • Measurement Planning Record Screen
  • KIA Planning Panel
  • Tracking Requirement Definition Layer
  • Forecast Definition Panel
  • Decision Trigger Mapping
  • Link to Phase 1 and Phase 2 records

Do not build:

  • testing
  • Ads execution
  • Finance
  • dashboards
  • automation
  • AI
  • full cross-Brain routing
  • MCR update automation

Keep it simple, stable, linked, and expandable.

Change Log

v1.0 — 2026-05-12

Initial creation of MWMS Opportunity System Phase Three Developer Build Pack.

Created to define the controlled Phase 3 build after Phase 2 Offer Evaluation acceptance.

Defines:

  • Measurement Planning Queue
  • Measurement Planning Record Screen
  • KIA Planning Panel
  • Tracking Requirement Definition Layer
  • Forecast Definition Panel
  • Decision Trigger Mapping
  • link to Phase 1 and Phase 2 records
  • Phase 3 completion criteria
  • Phase 3 testing requirements
  • what not to build yet
  • Supabase future lineage rule
  • Brain Request preparation rule
  • safe save point requirement
  • blocker reporting rule
  • no direct Brain site to MCR update rule

Change Impact Declaration

Pages Created:
MWMS Opportunity System Phase Three Developer Build Pack

Pages Updated:
None

Pages Deprecated:
None

Registries Requiring Update:
Recommended: HeadOffice Page Registry

Canon Version Update Required:
No

Monthly Change Log Entry Required:
Recommended, because this creates a new developer build pack for Phase 3 of the MWMS Opportunity System.