Document Type: Implementation Brief
Status: Active
Version: v1.0
Authority: HeadOffice
Applies To: Martyn, M, HeadOffice Brain, MCR, mwmsbrain.site, mwmsheadofficebrain.site, Supabase, Plugin/UI Systems, Brain Room, and Opportunity System Build Work
Parent: HeadOffice Brain
Last Reviewed: 2026-05-11

Purpose

The MWMS Opportunity System Implementation Control Brief defines how the MWMS Opportunity System build is coordinated between Martyn and M.

This page exists because MWMS now has more than one active builder.

M is building the operational and technical layers.

Martyn is building, refining, and governing the MCR, HeadOffice, and system architecture layers.

This brief prevents:

build overlap
duplicated work
unclear ownership
MCR drift
Brain site confusion
plugin/UI scope creep
Supabase structure confusion
HeadOffice visibility gaps
one builder blocking the other
operational work bypassing governance

This page is the master coordination brief for Opportunity System implementation.

It does not replace M’s developer-specific brief.

It sits above it.

Scope

This brief applies to:

Opportunity System build coordination
MCR source-of-truth work
mwmsbrain.site operational build work
mwmsheadofficebrain.site visibility/reporting work
Supabase request, task, event, result, and feedback records
plugin/UI build planning
Brain Room integration where relevant
HeadOffice review and approval paths
cross-Brain request handling
Affiliate Brain, Research Brain, Experimentation Brain, Finance Brain, Data Brain, Ads Brain, and HeadOffice Brain workflows

This brief controls the relationship between:

what Martyn builds
what M builds
what stays in MCR
what goes to mwmsbrain.site
what goes to mwmsheadofficebrain.site
what becomes plugin/UI
what requires HeadOffice review
what must not be touched yet

Core Principle

The Opportunity System must be built in controlled lanes.

The correct authority structure is:

MCR = Source Of Truth
mwmsbrain.site = Operational Execution Site
mwmsheadofficebrain.site = HeadOffice Visibility And Reporting Site
Supabase = Structured Records And Execution Data
Plugin/UI = Working Interfaces
HeadOffice = Review, Approval, Escalation, And MCR Decision Authority

Martyn and M may both build, but they must not build the same layer at the same time without a clear handoff.

The operating rule is:

Martyn governs and structures. M implements and wires. HeadOffice reviews and controls.

Build Lane Definitions

1. Martyn Build Lane

Martyn owns the MCR, HeadOffice, and system-governance side of the build.

Martyn may work on:

MCR pages
HeadOffice standards
Opportunity System protocols
copy maps
implementation control briefs
page registries
HeadOffice review paths
Brain operating rules
workflow definitions
acceptance checklists
developer briefs
MCR to Brain classification
future page planning
HeadOffice visibility requirements
system change logs where required

Martyn should not directly alter M’s active plugin files, Supabase implementation, or live mwmsbrain.site build unless that work is explicitly agreed.

2. M Build Lane

M owns the technical implementation and operational wiring side of the build.

M may work on:

mwmsbrain.site plugin work
WordPress admin screens
Brain Room operational wiring
Supabase task and event handling
Brain Request creation logic
task executor hooks
plugin UI screens
operational dashboards
request status handling
result return handling
developer implementation tasks
technical debugging
safe save points
code-level wiring

M must not directly change MCR canon.

M must not create new source-of-truth logic inside plugin code without HeadOffice-approved instruction.

M must not allow plugin/UI/Supabase systems to update MCR directly.

3. HeadOffice Build Lane

HeadOffice owns oversight and approval.

HeadOffice controls:

build priority
escalation review
MCR update approval
cross-Brain visibility
operational feedback review
system risk review
implementation sequencing
conflict resolution between Martyn and M
decision on whether feedback becomes canon
decision on whether a page becomes Copy To Brain or Later Plugin/UI

HeadOffice is the final authority when build lanes conflict.

System Layer Map

Layer	Owner	Purpose	Direct MCR Update Allowed?
MCR	Martyn / HeadOffice	Source Of Truth	Yes, by approved HeadOffice/Martyn action
mwmsbrain.site	M	Operational execution	No
mwmsheadofficebrain.site	M / Martyn depending on task	HeadOffice visibility and reporting	No
Supabase	M	Structured request/task/event/result records	No
Plugin/UI	M	Working interfaces and operational screens	No
Brain Room	M	Operational communication and request surface	No
HeadOffice Review	Martyn / HeadOffice	Approve, reject, park, escalate	Can approve MCR change
MCR Change	Martyn / HeadOffice	Canon update	Only after HeadOffice decision

Opportunity System Build Flow

The Opportunity System build must follow this flow:

MCR defines the system
↓
Implementation Control Brief assigns build lanes
↓
M builds approved operational surfaces
↓
Supabase stores structured records
↓
mwmsbrain.site executes the workflow
↓
mwmsheadofficebrain.site displays HeadOffice visibility
↓
Operational feedback routes to HeadOffice
↓
HeadOffice decides whether MCR changes

The prohibited flow is:

mwmsbrain.site / Plugin / Supabase / Brain Room → Direct MCR Update

Current Operating Direction

The current operating direction is to make the Opportunity System usable without destabilising M’s build.

The first working operational path is:

Affiliate Intake
↓
Offer Evaluation
↓
Research Request Where Required
↓
Experimentation Handoff
↓
Finance Capital Review Where Required
↓
HeadOffice Visibility
↓
Learning And Feedback Capture

This path must be implemented through structured Brain Requests and Supabase-backed lineage.

Martyn Current Build Responsibilities

Martyn’s current responsibilities are:

maintain MCR as Source Of Truth
update governing pages where required
classify pages as MCR Only, Copy To Brain, or Later Plugin/UI
ensure HeadOffice pages remain structurally correct
define build control logic
prevent overlap with M’s live build
prepare full-page outputs for approved MCR updates
update operating protocols before developer implementation
define what mwmsbrain.site needs operationally
define what mwmsheadofficebrain.site needs for visibility
keep HeadOffice review logic clear

Martyn should focus on:

structure
authority
operating rules
review paths
copy maps
build briefs
page registry clarity
HeadOffice visibility requirements

M Current Build Responsibilities

M’s current responsibilities are:

build or update approved plugin/UI features
wire mwmsbrain.site operational surfaces
preserve Supabase lineage
create or update request/task/event/result handling
maintain safe save points
avoid touching MCR directly
avoid changing canon logic in code
follow implementation briefs
report blockers clearly
surface missing requirements back to HeadOffice
ensure operational screens match approved MCR logic

M should focus on:

working screens
plugin structure
Supabase execution
Brain Request handling
task lifecycle
event logging
result return
HeadOffice visibility hooks
technical implementation

Shared Build Boundary

Martyn and M may both work on the Opportunity System, but the boundary is:

Martyn defines what should exist. M builds how it works.

If Martyn identifies a missing operational need, it should become:

an MCR page update
a build brief update
a copy map update
a plugin/UI specification
a HeadOffice review item
a task for M

If M identifies a missing operational need, it should become:

a feedback note
a blocker report
a HeadOffice review request
a proposed MCR update
a proposed plugin/UI change
a proposed Supabase schema change

M must not solve MCR gaps by inventing unapproved system logic in code.

Page Relationship Structure

This page sits above:

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

This page works alongside:

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

Existing Page Handling Rule

The existing page:

MWMS Opportunity System Implementation Brief For M

should not be renamed at this stage.

Reason:

M may already know and use it
it is developer-specific
it may contain M-focused instructions
it should remain as M’s build lane page
renaming it may create confusion

This new page becomes the master control page.

The existing M page remains the developer-specific page.

If Martyn’s build lane grows large enough, a separate page may later be created:

MWMS Opportunity System Implementation Brief For Martyn

But this is not required yet.

Active Build Separation Rule

No work should interfere with M’s active technical build unless explicitly assigned.

Martyn should avoid directly changing:

Supabase schema
live plugin files
active task executor code
active mwmsbrain.site plugin workflows
Brain Room implementation code
live developer wiring

M should avoid directly changing:

MCR canon pages
governance rules
HeadOffice authority pages
page naming rules
page parent structure
copy maps unless instructed
system standards

Both builders must protect the other builder’s active lane.

MCR Source Of Truth Rule

MCR remains the only Source Of Truth for:

system rules
canon
standards
architecture
governance
copy maps
implementation control logic
approved build direction

mwmsbrain.site may display or execute approved MCR-derived content.

mwmsheadofficebrain.site may display HeadOffice reporting and oversight.

Supabase may store structured operational data.

Plugin/UI systems may execute approved workflows.

None of these replace MCR.

Brain Site Direct Update Ban

No Brain site may directly update MCR.

This includes:

mwmsbrain.site
mwmsheadofficebrain.site
future Brain sites
plugins
dashboards
Brain Room
Supabase automations
AI employees
task executors

Any proposed MCR update must route through:

HeadOffice Review → MCR Decision → Approved MCR Update

Supabase Lineage Requirement

Supabase must preserve structured lineage across the Opportunity System.

Required lineage relationships include:

opportunity
offer
Brain Request
task
event
result
escalation
feedback
HeadOffice review
MCR update suggestion

Tasks must not become disconnected from their parent request.

Events must not become meaningless logs.

Results must return to the original request chain.

Feedback must be routed to HeadOffice where system change is suggested.

Brain Request Requirement

All cross-Brain movement inside the Opportunity System must use structured Brain Requests.

Examples:

Affiliate Brain requests Research Brain review
Affiliate Brain requests Experimentation Brain test design
Experimentation Brain requests Finance Brain budget review
Ads Brain requests Research Brain signal interpretation
Brain Room message creates a Brain Request
Plugin/UI action triggers a Brain Request
Brain site feedback triggers HeadOffice review

Informal notes are not valid system handoff.

HeadOffice Visibility Requirement

HeadOffice must be able to see:

active opportunities
current stage
current Brain owner
blocked requests
escalated requests
Research Brain requests
Experimentation Brain requests
Finance Brain reviews
task status
result summaries
capital exposure
test status
learning capture
system feedback
proposed MCR updates

HeadOffice does not need to manually control every action.

But HeadOffice must be able to review the full chain when needed.

Martyn And M Coordination Rules

Rule 1 — No Duplicate Building

Martyn and M should not build the same thing in different places.

If Martyn is creating governance or operating instruction, M should not recreate that logic independently in plugin code.

If M is building a plugin/UI surface, Martyn should not create a competing manual system elsewhere unless it is temporary and clearly labelled.

Rule 2 — No Silent Scope Expansion

Neither Martyn nor M should expand the Opportunity System into unrelated Brain areas without HeadOffice clarity.

Expansion must be recorded as:

new scope
parked future work
separate implementation brief
HeadOffice review item

Rule 3 — Blockers Must Be Routed Back

If M hits a missing rule, missing field, missing workflow, or unclear instruction, the issue should route back to HeadOffice.

If Martyn finds a build ambiguity, it should become a clearer brief, page update, or HeadOffice decision.

Rule 4 — Operational Build Must Match MCR

M’s implementation must match approved MCR logic.

If implementation cannot match the MCR logic due to technical constraints, M must report the issue.

HeadOffice then decides whether to:

adjust the build
adjust the workflow
adjust the MCR page
park the feature
split the feature into phases

Rule 5 — Save Points Are Required

M’s technical build must maintain clear safe save points.

A save point should include:

what changed
what works
what is not yet wired
what files were touched
what Supabase tables or fields were affected
what next step should be
whether MCR instruction is missing

Martyn’s MCR build should also maintain clear session close notes where required.

Opportunity System Build Priority

The current build priority is not to build everything.

The current priority is to get one clean working operating path.

Priority path:

Affiliate intake or opportunity entry
Structured opportunity record
Brain Request creation where needed
Task creation
Event logging
Result return
Status progression
HeadOffice visibility
Feedback capture
No direct MCR update

This is the first practical system loop.

What Must Not Be Built Yet Without Approval

Do not build the following without HeadOffice approval:

automatic MCR editing
automatic canon rewriting
uncontrolled cross-Brain automation
full dashboard system before data flow works
advanced AI employee autonomy before request lineage works
Finance scaling automation without Finance Brain rules
plugin screens that bypass Brain Requests
Supabase tasks without request context
duplicate registries inside Brain sites
hidden page sync between MCR and Brain sites

Acceptance Criteria

The Opportunity System implementation is acceptable when:

MCR remains Source Of Truth
mwmsbrain.site can operate the approved workflow
Supabase records opportunity movement
Brain Requests preserve cross-Brain lineage
tasks remain subordinate to requests
results return to their origin
HeadOffice can see system status
feedback can be routed to HeadOffice
MCR updates require approval
Martyn and M build lanes remain clear
no hidden authority layer is created

Governance Role

This brief ensures:

Martyn and M can build at the same time without conflict
MCR remains clean
mwmsbrain.site becomes useful
mwmsheadofficebrain.site receives the right visibility later
Supabase supports structured execution
plugin/UI build stays aligned with canon
HeadOffice controls system-wide authority
feedback becomes reviewable instead of chaotic
opportunity execution becomes practical without losing governance

Relationship To Other MWMS Pages

This page works with:

MWMS Opportunity System Operating Protocol
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 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
HeadOffice Cross Brain Performance And Control Dashboard Specification

Drift Protection

This brief protects against:

Martyn and M building over each other
MCR being bypassed
mwmsbrain.site becoming a competing Source Of Truth
M inventing unapproved canon in code
Martyn changing build direction without implementation clarity
Supabase tasks losing lineage
plugin/UI screens bypassing Brain Requests
HeadOffice losing visibility
Brain feedback becoming direct MCR change
Opportunity System work spreading into unrelated build lanes

Architectural Intent

The architectural intent is to create a clean build relationship:

MCR defines the system.
Martyn governs the structure.
M builds the operational layer.
Supabase stores the execution records.
Brain sites run the work.
HeadOffice reviews feedback.
Only approved changes update MCR.

This allows MWMS to move from planning into execution without losing control.

Final Rule

The Opportunity System must be built through clear lanes.

Martyn and M may both build, but they must not blur authority.

MCR remains Source Of Truth.

mwmsbrain.site is the operating site.

mwmsheadofficebrain.site is the HeadOffice visibility site.

Supabase is the structured execution record layer.

Plugin/UI systems are execution surfaces.

HeadOffice decides what feedback becomes canon.

No Brain site, plugin, UI, Supabase process, automation, AI employee, or task executor may directly update MCR.

Change Log

v1.0 — 2026-05-11

Initial creation of the MWMS Opportunity System Implementation Control Brief.

Created to coordinate parallel build work between Martyn and M.

Defines:

Martyn build lane
M build lane
HeadOffice authority lane
MCR Source Of Truth rule
mwmsbrain.site operational role
mwmsheadofficebrain.site visibility role
Supabase lineage requirement
Brain Request requirement
no direct Brain site to MCR update rule
build separation rules
acceptance criteria
drift protection for Opportunity System implementation

Change Impact Declaration

Pages Created:
MWMS Opportunity System Implementation Control Brief

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 implementation control page for active Opportunity System build coordination.