Document Type: Protocol
Status: Active
Version: v2.0
Authority: HeadOffice
Applies To: Phase 1 build validation for mwmsbrain.site Opportunity Intake System
Parent: HeadOffice Brain
Last Reviewed: 2026-04-25
Purpose
This protocol defines the acceptance criteria for Phase 1 of the MWMS Opportunity System build.
Its purpose is to ensure that:
• the intake system is truly usable
• the system behaves correctly under real use
• development is complete to required standard
• no critical functionality is missing
• the system is ready for real operation
• Phase 1 provides a stable foundation for future system layers
This checklist provides a clear pass/fail standard for Phase 1 completion.
Scope
This protocol applies to:
• Affiliate Brain Intake Queue
• Opportunity Intake Record Screen
• Intake Status System
• basic workflow functionality
It defines:
• required functionality
• usability requirements
• system behavior validation
• acceptance conditions
It does not include:
• evaluation system
• measurement planning
• forecasting
• testing system
• finance controls
• learning system
• dashboards
Core Principle
Phase 1 is complete only when the system is usable without friction.
“Built” is not equal to “usable.”
The system must pass real usage scenarios.
Acceptance Categories
Phase 1 must pass all categories:
• Record Creation
• Data Storage
• Queue Functionality
• Status Management
• Usability
• Stability
1. Record Creation
Requirements
Martyn must be able to:
• create a new opportunity record
• enter all required fields
• save the record successfully
Required Fields
• Product Name
• Product Link
• Platform
• Vendor Name
• Discovery Source
• Date Found
Acceptance Criteria
• form loads correctly
• all required fields are visible
• form submission works
• no errors on valid input
• user is not blocked unnecessarily
2. Data Storage
Requirements
System must:
• store all entered data
• retain data after page refresh
• persist records correctly
Acceptance Criteria
• data remains after saving
• no data loss occurs
• records are retrievable
• data consistency is maintained
3. Queue Functionality
Requirements
System must:
• display all opportunity records
• show records in list format
• group by status
Queue Must Show
• Product Name
• Platform
• Vendor
• Date Found
• Status
Acceptance Criteria
• new records appear immediately
• records display correctly
• grouping works as expected
• multiple records display correctly
4. Status Management
Requirements
User must be able to:
• set status to New
• move to Under Review
• reject opportunity
• escalate opportunity
Acceptance Criteria
• status updates correctly
• status changes persist
• UI reflects new status immediately
• no invalid states exist
5. Usability
Requirements
System must be:
• easy to use
• fast to interact with
• clear in layout
Acceptance Criteria
• form can be completed without confusion
• no unnecessary steps
• minimal clicks required
• navigation is intuitive
• user does not need instructions to operate
6. Stability
Requirements
System must:
• not crash during use
• handle multiple records
• handle repeated usage
Acceptance Criteria
• no system errors
• no broken screens
• consistent behavior across actions
• no data corruption
Functional Test Scenarios
Scenario 1 — Create Record
• create new opportunity
• save
• verify appears in queue
Scenario 2 — Update Status
• change status to Under Review
• verify update in queue
Scenario 3 — Reject Record
• reject opportunity
• verify moved to rejected group
Scenario 4 — Escalate Record
• escalate opportunity
• verify status change
Scenario 5 — Reload System
• refresh page
• confirm all records persist
Scenario 6 — Multiple Records (NEW)
• create multiple opportunities
• verify all display correctly
• verify no duplication or loss
Pass Criteria
Phase 1 is accepted only if:
• all categories pass
• all scenarios pass
• no major usability issues exist
• system is stable under normal use
• system can be used immediately without guidance
Fail Criteria
Phase 1 must be rejected if:
• required fields are missing
• data is not saved correctly
• queue does not display properly
• status changes fail
• system is confusing to use
• system crashes or errors occur
• data is inconsistent or lost
What Is NOT Required For Phase 1
The following must NOT be included:
• Offer Intelligence system
• measurement planning
• forecasting
• testing workflows
• finance controls
• dashboards
• automation
• AI features
These are part of later phases.
Controlled Loss Alignment
This phase supports the MWMS Controlled Loss Principle by:
• ensuring structured opportunity entry
• preventing untracked opportunities
• improving early-stage filtering
• preparing clean input for future testing
Governance Role
This protocol ensures:
• development meets required standard
• system is usable before expansion
• future phases build on a stable foundation
• system progression remains controlled
Relationship To Other MWMS Pages
This protocol operates alongside:
• MWMS Opportunity System Implementation Brief For M
• MWMS Opportunity System Build Order
• Affiliate Brain Offer Intake Form
• Affiliate Brain Opportunity Intake Workflow
• Affiliate Brain Intake Screen Specification
Drift Protection
The system must prevent:
• incomplete builds being accepted
• missing core functionality
• adding future features prematurely
• misalignment with implementation brief
• premature system expansion
Architectural Intent
This checklist ensures MWMS starts with:
👉 a usable foundation
not:
👉 a partially working system
It guarantees that Phase 1 produces a real operational tool.
Change Log
Version: v2.0
Date: 2026-04-25
Author: HeadOffice
Change
Updated Acceptance Checklist to:
• align with updated Opportunity System structure
• improve validation clarity
• add multi-record testing scenario
• reinforce Phase 1 boundaries
• ensure stronger usability and stability validation
Pages Updated
MWMS Opportunity Intake Phase One Acceptance Checklist
Pages Created
None
Registries Requiring Update
None