System: MWMS
Document Type: Protocol
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, MWMS Brain, Brain Room, AI Manager, AI Employee Router, Task Executor Systems, Newsletter Intelligence, Course Absorption System, Opportunity System, AI Business Systems Brain
Parent Page: HeadOffice
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR

Purpose

The purpose of this document is to define the MWMS AI Employee Handoff Protocol.

This protocol establishes how work is passed from one AI Employee, Brain, workflow stage, system, queue, or human reviewer to another without losing context, ownership, validation status, risk awareness, or business intent.

MWMS is being designed as a governed AI workforce system.

A workforce cannot operate properly if work is handed off vaguely.

A handoff must make clear:

what work has been completed
what source material was used
what decision or output was produced
what still needs to happen
which Brain owns the next step
which AI Employee or human should act next
what context must be preserved
what risks or limits exist
what validation status applies
where the output should go
what must be logged

This protocol exists to prevent MWMS from losing value between workflow stages.

Scope

This protocol applies to all MWMS workflows where work moves between:

one AI Employee and another AI Employee
one Brain and another Brain
AI Employee and human reviewer
human reviewer and AI Employee
Brain Room and AI Manager
AI Manager and AI Employee Router
AI Employee Router and Task Executor
Newsletter Intelligence and HeadOffice Queue
Course Absorption and MCR page creation
Affiliate Brain and Research Brain
Research Brain and Experimentation Brain
Experimentation Brain and Finance Brain
Finance Brain and HeadOffice
HeadOffice and M
Dev Console and development workflow
MCR and Brain sites
future AIBS client systems

This protocol applies to both manual and automated handoffs.

Manual handoffs include instructions from Martyn to M, course absorption outputs being turned into MCR pages, page drafts being reviewed, and reports being routed to future work.

Automated handoffs include task records, Supabase events, queue items, dashboard cards, routed actions, and future AI Employee workflow transitions.

Core Definition

An AI Employee Handoff is the controlled transfer of work from one role, Brain, stage, system, or reviewer to the next.

A handoff is not simply “passing along an output.”

A proper handoff includes the information needed for the next role to continue the work safely and correctly.

A complete handoff must preserve:

source
task purpose
current status
completed work
pending work
context
assumptions
risks
validation state
required next action
owner
destination
logging requirement

A handoff is valid only when the next person, AI Employee, Brain, or system can understand what to do without guessing.

Core Principle

The core principle of this protocol is:

AI work must not move between Brains, Employees, systems, or humans without a clear handoff.

This protects MWMS from:

lost context
repeated work
poor routing
duplicated pages
broken workflows
unclear ownership
weak validation
unsafe automation
vague developer instructions
dashboard confusion
abandoned actions
false completion

A task is not truly complete until its handoff is complete.

Why Handoffs Matter

MWMS will increasingly depend on multi-step workflows.

A single piece of work may move through several stages.

For example:

A newsletter signal may move through:

Newsletter Intake Agent
Cleaning Agent
Signal Extraction Agent
Brain Routing Agent
Validation Agent
Newsletter Queue Review
HeadOffice Dashboard
Routed Actions
relevant Brain
Learning Log

An affiliate offer may move through:

Affiliate Brain
Research Brain
Ads Brain
Finance Brain
Experimentation Brain
HeadOffice
Test planning
Learning capture

A developer issue may move through:

Martyn
Brain Room
Dev Console
AI Support
M
testing
save point update

Without strong handoffs, these workflows break.

With strong handoffs, MWMS keeps moving forward cleanly.

Handoff Types

MWMS recognizes several types of handoff.

1. AI Employee To AI Employee Handoff

This occurs when one AI Employee completes a stage and another AI Employee continues the work.

Example:

Course Intake Agent → Framework Extraction Agent
Signal Extraction Agent → Brain Routing Agent
Research Agent → Validation Agent
Offer Evaluation Agent → Finance Break Even Agent
Task Builder Agent → Orchestrator Agent

Required handoff content:

completed stage
output produced
source used
unresolved questions
validation status
next required task
risk notes

Rule:

One AI Employee must not assume the next AI Employee already understands the context.

2. Brain To Brain Handoff

This occurs when work moves from one Brain to another.

Example:

Affiliate Brain → Research Brain
Research Brain → Experimentation Brain
Experimentation Brain → Finance Brain
Content Brain → Ads Brain
HeadOffice Brain → Operations Brain

Required handoff content:

originating Brain
receiving Brain
reason for handoff
task summary
source material
decision needed
expected output
urgency
risk level
validation requirement

Rule:

Brain-to-Brain handoffs must preserve ownership and reason for transfer.

3. AI Employee To Human Handoff

This occurs when an AI Employee prepares work for human review or action.

Example:

AI generates MCR page draft for Martyn
AI prepares developer brief for M
AI creates offer verdict for Martyn review
AI creates validation report for HeadOffice decision

Required handoff content:

clear verdict
what was done
what needs review
what decision is required
risk notes
what not to touch
next step

Rule:

A human should not need to reconstruct the logic from scratch.

4. Human To AI Employee Handoff

This occurs when Martyn, M, or another human gives context or instruction to an AI Employee.

Example:

Martyn uploads course files
M provides code status
Martyn gives screenshot of WordPress page list
Martyn says “continue from this save point”
Martyn asks for full page output

Required handoff content:

task request
relevant source material
known constraints
current system state
desired output
urgency
forbidden areas

Rule:

Human instructions should be converted into structured work before serious AI execution.

5. Queue To Workflow Handoff

This occurs when a queue item becomes active work.

Example:

Newsletter Queue Review item becomes Routed Action
Course absorption item becomes MCR page draft
Offer intake item becomes research task
Brain Room message becomes AI Manager task

Required handoff content:

queue item ID or reference
status
priority
owning Brain
assigned Employee
next workflow
due timing where relevant

Rule:

Queue items must not become action items without ownership and next step clarity.

6. Workflow To Dashboard Handoff

This occurs when a workflow output becomes visible in a dashboard.

Example:

Newsletter intelligence appears in HeadOffice Dashboard
test result appears in Experimentation Dashboard
finance alert appears in HeadOffice reporting
routed action appears in action panel

Required handoff content:

signal
Brain
action type
priority
urgency
owner
status
reason
source
next step

Rule:

Dashboard handoffs must be short, specific, validated enough, and action-ready.

7. Workflow To MCR Handoff

This occurs when an output is ready to become a canonical MCR page or page update.

Example:

course framework becomes new MCR standard
current page is rewritten
registry update is required
new Brain framework is added

Required handoff content:

proposed page title
parent page
document type
source reason
full page output
related standards
duplication check
validation status
change log entry

Rule:

MCR handoffs must be complete, clean, and ready to save.

8. Workflow To Developer Handoff

This occurs when work is handed to M or a future developer.

Example:

exact plugin change
WordPress UI issue
Supabase route update
file replacement
testing instruction
save point update

Required handoff content:

exact site
exact system area
exact file path where applicable
exact current issue
exact required action
exact replacement or insertion location
what not to touch
test steps
expected result
rollback awareness where appropriate

Rule:

Developer handoffs must be precise enough to act on safely.

9. Workflow To Client Handoff

This applies to future AIBS systems.

Example:

AI-generated business report delivered to client
client workflow result sent for approval
automation output requires business owner decision
client dashboard item requires action

Required handoff content:

plain-language summary
business meaning
recommended action
approval required
risk notes
next step
owner

Rule:

Client handoffs must be clear, non-confusing, and safe for business users.

Standard Handoff Package

Every important MWMS handoff should include the following fields.

1. Handoff Title

A clear title describing the transfer.

Example:

Affiliate Offer Research Handoff To Experimentation Brain

2. Source

Where the work came from.

Examples:

newsletter
course file
Brain Room message
offer page
Supabase task
MCR page
developer note
dashboard item

3. Originating Brain

The Brain where the work began.

4. Receiving Brain Or Role

The Brain, AI Employee, human, queue, dashboard, or system receiving the work.

5. Reason For Handoff

Why the work is being transferred.

Examples:

needs research
needs validation
needs finance review
ready for MCR save
needs developer implementation
needs HeadOffice decision
ready for dashboard display
requires human approval

6. Work Completed

What has already been done.

This prevents duplicate work.

7. Output Produced

The actual result being handed off.

This may be:

report
verdict
structured data
full page output
task record
dashboard card
developer brief
validation result

8. Context To Preserve

Important background the next role must know.

Examples:

developer boundary
current save point
source limitations
previous decisions
active constraints
relevant standards
known risks
user preference
incomplete data

9. Validation Status

The current validation state.

Examples:

Draft
Self Checked
Needs Validation
Validated
Failed Validation
Human Review Required
Source Verification Required
Parked Pending Input

10. Risk Level

The risk level of the handoff.

Recommended levels:

Low
Medium
High
Critical

11. Required Next Action

The exact next action required.

Examples:

review and approve
revise
route to Research Brain
create MCR page
send to M
create task
park
reject
test
validate source
update registry
log learning

12. Owner Of Next Action

Who or what owns the next step.

Examples:

Martyn
M
HeadOffice
Affiliate Brain
Research Brain
Finance Brain
Validation Agent
AI Manager
Human Review Queue

13. Due Timing

Optional timing information when relevant.

Examples:

immediate
today
tomorrow
next session
before build
before launch
after validation
no timing required

14. Logging Requirement

Whether this handoff must be logged.

Important handoffs should usually be logged.

15. Learning Capture

Whether this handoff produced a reusable lesson.

Default Handoff Template

Handoff Title:
Source:
Originating Brain:
Receiving Brain Or Role:
Reason For Handoff:
Work Completed:
Output Produced:
Context To Preserve:
Validation Status:
Risk Level:
Required Next Action:
Owner Of Next Action:
Due Timing:
Logging Required:
Learning Capture Required:

This template may be shortened for low-risk work.

It should not be shortened for high-risk, developer, MCR, finance, compliance, or client-facing handoffs.

Handoff Quality Checklist

Before a handoff is accepted, check:

Is the handoff title clear?
Is the source identified?
Is the originating Brain clear?
Is the receiving Brain or role clear?
Is the reason for handoff stated?
Is completed work summarized?
Is the output included or referenced?
Is important context preserved?
Is validation status clear?
Is risk level assigned?
Is the next action specific?
Is the next owner clear?
Is human review needed?
Is logging required?
Is learning capture required?
Is anything unresolved?
Is the handoff too vague to act on?
Does this affect M’s active build?
Does this need HeadOffice visibility?
Can the receiver continue without guessing?

A handoff that fails this checklist should be revised before it moves forward.

Handoff Failure Modes

MWMS must watch for handoff failure.

Common failure modes include:

Work is passed with no clear owner
Output is passed without source
Context is lost between stages
Validation status is unclear
Risk level is not stated
Next action is vague
Human review is skipped
Receiving Brain is wrong
Work is duplicated because completed work is not stated
Dashboard item has no action
M receives vague developer instructions
Course output is saved without duplication check
Offer moves forward without finance or risk review
Newsletter signal is routed without usefulness check
Client receives unclear or unsafe output
Handoff is treated as completion when it is only transfer
Important learning is not logged

Any handoff showing these failure modes should be paused and corrected.

Application To Newsletter Intelligence

Newsletter Intelligence handoffs should move from raw signal to operational action.

A good newsletter handoff includes:

newsletter source
extracted signal
primary Brain
supporting Brains
recommended action
confidence
urgency
priority
validation status
queue or dashboard destination
whether human review is required

Example:

Handoff Title:
Newsletter Signal Handoff To Ads Brain

Reason For Handoff:
Newsletter contains platform change affecting paid traffic testing.

Required Next Action:
Review signal and decide whether to monitor, test, or update Ads Brain rules.

Newsletter handoff rule:

Newsletter signals must not be routed unless they are specific, useful, and assigned to a Brain.

Application To Course Absorption

Course absorption handoffs should move from extracted value to MWMS structure.

A good course handoff includes:

course name
lesson/module
extracted principle
MWMS relevance
affected Brain
proposed page or update
what to ignore
duplication status
validation status
next action

Example:

Handoff Title:
Course Framework Handoff To MCR Page Creation

Reason For Handoff:
Lesson produced a reusable MWMS operating standard.

Required Next Action:
Create full page output for MCR review.

Course handoff rule:

Course material must not become MCR structure unless the handoff explains why it improves MWMS.

Application To Offer Evaluation

Offer evaluation handoffs are high value and often high risk.

A good offer handoff includes:

offer name
network
verdict
evidence
traffic fit
compliance risk
finance notes
experimentation fit
next Brain
next decision

Example:

Handoff Title:
Affiliate Offer Handoff To Finance Brain

Reason For Handoff:
Offer appears testable but requires break-even and budget review.

Required Next Action:
Calculate minimum conversion threshold and safe test budget.

Offer handoff rule:

No offer should move toward testing without clear Research, Finance, Experimentation, and HeadOffice handoffs where required.

Application To Brain Room

Brain Room handoffs should convert discussion into structured work.

A good Brain Room handoff includes:

message summary
request type
owning Brain
assigned AI Employee
context needed
task status
risk level
next action
destination

Example:

Handoff Title:
Brain Room Request Handoff To AI Manager

Reason For Handoff:
Message requires structured AI task execution.

Required Next Action:
Create Agentic Work Unit and assign appropriate AI Employee.

Brain Room handoff rule:

Brain Room should not become a graveyard of useful but unstructured discussion.

Application To M Developer Work

Developer handoffs must be strict.

A good M handoff includes:

site name
plugin/module
exact file path where applicable
exact current state
exact required change
full file output if required
exact instruction
what not to touch
test steps
expected result
save point impact

Example:

Handoff Title:
Dev Console UI Update Handoff To M

Reason For Handoff:
M needs exact implementation instructions.

Required Next Action:
Replace specified file with full provided output, test page load, confirm no PHP errors.

Developer handoff rule:

If M has to guess, the handoff is not valid.

Application To MCR Page Creation

MCR handoffs must ensure clean structure.

A good MCR handoff includes:

page title
parent page
document type
status
source of truth
full page output
related pages
duplication check
registry update need
change log

MCR handoff rule:

A page draft is not ready for MCR until its placement, purpose, and relationship to existing standards are clear.

Application To AIBS Client Systems

Client handoffs must be simple and safe.

A good client handoff includes:

plain-language finding
business meaning
recommended action
risk
approval needed
next step
owner

Client handoff rule:

Client-facing handoffs must reduce confusion, not create more decisions without guidance.

Handoff Validation

Every important handoff should be validated before transfer.

Validation checks:

source present
owner clear
receiver clear
reason clear
next action clear
risk stated
validation status included
context preserved
human review identified
logging requirement known

A handoff should not proceed if the receiving party cannot act safely.

Handoff Logging

Important handoffs should be logged.

A handoff log may include:

handoff created
source
from Brain
to Brain or role
status
risk level
next action
owner
due timing
validation status
completion status
learning captured

Handoff logs support:

auditability
task tracking
dashboard visibility
workflow debugging
cross-Brain coordination
future automation

Handoff Statuses

Recommended handoff statuses:

Draft
Ready For Review
Sent
Received
Accepted
Needs Clarification
In Progress
Completed
Parked
Rejected
Escalated
Logged
Archived

These statuses help MWMS track work as it moves through the system.

Human Review Rule

Human review is required for handoffs involving:

MCR canon updates
developer implementation
paid traffic decisions
financial analysis
compliance-sensitive material
live system changes
public-facing content
client-facing outputs
major Brain architecture changes
high-risk automations
uncertain ownership
M’s active build areas

Human review protects MWMS from moving too quickly in high-risk areas.

Automation Readiness Rule

Handoffs should only be automated when the handoff format is stable.

Before automating a handoff, confirm:

sender is known
receiver is known
required fields are defined
validation status is available
risk level is assigned
next action is predictable
failure cases are known
human review rules are defined
logging is available
the handoff adds real operational value

Automation rule:

Do not automate handoffs that humans cannot perform clearly yet.

Governance Role

HeadOffice owns the MWMS AI Employee Handoff Protocol.

HeadOffice is responsible for:

defining handoff standards
ensuring Brain-to-Brain transfers preserve context
ensuring AI Employee handoffs remain controlled
ensuring high-risk handoffs require review
protecting M from vague developer handoffs
protecting MCR from incomplete page handoffs
protecting dashboards from weak routed outputs
maintaining visibility over cross-Brain work
ensuring handoffs support business outcomes

Individual Brains may define specialized handoff formats, but they must align with this protocol.

Relationship To Other MWMS Standards

This protocol supports and must align with:

MWMS AI Agent Operations Core
MWMS Agentic Work Unit Standard
MWMS AI Employee Role Card Standard
MWMS AI Agent Orchestration Framework
MWMS AI Workflow Pipeline Standard
MWMS AI Output Validation Standard
MWMS Messy Input Normalization Framework
MWMS Agentic Reporting Standard
MWMS Brain Routing Rule
MWMS Brain To Brain Request Protocol
MWMS AI Output Standard Full File Delivery Rule
MWMS Brain Header Schema Standard
MWMS Page Naming Standard
MWMS Document Structure Standard
MWMS Architecture Registry
MWMS Brain Interaction Map
MWMS System Data Flow Map
MWMS Supabase Event Schema
HeadOffice Newsletter Intelligence Operating Protocol
MWMS Course Absorption Operating Rule
MWMS Opportunity System Operating Protocol
AI Business Systems Brain Blueprint

This protocol defines how work moves safely between the roles, Brains, pipelines, reports, and validation systems defined by those standards.

Drift Protection

This protocol protects MWMS from the following forms of drift:

Losing context between workflow stages
Passing work without ownership
Treating transfer as completion
Routing outputs without validation status
Sending vague developer instructions to M
Moving course material into MCR without clear value
Moving offers toward testing without proper review
Sending dashboard items with no next action
Creating cross-Brain confusion
Skipping human review on high-risk work
Failing to log important transfers
Duplicating work because previous stages were not summarized
Letting Brain Room discussion disappear without task conversion
Creating client confusion through unclear handoffs
Automating handoffs before manual handoff quality is proven

Any handoff showing these drift signs should be revised before proceeding.

Architectural Intent

The architectural intent of the MWMS AI Employee Handoff Protocol is to make MWMS work transferable without losing control.

As MWMS grows, work will increasingly move between Brains, AI Employees, humans, dashboards, queues, task systems, and client-facing workflows.

The system must preserve meaning as work moves.

The long-term goal is that every important MWMS handoff can answer:

What is being handed off?
Where did it come from?
Who completed the previous step?
What was completed?
What still needs to happen?
Who owns the next step?
What context must be preserved?
What risks exist?
Has it been validated?
Where does it go next?
What should be logged?
What should MWMS learn?

When MWMS can answer those questions consistently, it can operate as a coordinated AI workforce instead of a set of disconnected outputs.

Change Log

v1.0 — Initial Draft

Created the MWMS AI Employee Handoff Protocol as the standard for transferring work between AI Employees, Brains, humans, queues, dashboards, task systems, MCR, developers, and future client-facing AIBS workflows.

This protocol supports the MWMS AI Agent Operations Core, Agentic Work Unit Standard, AI Employee Role Card Standard, AI Agent Orchestration Framework, AI Workflow Pipeline Standard, AI Output Validation Standard, Messy Input Normalization Framework, and Agentic Reporting Standard by defining how context, ownership, validation status, risk, next action, destination, logging, and learning must be preserved during handoffs.