Document Type: Protocol
Status: Active
Version: v2.1
Authority: HeadOffice
Applies To: Phase 1 build validation for mwmsbrain.site Opportunity Intake System, M’s Phase 1 build work, Martyn’s acceptance review, Supabase intake records where used, and future plugin/UI expansion readiness
Parent: HeadOffice Brain
Last Reviewed: 2026-05-11

Purpose

The MWMS Opportunity Intake Phase One Acceptance Checklist 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
M does not mark the build complete before the working system is actually usable
no hidden later-phase functionality has been added
no Brain site to MCR direct-update pathway exists
future Supabase lineage is not blocked

This checklist provides a clear pass/fail standard for Phase 1 completion.

The previous version already defined the core acceptance categories as Record Creation, Data Storage, Queue Functionality, Status Management, Usability, and Stability, with test scenarios for creating records, updating status, rejecting, escalating, reloading, and testing multiple records.

Scope

This protocol applies to:

Affiliate Brain Intake Queue
Opportunity Intake Record Screen
Intake Status System
basic workflow functionality
mwmsbrain.site Phase 1 intake operation
Phase 1 manual acceptance testing
safe save point review
future compatibility review

It defines:

required functionality
usability requirements
system behaviour validation
acceptance conditions
fail conditions
what must not be included
no-MCR-direct-update checks
future lineage readiness checks

It does not include:

Offer Intelligence system
Measurement Planning
Forecasting
Testing system
Finance controls
Research signal system
Learning system
Dashboards
Automation
AI integrations
full Brain Request automation

Core Principle

Phase 1 is complete only when the system is usable without friction.

Built is not equal to usable.

Visible is not equal to working.

Saved once is not equal to stable.

The system must pass real usage scenarios.

The required Phase 1 outcome is:

Martyn can create, save, reopen, edit, view, reject, escalate, and manage basic opportunity records on mwmsbrain.site without confusion or data loss.

Source Of Truth Rule

MCR remains the Source of Truth.

The Phase 1 intake system is an operational surface on mwmsbrain.site.

The intake system must not:

update MCR directly
create MCR pages automatically
rewrite canon
alter governance rules
create hidden source-of-truth logic inside plugin code
treat Supabase records as canon
treat Brain-site data as authority over MCR

If the Phase 1 system reveals that an MCR page, field, workflow, or rule needs improvement, that must be routed to HeadOffice for review.

The approved path is:

Operational Feedback → HeadOffice Review → MCR Decision

The prohibited path is:

mwmsbrain.site → Direct MCR Update

Acceptance Categories

Phase 1 must pass all categories:

Record Creation
Data Storage
Queue Functionality
Status Management
Usability
Stability
Scope Control
Future Compatibility
Safe Save Point
MCR Protection

If any required category fails, Phase 1 is not accepted.

1. Record Creation

Requirements

Martyn must be able to:

create a new opportunity record
enter all required Phase 1 fields
save the record successfully
return to the record after saving

Required Fields

The record screen must include:

Product Name
Product Link
Platform
Vendor Name
Discovery Source
Date Found
Competitors Found
Ads Found
Notes
Fits MWMS
Exclusion Flag
Status
Review Notes

Acceptance Criteria

Pass if:

form loads correctly
all required Phase 1 fields are visible
form submission works
valid input saves without error
user is not blocked unnecessarily
incomplete opportunity data can still be saved
default status is applied if needed
record can be reopened after creation

Fail if:

form does not load
required fields are missing
save fails
record disappears after save
fields are blocked unnecessarily
user cannot create a usable record

2. Data Storage

Requirements

The system must:

store all entered data
retain data after page refresh
persist records correctly
allow saved records to be reopened
allow saved records to be edited

Acceptance Criteria

Pass if:

data remains after saving
data remains after page refresh
records are retrievable
edited data is saved correctly
no entered fields disappear
data consistency is maintained

Fail if:

data is lost
records cannot be retrieved
edited fields do not save
refresh causes data loss
record values change unexpectedly
database storage is unreliable

3. Queue Functionality

Requirements

The system must:

display all opportunity records
show records in list format
allow records to be opened
show current record status
support multiple records
support status grouping or filtering

Queue Must Show

At minimum, the queue must show:

Product Name
Platform
Vendor Name
Date Found
Status

Optional but useful:

Discovery Source
Last Updated

Acceptance Criteria

Pass if:

new records appear in the queue
records display correctly
record list is readable
multiple records display correctly
records can be opened from the queue
status is visible
grouping or filtering by status works if implemented

Fail if:

new records do not appear
queue is blank despite saved records
records cannot be opened
multiple records break the display
status is missing or incorrect
queue layout is confusing or unusable

4. Status Management

Requirements

User must be able to:

set status to New
move status to Under Review
reject opportunity
escalate opportunity

Allowed Statuses

The only required Phase 1 statuses are:

New
Under Review
Rejected
Escalated

Acceptance Criteria

Pass if:

status updates correctly
status changes persist
UI reflects new status after save/action
no invalid status is created
status always has a value
status changes do not erase record data

Fail if:

status does not update
status update does not persist
UI shows old status after change
invalid status appears
status becomes blank
changing status loses field data

5. Usability

Requirements

The system must be:

easy to use
fast to interact with
clear in layout
low-friction
understandable without special instructions

Acceptance Criteria

Pass if:

form can be completed without confusion
queue is easy to understand
navigation is intuitive
minimal clicks are required
status actions are obvious
user can operate the system without needing developer guidance

Fail if:

form is confusing
queue is unclear
too many unnecessary steps exist
status actions are hard to find
user needs repeated instruction to operate basic workflow
UI feels like a developer test page rather than a usable tool

6. Stability

Requirements

The system must:

not crash during use
handle multiple records
handle repeated usage
preserve data under normal actions
display screens consistently

Acceptance Criteria

Pass if:

no system errors occur during normal testing
no broken screens appear
behaviour is consistent across actions
no data corruption occurs
multiple records behave correctly
repeated create/edit/status changes work

Fail if:

system crashes
screen breaks
records duplicate incorrectly
data corrupts
repeated actions fail
plugin errors appear during normal use

7. Scope Control

Requirements

Phase 1 must stay inside the approved build scope.

Phase 1 should include only:

Opportunity Intake Queue
Opportunity Intake Record
Status Management System

Acceptance Criteria

Pass if the system does not include:

Offer Intelligence system
Measurement Planning UI
Forecasting system
Testing workflows
Finance logic
Research Brain signal systems
Dashboards
Automation
AI features
Advanced scoring
Cross-Brain linking
Automatic MCR updates
Full Brain Request automation

Fail if:

M builds later-phase features early
extra systems create confusion
plugin begins making unapproved decisions
workflow expands beyond Phase 1 without HeadOffice approval

8. Future Compatibility

Requirements

Even though Phase 1 is simple, it must not block later expansion.

The system should be capable of later connecting to:

offer evaluation
Research Brain requests
Experimentation Brain handoff
Finance Brain review
Brain Requests
task records
event records
result records
feedback records
HeadOffice visibility
dashboards

Acceptance Criteria

Pass if:

record structure can be expanded later
statuses can be extended later if approved
escalation can later become a Brain Request
records can later link to request/task/event/result objects
no obvious hard-coded dead end blocks future phases

Fail if:

system is built as a dead end
fields cannot be expanded
status logic cannot be extended
escalation cannot later connect to Brain Requests
database design prevents future lineage

9. Safe Save Point

Requirements

M must provide a safe save point when Phase 1 is ready for review.

The safe save point must 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

Acceptance Criteria

Pass if:

safe save point is clear
touched files are identified
database changes are identified
current working state is clear
remaining gaps are declared
next step is understandable

Fail if:

M says “done” without a save point
changed files are unknown
database changes are unclear
unresolved issues are hidden
next step is not clear

10. MCR Protection

Requirements

The Phase 1 system must not directly update MCR.

The system must not:

write to MCR pages
edit MCR pages
sync Brain-site content back to MCR
create canon automatically
create governance rules in plugin code
treat operational records as MCR authority

Acceptance Criteria

Pass if:

no direct MCR update pathway exists
no automatic MCR editing exists
operational feedback remains separate
HeadOffice review is required for any MCR change
plugin code remains execution logic only

Fail if:

Brain site can update MCR directly
plugin writes canon content
Supabase triggers MCR edits
operational feedback automatically changes MCR
MCR authority is bypassed

Functional Test Scenarios

Scenario 1 — Create Record

Steps:

Create new opportunity.
Enter basic fields.
Save.
Verify record appears in queue.

Pass if:

record saves
record appears in queue
data is correct

Scenario 2 — Reopen And Edit Record

Steps:

Open saved record from queue.
Edit at least two fields.
Save.
Reopen again.

Pass if:

edited data persists
no other data is lost

Scenario 3 — Update Status To Under Review

Steps:

Open an opportunity.
Change status to Under Review.
Save.
Verify update in queue.

Pass if:

status changes correctly
queue reflects the change

Scenario 4 — Reject Record

Steps:

Open an opportunity.
Click or select Reject.
Save if needed.
Verify status is Rejected.
Verify it appears under Rejected grouping/filter where applicable.

Pass if:

status is Rejected
record data remains intact

Scenario 5 — Escalate Record

Steps:

Open an opportunity.
Click or select Escalate.
Save if needed.
Verify status is Escalated.

Pass if:

status changes to Escalated
record data remains intact
escalation does not trigger unapproved automation

Scenario 6 — Reload System

Steps:

Create or edit record.
Refresh page.
Reopen record.
Check all fields.

Pass if:

all data persists
status persists
queue still displays correctly

Scenario 7 — Multiple Records

Steps:

Create multiple opportunities.
Give them different statuses.
View queue.
Open each record.

Pass if:

all records display correctly
statuses remain correct
no duplication or loss occurs
each record opens correctly

Scenario 8 — Scope Boundary Check

Steps:

Review available screens and features.
Confirm no later-phase modules were added.

Pass if:

no Offer Intelligence
no Measurement Planning
no Forecasting
no Testing
no Finance
no Dashboards
no AI automation
no direct MCR update feature

Pass Criteria

Phase 1 is accepted only if:

all acceptance categories pass
all required functional scenarios pass
no major usability issues exist
system is stable under normal use
records can be created, saved, reopened, edited, and listed
statuses can be changed and persisted
data survives reload
multiple records work correctly
no later-phase features were added
no MCR direct-update pathway exists
future lineage is not blocked
M provides a safe save point
system can be used immediately without guidance

Fail Criteria

Phase 1 must be rejected if:

required fields are missing
records cannot be created
data is not saved correctly
queue does not display properly
records cannot be reopened
status changes fail
status changes do not persist
data is inconsistent or lost
system is confusing to use
system crashes or errors occur
multiple records break the system
later-phase features were added prematurely
plugin/UI creates hidden authority
Brain site can directly update MCR
Supabase structure blocks future lineage
no safe save point is provided

What Is Not Required For Phase 1

The following are not required and must not be treated as Phase 1 acceptance requirements:

Offer Intelligence system
Measurement Planning
Forecasting
Testing workflows
Finance controls
Research signal systems
Learning system
Dashboards
Automation
AI features
full Brain Request routing
HeadOffice dashboard
MCR update automation

These are later phases.

Do not fail Phase 1 because these are not present.

Do fail Phase 1 if these were built prematurely and caused scope drift.

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
reducing random opportunity decisions
creating usable records before money or time is spent on deeper 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
M’s Phase 1 work is judged fairly
Martyn has a clear pass/fail checklist
HeadOffice protects MCR authority
mwmsbrain.site becomes useful without becoming a Source of Truth

Relationship To Other MWMS Pages

This protocol operates alongside:

MWMS Opportunity System Implementation Control Brief
MWMS Opportunity System Implementation Brief For M
MWMS Opportunity Intake Phase One Developer Build Pack
MWMS Opportunity System Build Order
MWMS Opportunity System Operating Protocol
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
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
fake completion
accepting screens that do not save data
accepting records that cannot be reopened
accepting queues that do not display correctly
adding future features prematurely
misalignment with implementation brief
premature system expansion
direct Brain site to MCR updates
plugin/UI becoming hidden authority
Supabase records blocking future lineage
no-save-point developer handoffs

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.

The architectural intent is:

Accept only what works. Reject what only looks built.

Final Rule

Phase 1 is accepted only when Martyn can use the system in real conditions.

The system must create, save, reopen, edit, list, reject, and escalate opportunity records reliably.

No later-phase features are required.

No direct MCR update pathway is allowed.

M must provide a safe save point.

If the system is not usable, Phase 1 is not complete.

Change Log

v2.0 — 2026-04-25

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

v2.1 — 2026-05-11

Updated checklist to align with:

MWMS Opportunity System Implementation Control Brief
MWMS Opportunity System Implementation Brief For M
MWMS Opportunity Intake Phase One Developer Build Pack
MWMS Opportunity System Operating Protocol
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
MCR Protection acceptance category
Future Compatibility acceptance category
Safe Save Point acceptance category
Scope Control acceptance category
Reopen And Edit Record scenario
Scope Boundary Check scenario
stronger pass/fail criteria
no direct Brain site to MCR update rule
no hidden plugin/UI authority rule

Change Impact Declaration

Pages Updated:
MWMS Opportunity Intake Phase One Acceptance Checklist

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 acceptance checklist update recorded in the current MWMS System Change Log.