Document Type: Protocol
Status: Active
Version: v1.0
Authority: HeadOffice
Applies To: Phase 2 build validation for mwmsbrain.site Offer Evaluation System, M’s Phase 2 build work, Martyn’s acceptance review, Supabase evaluation records where used, future Brain Request expansion, and plugin/UI readiness
Parent: HeadOffice Brain
Last Reviewed: 2026-05-12

Purpose

The MWMS Opportunity System Phase Two Acceptance Checklist defines the acceptance criteria for Phase 2 of the MWMS Opportunity System build.

Its purpose is to ensure that the Affiliate Brain Offer Evaluation System is truly usable before Phase 2 is accepted as complete.

Phase 2 must not be marked complete simply because screens exist.

It must prove that:

Offer Intelligence Queue works
evaluation records can be created
evaluation records link back to Phase 1 opportunity records
basic evaluation fields save correctly
evaluation status updates correctly
decision actions work
records can be reopened and edited
data persists after reload
multiple records work correctly
no Phase 3 features were added early
no Brain site to MCR direct update exists
safe save point is provided

This checklist creates the pass/fail standard for accepting Phase 2.

Scope

This protocol applies to:

Offer Intelligence Queue
Offer Intelligence Record Screen
Evaluation Decision Panel
link between Phase 1 opportunity record and Phase 2 evaluation record
basic evaluation workflow
evaluation status handling
Phase 2 manual acceptance testing
future compatibility review
safe save point review
MCR protection check

It defines:

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

It does not include:

Measurement Planning UI
Forecasting
Testing workflows
Finance controls
full Research Brain automation
dashboards
automation
AI integrations
full Brain Request routing
HeadOffice dashboard reporting
MCR update automation

Core Principle

Phase 2 is complete only when the system allows Martyn to evaluate captured opportunities in a structured, usable, and reliable way.

Built is not equal to accepted.

Visible is not equal to working.

Linked once is not equal to lineage safe.

The required Phase 2 outcome is:

Martyn can open an intake opportunity, create or open an evaluation record, complete basic evaluation fields, make a decision, save it, reopen it, and confirm the record remains linked to the original Phase 1 opportunity record.

Source Of Truth Rule

MCR remains the Source of Truth.

The Phase 2 Offer Evaluation System is an operational surface on mwmsbrain.site.

The 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 evaluation records as canon
treat Brain-site data as authority over MCR

If Phase 2 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 2 must pass all categories:

Phase 1 Linkage
Offer Intelligence Queue
Evaluation Record Creation
Evaluation Field Storage
Evaluation Status Management
Decision Actions
Reopen And Edit Behaviour
Multi-Record Behaviour
Usability
Stability
Scope Control
Future Compatibility
Safe Save Point
MCR Protection

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

1. Phase 1 Linkage

Requirements

Each Phase 2 evaluation record must link back to a Phase 1 opportunity intake record.

The system must preserve the relationship:

Opportunity Intake Record → Offer Evaluation Record

Required Linked Data

At minimum, the evaluation record should reference or display:

Product Name
Product Link
Platform
Vendor Name
Discovery Source
Date Found
Intake Status
Evaluation Status

Acceptance Criteria

Pass if:

evaluation record clearly links to the original intake record
intake details are visible or accessible from the evaluation screen
the evaluation record does not become an isolated object
the link remains after save and reload
multiple evaluations do not overwrite or confuse intake record links

Fail if:

evaluation record has no clear source intake record
intake data is lost or disconnected
evaluation records appear without origin context
multiple records link incorrectly
the system cannot tell which intake created the evaluation

2. Offer Intelligence Queue

Requirements

The Offer Intelligence Queue must:

display opportunities ready for evaluation
show linked Phase 1 intake records
allow opening or creating an evaluation record
show current evaluation status
allow filtering or grouping by evaluation status where practical
make unevaluated opportunities clear

Queue Must Show

At minimum, the queue must show:

Product Name
Platform
Vendor Name
Discovery Source
Intake Status
Evaluation Status
Date Found

Optional but useful:

Last Updated
Fits MWMS
Exclusion Flag
Research Needed

Acceptance Criteria

Pass if:

queue loads correctly
records appear in the queue
evaluation status is visible
unevaluated records are identifiable
records can be opened from the queue
multiple records display correctly
queue remains readable and usable

Fail if:

queue does not show records
queue records cannot be opened
evaluation status is missing
intake records and evaluation records are confused
multiple records break the queue
queue layout is unclear or unusable

3. Evaluation Record Creation

Requirements

Martyn must be able to:

create an evaluation record from an intake opportunity
open an existing evaluation record
save the evaluation record
return to the evaluation record later

Acceptance Criteria

Pass if:

evaluation record creation works
evaluation record is linked to intake record
save works without error
record appears in the Offer Intelligence Queue
record can be reopened after save
user is not blocked unnecessarily

Fail if:

evaluation record cannot be created
save fails
record disappears after save
record is not linked to intake
user is blocked by unnecessary required fields
duplicate evaluation records are created accidentally without clear reason

4. Evaluation Field Storage

Requirements

The system must store all Phase 2 evaluation fields.

Required Fields

The evaluation screen must include the core Phase 2 fields.

Identity And Source Fields

Product Name
Product Link
Platform
Vendor Name
Discovery Source
Date Found

Basic Offer Review Fields

Offer Type
Niche / Market
Target Audience
Primary Problem
Main Promise
Payout / Commission Notes
Funnel Type
Sales Page / VSL Link
Notes

Basic Viability Fields

Commercial Potential
Audience Fit
Traffic Fit
Offer Clarity
Compliance Sensitivity
Competition Present
Research Needed
Evaluation Notes

Evaluation Decision Fields

Evaluation Status
Decision
Decision Reason
Next Step
Review Notes

Acceptance Criteria

Pass if:

fields are visible
fields can be edited
fields save correctly
saved fields persist after reload
edited fields update correctly
no entered data disappears

Fail if:

required Phase 2 fields are missing
fields do not save
saved values disappear after reload
editing one field erases another
field values change unexpectedly
data storage is unreliable

5. Evaluation Status Management

Requirements

The system must support the approved Phase 2 evaluation statuses.

Allowed Evaluation Statuses

Not Started
In Review
Rejected
Parked
Research Needed
Ready For Measurement Planning

Acceptance Criteria

Pass if:

evaluation status can be updated
status changes persist
queue reflects updated status
record reflects updated status
no invalid status appears
status always has a value

Fail if:

status does not update
status does not persist
queue and record show different statuses
invalid status appears
status becomes blank
status change causes data loss

6. Decision Actions

Requirements

The Evaluation Decision Panel must support the approved Phase 2 decision actions.

Required Decision Actions

Reject

Sets:

Evaluation Status = Rejected
Decision = Reject

Park

Sets:

Evaluation Status = Parked
Decision = Park

Request Research

Sets:

Evaluation Status = Research Needed
Decision = Request Research

Proceed To Measurement Planning

Sets:

Evaluation Status = Ready For Measurement Planning
Decision = Proceed To Measurement Planning

Needs More Information

Sets:

Evaluation Status = In Review
Decision = Needs More Information

Acceptance Criteria

Pass if:

each decision action works
decision action updates the correct fields
decision reason and notes can be saved
record remains linked to intake
queue reflects decision state
decision action does not trigger unapproved automation
decision action does not directly update MCR

Fail if:

decision actions fail
wrong status is applied
decision does not persist
record data is lost
decision action creates unexpected automation
decision action creates MCR changes
decision action breaks intake/evaluation link

7. Reopen And Edit Behaviour

Requirements

Martyn must be able to reopen and edit saved evaluation records.

Acceptance Criteria

Pass if:

saved evaluation records can be reopened
existing data loads correctly
fields can be edited
edited data saves correctly
edits persist after reload
evaluation decision can be changed if needed

Fail if:

record cannot be reopened
saved data does not load
edits fail
edits do not persist
editing causes data loss
evaluation record becomes disconnected from intake

8. Multi-Record Behaviour

Requirements

The system must support multiple evaluation records.

Acceptance Criteria

Pass if:

multiple intake records can move to evaluation
multiple evaluation records display correctly
each evaluation remains linked to the correct intake
statuses remain correct per record
no record overwrites another
no duplicate confusion occurs during normal use

Fail if:

multiple records break the queue
one evaluation overwrites another
records link to the wrong intake
status updates affect the wrong record
duplicate records appear without clarity
queue becomes unreliable

9. Usability

Requirements

The Phase 2 system must be:

clear
simple
practical
fast enough to use
understandable without developer guidance

Acceptance Criteria

Pass if:

queue is easy to understand
evaluation screen is logically laid out
decision actions are easy to find
link to intake context is clear
user can complete an evaluation without confusion
unnecessary clicks are avoided

Fail if:

screen is confusing
queue is unclear
decision actions are hidden
intake context is unclear
workflow requires too many steps
user needs repeated explanation to operate the system

10. Stability

Requirements

The system must:

not crash during normal use
handle repeated evaluation actions
preserve data under normal use
display consistently
support multiple records

Acceptance Criteria

Pass if:

no system errors occur during normal testing
no broken screens appear
repeated create/edit/save/status changes work
data remains consistent
multiple records behave correctly

Fail if:

system crashes
plugin errors appear
screen breaks
repeated actions fail
data corrupts
normal use creates inconsistent records

11. Scope Control

Requirements

Phase 2 must stay inside the approved build scope.

Phase 2 should include only:

Offer Intelligence Queue
Offer Intelligence Record Screen
Evaluation Decision Panel
Link to Phase 1 opportunity record
Basic Research Needed marker

Acceptance Criteria

Pass if the system does not include:

Measurement Planning UI
Forecasting system
Testing workflows
Finance logic
Dashboards
Automation
AI features
Advanced scoring
Full Research Brain automation
Full Brain Request routing
Automatic MCR updates

Fail if:

Phase 3 features are built early
measurement or forecasting is added early
testing or Finance logic appears early
dashboard or automation is added early
plugin begins making unapproved decisions
scope expands without HeadOffice approval

12. Future Compatibility

Requirements

Even though Phase 2 is simple, it must not block future expansion.

The system should later be able to connect to:

Measurement Planning
Forecasting
Research Brain tasks
Experimentation Brain handoff
Finance Brain review
Brain Requests
task records
event records
result records
feedback records
HeadOffice visibility
dashboards

Acceptance Criteria

Pass if:

evaluation structure can be expanded later
evaluation records can later connect to Brain Requests
Request Research can later create a Research Brain Request
Proceed To Measurement Planning can later connect to Phase 3
records can later link to 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
evaluation statuses cannot be extended
Request Research cannot later connect to Research Brain
Ready For Measurement Planning cannot later connect to Phase 3
database design prevents future lineage

13. Safe Save Point

Requirements

M must provide a safe save point when Phase 2 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

14. MCR Protection

Requirements

The Phase 2 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 — Open Offer Intelligence Queue

Steps:

Open Offer Intelligence Queue.
Confirm intake opportunities appear or can be selected for evaluation.
Confirm evaluation status is visible.

Pass if:

queue loads
records display
evaluation status is visible
records can be opened

Scenario 2 — Create Evaluation Record From Intake

Steps:

Select a Phase 1 intake opportunity.
Create or open an evaluation record.
Confirm intake details are linked or visible.
Save evaluation record.

Pass if:

evaluation record is created
evaluation record saves
evaluation record links to intake
record appears in evaluation queue

Scenario 3 — Save Basic Evaluation Fields

Steps:

Open evaluation record.
Fill in basic offer review fields.
Fill in basic viability fields.
Save.
Reload.

Pass if:

all entered data persists
no field data is lost
record remains linked to intake

Scenario 4 — Reject Evaluation

Steps:

Open evaluation record.
Choose Reject.
Enter decision reason.
Save if needed.
Confirm queue shows Rejected.

Pass if:

Evaluation Status = Rejected
Decision = Reject
decision reason persists
record remains retrievable

Scenario 5 — Park Evaluation

Steps:

Open evaluation record.
Choose Park.
Save if needed.
Confirm queue shows Parked.

Pass if:

Evaluation Status = Parked
Decision = Park
record remains retrievable

Scenario 6 — Request Research

Steps:

Open evaluation record.
Choose Request Research.
Add reason or notes.
Save if needed.
Confirm queue shows Research Needed.

Pass if:

Evaluation Status = Research Needed
Decision = Request Research
notes persist
no unapproved automation triggers
no full Research Brain workflow is created

Scenario 7 — Proceed To Measurement Planning

Steps:

Open evaluation record.
Choose Proceed To Measurement Planning.
Save if needed.
Confirm queue shows Ready For Measurement Planning.

Pass if:

Evaluation Status = Ready For Measurement Planning
Decision = Proceed To Measurement Planning
no Phase 3 screen is required yet
no measurement/forecasting system is built inside Phase 2

Scenario 8 — Needs More Information

Steps:

Open evaluation record.
Choose Needs More Information.
Add review notes.
Save if needed.
Confirm queue shows In Review.

Pass if:

Evaluation Status = In Review
Decision = Needs More Information
notes persist

Scenario 9 — Reopen And Edit Evaluation

Steps:

Open a saved evaluation.
Edit at least two fields.
Save.
Reload and reopen.

Pass if:

edited data persists
no other data is lost
intake link remains intact

Scenario 10 — Multiple Evaluation Records

Steps:

Create or open multiple evaluations from different intake records.
Give them different statuses.
View the queue.
Reopen each record.

Pass if:

all records display correctly
statuses remain correct
each evaluation links to the correct intake
no duplication or loss occurs

Scenario 11 — Scope Boundary Check

Steps:

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

Pass if there is:

no Measurement Planning UI
no Forecasting
no Testing
no Finance logic
no Dashboards
no AI automation
no full cross-Brain routing
no direct MCR update feature

Pass Criteria

Phase 2 is accepted only if:

all acceptance categories pass
all required functional scenarios pass
Offer Intelligence Queue works
evaluation records can be created
evaluation records link to Phase 1 opportunity records
evaluation fields save correctly
evaluation statuses update correctly
decision actions work
records can be reopened and edited
data persists after reload
multiple records work correctly
no Phase 3 features were added early
no measurement, forecasting, testing, Finance, dashboard, automation, AI, or MCR update features were added
no Brain site to MCR direct-update pathway exists
future lineage is not blocked
M provides a safe save point
system can be used immediately without developer guidance

Fail Criteria

Phase 2 must be rejected if:

Offer Intelligence Queue does not work
evaluation records cannot be created
evaluation records do not link back to intake records
basic evaluation fields do not save
evaluation status changes fail
decision actions fail
records cannot be reopened
edited data does not persist
multiple records break the system
later-phase features were added prematurely
measurement/forecasting/testing/Finance/dashboard/automation/AI appears early
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 2

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

Measurement Planning UI
Forecasting
Testing workflows
Finance controls
full Research Brain automation
dashboards
automation
AI integrations
full Brain Request routing
HeadOffice dashboard reporting
MCR update automation

These are later phases.

Do not fail Phase 2 because these are not present.

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

Controlled Loss Alignment

This phase supports the MWMS Controlled Loss Principle by:

preventing weak opportunities from moving too quickly into testing
improving early-stage filtering
reducing wasted research
reducing wasted test spend
creating structured evaluation before measurement and forecasting
allowing poor-fit offers to be rejected or parked early

Governance Role

This protocol ensures:

Phase 2 development meets required standard
Offer Evaluation is usable before expansion
future phases build on a stable foundation
system progression remains controlled
M’s Phase 2 work is judged fairly
Martyn has a clear pass/fail checklist
HeadOffice protects MCR authority
mwmsbrain.site becomes more 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 System Phase Two Developer Build Pack
MWMS Opportunity Intake Phase One Developer Build Pack
MWMS Opportunity Intake Phase One Acceptance Checklist
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
Affiliate Brain Offer Intelligence
Affiliate Brain Offer Intelligence Screen Specification
Affiliate Brain Evaluation Field Schema
Affiliate Brain Opportunity Intake Workflow
Affiliate Brain Offer Intelligence Page Template

Drift Protection

The system must prevent:

incomplete Phase 2 builds being accepted
missing core evaluation functionality
accepting screens that do not save data
accepting records that cannot be reopened
accepting evaluation records that are not linked to intake
accepting queues that do not display correctly
adding future features prematurely
misalignment with Phase 2 Developer Build Pack
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 moves from:

captured opportunities

to:

usable offer evaluation

without prematurely jumping into measurement, forecasting, testing, Finance, dashboards, or automation.

It guarantees that Phase 2 produces a real operational evaluation tool.

The architectural intent is:

Accept only evaluation work that can be used, reopened, trusted, and expanded.

Final Rule

Phase 2 is accepted only when Martyn can use the Offer Evaluation system in real conditions.

The system must:

show evaluation records
create evaluation records
link them to intake records
save evaluation fields
apply decision actions
reopen and edit records
preserve data after reload
support multiple records
avoid later-phase scope drift
protect MCR authority

No direct MCR update pathway is allowed.

M must provide a safe save point.

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

Change Log

v1.0 — 2026-05-12

Initial creation of MWMS Opportunity System Phase Two Acceptance Checklist.

Created to define pass/fail criteria for Phase 2 of the MWMS Opportunity System.

Defines:

Phase 1 linkage checks
Offer Intelligence Queue acceptance criteria
Evaluation Record creation criteria
Evaluation Field Storage criteria
Evaluation Status Management criteria
Decision Actions criteria
Reopen And Edit behaviour
Multi-Record behaviour
Scope Control
Future Compatibility
Safe Save Point
MCR Protection
Functional Test Scenarios
Pass/Fail criteria

Change Impact Declaration

Pages Created:
MWMS Opportunity System Phase Two Acceptance Checklist

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 acceptance checklist for Phase 2 of the MWMS Opportunity System.