MWMS MCR

MWMS Architecture Registry Operational Infrastructure Update 2026 05 11 To 2026 05 12

Document Type: Architecture Update Log
Status: Active
Version: v1.0
Authority: HeadOffice
Parent: MWMS Architecture Registry
Applies To: MWMS Architecture Registry, Layer 6 Operational Infrastructure, MCR, mwmsbrain.site, mwmsheadofficebrain.site, Supabase, Plugin/UI Systems, Brain Room, Opportunity System Build Control, Martyn, M
Last Reviewed: 2026-05-12

Purpose

The MWMS Architecture Registry Operational Infrastructure Update 2026 05 11 To 2026 05 12 records the detailed Layer 6 Operational Infrastructure update made to the MWMS Architecture Registry during May 11–12, 2026.

This page exists because the main MWMS Architecture Registry has become too large to keep expanding with every detailed update.

The purpose of this page is to:

  • preserve detailed architecture update history
  • reduce bloat in the main Architecture Registry
  • keep the main registry usable as the master structural index
  • record the full MCR to Brain Site operational wiring update
  • record the Opportunity System Phase 1–3 build-control structure
  • preserve the authority logic around MCR, Brain sites, plugins, UI, Supabase, Brain Room, and HeadOffice
  • document the phase-gated build control now applied to mwmsbrain.site work

This page is a detailed update log.

The main MWMS Architecture Registry remains the master structural index.

Scope

This update applies to:

  • MWMS Architecture Registry
  • Layer 6 Operational Infrastructure
  • MCR to Brain Site wiring
  • mwmsbrain.site operational execution
  • mwmsheadofficebrain.site visibility and reporting
  • Supabase lineage and execution records
  • plugin/UI execution boundaries
  • Brain Room operational input surfaces
  • HeadOffice review authority
  • Opportunity System build-control structure
  • Phase 1 Intake build control
  • Phase 2 Offer Evaluation build control
  • Phase 3 Measurement And Forecast Planning build control
  • Martyn and M build-lane separation

This update records architecture-level structure only.

It does not replace:

  • MWMS Architecture Registry
  • 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 Opportunity System Build Order
  • HeadOffice Page Registry
  • MWMS System Change Log 2026 05 01 To 2026 05 15

Core Principle

The main Architecture Registry should stay readable.

Detailed updates should be stored in dated update pages when the change is too large for the main registry.

The governing principle is:

Main Registry = master structural index.
Dated Update Pages = detailed architecture change history.

This prevents the Architecture Registry from becoming too large to maintain while still preserving full structural memory.

Architecture Registry Bloat Control Rule

Large architecture updates may be recorded in dated Architecture Registry Update pages.

The main Architecture Registry should include:

  • active structural summary
  • current layer ownership
  • major system placement
  • version reference
  • link or reference to the dated update page

The main Architecture Registry should not carry every detailed change item when a dated update page can preserve the detail more cleanly.

This rule applies when an update includes:

  • large page lists
  • major system expansion
  • multi-page build-control structures
  • detailed governance changes
  • large operational infrastructure updates
  • repeated phase build packs
  • acceptance checklist chains
  • long implementation notes

Update Summary

This update records the integration of:

  1. MCR To Brain Site Operational Wiring
  2. Opportunity System Build Control
  3. Phase 1 Intake Build Gate
  4. Phase 2 Offer Evaluation Build Gate
  5. Phase 3 Measurement And Forecast Planning Build Gate
  6. Martyn And M Build Lane Separation
  7. No Brain Site To MCR Direct Update Rule
  8. Supabase Lineage And Execution Role
  9. Plugin/UI Execution Boundary
  10. mwmsbrain.site And mwmsheadofficebrain.site Role Clarity

Layer Affected

Layer 6 — Operational Infrastructure

This update belongs to:

Layer 6 — Operational Infrastructure

Layer 6 contains the operational infrastructure required to turn MWMS structure into usable work.

This layer governs:

  • Brain site execution
  • plugin systems
  • UI systems
  • Supabase records
  • task systems
  • event logs
  • request lineage
  • result return
  • Brain Room interfaces
  • HeadOffice visibility infrastructure
  • MCR to Brain operating pathways

Layer 6 does not own canon.

Layer 6 executes approved structure.

MCR To Brain Site Operational Wiring

The operational wiring structure defines how approved MCR knowledge becomes operational inside downstream MWMS environments.

This includes:

  • mwmsbrain.site
  • mwmsheadofficebrain.site
  • future Brain sites
  • WordPress plugin systems
  • UI surfaces
  • Supabase request and task systems
  • Brain Room
  • HeadOffice reporting surfaces

Core Wiring Pages

The following pages define the controlled MCR to Brain Site wiring structure:

  • 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

Structural Role

These pages ensure MWMS can:

  • classify pages before copying them downstream
  • keep MCR as Source of Truth
  • prevent blind copying
  • define what belongs in MCR only
  • define what may be copied to Brain sites
  • define what should become plugin/UI later
  • define structured Brain Requests
  • preserve cross-Brain lineage
  • prevent Brain sites from directly editing MCR
  • route operational feedback through HeadOffice
  • preserve HeadOffice review authority

Approved Direction

The approved authority direction is:

MCR → Brain Site → Plugin/UI/Supabase Execution

The approved feedback direction is:

Brain Site Feedback → HeadOffice Review → MCR Decision

The prohibited direction is:

Brain Site / Plugin / UI / Supabase / Automation → Direct MCR Update

Opportunity System Build Control

The Opportunity System build-control structure defines how the first practical mwmsbrain.site operating system is built in phases.

The controlled operating path is:

Opportunity Intake → Offer Evaluation → Measurement And Forecast Planning → Testing → Result And Learning → Capital Control → HeadOffice Oversight

This update records Phase 1 through Phase 3 build-control documentation.

Core Opportunity System Build Pages

The following pages are part of the Opportunity System build-control structure:

  • MWMS Opportunity System Operating Protocol
  • MWMS Opportunity System Implementation Control Brief
  • MWMS Opportunity System Implementation Brief For M
  • MWMS Opportunity System Build Order
  • MWMS Opportunity Intake Phase One Developer Build Pack
  • MWMS Opportunity Intake Phase One Acceptance Checklist
  • MWMS Opportunity System Phase Two Developer Build Pack
  • MWMS Opportunity System Phase Two Acceptance Checklist
  • MWMS Opportunity System Phase Three Developer Build Pack
  • MWMS Opportunity System Phase Three Acceptance Checklist

Structural Role

These pages ensure MWMS can:

  • build mwmsbrain.site in the correct sequence
  • prevent M from guessing the build order
  • prevent Martyn and M from building over each other
  • define M’s implementation lane
  • define Martyn’s MCR and HeadOffice governance lane
  • protect MCR as Source of Truth
  • require acceptance gates before phase progression
  • prevent dashboards before data flow exists
  • prevent automation before manual workflow stability
  • prevent testing before measurement and forecasting
  • prevent Finance logic before test and result logic exist
  • preserve Supabase lineage
  • keep plugin/UI systems as execution surfaces only

Build Lane Structure

Martyn Build Lane

Martyn owns:

  • MCR structure
  • HeadOffice governance pages
  • build-control pages
  • operating protocols
  • copy maps
  • page registries
  • system change logs
  • architecture update pages
  • acceptance logic
  • HeadOffice review pathways
  • MCR update decisions where approved

Martyn should not directly alter M’s live plugin work unless specifically agreed.

M Build Lane

M owns:

  • mwmsbrain.site technical implementation
  • WordPress plugin/UI work
  • Supabase wiring where assigned
  • queue screens
  • record screens
  • status actions
  • request/task/event/result handling where assigned
  • safe save points
  • technical debugging
  • implementation testing

M must not directly update MCR canon.

M must not invent missing system authority inside plugin code.

M must report missing rules, missing fields, unclear workflow, or technical conflicts back to HeadOffice/Martyn.

HeadOffice Authority Lane

HeadOffice owns:

  • build priority
  • escalation review
  • approval of MCR changes
  • cross-Brain visibility requirements
  • decision on whether feedback becomes canon
  • conflict resolution between Martyn’s structural lane and M’s implementation lane
  • governance of the MCR to Brain Site wiring chain

Phase 1 Build Gate

Phase 1 Name

Affiliate Brain Opportunity Intake System

Phase 1 Pages

  • MWMS Opportunity Intake Phase One Developer Build Pack
  • MWMS Opportunity Intake Phase One Acceptance Checklist

Phase 1 Purpose

Phase 1 creates the first operational entry point for opportunities.

It allows Martyn to:

  • create opportunity records
  • save records
  • view records in a queue
  • reopen records
  • edit records
  • reject records
  • escalate records

Phase 1 Gate Rule

Phase 1 must be accepted before Phase 2 begins.

Phase 1 must not include:

  • Offer Intelligence
  • Measurement Planning
  • Forecasting
  • Testing
  • Finance
  • Dashboards
  • Automation
  • AI
  • Full Brain Request routing
  • MCR update automation

Phase 2 Build Gate

Phase 2 Name

Affiliate Brain Offer Evaluation System

Phase 2 Pages

  • MWMS Opportunity System Phase Two Developer Build Pack
  • MWMS Opportunity System Phase Two Acceptance Checklist

Phase 2 Purpose

Phase 2 creates the controlled offer evaluation layer after opportunity intake.

It allows Martyn to:

  • open the Offer Intelligence Queue
  • create evaluation records
  • link evaluation records back to Phase 1 intake records
  • complete basic offer review fields
  • complete basic viability fields
  • apply evaluation decisions
  • reject
  • park
  • request research
  • proceed to measurement planning
  • mark needs more information

Phase 2 Gate Rule

Phase 2 must be accepted before Phase 3 begins.

Phase 2 must not include:

  • Measurement Planning
  • Forecasting
  • Testing
  • Finance
  • Dashboards
  • Automation
  • AI
  • Full Research Brain automation
  • Full Brain Request routing
  • MCR update automation

Phase 3 Build Gate

Phase 3 Name

Measurement And Forecast Planning System

Phase 3 Pages

  • MWMS Opportunity System Phase Three Developer Build Pack
  • MWMS Opportunity System Phase Three Acceptance Checklist

Phase 3 Purpose

Phase 3 creates the controlled measurement and forecasting layer before testing.

It allows Martyn to define:

  • measurement planning records
  • KIA planning logic
  • tracking requirements
  • forecast assumptions
  • decision triggers
  • measurement status
  • forecast status
  • links back to Phase 1 intake and Phase 2 evaluation

Phase 3 Core Logic

Phase 3 is governed by:

Question → Information → Action

This means:

  • define the question before collecting data
  • define required information before testing
  • define the action before interpreting results

Phase 3 also requires:

  • tracking requirements before testing
  • forecast expectations before testing
  • decision triggers before testing
  • Phase 1 and Phase 2 lineage before testing

Phase 3 Gate Rule

Phase 3 must be accepted before Phase 4 testing begins.

Phase 3 must not include:

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

Phase 4 Protection

Phase 4 must not begin until Phase 3 is accepted.

Phase 4 will later cover:

  • Test Candidate Queue
  • Test Candidate Record Screen
  • Experimentation Brain handoff
  • test setup
  • controlled test structure
  • linked measurement plan
  • linked forecast plan

Phase 4 must not be built early.

The purpose of this update is to prevent testing from starting before measurement and forecast planning are structurally complete.

Supabase Role

Supabase is the structured record and execution data layer.

Supabase may store:

  • opportunity records
  • evaluation records
  • measurement records
  • forecast records
  • Brain Requests
  • tasks
  • events
  • results
  • feedback
  • HeadOffice review items

Supabase must preserve lineage between:

Opportunity → Evaluation → Measurement → Forecast → Future Test → Result → Learning → Feedback

Supabase must not become the Source of Truth.

Supabase must not directly update MCR.

Plugin And UI Role

Plugin and UI systems are execution surfaces.

They may:

  • display queues
  • display records
  • save operational data
  • update status fields
  • support workflow steps
  • support review screens
  • show operational context
  • support HeadOffice visibility later

They must not:

  • define canon
  • rewrite MCR
  • create hidden authority rules
  • bypass HeadOffice review
  • bypass phase gates
  • create full automation before manual workflow is stable

Brain Room Role

Brain Room may later operate as an input or request surface.

Brain Room may:

  • capture human instructions
  • create structured Brain Requests
  • support task routing
  • preserve conversation context
  • show operational state

Brain Room must not:

  • replace the Brain Request protocol
  • directly update MCR
  • bypass HeadOffice review
  • become an informal side-channel for canon changes

mwmsbrain.site Role

mwmsbrain.site is the operational execution site.

It is where approved MCR-derived operational workflows become usable.

mwmsbrain.site may contain:

  • intake screens
  • evaluation screens
  • measurement planning screens
  • forecast screens
  • task views
  • queues
  • operational dashboards later
  • plugin/UI execution surfaces

mwmsbrain.site must not:

  • own canon
  • directly update MCR
  • replace MCR
  • create hidden governance
  • bypass HeadOffice review

mwmsheadofficebrain.site Role

mwmsheadofficebrain.site is the HeadOffice visibility and reporting site.

It is where HeadOffice should later see:

  • system status
  • opportunity flow
  • active blockers
  • phase progression
  • escalations
  • review items
  • MCR update suggestions
  • cross-Brain performance
  • operational reporting

mwmsheadofficebrain.site must not:

  • own canon
  • directly update MCR
  • replace MCR
  • bypass HeadOffice review

HeadOffice Review Role

HeadOffice is the review and approval authority.

HeadOffice decides whether operational feedback becomes:

  • MCR update
  • copy map update
  • plugin/UI update
  • Supabase schema update
  • task schema update
  • dashboard update
  • parked insight
  • rejected suggestion
  • future build item

No downstream system may update MCR without HeadOffice review.

Architecture Registry Main Page Reference

The main MWMS Architecture Registry should include a short reference to this update instead of carrying the full detail.

Recommended v6.5 note for the main Architecture Registry:

Version v6.5

Date: 2026-05-12
Author: HeadOffice

Change:
Added reference to MWMS Architecture Registry Operational Infrastructure Update 2026 05 11 To 2026 05 12.

This update records the MCR to Brain Site operational wiring expansion and Opportunity System Phase 1–3 build-control structure, including Phase Three Developer Build Pack and Phase Three Acceptance Checklist.

The main Architecture Registry remains the master structural index. Detailed operational infrastructure update history is stored in the dated update page to prevent registry bloat.

Structural Protection Added

This update adds structural protection against:

  • MCR being bypassed by Brain sites
  • mwmsbrain.site becoming a competing Source of Truth
  • mwmsheadofficebrain.site becoming a competing Source of Truth
  • plugin/UI systems creating hidden authority
  • Supabase records replacing canon
  • Brain Room becoming an informal canon channel
  • M inventing unapproved rules in code
  • Martyn and M building over each other
  • dashboards being built before workflow data exists
  • automation being built before manual workflow stability
  • Phase 2 starting before Phase 1 acceptance
  • Phase 3 starting before Phase 2 acceptance
  • Phase 4 testing starting before Phase 3 acceptance
  • testing without KIA logic
  • testing without tracking requirement awareness
  • testing without forecast expectations
  • testing without decision triggers

Relationship To Other MWMS Pages

This architecture update log works alongside:

  • MWMS Architecture Registry
  • HeadOffice Page Registry
  • MWMS System Change Log 2026 05 01 To 2026 05 15
  • 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 Opportunity System Operating Protocol
  • MWMS Opportunity System Implementation Control Brief
  • MWMS Opportunity System Implementation Brief For M
  • MWMS Opportunity System Build Order
  • MWMS Opportunity Intake Phase One Developer Build Pack
  • MWMS Opportunity Intake Phase One Acceptance Checklist
  • MWMS Opportunity System Phase Two Developer Build Pack
  • MWMS Opportunity System Phase Two Acceptance Checklist
  • MWMS Opportunity System Phase Three Developer Build Pack
  • MWMS Opportunity System Phase Three Acceptance Checklist

Drift Protection

This update protects against:

  • Architecture Registry bloat
  • detailed update history being lost
  • large operational updates being hidden inside an unreadable master page
  • MCR to Brain Site wiring being forgotten
  • Opportunity System phase-gate logic being scattered
  • Phase 3 measurement and forecasting being skipped
  • Phase 4 testing starting too early
  • Supabase lineage becoming disconnected
  • HeadOffice losing visibility over build-control structure
  • Martyn and M losing lane clarity

Architectural Intent

The architectural intent of this update is to keep MWMS architecture:

  • readable
  • governed
  • traceable
  • modular
  • scalable
  • easier to update
  • easier to review
  • easier to audit

The main Architecture Registry remains the master structural index.

This page preserves the detailed operational infrastructure update.

The operating principle is:

Keep the master registry clean. Store large update detail in dated architecture update pages.

Final Rule

The main MWMS Architecture Registry should not carry every detailed update when a large dated update page is more appropriate.

This page records the detailed Layer 6 Operational Infrastructure update for May 11–12, 2026.

The main Architecture Registry should reference this page in v6.5 and remain the master structural index.

Change Log

v1.0 — 2026-05-12

Initial creation of MWMS Architecture Registry Operational Infrastructure Update 2026 05 11 To 2026 05 12.

Created to record the detailed MCR to Brain Site operational wiring and Opportunity System Phase 1–3 build-control architecture update without further bloating the main MWMS Architecture Registry.

Records:

  • MCR to Brain Site operational wiring
  • Opportunity System build-control structure
  • Phase 1 Intake gate
  • Phase 2 Offer Evaluation gate
  • Phase 3 Measurement And Forecast Planning gate
  • Martyn and M build-lane separation
  • Supabase lineage role
  • plugin/UI execution boundary
  • Brain Room input-surface role
  • mwmsbrain.site operational role
  • mwmsheadofficebrain.site visibility role
  • no direct Brain site to MCR update rule
  • recommended v6.5 reference note for the main Architecture Registry

Change Impact Declaration

Pages Created:
MWMS Architecture Registry Operational Infrastructure Update 2026 05 11 To 2026 05 12

Pages Updated:
None

Pages Deprecated:
None

Registries Requiring Update:
Recommended: HeadOffice Page Registry
Recommended: MWMS System Change Log 2026 05 01 To 2026 05 15
Recommended: MWMS Architecture Registry short v6.5 reference note

Canon Version Update Required:
No for this page.
Yes for MWMS Architecture Registry if the v6.5 reference note is added.

Monthly Change Log Entry Required:
Recommended, because this creates a dated architecture update log and changes how large Architecture Registry updates should be stored.

END MWMS ARCHITECTURE REGISTRY OPERATIONAL INFRASTRUCTURE UPDATE 2026 05 11 TO 2026 05 12 v1.0