MWMS MCR

MWMS AI Exchange Zone And Dependency Control Framework

System: MWMS
Document Type: Framework
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, Course Absorption System, Newsletter Intelligence, 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 Exchange Zone And Dependency Control Framework.

This framework explains how MWMS controls the moments where work passes from one AI Employee, Brain, workflow, tool, queue, dashboard, developer, human reviewer, or future client system to another.

These transition points are called Exchange Zones.

An Exchange Zone is where work changes hands.

Most workflow failures do not happen because one AI Employee cannot produce output.

They happen because:

  • the next role does not receive the right context
  • the handoff is vague
  • dependencies are unclear
  • validation status is missing
  • the previous stage assumed the next stage would understand
  • the next stage begins work before required inputs exist
  • the output format does not match the receiver’s needs
  • ownership is unclear
  • partial failure is hidden
  • human review is skipped
  • work moves forward when it should stop

MWMS must treat handoff points as controlled system zones, not casual transitions.

This framework makes Exchange Zones visible, governed, validated, and measurable.

Scope

This framework applies to all meaningful handoffs and dependency points across MWMS.

This includes exchanges between:

  • AI Employee to AI Employee
  • Brain to Brain
  • AI Employee to human
  • human to AI Employee
  • Brain Room to AI Manager
  • AI Manager to AI Employee Router
  • AI Employee Router to Task Executor
  • Task Executor to validation
  • validation to routing
  • Course Absorption to MCR page creation
  • Newsletter Intelligence to Queue Review
  • Queue Review to Routed Actions
  • Affiliate Brain to Research Brain
  • Research Brain to Experimentation Brain
  • Experimentation Brain to Finance Brain
  • Finance Brain to HeadOffice
  • HeadOffice to M
  • Developer Support Agent to M
  • MCR to Brain site
  • AI workflow to dashboard
  • tool/plugin output to workflow
  • future AIBS workflow to client review

This framework does not authorize new development work.

It defines the control logic that should be proven manually before automation, plugin/UI build work, or Task Executor routing.

Core Definition

An Exchange Zone is the controlled transition point where work moves from one role, Brain, system, queue, workflow stage, human, or tool to another.

An Exchange Zone includes:

  • the sender
  • the receiver
  • the output being transferred
  • the required input for the receiver
  • validation status
  • risk level
  • context to preserve
  • known gaps
  • dependencies
  • next action
  • owner of next action
  • stop conditions
  • logging requirement

A handoff is the package.

The Exchange Zone is the controlled area where the handoff happens.

Core Principle

The core principle of this framework is:

Work should not cross an Exchange Zone unless the receiving role has what it needs to continue safely.

A strong Exchange Zone answers:

  • Who is sending the work?
  • Who is receiving the work?
  • What exactly is being transferred?
  • What has already been done?
  • What still needs to happen?
  • What context must travel with it?
  • What validation has occurred?
  • What dependencies remain?
  • What risk exists?
  • What should stop the workflow?
  • Who owns the next action?

If these questions cannot be answered, the work should pause, be revised, parked, or escalated.

Exchange Zone Types

MWMS recognizes the following Exchange Zone types.

1. AI Employee To AI Employee Exchange

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

Examples:

  • Researcher Agent hands evidence to Analyst Agent
  • Analyst Agent hands decision logic to Writer Agent
  • Writer Agent hands draft to Reviewer Agent
  • Reviewer Agent hands revision notes to Validator Agent
  • Validator Agent hands approved output to Router Agent

Required controls:

  • clear sender
  • clear receiver
  • output type
  • required next action
  • validation status
  • known gaps
  • source references
  • role boundary

Rule:

AI Employee handoffs must preserve task meaning, not just output text.

2. Brain To Brain Exchange

This occurs when one Brain passes work to another Brain.

Examples:

  • Affiliate Brain sends offer to Research Brain
  • Research Brain sends evidence to Experimentation Brain
  • Experimentation Brain sends test plan to Finance Brain
  • Finance Brain sends budget verdict to HeadOffice
  • Content Brain sends production insight to Ads Brain
  • Newsletter Intelligence sends platform signal to Ads Brain

Required controls:

  • originating Brain
  • receiving Brain
  • reason for transfer
  • source material
  • decision status
  • supporting Brains
  • risk notes
  • expected output from receiver

Rule:

Brain-to-Brain exchanges must explain why the receiving Brain is needed.

3. Human To AI Exchange

This occurs when Martyn, M, or another human gives work to an AI Employee or Brain.

Examples:

  • Martyn uploads course files
  • Martyn asks for duplicate cleanup
  • M reports a development issue
  • user provides screenshots
  • client gives source document
  • human reviewer approves a task for AI processing

Required controls:

  • current request
  • source material
  • source completeness
  • human intent
  • constraints
  • what not to do
  • output expected
  • human review requirement

Rule:

Human input must be normalized before it becomes AI work.

4. AI To Human Exchange

This occurs when AI output is handed to a human for review, decision, build, or action.

Examples:

  • full page output given to Martyn
  • developer brief given to M
  • validation report given to HeadOffice
  • client report draft given for approval
  • readiness review given for decision

Required controls:

  • clear verdict
  • source grounding
  • risk notes
  • required action
  • what not to do
  • decision needed
  • human approval stage
  • known gaps

Rule:

AI-to-human handoffs must make the human’s decision easier, not harder.

5. Workflow Stage Exchange

This occurs when work moves from one workflow stage to another.

Examples:

  • input cleaning to classification
  • classification to task creation
  • task creation to context attachment
  • processing to validation
  • validation to routing
  • routing to logging
  • logging to learning update

Required controls:

  • stage completed
  • next stage
  • stage output
  • stage status
  • pass/fail state
  • required input for next stage
  • stop conditions

Rule:

A workflow stage should not begin until the previous stage output is usable.

6. Tool Output To Workflow Exchange

This occurs when a plugin, API, automation, or tool produces output that enters a workflow.

Examples:

  • Gmail email body enters Newsletter Intelligence
  • OpenAI output enters JSON Parse
  • JSON Parse output enters Supabase
  • Supabase row enters HeadOffice Dashboard
  • WordPress page list enters duplicate cleanup
  • uploaded transcript enters Course Absorption
  • data analysis output enters Finance Brain

Required controls:

  • tool used
  • tool permission boundary
  • output completeness
  • schema match
  • validation requirement
  • failure handling
  • log destination

Rule:

Tool output must be treated as unvalidated until checked.

7. Queue To Action Exchange

This occurs when a review queue item becomes an action.

Examples:

  • Newsletter Queue Review item becomes Routed Action
  • Offer intake becomes Research Request
  • validation failure becomes revision task
  • Brain Room message becomes Agentic Work Unit
  • dashboard item becomes M task
  • parked item becomes active task

Required controls:

  • queue item source
  • review decision
  • owner
  • priority
  • urgency
  • action type
  • next step
  • validation status

Rule:

Queue items should not become actions without a decision state.

8. MCR To Brain Site Exchange

This occurs when MCR governance content is copied, simplified, or operationalized into a Brain site.

Examples:

  • MCR framework copied to mwmsbrain.site
  • HeadOffice standard simplified for HeadOffice Brain
  • operational workflow copied into Affiliate Brain
  • MCR page informs plugin/UI design

Required controls:

  • source MCR page
  • copy classification
  • destination Brain site
  • transformation rule
  • what stays MCR-only
  • what becomes operational
  • what may become plugin/UI later
  • validation before copy

Rule:

MCR remains source of truth. Brain sites receive operational copies, not uncontrolled rewrites.

9. Developer Exchange Zone

This occurs when work is handed to M or future developers.

Examples:

  • exact plugin change request
  • file replacement instruction
  • Supabase schema task
  • WordPress admin UI task
  • dashboard bug fix
  • Brain Room wiring task

Required controls:

  • exact site
  • exact file path where available
  • current save point
  • current evidence
  • required change
  • what not to touch
  • test steps
  • expected result
  • rollback or containment notes
  • risk level

Rule:

If M has to guess, the Developer Exchange Zone has failed.

10. Client Exchange Zone

This occurs in future AIBS client-facing workflows.

Examples:

  • client input enters AI workflow
  • AI report goes to client review
  • client approval moves draft to delivery
  • client system data enters reporting pipeline
  • client action recommendation goes to human decision

Required controls:

  • client source
  • client permission boundary
  • client data isolation
  • approval gate
  • privacy risk
  • output status
  • human review
  • audit log

Rule:

Client Exchange Zones require stricter isolation, review, and logging than internal workflows.

Dependency Control

Dependencies are conditions that must be satisfied before work can continue.

MWMS must identify dependencies at every Exchange Zone.

Dependency Type 1: Input Dependency

The receiver needs specific input before continuing.

Examples:

  • Analyst needs research notes
  • Writer needs approved outline
  • Developer Support Agent needs file contents
  • Finance Brain needs payout and cost assumptions
  • Validator needs task instruction and source

Rule:

If required input is missing, the work should not proceed as if complete.

Dependency Type 2: Context Dependency

The receiver needs context before continuing.

Examples:

  • MCR page draft needs parent page and document type
  • developer handoff needs current save point
  • offer evaluation needs traffic platform and goal
  • newsletter routing needs Brain Routing Rule
  • client report needs client workflow purpose

Rule:

Missing context creates false confidence.

Dependency Type 3: Validation Dependency

The next step depends on validation.

Examples:

  • page cannot be saved before validation
  • dashboard item cannot display before review
  • M cannot receive brief before developer validation
  • offer cannot move to test before Finance and Experimentation review

Rule:

Validation dependencies must be visible before routing.

Dependency Type 4: Approval Dependency

The next step requires human approval.

Examples:

  • MCR save
  • developer handoff
  • paid traffic action
  • client report delivery
  • public content
  • finance decision
  • live system change

Rule:

Approval dependencies must not be bypassed by automation.

Dependency Type 5: Tool Permission Dependency

The next step requires approved tool access.

Examples:

  • Gmail read
  • Supabase write
  • WordPress read
  • Google Ads access
  • client CRM access
  • n8n/Make trigger

Rule:

If tool permission is unclear, tool use must stop.

Dependency Type 6: Sequence Dependency

One step must happen before another.

Examples:

  • clean before summarize
  • research before analysis
  • draft before review
  • review before validation
  • validation before routing
  • manual proof before automation

Rule:

Sequence errors create hidden workflow failure.

Dependency Type 7: Risk Dependency

The next step depends on risk classification.

Examples:

  • low-risk summary can be handled quickly
  • high-risk developer brief needs validation
  • critical client output needs human approval
  • finance action requires conservative review

Rule:

Risk level determines how much control is required.

Exchange Zone Control Checklist

Before work crosses an Exchange Zone, check:

  1. Who is the sender?
  2. Who is the receiver?
  3. What is being transferred?
  4. Why is it being transferred?
  5. What work has already been completed?
  6. What output was produced?
  7. What source material supports it?
  8. What context must be preserved?
  9. What known gaps exist?
  10. What assumptions exist?
  11. What validation status applies?
  12. What risk level applies?
  13. What dependencies remain?
  14. What approval is required?
  15. What tool permission is required?
  16. What is the required next action?
  17. Who owns the next action?
  18. What should stop the workflow?
  19. What must be logged?
  20. What learning should be captured?

If several answers are unclear, the Exchange Zone is not ready.

Exchange Zone Record Template

Use this template when a handoff or dependency point is important.

Exchange Zone Name

Field:
Exchange Zone Name:

Exchange Zone Type

Field:
Exchange Zone Type:

Recommended values:

  • AI Employee To AI Employee
  • Brain To Brain
  • Human To AI
  • AI To Human
  • Workflow Stage
  • Tool Output To Workflow
  • Queue To Action
  • MCR To Brain Site
  • Developer Exchange
  • Client Exchange

Sender

Field:
Sender:

Receiver

Field:
Receiver:

Source Material

Field:
Source Material:

Output Being Transferred

Field:
Output Being Transferred:

Work Completed

Field:
Work Completed:

Reason For Transfer

Field:
Reason For Transfer:

Required Input For Receiver

Field:
Required Input For Receiver:

Context To Preserve

Field:
Context To Preserve:

Known Gaps

Field:
Known Gaps:

Assumptions

Field:
Assumptions:

Dependencies

Field:
Dependencies:

Validation Status

Field:
Validation Status:

Risk Level

Field:
Risk Level:

Recommended values:

  • Low
  • Medium
  • High
  • Critical

Human Approval Required

Field:
Human Approval Required: Yes / No

Tool Permission Required

Field:
Tool Permission Required: Yes / No

Stop Conditions

Field:
Stop Conditions:

Required Next Action

Field:
Required Next Action:

Owner Of Next Action

Field:
Owner Of Next Action:

Logging Required

Field:
Logging Required: Yes / No

Learning Capture Required

Field:
Learning Capture Required: Yes / No

Exchange Status

Field:
Exchange Status:

Recommended values:

  • Draft
  • Ready For Transfer
  • Waiting For Input
  • Waiting For Validation
  • Waiting For Approval
  • Transferred
  • Blocked
  • Parked
  • Rejected
  • Escalated
  • Completed

Quick Use Version

Exchange Zone Name:
Exchange Zone Type:
Sender:
Receiver:
Source Material:
Output Being Transferred:
Work Completed:
Reason For Transfer:
Required Input For Receiver:
Context To Preserve:
Known Gaps:
Assumptions:
Dependencies:
Validation Status:
Risk Level:
Human Approval Required:
Tool Permission Required:
Stop Conditions:
Required Next Action:
Owner Of Next Action:
Logging Required:
Learning Capture Required:
Exchange Status:

Example 1: Course Absorption To MCR Exchange

Exchange Zone Name:
Course Absorption To MCR Page Creation Exchange

Exchange Zone Type:
AI To Human / Workflow Stage / MCR Exchange

Sender:
Course Absorption Agent

Receiver:
Martyn / MCR Page Creation

Source Material:
Course transcript or lesson block

Output Being Transferred:
Full MCR page output

Work Completed:
Course material reviewed, system value extracted, page draft created.

Reason For Transfer:
Output may be saved as an MCR Source Of Truth page.

Required Input For Receiver:
Full page output, parent page, page title, document type, registry update need.

Context To Preserve:
MCR is source of truth. Do not create duplicate page. Human review required.

Known Gaps:
Existing page search may need confirmation.

Assumptions:
Assuming page title does not already exist unless checked.

Dependencies:
Duplicate check, page parent confirmation, human review.

Validation Status:
Needs Validation / Human Review Required

Risk Level:
Medium

Human Approval Required:
Yes

Tool Permission Required:
No, unless WordPress access is being used.

Stop Conditions:
Duplicate page found, parent unclear, source incomplete, content weak.

Required Next Action:
Review, save to MCR if approved, update registry if needed.

Owner Of Next Action:
Martyn

Logging Required:
Yes if saved

Learning Capture Required:
Yes

Exchange Status:
Ready For Transfer

Example 2: Newsletter Queue To Routed Action Exchange

Exchange Zone Name:
Newsletter Queue Item To Routed Action Exchange

Exchange Zone Type:
Queue To Action

Sender:
Newsletter Queue Review

Receiver:
Routed Actions / HeadOffice Dashboard

Source Material:
Newsletter intelligence record

Output Being Transferred:
Reviewed signal action

Work Completed:
Signal extracted, primary Brain assigned, priority and urgency proposed.

Reason For Transfer:
Signal is strong enough to become an actionable routed item.

Required Input For Receiver:
Signal, Brain owner, action type, due timing, owner, next step, status.

Context To Preserve:
Do not treat generic AI news as routed action. Human review required before downstream action.

Known Gaps:
May need current verification if signal affects tools, compliance, ads, or finance.

Assumptions:
Signal source is accurate but may need verification before action.

Dependencies:
Queue review decision, validation, owner assignment.

Validation Status:
Needs Validation / Reviewed

Risk Level:
Medium

Human Approval Required:
Yes before downstream action

Tool Permission Required:
No unless task creation is automated.

Stop Conditions:
Generic signal, unclear Brain, missing action, high-risk claim unverified.

Required Next Action:
Route, park, reject, or create reviewed action.

Owner Of Next Action:
HeadOffice

Logging Required:
Yes

Learning Capture Required:
Yes if repeated pattern appears

Exchange Status:
Waiting For Review

Example 3: Affiliate Brain To Research Brain Exchange

Exchange Zone Name:
Affiliate Offer To Research Brain Exchange

Exchange Zone Type:
Brain To Brain

Sender:
Affiliate Brain

Receiver:
Research Brain

Source Material:
Offer intake and sales page

Output Being Transferred:
Research request

Work Completed:
Offer captured and preliminary evaluation started.

Reason For Transfer:
Offer requires evidence verification before test or finance review.

Required Input For Receiver:
Offer name, network, niche, claims, payout if known, research questions, risk notes.

Context To Preserve:
Vendor claims are not evidence. Do not move toward spend until evidence and finance review exist.

Known Gaps:
Payout, EPC, refund risk, vendor reliability, traffic costs may be missing.

Assumptions:
Offer may be viable but unverified.

Dependencies:
Research evidence, current data, compliance review where needed.

Validation Status:
Source Verification Required

Risk Level:
High

Human Approval Required:
Yes before spend or testing

Tool Permission Required:
Possibly, if web or network research is required.

Stop Conditions:
No reliable evidence, compliance concern, unsupported claims, weak traffic fit.

Required Next Action:
Research and return evidence brief.

Owner Of Next Action:
Research Brain

Logging Required:
Yes

Learning Capture Required:
Yes

Exchange Status:
Ready For Transfer

Example 4: Developer Support To M Exchange

Exchange Zone Name:
Developer Brief To M Exchange

Exchange Zone Type:
Developer Exchange / AI To Human

Sender:
Developer Support Agent / HeadOffice

Receiver:
M

Source Material:
Screenshot, file content, user instruction, current save point

Output Being Transferred:
Developer handoff brief

Work Completed:
Issue analyzed and exact instruction prepared.

Reason For Transfer:
M needs to implement or review a specific change.

Required Input For Receiver:
Site, file path, exact change, what not to touch, test steps, expected result.

Context To Preserve:
M must not guess. Do not touch unrelated systems. Current save point matters.

Known Gaps:
Any missing file path or file content must be stated.

Assumptions:
No hidden system state unless confirmed.

Dependencies:
Human review, file evidence, test plan.

Validation Status:
High Risk Validation Required

Risk Level:
High

Human Approval Required:
Yes

Tool Permission Required:
No unless live system access is involved.

Stop Conditions:
M would need to guess, file path missing, live risk unclear, unrelated system impact.

Required Next Action:
M applies only the stated change and reports result.

Owner Of Next Action:
M

Logging Required:
Yes

Learning Capture Required:
Yes if save point or rule changes

Exchange Status:
Ready For Transfer After Review

Example 5: Brain Room To AI Manager Exchange

Exchange Zone Name:
Brain Room Request To AI Manager Exchange

Exchange Zone Type:
Human To AI / Workflow Stage

Sender:
Brain Room

Receiver:
AI Manager

Source Material:
Brain Room message and thread context

Output Being Transferred:
Structured request candidate

Work Completed:
Message captured and request identified.

Reason For Transfer:
Brain Room discussion may need to become structured AI work.

Required Input For Receiver:
Message, sender, thread, task type, owning Brain, risk level, current context.

Context To Preserve:
Brain Room is discussion space; not every message becomes a task. Human review needed for medium/high-risk work.

Known Gaps:
Message may mix multiple tasks or lack detail.

Assumptions:
Request should be classified before task creation.

Dependencies:
Input normalization, task classification, Brain routing, human review where needed.

Validation Status:
Needs Classification

Risk Level:
Variable

Human Approval Required:
Yes for medium/high-risk tasks

Tool Permission Required:
Only if automation is enabled later.

Stop Conditions:
Unclear task, mixed requests, M active build affected, high-risk action requested.

Required Next Action:
Create Agentic Work Unit, respond, park, reject, or escalate.

Owner Of Next Action:
AI Manager / HeadOffice

Logging Required:
Yes if task created

Learning Capture Required:
Yes if repeated request pattern appears

Exchange Status:
Draft

Exchange Zone Readiness Checklist

Before approving an Exchange Zone, check:

  1. Is the sender clear?
  2. Is the receiver clear?
  3. Is the output being transferred clear?
  4. Is the reason for transfer clear?
  5. Is the required input for the receiver defined?
  6. Is work completed summarized?
  7. Is source material referenced?
  8. Is context preserved?
  9. Are known gaps stated?
  10. Are assumptions marked?
  11. Are dependencies listed?
  12. Is validation status clear?
  13. Is risk level assigned?
  14. Is human approval required?
  15. Is tool permission required?
  16. Are stop conditions listed?
  17. Is required next action clear?
  18. Is next owner clear?
  19. Is logging required?
  20. Is learning capture required?
  21. Does the receiver have enough to continue safely?
  22. Is the Exchange Zone too vague?
  23. Should the work be parked instead?
  24. Should the work be escalated?
  25. Is automation premature?

If several answers are unclear, the Exchange Zone is not ready.

Common Exchange Zone Failure Modes

Exchange Zone control has failed if:

  1. The receiver is unclear.
  2. The sender assumes the receiver understands missing context.
  3. The output has no validation status.
  4. The required next action is vague.
  5. Dependencies are hidden.
  6. Work moves forward before required input exists.
  7. Human approval is skipped.
  8. Tool permission is assumed.
  9. The output format does not match receiver needs.
  10. A queue item becomes an action without review.
  11. M receives vague instructions.
  12. MCR receives unvalidated page output.
  13. Dashboard receives weak signals.
  14. Client output moves forward without approval.
  15. Partial failure is hidden instead of contained.

Manual Use Rule

This framework should be used manually before Exchange Zones become technical infrastructure.

Manual use helps MWMS learn:

  • where handoffs fail
  • which dependencies repeat
  • where validation is missing
  • which Exchange Zones need structured records
  • which handoffs can remain simple
  • which require human approval
  • which may later become Supabase status transitions
  • which may become Brain Room or AI Manager routing rules
  • which should never be automated

Manual Exchange Zone proof comes before automation.

Future Plugin Or UI Relevance

This framework may later support:

  • Exchange Zone Registry
  • Brain-to-Brain handoff screens
  • Brain Room to AI Manager handoff workflow
  • AI Employee Router dependency rules
  • Task Executor stage transitions
  • HeadOffice dependency dashboard
  • Developer handoff panel for M
  • Newsletter Queue to Routed Action controls
  • Opportunity System handoff controls
  • AIBS client workflow approval gates

Possible future fields:

  • exchange_zone_id
  • exchange_zone_name
  • exchange_zone_type
  • sender
  • receiver
  • source_material
  • output_transferred
  • work_completed
  • reason_for_transfer
  • required_input_for_receiver
  • context_to_preserve
  • known_gaps
  • assumptions
  • dependencies
  • validation_status
  • risk_level
  • human_approval_required
  • tool_permission_required
  • stop_conditions
  • required_next_action
  • owner_next_action
  • logging_required
  • learning_capture_required
  • exchange_status
  • created_at
  • updated_at

No technical build is authorized by this framework alone.

Governance Role

HeadOffice owns the MWMS AI Exchange Zone And Dependency Control Framework.

HeadOffice is responsible for:

  • defining Exchange Zone governance
  • preventing vague handoffs
  • ensuring dependencies are visible
  • ensuring work does not move forward without required input
  • ensuring validation status travels with work
  • ensuring high-risk exchanges require human review
  • ensuring tool permission dependencies are respected
  • protecting M from unclear developer handoffs
  • protecting MCR from unvalidated page outputs
  • protecting dashboards from weak signals
  • protecting future AIBS client systems
  • deciding when Exchange Zones are ready for operational copy or plugin/UI transformation

Individual Brains may define specialized Exchange Zones, but HeadOffice governs cross-Brain, high-risk, developer, tool-enabled, automation-related, and client-facing exchanges.

Relationship To Other MWMS Standards

This framework supports and must align with:

  • MWMS AI Agent Operations Core
  • MWMS AI Multi Agent Role Design Framework
  • MWMS AI Agent Skill Library Framework
  • MWMS AI Plugin Orchestration Framework
  • MWMS AI Documentation Automation Pipeline Framework
  • MWMS AI Employee Handoff Protocol
  • MWMS AI Employee Handoff Package Template
  • MWMS AI Workflow Pipeline Standard
  • MWMS AI Workflow Pipeline Checklist
  • MWMS Agentic Work Unit Standard
  • MWMS Agentic Work Unit Template
  • MWMS AI Agent Context Pack Template
  • MWMS AI Output Validation Standard
  • MWMS AI Output Validation Checklist
  • MWMS AI Tool Permission Record Template
  • MWMS AI Agent Failure Handling And Escalation Protocol
  • MWMS AI Agent Failure Log Record
  • MWMS AI Agent Outcome Measurement Framework
  • MWMS AI Agent Outcome Log Record
  • MWMS Brain Routing Rule
  • MWMS Brain To Brain Request Protocol
  • MWMS Supabase Event Schema
  • MCR To Brain Copy Rule
  • AI Business Systems Brain Blueprint

This framework adds the controlled transition and dependency layer to the MWMS AI Agent Operations Core.

Drift Protection

This framework protects MWMS from the following forms of drift:

  1. Treating handoffs as informal chat
  2. Losing context between AI Employees
  3. Moving work between Brains without reason
  4. Letting dependencies remain hidden
  5. Allowing outputs to move without validation status
  6. Creating orphaned tasks
  7. Sending vague developer instructions to M
  8. Copying MCR content to Brain sites without transformation rules
  9. Turning queue items into actions without review
  10. Letting tool outputs enter workflows unchecked
  11. Allowing partial failures to corrupt downstream work
  12. Skipping human approval at high-risk transition points
  13. Automating handoffs before manual proof
  14. Losing accountability between workflow stages
  15. Creating client-facing outputs without approval gates

Any important transition without Exchange Zone control should be treated as incomplete.

Architectural Intent

The architectural intent of the MWMS AI Exchange Zone And Dependency Control Framework is to make handoffs safe, visible, and reliable.

MWMS is building a coordinated AI workforce.

Coordinated work depends on controlled transitions.

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

  • Who is sending the work?
  • Who is receiving the work?
  • What is being transferred?
  • Why is it being transferred?
  • What has already been done?
  • What does the receiver need?
  • What dependencies remain?
  • What context must travel with the output?
  • What validation status applies?
  • What risk level applies?
  • What should stop the workflow?
  • Who owns the next action?
  • What must be logged?
  • What learning should be captured?

When MWMS controls Exchange Zones properly, the system can scale from manual collaboration into future automation without losing context, ownership, or safety.

Change Log

v1.0 — Initial Draft

Created the MWMS AI Exchange Zone And Dependency Control Framework to define how MWMS controls handoffs, dependencies, baton-passing, workflow transitions, tool output transitions, queue-to-action movement, developer handoffs, MCR-to-Brain transfers, and future client workflow exchanges.

This framework establishes Exchange Zone types, dependency controls, records, examples, readiness checks, failure modes, future plugin/UI relevance, governance role, drift protection, and architectural intent.

It establishes that work should not cross an Exchange Zone unless the receiver has what it needs to continue safely.