MWMS Opportunity Intake Phase One Developer Build Pack

Document Type: Protocol
Status: Active
Version: v2.0
Authority: HeadOffice
Applies To: M (developer), mwmsbrain.site Phase 1 build execution
Parent: HeadOffice Brain
Last Reviewed: 2026-04-25


Purpose

This document consolidates all requirements for Phase 1 of the MWMS Opportunity System into a single developer-ready build pack.

Its purpose is to:

• provide a single source of truth for Phase 1 implementation
• eliminate the need to reference multiple pages during build
• define exactly what must be built
• define what must not be built
• define completion criteria
• ensure Phase 1 supports future system expansion

This is the execution pack M should follow during development.


Scope

This protocol applies to:

• Affiliate Brain Intake System
• mwmsbrain.site Phase 1 build
• UI and workflow implementation

It defines:

• required features
• required fields
• required actions
• system behavior
• completion requirements

It does not include:

• evaluation system
• measurement planning
• forecasting
• testing system
• finance controls
• research signal system
• dashboards


Core Principle

Build a simple, usable intake system.

Do not build beyond Phase 1 requirements.

Speed and usability are prioritized over completeness.


Phase 1 Build Target

System Name

Affiliate Brain Opportunity Intake System


Components To Build

• Opportunity Intake Queue
• Opportunity Intake Record
• Status Management System


1. Opportunity Intake Queue


Required Features

• display all opportunity records
• group records by status
• allow record selection


Required Fields In Queue

• Product Name
• Platform
• Vendor Name
• Date Found
• Status


Required Status Groups

• New
• Under Review
• Rejected
• Escalated


Required Actions

• Open Record
• Change Status


2. Opportunity Intake Record


Required Fields

Identity

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


Basic Research

• Competitors Found (Yes / No)
• Ads Found (Yes / No)
• Notes


Fit

• Fits MWMS (Yes / No)
• Exclusion Flag


Workflow

• Status
• Review Notes


Required Behavior

• all fields must be editable
• form must save correctly
• data must persist
• no required field may block save (use flexible input)


3. Status Management System


Allowed Statuses

• New
• Under Review
• Rejected
• Escalated


Required Actions

Reject
→ sets status to Rejected

Under Review
→ sets status to Under Review

Escalate
→ sets status to Escalated


Behavior Requirements

• status changes must persist
• UI must update immediately
• no invalid states allowed
• status must always have a value


System Behavior Requirements

The system must:

• save records reliably
• display records immediately after creation
• update status in real time
• persist data after refresh
• handle multiple records
• allow fast data entry


User Flow


Step 1

Martyn creates a new opportunity


Step 2

Martyn fills in basic fields


Step 3

Martyn saves the record


Step 4

Record appears in queue


Step 5

Martyn reviews and sets status


Completion Criteria


Phase 1 is complete when:

• records can be created
• records can be saved
• records appear in queue
• statuses can be changed
• data persists
• system is usable without confusion
• no UI errors exist


Testing Requirements

M must verify:

• record creation works
• status updates work
• queue updates correctly
• data persists after reload
• no UI errors exist
• multiple records behave correctly


What Not To Build

Do NOT include:

• Offer Intelligence
• Measurement Planning UI
• Forecasting systems
• testing workflows
• finance logic
• dashboards
• automation
• AI integrations
• advanced scoring
• cross-brain linking


Build Constraints

M must:

• keep UI simple
• avoid unnecessary features
• minimize clicks
• prioritize clarity
• avoid premature structure complexity


Future Compatibility Rule (NEW)

Even though Phase 1 is simple, the system must:

• allow additional fields later
• allow linking to future systems
• allow expansion of status logic
• avoid hard-coded limitations

This ensures Phase 2+ can be added without rebuild.


Dependencies

Derived from:

• MWMS Opportunity System Build Order
• MWMS Opportunity System Implementation Brief For M
• MWMS Opportunity Intake Phase One Acceptance Checklist
• Affiliate Brain Offer Intake Form
• Affiliate Brain Opportunity Intake Workflow
• Affiliate Brain Intake Screen Specification


Controlled Loss Alignment

This phase supports the MWMS Controlled Loss Principle by:

• enforcing structured opportunity entry
• enabling early filtering
• preventing untracked decisions
• preparing clean input for future testing


Governance Role

This document ensures:

• Phase 1 build is executed correctly
• development is focused
• system integrity is maintained
• unnecessary complexity is avoided
• future phases can be layered cleanly


Drift Protection

The system must prevent:

• overbuilding
• adding future features
• deviating from scope
• incomplete implementation
• early introduction of measurement or testing logic


Architectural Intent

This build pack ensures MWMS begins with:

👉 a working intake system

It provides:

• real usage
• real data
• real feedback

before expansion into later phases.


Change Log

Version: v2.0
Date: 2026-04-25
Author: HeadOffice


Change

Updated Build Pack to:

• align with updated Opportunity System Flow
• clarify Phase 1 boundaries
• prevent early measurement and forecasting implementation
• add future compatibility rule
• improve developer clarity and constraints


Pages Updated

MWMS Opportunity Intake Phase One Developer Build Pack


Pages Created

None


Registries Requiring Update

None


End of Protocol