Document Type: Protocol
Status: Active
Version: v1.0
Authority: HeadOffice
Applies To: Phase 3 build validation for mwmsbrain.site Measurement And Forecast Planning System, M’s Phase 3 build work, Martyn’s acceptance review, Data Brain measurement workflow, Experimentation Brain forecast workflow, Supabase measurement and forecast 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 Three Acceptance Checklist defines the acceptance criteria for Phase 3 of the MWMS Opportunity System build.

Its purpose is to ensure that the Measurement And Forecast Planning System is truly usable before Phase 3 is accepted as complete.

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

It must prove that:

Measurement Planning Queue works
measurement and forecast records can be created
records link back to Phase 1 intake and Phase 2 evaluation records
KIA fields save correctly
tracking requirement fields save correctly
forecast fields save correctly
decision trigger fields save correctly
measurement status updates correctly
forecast status updates correctly
records can be reopened and edited
data persists after reload
multiple records work correctly
no Phase 4 testing 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 3.

Scope

This protocol applies to:

Measurement Planning Queue
Measurement Planning Record Screen
KIA Planning Panel
Tracking Requirement Definition Layer
Forecast Definition Panel
Decision Trigger Mapping
link between Phase 1 opportunity record, Phase 2 evaluation record, and Phase 3 measurement/forecast record
measurement status handling
forecast status handling
Phase 3 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:

Test Candidate Queue
Test Candidate Record Screen
Test Execution workflow
Ads Brain execution logic
Finance controls
dashboards
automation
AI integrations
full Brain Request routing
HeadOffice dashboard reporting
MCR update automation

Core Principle

Phase 3 is complete only when the system allows Martyn to define measurement logic and forecast expectations in a structured, usable, and reliable way.

Built is not equal to accepted.

Visible is not equal to working.

Forecast fields existing is not equal to forecast readiness.

The required Phase 3 outcome is:

Martyn can open a Phase 2 evaluation marked Ready For Measurement Planning, create or open a measurement/forecast record, complete KIA planning, define tracking requirements, define forecast assumptions, map decision triggers, save the record, reopen it, and confirm the record remains linked to the original Phase 1 intake and Phase 2 evaluation records.

Source Of Truth Rule

MCR remains the Source of Truth.

The Phase 3 Measurement And Forecast Planning 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 measurement or forecast records as canon
treat Brain-site data as authority over MCR

If Phase 3 reveals that an MCR page, field, workflow, forecast rule, measurement rule, or operating standard 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 3 must pass all categories:

Phase 1 And Phase 2 Linkage
Measurement Planning Queue
Measurement And Forecast Record Creation
KIA Field Storage
Tracking Requirement Field Storage
Forecast Field Storage
Decision Trigger Mapping
Measurement Status Management
Forecast Status Management
Reopen And Edit Behaviour
Multi-Record Behaviour
Usability
Stability
Scope Control
Future Compatibility
Safe Save Point
MCR Protection

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

1. Phase 1 And Phase 2 Linkage

Requirements

Each Phase 3 measurement/forecast record must link back to:

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

The system must preserve the relationship between the original opportunity, its evaluation, and its measurement/forecast planning record.

Required Linked Data

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

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

Acceptance Criteria

Pass if:

measurement/forecast record clearly links to the original intake record
measurement/forecast record clearly links to the original evaluation record
intake and evaluation details are visible or accessible from the Phase 3 screen
the Phase 3 record does not become an isolated object
the link remains after save and reload
multiple measurement records do not overwrite or confuse Phase 1 or Phase 2 links

Fail if:

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

2. Measurement Planning Queue

Requirements

The Measurement Planning Queue must:

display Phase 2 evaluation records marked Ready For Measurement Planning
show linked Phase 1 intake records
show linked Phase 2 evaluation records
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

Queue Must Show

At minimum, the queue must show:

Product Name
Platform
Vendor Name
Evaluation Status
Measurement Status
Forecast Status
Date Found

Optional but useful:

Last Updated
Evaluation Decision
Commercial Potential
Research Needed
Compliance Sensitivity

Acceptance Criteria

Pass if:

queue loads correctly
records appear in the queue
measurement status is visible
forecast status is visible
unplanned 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
measurement status is missing
forecast status is missing
intake, evaluation, and measurement records are confused
multiple records break the queue
queue layout is unclear or unusable

3. Measurement And Forecast Record Creation

Requirements

Martyn must be able to:

create a measurement/forecast record from a Phase 2 evaluation record
open an existing measurement/forecast record
save the measurement/forecast record
return to the measurement/forecast record later

Acceptance Criteria

Pass if:

measurement/forecast record creation works
measurement/forecast record is linked to Phase 1 intake
measurement/forecast record is linked to Phase 2 evaluation
save works without error
record appears in the Measurement Planning Queue
record can be reopened after save
user is not blocked unnecessarily

Fail if:

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

4. KIA Field Storage

Requirements

The KIA Planning Panel must save and preserve:

Question → Information → Action

Required KIA Fields

Question Fields

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

Information Fields

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

Action Fields

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

Acceptance Criteria

Pass if:

KIA fields are visible
KIA fields can be edited
KIA fields save correctly
saved KIA fields persist after reload
edited KIA fields update correctly
no entered KIA data disappears
the primary question remains visible and easy to find

Fail if:

required KIA fields are missing
KIA fields do not save
KIA values disappear after reload
editing one KIA field erases another
field values change unexpectedly
KIA logic is unclear or unusable

5. Tracking Requirement Field Storage

Requirements

The Tracking Requirement Definition Layer must record tracking requirements without actually building tracking.

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

Acceptance Criteria

Pass if:

tracking requirement fields are visible
tracking requirement fields can be edited
tracking requirement fields save correctly
saved tracking fields persist after reload
tracking readiness can be recorded
measurement risk notes can be saved
system does not create tracking automatically

Fail if:

required tracking fields are missing
tracking fields do not save
tracking values disappear after reload
tracking readiness cannot be recorded
the system tries to build or modify tracking automatically
the system changes Google Ads, GTM, GA4, or conversion actions during Phase 3

6. Forecast Field Storage

Requirements

The Forecast Definition Panel must save forecast assumptions and thresholds.

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

Acceptance Criteria

Pass if:

forecast fields are visible
forecast fields can be edited
forecast fields save correctly
forecast assumptions persist after reload
forecast thresholds remain visible
forecast confidence can be recorded
no spend or Finance logic is triggered

Fail if:

required forecast fields are missing
forecast fields do not save
forecast values disappear after reload
thresholds are unclear
forecast confidence cannot be recorded
the system attempts to control budget or spend
Finance logic appears inside Phase 3

7. Decision Trigger Mapping

Requirements

Decision Trigger Mapping must save planned decision rules for later result interpretation.

Phase 3 does not compare results yet.

Phase 3 only defines 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

Acceptance Criteria

Pass if:

decision trigger fields are visible
decision trigger fields can be edited
decision trigger fields save correctly
saved decision triggers persist after reload
planned decision rules remain visible
decision rules do not execute automatically
no Phase 4 test is created automatically

Fail if:

decision trigger fields are missing
decision triggers do not save
decision trigger values disappear after reload
decision triggers execute automatically
a test is created automatically
status or workflow moves forward without user action

8. Measurement Status Management

Requirements

The system must support the approved Phase 3 measurement statuses.

Allowed Measurement Statuses

Not Started
In Planning
Measurement Ready
Needs More Information
Blocked

Acceptance Criteria

Pass if:

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

Fail if:

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

9. Forecast Status Management

Requirements

The system must support the approved Phase 3 forecast statuses.

Allowed Forecast Statuses

Not Started
Draft Forecast
Forecast Ready
Needs More Information
Blocked

Acceptance Criteria

Pass if:

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

Fail if:

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

10. Reopen And Edit Behaviour

Requirements

Martyn must be able to reopen and edit saved measurement/forecast records.

Acceptance Criteria

Pass if:

saved measurement/forecast records can be reopened
existing data loads correctly
fields can be edited
edited data saves correctly
edits persist after reload
measurement status can be changed if needed
forecast status can be changed if needed
links to Phase 1 and Phase 2 remain intact

Fail if:

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

11. Multi-Record Behaviour

Requirements

The system must support multiple measurement/forecast records.

Acceptance Criteria

Pass if:

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

Fail if:

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

12. Usability

Requirements

The Phase 3 system must be:

clear
simple
practical
fast enough to use
understandable without developer guidance

Acceptance Criteria

Pass if:

queue is easy to understand
measurement/forecast screen is logically laid out
KIA structure is easy to follow
tracking requirements are easy to record
forecast assumptions are easy to record
decision triggers are easy to find
link to intake and evaluation context is clear
user can complete a measurement/forecast plan without confusion
unnecessary clicks are avoided

Fail if:

screen is confusing
queue is unclear
KIA structure is hard to understand
forecast fields are hard to find
decision trigger fields are hidden
intake or evaluation context is unclear
workflow requires too many steps
user needs repeated explanation to operate the system

13. Stability

Requirements

The system must:

not crash during normal use
handle repeated measurement/forecast 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

14. Scope Control

Requirements

Phase 3 must stay inside the approved build scope.

Phase 3 should include only:

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

Acceptance Criteria

Pass if the system does not include:

Test Candidate Queue
Test Candidate Record Screen
Test Execution workflow
Ads Brain execution logic
Finance logic
Dashboards
Automation
AI features
Full Experimentation Brain automation
Full Brain Request routing
Automatic MCR updates

Fail if:

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

15. Future Compatibility

Requirements

Even though Phase 3 is simple, it must not block 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

Acceptance Criteria

Pass if:

measurement structure can be expanded later
forecast structure can be expanded later
measurement/forecast records can later connect to Brain Requests
Ready For Test Setup can later create an Experimentation Brain Request
Tracking Review can later create a Data Brain or Ads Brain request
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
measurement statuses cannot be extended
forecast statuses cannot be extended
Ready For Test Setup cannot later connect to Phase 4
database design prevents future lineage

16. Safe Save Point

Requirements

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

17. MCR Protection

Requirements

The Phase 3 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 Measurement Planning Queue

Steps:

Open Measurement Planning Queue.
Confirm Phase 2 records marked Ready For Measurement Planning appear or can be selected.
Confirm measurement status is visible.
Confirm forecast status is visible.

Pass if:

queue loads
records display
measurement status is visible
forecast status is visible
records can be opened

Scenario 2 — Create Measurement And Forecast Record From Evaluation

Steps:

Select a Phase 2 evaluation record marked Ready For Measurement Planning.
Create or open a measurement/forecast record.
Confirm intake and evaluation details are linked or visible.
Save measurement/forecast record.

Pass if:

measurement/forecast record is created
record saves
record links to intake
record links to evaluation
record appears in measurement queue

Scenario 3 — Save KIA Fields

Steps:

Open measurement/forecast record.
Fill in Question fields.
Fill in Information fields.
Fill in Action fields.
Save.
Reload.

Pass if:

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

Scenario 4 — Save Tracking Requirement Fields

Steps:

Open measurement/forecast record.
Fill in tracking requirement fields.
Save.
Reload.

Pass if:

all entered tracking requirement data persists
tracking readiness status persists
no tracking is created or changed automatically

Scenario 5 — Save Forecast Fields

Steps:

Open measurement/forecast record.
Fill in forecast fields.
Save.
Reload.

Pass if:

all entered forecast data persists
thresholds remain visible
forecast confidence persists
no budget, Finance, or test execution logic triggers

Scenario 6 — Save Decision Trigger Mapping

Steps:

Open measurement/forecast record.
Fill in decision trigger fields.
Save.
Reload.

Pass if:

all decision trigger fields persist
decision logic remains visible
no automatic action is triggered
no test is created

Scenario 7 — Mark Measurement Ready

Steps:

Open measurement/forecast record.
Choose Mark Measurement Ready.
Save if needed.
Confirm queue shows Measurement Ready.

Pass if:

Measurement Status = Measurement Ready
status persists after reload
record data remains intact

Scenario 8 — Mark Forecast Ready

Steps:

Open measurement/forecast record.
Choose Mark Forecast Ready.
Save if needed.
Confirm queue shows Forecast Ready.

Pass if:

Forecast Status = Forecast Ready
status persists after reload
record data remains intact

Scenario 9 — Ready For Test Setup

Steps:

Open measurement/forecast record.
Choose Ready For Test Setup.
Save if needed.
Confirm measurement and forecast statuses show ready.

Pass if:

Measurement Status = Measurement Ready
Forecast Status = Forecast Ready
no Phase 4 test is created automatically
no Ads execution is triggered
no Finance logic is triggered

Scenario 10 — Needs More Information

Steps:

Open measurement/forecast record.
Choose Needs More Information.
Add notes.
Save if needed.
Confirm queue reflects Needs More Information.

Pass if:

status updates correctly
notes persist
record remains retrievable

Scenario 11 — Block Planning

Steps:

Open measurement/forecast record.
Choose Block Planning.
Add blocker reason.
Save if needed.
Confirm queue reflects Blocked.

Pass if:

status updates correctly
blocker notes persist
record remains retrievable

Scenario 12 — Reopen And Edit Measurement Forecast Record

Steps:

Open a saved measurement/forecast record.
Edit at least two fields.
Save.
Reload and reopen.

Pass if:

edited data persists
no other data is lost
intake and evaluation links remain intact

Scenario 13 — Multiple Measurement Forecast Records

Steps:

Create or open multiple measurement/forecast records from different evaluation records.
Give them different measurement and forecast statuses.
View the queue.
Reopen each record.

Pass if:

all records display correctly
statuses remain correct
each measurement/forecast record links to the correct intake and evaluation
no duplication or loss occurs

Scenario 14 — Scope Boundary Check

Steps:

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

Pass if there is:

no Test Candidate Queue
no Test Candidate Record Screen
no Test Execution workflow
no Ads execution
no Finance logic
no Dashboards
no AI automation
no full cross-Brain routing
no direct MCR update feature

Pass Criteria

Phase 3 is accepted only if:

all acceptance categories pass
all required functional scenarios pass
Measurement Planning Queue works
measurement/forecast records can be created
records link to Phase 1 intake and Phase 2 evaluation records
KIA fields save correctly
tracking requirement fields save correctly
forecast fields save correctly
decision trigger fields save correctly
measurement status updates correctly
forecast status updates correctly
records can be reopened and edited
data persists after reload
multiple records work correctly
no Phase 4 features were added early
no testing, Ads execution, 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 3 must be rejected if:

Measurement Planning Queue does not work
measurement/forecast records cannot be created
measurement/forecast records do not link back to intake records
measurement/forecast records do not link back to evaluation records
KIA fields do not save
tracking requirement fields do not save
forecast fields do not save
decision trigger fields do not save
measurement status changes fail
forecast status changes fail
records cannot be reopened
edited data does not persist
multiple records break the system
later-phase features were added prematurely
testing, Ads execution, Finance, dashboard, automation, or 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 3

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

Test Candidate Queue
Test Candidate Record Screen
Test Execution workflow
Ads Brain execution logic
Finance controls
dashboards
automation
AI integrations
full Brain Request routing
HeadOffice dashboard reporting
MCR update automation

These are later phases.

Do not fail Phase 3 because these are not present.

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

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 test decisions
protecting capital from unclear experiments

Governance Role

This protocol ensures:

Phase 3 development meets required standard
measurement and forecasting are usable before testing
future phases build on a stable foundation
system progression remains controlled
M’s Phase 3 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 Three Developer Build Pack
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 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
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:

incomplete Phase 3 builds being accepted
missing core measurement functionality
missing core forecast functionality
accepting screens that do not save data
accepting records that cannot be reopened
accepting records that are not linked to intake and evaluation
accepting queues that do not display correctly
adding future features prematurely
misalignment with Phase Three 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
testing without KIA logic
testing without forecast expectations
testing without tracking-readiness awareness

Architectural Intent

This checklist ensures MWMS moves from:

evaluated opportunities

to:

usable measurement and forecast planning

without prematurely jumping into test setup, Ads execution, Finance, dashboards, or automation.

It guarantees that Phase 3 produces a real operational planning tool.

The architectural intent is:

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

Final Rule

Phase 3 is accepted only when Martyn can use the Measurement And Forecast Planning system in real conditions.

The system must:

show measurement planning records
create measurement/forecast records
link them to Phase 1 intake and Phase 2 evaluation records
save KIA fields
save tracking requirement fields
save forecast fields
save decision trigger fields
update measurement and forecast statuses
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 3 is not complete.

Change Log

v1.0 — 2026-05-12

Initial creation of MWMS Opportunity System Phase Three Acceptance Checklist.

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

Defines:

Phase 1 and Phase 2 linkage checks
Measurement Planning Queue acceptance criteria
Measurement And Forecast Record creation criteria
KIA Field Storage criteria
Tracking Requirement Field Storage criteria
Forecast Field Storage criteria
Decision Trigger Mapping criteria
Measurement Status Management
Forecast Status Management
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 Three 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 3 of the MWMS Opportunity System.