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
Version: v1.1
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, Automation Brain, AIBS Brain
Parent Page: HeadOffice
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR
Last Reviewed: 2026-06-18
Source / Origin: MWMS AI Exchange Zone And Dependency Control Framework v1.0 + AI Automations by Jack — Multi-Agent Orchestration, Independent Review, Rescue Routing, Persistent Agents, External Knowledge And Session Continuity Block
MWMS Classification: Exchange Zone Framework / Dependency Control Framework / Cross-Agent Transition Standard / Workflow Handoff Control Layer
Primary Brain: HeadOffice Brain
Supporting Brains: MWMS Brain, Automation Brain, Operations Brain, Data Brain, Risk Brain, Compliance Brain, SIT Brain, AIBS Brain
Related Pages: MWMS AI Agent Operations Core, MWMS AI Multi Agent Role Design Framework, MWMS AI Agent Skill Library Framework, MWMS AI Employee Handoff Protocol, MWMS AI Workflow Pipeline Standard, MWMS Agentic Work Unit Standard, MWMS AI Output Validation Standard, MWMS AI Agent Failure Handling And Escalation Protocol, MWMS AI Agent Outcome Measurement Framework, MWMS AI Ambiguity And Partial Failure Containment Framework, MWMS AI Agent Memory And Context Framework, MWMS AI Tool Permission And Access Framework, MWMS AI Observability Metadata Standard, MWMS Brain Routing Rule, MWMS Brain To Brain Request Protocol, MWMS Supabase Event Schema
Source Evidence: The existing framework defines Exchange Zones as controlled transition points between AI Employees, Brains, workflow stages, tools, queues, humans, MCR, developers and future client systems. The absorbed material strengthens the framework with Work Unit continuity, dependency-state controls, sender and receiver acceptance, model-route transfers, independent-review gates, rescue thresholds, persistent-agent checkpoints, external-knowledge provenance, tool-execution evidence and session-to-session continuity.

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 stage
  • model route
  • tool
  • queue
  • dashboard
  • developer
  • human reviewer
  • persistent agent
  • external knowledge system
  • future AIBS client workflow

to another.

These transition points are called Exchange Zones.

An Exchange Zone is where work changes hands, ownership, system, authority, format, workflow stage or operational destination.

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

They occur because:

  • the next role does not receive the right context
  • the handoff is vague
  • dependencies are hidden
  • validation status is missing
  • failure history is omitted
  • the sender assumes the receiver already understands
  • the receiver begins before required inputs exist
  • the output format does not match the destination
  • ownership is unclear
  • model-route changes lose state
  • tool success is assumed without outcome evidence
  • partial failure is hidden
  • human review is skipped
  • work moves forward when it should stop
  • a new session loses the previous save point

MWMS must treat transition points as controlled system zones, not casual transfers.

This framework makes Exchange Zones:

  • visible
  • structured
  • governed
  • validated
  • accepted
  • measurable
  • stoppable
  • recoverable

Scope

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

This includes exchanges between:

  • AI Employee and AI Employee
  • model route and model route
  • Brain and Brain
  • AI Employee and human
  • human and AI Employee
  • Brain Room and AI Manager
  • AI Manager and AI Employee Router
  • AI Employee Router and Task Executor
  • Task Executor and validation
  • validation and routing
  • producing agent and independent reviewer
  • failed route and Rescue Agent
  • Course Absorption and MCR page creation
  • Newsletter Intelligence and Queue Review
  • Queue Review and Routed Actions
  • Affiliate Brain and Research Brain
  • Research Brain and Experimentation Brain
  • Experimentation Brain and Finance Brain
  • Finance Brain and HeadOffice
  • HeadOffice and M
  • Developer Support and M
  • MCR and Brain sites
  • AI workflow and dashboard
  • tool output and workflow
  • persistent agent and human owner
  • external knowledge system and reasoning agent
  • one work session and the next
  • future AIBS workflow and client review

This framework applies to:

  • manual exchanges
  • assisted exchanges
  • automated exchanges
  • cross-model exchanges
  • persistent-agent exchanges
  • client-facing exchanges

This framework does not authorise development work.

It defines the control logic that must be proven manually before automation, plugin, UI, queue or Task Executor implementation.

Core Definition

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

An Exchange Zone includes:

  • Exchange Zone ID
  • Work Unit ID
  • sender
  • receiver
  • sender authority
  • receiver authority
  • output being transferred
  • required receiver input
  • current workflow state
  • validation status
  • independent-review status
  • risk level
  • context to preserve
  • source evidence
  • known gaps
  • assumptions
  • failure history
  • dependencies
  • permissions
  • next action
  • owner of next action
  • acceptance status
  • stop conditions
  • rescue conditions
  • logging requirement
  • knowledge commitment requirement
  • closure requirement

A handoff is the package transferred.

The Exchange Zone is the governed transition where that handoff is checked, accepted, blocked, escalated, parked or rejected.

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 it?
  • What Work Unit does it belong to?
  • What exactly is being transferred?
  • What has already been completed?
  • What remains unresolved?
  • What source supports the work?
  • What context must travel?
  • What validation has occurred?
  • What failure history exists?
  • What dependencies remain?
  • What permissions apply?
  • What risk exists?
  • What should stop the workflow?
  • What rescue route applies?
  • Who owns the next action?
  • Has the receiver accepted the transfer?
  • What must be logged?
  • What knowledge should be committed?

If those questions cannot be answered, the work should:

  • pause
  • return for revision
  • move to review
  • be parked
  • be rejected
  • be escalated
  • trigger rescue

Exchange Zone State Rule

Work crossing an Exchange Zone should carry an explicit state.

Recommended states:

  • Draft
  • Waiting For Input
  • Waiting For Context
  • Waiting For Validation
  • Waiting For Independent Review
  • Waiting For Human Approval
  • Ready For Transfer
  • Transferred
  • Received
  • Accepted
  • Accepted With Conditions
  • Needs Clarification
  • Blocked
  • Rescue Required
  • Parked
  • Rejected
  • Escalated
  • Completed
  • Closed

Rule

Transferred does not mean accepted.

Accepted does not mean completed.

Completed does not mean closed.

Exchange Zone Types

MWMS recognises the following Exchange Zone types.

  1. AI Employee To AI Employee Exchange

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

Examples:

  • Researcher Agent → Analyst Agent
  • Analyst Agent → Writer Agent
  • Writer Agent → Reviewer Agent
  • Reviewer Agent → Validator Agent
  • Validator Agent → Router Agent

Required controls:

  • Work Unit ID
  • sender
  • receiver
  • completed stage
  • output
  • source references
  • context
  • validation status
  • known gaps
  • failure history
  • required next action
  • role boundary
  • receiver acceptance

Rule

AI Employee exchanges must preserve task meaning, not merely transfer output text.

  1. Model To Model Exchange

This occurs when work moves from one model or capability route to another.

Examples:

  • bulk extraction model → advanced reasoning model
  • primary model → independent reviewer
  • failed model route → Rescue Agent route
  • text model → multimodal model
  • hosted model → local private model

Required controls:

  • original task
  • Work Unit ID
  • previous model role
  • output produced
  • evidence used
  • assumptions
  • failure history
  • reason for route change
  • expected contribution from the next model
  • validation requirement

Rule

A model change must not reset or erase task history.

  1. Brain To Brain Exchange

This occurs when one Brain passes work to another.

Examples:

  • Affiliate Brain → Research Brain
  • Research Brain → Experimentation Brain
  • Experimentation Brain → Finance Brain
  • Finance Brain → HeadOffice
  • Content Brain → Ads Brain
  • Newsletter Intelligence → relevant specialist Brain

Required controls:

  • Originating Brain
  • Receiving Brain
  • reason for transfer
  • source material
  • current decision status
  • Supporting Brains
  • risk
  • expected receiver output
  • final authority
  • logging requirement

Rule

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

  1. Human To AI Exchange

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

Examples:

  • Martyn uploads course files
  • Martyn asks for MCR review
  • M reports a development issue
  • Martyn supplies screenshots
  • client supplies source material
  • human reviewer approves AI processing

Required controls:

  • current request
  • source
  • source completeness
  • human intent
  • known constraints
  • current save point
  • forbidden areas
  • required output
  • review requirements

Rule

Human input must be normalised before it becomes serious AI work.

  1. AI To Human Exchange

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

Examples:

  • full page output → Martyn
  • developer brief → M
  • validation report → HeadOffice
  • client report draft → client approver
  • readiness review → decision owner

Required controls:

  • clear verdict
  • work completed
  • source grounding
  • risk
  • known gaps
  • required human decision
  • next action
  • what not to do
  • approval stage
  • expected result

Rule

AI-to-human exchanges must make the human’s decision easier, not force them to reconstruct the work.

  1. Workflow Stage Exchange

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

Examples:

  • intake → normalization
  • normalization → classification
  • classification → Work Unit creation
  • research → analysis
  • draft → review
  • review → validation
  • validation → routing
  • routing → outcome logging
  • outcome logging → knowledge commitment
  • knowledge commitment → closure

Required controls:

  • completed stage
  • next stage
  • stage output
  • pass or fail status
  • required next-stage inputs
  • open blockers
  • stop conditions

Rule

A workflow stage must not begin until the prior stage output is usable.

  1. Producer To Independent Reviewer Exchange

This occurs when output requires genuinely separate challenge.

Required controls:

  • original task
  • source material
  • producing role
  • producing model
  • output
  • applicable standard
  • risk level
  • disputed assumptions
  • review verdict required

The reviewer should return:

  • Pass
  • Pass With Conditions
  • Revise
  • Reject
  • Escalate

Rule

The reviewer must receive the original task and evidence, not merely the producer’s summary.

  1. Failed Route To Rescue Agent Exchange

This occurs when the normal route reaches the failure threshold.

Required controls:

  • original Work Unit
  • original source
  • expected outcome
  • exact failure
  • failure count
  • chronological attempt history
  • models and tools used
  • outputs produced
  • validation failures
  • current system state
  • inherited assumptions
  • risk
  • new verification gate

Rule

The Rescue Agent must use a materially different method.

  1. Tool Output To Workflow Exchange

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

Examples:

  • Gmail body → Newsletter Intelligence
  • extraction output → structured parser
  • parsed record → database
  • database row → dashboard
  • WordPress page list → duplicate check
  • uploaded transcript → Course Absorption
  • analytical calculation → Finance Brain

Required controls:

  • tool identity
  • approved permission
  • command or request
  • output completeness
  • schema match
  • error state
  • resulting system state
  • validation requirement
  • evidence of execution
  • failure route

Rule

Tool output is unvalidated until the affected state is checked.

  1. Queue To Action Exchange

This occurs when a queue item becomes active work.

Examples:

  • Newsletter Queue item → Routed Action
  • offer intake → research request
  • validation failure → revision task
  • Brain Room message → Agentic Work Unit
  • dashboard item → M task
  • parked item → active workflow

Required controls:

  • queue record
  • review decision
  • owner
  • priority
  • urgency
  • action type
  • validation status
  • next step
  • acceptance state

Rule

A queue item should not become action without a clear decision state and owner.

  1. MCR To Brain Site Exchange

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

Required controls:

  • exact MCR source page
  • source version
  • destination Brain
  • copy classification
  • transformation rule
  • what remains MCR-only
  • what becomes operational
  • what may become technical later
  • validation before copy
  • drift-control responsibility

Rule

MCR remains Source Of Truth.

Brain sites receive governed operational copies, not uncontrolled rewrites.

  1. Developer Exchange Zone

This occurs when work is handed to M or another developer.

Required controls:

  • exact site
  • exact system
  • exact file or screen
  • current evidence
  • current save point
  • exact required change
  • exact location
  • what not to touch
  • test steps
  • expected result
  • rollback
  • risk
  • approval
  • verification

Rule

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

  1. Persistent Agent To Human Exchange

This occurs when a scheduled or background AI Employee surfaces an alert, exception, report or decision request.

Required controls:

  • persistent-agent identity
  • owner
  • trigger or schedule
  • last successful run
  • current state
  • source evidence
  • failure count
  • cost state
  • shutdown status
  • recommended action
  • urgency
  • receiver

Rule

Persistent agents should surface qualified exceptions, not raw background noise.

  1. External Knowledge To Reasoning Exchange

This occurs when retrieved evidence is handed to a reasoning or decision role.

Required controls:

  • retrieval query
  • source collection
  • source authority
  • freshness
  • provenance
  • client or project boundary
  • retrieved evidence
  • conflicting evidence
  • evidence gaps
  • expected reasoning task

Rule

Retrieved material is evidence input.

It is not an approved decision.

  1. Session To Session Exchange

This occurs when work continues across sessions, chats, tools or interfaces.

Required controls:

  • session objective
  • completed work
  • incomplete work
  • decisions made
  • failures
  • current save point
  • current active page or record
  • open issues
  • exact next action
  • next owner
  • knowledge committed

Rule

A new session must not be required to rebuild the operating state from raw conversation history.

  1. Client Exchange Zone

This occurs in future AIBS client-facing workflows.

Examples:

  • client input → AI workflow
  • AI report → client review
  • client approval → delivery
  • client data → reporting pipeline
  • recommendation → business-owner decision

Required controls:

  • client identity
  • approved source
  • permission boundary
  • data isolation
  • privacy risk
  • approval gate
  • output status
  • human review
  • logging
  • acceptance
  • retention rule

Rule

Client Exchange Zones require stricter isolation, approval and audit controls than internal exchanges.

Dependency Control

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

MWMS must identify dependencies at every important Exchange Zone.

  1. Input Dependency

The receiver requires specific input.

Examples:

  • Analyst requires research evidence.
  • Writer requires approved analysis.
  • Developer Support requires current file evidence.
  • Finance Brain requires payout and cost assumptions.
  • Validator requires source and original task.

Rule

Missing input must remain visible and must block work where material.

  1. Context Dependency

The receiver requires current operational context.

Examples:

  • MCR draft requires exact parent.
  • developer handoff requires save point.
  • offer evaluation requires traffic goal.
  • client report requires client scope.
  • rescue route requires previous attempts.

Rule

Missing context creates false confidence.

  1. Source Authority Dependency

The receiver requires an authoritative or sufficiently reliable source.

Examples:

  • MCR comparison requires current MCR evidence.
  • finance decision requires verified figures.
  • legal or compliance work requires authoritative source.
  • current platform action requires current documentation.

Rule

A relevant source is not automatically an authoritative source.

  1. Validation Dependency

The next step depends on successful validation.

Examples:

  • MCR page cannot be saved before review.
  • dashboard item cannot display before readiness check.
  • developer brief cannot go to M before validation.
  • offer cannot move to test planning before required reviews.

Rule

Validation dependencies must be explicit.

  1. Independent Review Dependency

The next step requires separate review.

Examples:

  • major MCR update
  • compliance-sensitive output
  • finance decision
  • client-facing recommendation
  • live-system action
  • repeated model failure

Rule

Self-review does not satisfy an independent-review dependency.

  1. Approval Dependency

The next step requires human approval.

Examples:

  • MCR publication
  • developer handoff
  • paid traffic
  • client delivery
  • public content
  • live-system change
  • destructive action

Rule

Automation must not bypass human approval dependencies.

  1. Tool Permission Dependency

The next step requires approved access.

Examples:

  • Gmail read
  • database write
  • WordPress update
  • client CRM access
  • automation trigger
  • remote command

Rule

Task ownership does not automatically provide tool authority.

  1. Sequence Dependency

One stage must occur before another.

Examples:

  • normalise before analyse
  • research before decision
  • draft before review
  • review before validation
  • validation before routing
  • outcome verification before closure
  • manual proof before automation

Rule

Sequence errors create hidden workflow failure.

  1. Risk Dependency

The next control level depends on risk.

Examples:

  • low-risk summary may use light validation
  • high-risk developer brief needs formal review
  • critical client output needs human approval
  • finance decision needs conservative evidence

Rule

Risk level determines the strength of the Exchange Zone.

  1. Failure-State Dependency

The next step depends on whether failure thresholds have been reached.

Examples:

  • first failure may permit corrected retry
  • second materially identical failure triggers rescue
  • persistent-agent failure may require pause
  • repeated tool mismatch may require alternate route

Rule

Failure history must travel with the work.

  1. Outcome Dependency

The next stage depends on whether the intended outcome occurred.

Examples:

  • tool command must change the target state
  • action must be accepted
  • page must be saved
  • client must receive and understand delivery
  • alert must be resolved

Rule

Output alone does not satisfy an outcome dependency.

  1. Knowledge Commitment Dependency

Durable knowledge requires:

  • valid source
  • correct authority
  • validation
  • correct destination
  • duplication check
  • approval
  • version and status

Rule

Unverified work must not enter durable organisational memory.

Dependency State Model

Every material dependency should use one state:

  • Not Required
  • Required
  • Waiting
  • Satisfied
  • Partially Satisfied
  • Failed
  • Waived By Authorised Human
  • Blocked
  • Rescue Required

Rule

A partially satisfied dependency must not be presented as satisfied.

Critical Dependency Rule

A Critical Dependency is any dependency whose absence could affect:

  • MCR
  • finance
  • paid traffic
  • compliance
  • security
  • credentials
  • client data
  • live systems
  • public content
  • M’s active development work

Critical Dependencies must be:

  • explicitly identified
  • verified
  • approved where required
  • logged
  • preserved in the Handoff Package

Exchange Zone Control Checklist

Before work crosses an Exchange Zone, check:

  • Is the Exchange Zone ID present?
  • Is the Work Unit ID present?
  • Who is the sender?
  • Who is the receiver?
  • What authority does each hold?
  • What is being transferred?
  • Why is it being transferred?
  • What work is complete?
  • What remains incomplete?
  • What source supports it?
  • Is source authority clear?
  • What context must be preserved?
  • What known gaps exist?
  • What assumptions exist?
  • What failure history exists?
  • What validation status applies?
  • Is independent review required?
  • What risk level applies?
  • What dependencies remain?
  • What approval is required?
  • What tool permission is required?
  • What is the required next action?
  • Who owns the next action?
  • What should stop the workflow?
  • What triggers rescue?
  • Has the receiver accepted the transfer?
  • What must be logged?
  • What learning should be captured?
  • What knowledge should be committed?
  • How will the Exchange Zone close?

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

Exchange Zone Record Template

Exchange Zone ID:

Work Unit ID:

Exchange Zone Name:

Exchange Zone Type:

Workflow:

Workflow Stage:

Sender:

Sender Authority:

Receiver:

Receiver Authority:

Source Material:

Source Authority:

Output Being Transferred:

Work Completed:

Work Remaining:

Reason For Transfer:

Required Input For Receiver:

Context To Preserve:

Known Gaps:

Assumptions:

Failure History:

Dependencies:

Dependency States:

Critical Dependencies:

Validation Status:

Independent Review Status:

Risk Level:

Human Approval Required:

Tool Permission Required:

Tool Execution Evidence:

Stop Conditions:

Failure Threshold:

Rescue Route:

Required Next Action:

Owner Of Next Action:

Expected Receiver Output:

Expected Business Outcome:

Receiver Acceptance Status:

Logging Required:

Learning Capture Required:

Knowledge Commitment Required:

Closure Requirement:

Exchange Status:

Quick Use Version

Exchange Zone ID:

Work Unit ID:

Exchange Zone Name:

Exchange Zone Type:

Sender:

Receiver:

Source Material:

Output Being Transferred:

Work Completed:

Work Remaining:

Reason For Transfer:

Required Receiver Input:

Context To Preserve:

Known Gaps:

Assumptions:

Failure History:

Dependencies:

Validation Status:

Independent Review Status:

Risk Level:

Human Approval Required:

Tool Permission Required:

Stop Conditions:

Failure Threshold:

Rescue Route:

Required Next Action:

Owner Of Next Action:

Receiver Acceptance Status:

Logging Required:

Knowledge Commitment 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

Source Material:

Course transcript, PDF or lesson block

Output Being Transferred:

Full MCR page output or approved page-update recommendation

Work Completed:

Source reviewed, useful value extracted, existing MCR compared and output prepared.

Work Remaining:

Human review, WordPress save, registry action where confirmed and session save point.

Required Input For Receiver:

  • exact title
  • exact parent
  • document type
  • preserved status
  • full page output
  • Change Impact Declaration
  • duplication result

Context To Preserve:

  • MCR is Source Of Truth.
  • Prefer update over new-page creation.
  • Do not invent existing pages.
  • Do not interfere with M’s active work.

Dependencies:

  • current MCR comparison
  • exact parent
  • human review
  • duplication check
  • approved status

Stop Conditions:

  • source incomplete
  • duplicate unresolved
  • parent uncertain
  • weak system value
  • incorrect Brain name
  • unsupported claim

Owner Of Next Action:

Martyn

Receiver Acceptance Status:

Human Review Required

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 business signal

Required Receiver Input:

  • signal
  • source
  • Owning Brain
  • priority
  • urgency
  • action type
  • owner
  • next step
  • validation status

Dependencies:

  • queue decision
  • signal usefulness
  • source verification where required
  • owner assignment
  • human review for material action

Stop Conditions:

  • generic AI news
  • unsupported urgency
  • unclear Brain
  • no action
  • current claim unverified

Expected Business Outcome:

Useful intelligence becomes owned action while noise is rejected.

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 evidence

Output Being Transferred:

Structured research request

Required Receiver Input:

  • offer identity
  • niche
  • promise
  • mechanism
  • payout where known
  • vendor claims
  • research questions
  • compliance concerns
  • traffic goal

Context To Preserve:

Vendor claims are not verified evidence.

Dependencies:

  • current research
  • source authority
  • compliance review where required
  • finance review before spend

Stop Conditions:

  • vendor identity unclear
  • major compliance issue
  • no credible evidence
  • weak traffic fit
  • missing critical source

Expected Receiver Output:

Evidence brief with source authority, gaps and recommendation.

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:

Current screenshot, file content, user instruction and save point

Output Being Transferred:

Developer Handoff Package

Required Receiver Input:

  • exact site
  • exact system area
  • exact file or screen
  • current state
  • exact change
  • what not to touch
  • test steps
  • expected result
  • rollback where relevant

Dependencies:

  • current evidence
  • exact scope
  • human approval
  • test plan
  • developer boundary

Stop Conditions:

  • M must guess
  • current file absent
  • hidden state unresolved
  • live-system risk unclear
  • unrelated system may be affected

Expected Business Outcome:

M can implement the required change safely and verify the result.

Exchange Status:

Ready For Transfer After Review

Example 5: Primary Agent To Independent Reviewer Exchange

Exchange Zone Name:

High-Risk Output To Independent Reviewer Exchange

Exchange Zone Type:

Producer To Independent Reviewer

Sender:

Producing AI Employee

Receiver:

Independent Reviewer

Source Material:

Original Work Unit, source material and draft output

Output Being Transferred:

High-risk draft requiring independent review

Required Receiver Input:

  • original objective
  • source evidence
  • producing role
  • model route
  • output
  • assumptions
  • risk
  • applicable standard

Dependencies:

  • genuine reviewer independence
  • source availability
  • formal review verdict
  • human approval where required

Stop Conditions:

  • reviewer lacks original source
  • reviewer inherits unsupported assumptions
  • reviewer is not independent
  • high-risk issues remain unresolved

Expected Receiver Output:

Pass, Pass With Conditions, Revise, Reject or Escalate.

Exchange Status:

Waiting For Independent Review

Example 6: Failed Route To Rescue Agent Exchange

Exchange Zone Name:

Repeated Failure To Rescue Agent Exchange

Exchange Zone Type:

Failed Route To Rescue Agent

Sender:

Failure Handler / Original Workflow

Receiver:

Rescue Agent

Source Material:

Original Work Unit, source, prior attempts, outputs and failure records

Output Being Transferred:

Rescue Packet

Failure History:

Two materially identical failures without verified progress.

Dependencies:

  • complete attempt history
  • preserved current state
  • materially different rescue route
  • new verification gate
  • human escalation where risk is high

Stop Conditions:

  • Rescue Agent repeats failed approach
  • failure history is incomplete
  • source is unavailable
  • authority is unclear

Expected Receiver Output:

Independent diagnosis, alternative route, corrected output or stop recommendation.

Exchange Status:

Rescue Required

Example 7: Persistent Agent To Human Exchange

Exchange Zone Name:

Persistent Monitoring Alert To Human Owner

Exchange Zone Type:

Persistent Agent To Human

Sender:

Persistent Monitoring Agent

Receiver:

Human Owner / HeadOffice

Source Material:

Approved monitoring source and latest agent run

Output Being Transferred:

Qualified alert or exception report

Required Receiver Input:

  • alert
  • source
  • last-known state
  • current state
  • confidence
  • failure count
  • risk
  • recommended action
  • urgency

Dependencies:

  • source freshness
  • duplicate suppression
  • cost boundary
  • human review
  • shutdown control

Stop Conditions:

  • source stale
  • repeated false alerts
  • failure threshold reached
  • cost limit exceeded
  • owner unavailable for required approval

Expected Business Outcome:

A meaningful exception reaches the correct human without background noise.

Exchange Status:

Waiting For Human Review

Example 8: Session To Session Exchange

Exchange Zone Name:

Course Absorption Session Closure Exchange

Exchange Zone Type:

Session To Session

Sender:

Current Course Absorption Session

Receiver:

Next Course Absorption Session

Output Being Transferred:

Current save point and next-work instruction

Required Receiver Input:

  • course name
  • block completed
  • pages updated
  • pages still remaining
  • current source files
  • unresolved issues
  • exact next page
  • exact next action

Dependencies:

  • accurate save point
  • completed work separated from incomplete work
  • status preserved
  • durable knowledge committed

Stop Conditions:

  • completed pages uncertain
  • next page uncertain
  • incorrect status
  • unresolved output error

Expected Business Outcome:

The next session resumes immediately without repeating completed work.

Exchange Status:

Ready For Next Session

Exchange Zone Acceptance

The receiver should assign one acceptance state:

Accepted

The package is complete and work may continue.

Accepted With Conditions

Work may continue after stated conditions are met.

Needs Clarification

Important information is missing.

Rejected

The transfer is invalid, misrouted or unsafe.

Escalated

Authority or risk requires higher review.

Parked

The transfer is valid but should not proceed now.

Rule

The receiver must not silently continue from an incomplete exchange.

Dependency Escalation Rule

Escalate a dependency when:

  • it remains blocked beyond the workflow’s useful timeframe
  • the owner is unclear
  • required authority is unavailable
  • source evidence cannot be obtained
  • permission remains unresolved
  • the dependency repeatedly fails
  • business impact is high
  • continuing would create risk

Escalation should identify:

  • blocked dependency
  • reason
  • owner
  • risk
  • required decision
  • safe fallback
  • next review point

Deterministic Rescue Rule

The standard rescue threshold is:

Two materially identical failures without verified progress.

At the threshold:

  • stop the current route
  • freeze the Work Unit
  • preserve failure history
  • create a Rescue Packet
  • assign a materially different route
  • define a new verification gate

Rule

Changing wording or starting a new session does not reset the failure count.

Tool Execution Evidence Rule

Where an Exchange Zone includes tool action, record:

  • tool
  • requested action
  • approved permission
  • target
  • response
  • resulting system state
  • error state
  • verification evidence

Rule

A generated command is not proof of execution.

A successful API response is not proof of the intended business outcome unless the target state is verified.

Cross-Interface Continuity Rule

Where work moves between:

  • chat
  • Brain Room
  • dashboard
  • MCR
  • task system
  • email
  • remote channel
  • local agent
  • hosted agent
  • client interface

the Exchange Zone must preserve:

  • Work Unit ID
  • source
  • owner
  • current state
  • validation
  • failure history
  • next action
  • destination

Rule

Changing interface must not reset the task.

Exchange Zone Readiness Checklist

Before approving an Exchange Zone, check:

  • Is the sender clear?
  • Is the receiver clear?
  • Is the Work Unit clear?
  • Is the output clear?
  • Is the transfer reason clear?
  • Is completed work summarised?
  • Is remaining work visible?
  • Is the source referenced?
  • Is source authority clear?
  • Is context preserved?
  • Are gaps stated?
  • Are assumptions marked?
  • Is failure history preserved?
  • Are dependencies listed?
  • Is each dependency state clear?
  • Are Critical Dependencies identified?
  • Is validation status clear?
  • Is independent review required?
  • Is risk assigned?
  • Is human approval required?
  • Is tool permission required?
  • Is execution evidence required?
  • Are stop conditions listed?
  • Is the failure threshold defined?
  • Is the Rescue Route defined?
  • Is the next action clear?
  • Is the next owner clear?
  • Is the expected output clear?
  • Is the expected business outcome clear?
  • Has the receiver accepted?
  • Is logging required?
  • Is knowledge commitment required?
  • Is closure defined?
  • Should the work be parked?
  • Should the work be escalated?
  • Is automation premature?

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

Common Exchange Zone Failure Modes

Exchange Zone control has failed when:

  • the receiver is unclear
  • the sender assumes missing context
  • Work Unit identity is lost
  • validation status is omitted
  • failure history is omitted
  • the next action is vague
  • dependencies are hidden
  • a dependency is partially satisfied but marked complete
  • human approval is skipped
  • tool permission is assumed
  • tool execution is not verified
  • output format does not match receiver needs
  • queue item becomes action without review
  • M receives vague instructions
  • MCR receives unvalidated output
  • dashboard receives weak signals
  • independent review is not genuinely independent
  • Rescue Agent repeats the failed route
  • persistent-agent alerts have no owner
  • client output moves without approval
  • session continuity is lost
  • knowledge is committed before validation
  • partial failure is hidden

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 recur
  • where validation is missing
  • which Exchange Zones need structured records
  • which exchanges may remain lightweight
  • which require independent review
  • which require human approval
  • where Rescue Routes are needed
  • which transitions may later become database states
  • 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 workflow
  • AI Employee Router dependency controls
  • Task Executor stage transitions
  • HeadOffice dependency dashboard
  • developer handoff panel
  • independent-review queue
  • Rescue Agent queue
  • persistent-agent alert controls
  • Newsletter Queue to Routed Action control
  • Opportunity System handoffs
  • AIBS client approval gates

Possible future fields:

exchange_zone_id

work_unit_id

exchange_zone_name

exchange_zone_type

workflow

workflow_stage

sender

sender_authority

receiver

receiver_authority

source_material

source_authority

output_transferred

work_completed

work_remaining

reason_for_transfer

required_receiver_input

context_to_preserve

known_gaps

assumptions

failure_history

dependencies

dependency_states

critical_dependencies

validation_status

independent_review_status

risk_level

human_approval_required

tool_permission_required

tool_execution_evidence

stop_conditions

failure_threshold

rescue_route

required_next_action

owner_next_action

expected_receiver_output

expected_business_outcome

receiver_acceptance_status

logging_required

learning_capture_required

knowledge_commitment_required

closure_requirement

exchange_status

created_at

updated_at

No technical build is authorised 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 remain visible
  • ensuring Critical Dependencies are satisfied
  • ensuring validation travels with work
  • ensuring failure history travels with work
  • governing independent review
  • enforcing Rescue Routes
  • protecting human approval gates
  • ensuring tool permissions are respected
  • ensuring tool execution is verified
  • protecting M from unclear developer work
  • protecting MCR from unvalidated output
  • protecting dashboards from weak signals
  • protecting persistent-agent workflows
  • protecting future AIBS clients
  • governing session continuity
  • deciding when Exchange Zones are ready for technical implementation

Individual Brains may define specialised Exchange Zones.

HeadOffice governs:

  • cross-Brain exchanges
  • high-risk exchanges
  • MCR exchanges
  • developer exchanges
  • tool-enabled exchanges
  • persistent-agent exchanges
  • rescue exchanges
  • client exchanges
  • automation-related exchanges

Relationship To SIT Brain

SIT Brain may:

  • verify Exchange Zone completeness
  • verify dependency states
  • detect missing Critical Dependencies
  • detect false transfer readiness
  • enforce validation gates
  • verify independent-review status
  • verify failure thresholds
  • trigger Rescue Routing
  • verify tool execution evidence
  • block unsafe transfers
  • detect missing receiver acceptance
  • prevent premature knowledge commitment
  • verify closure

Relationship To Data Brain

Data Brain supports:

  • Exchange Zone IDs
  • Work Unit linkage
  • sender and receiver records
  • dependency states
  • validation records
  • failure history
  • acceptance records
  • tool-execution evidence
  • Rescue Packets
  • outcome records
  • status history
  • knowledge-commitment records
  • closure records

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 Workflow Pipeline Standard
  • MWMS Agentic Work Unit Standard
  • MWMS AI Agent Memory And Context Framework
  • MWMS AI Output Validation Standard
  • MWMS AI Tool Permission And Access Framework
  • MWMS AI Agent Failure Handling And Escalation Protocol
  • MWMS AI Agent Outcome Measurement Framework
  • MWMS AI Ambiguity And Partial Failure Containment Framework
  • MWMS Brain Routing Rule
  • MWMS Brain To Brain Request Protocol
  • MWMS Supabase Event Schema
  • MCR To Brain Copy Rule
  • AIBS 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:

  • informal handoffs
  • lost context
  • model-route resets
  • unexplained Brain transfers
  • hidden dependencies
  • output moving without validation
  • orphaned tasks
  • vague developer instructions
  • uncontrolled MCR-to-Brain copying
  • queue items becoming action without review
  • unverified tool output
  • hidden partial failure
  • skipped human approval
  • fake independent review
  • repeated failed routes
  • noisy persistent-agent alerts
  • session continuity loss
  • knowledge commitment before approval
  • automation before manual proof
  • lost accountability between stages

Exchange Zone Drift Signals

MWMS should watch for:

  • no Exchange Zone ID
  • no Work Unit ID
  • sender unclear
  • receiver unclear
  • authority unclear
  • source missing
  • source authority missing
  • output unclear
  • completed work missing
  • remaining work hidden
  • context missing
  • assumptions hidden
  • failure history omitted
  • dependency states missing
  • validation unclear
  • reviewer independence unclear
  • permission unclear
  • stop conditions absent
  • failure threshold absent
  • Rescue Route absent
  • next owner unclear
  • receiver acceptance missing
  • outcome undefined
  • knowledge commitment uncontrolled
  • closure missing

Rule

Exchange Zone drift must be corrected before the work receives further operational authority.

Minimum Compliance Standard

An important Exchange Zone is compliant only when it defines:

  • Exchange Zone ID
  • Work Unit ID
  • Exchange Zone Type
  • sender
  • receiver
  • sender and receiver authority
  • source
  • source authority
  • output
  • completed work
  • remaining work
  • transfer reason
  • required receiver input
  • context
  • gaps
  • assumptions
  • failure history
  • dependencies
  • dependency states
  • Critical Dependencies
  • validation status
  • independent-review status
  • risk
  • approval
  • tool permission
  • tool-execution evidence where relevant
  • stop conditions
  • failure threshold
  • Rescue Route
  • next action
  • next owner
  • expected output
  • expected business outcome
  • receiver acceptance
  • logging
  • learning
  • knowledge commitment
  • closure
  • current status

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 exchange can answer:

  • Who is sending the work?
  • Who is receiving it?
  • What Work Unit does it belong to?
  • What authority does each role hold?
  • What is being transferred?
  • Why is it being transferred?
  • What has already been completed?
  • What remains incomplete?
  • What source supports the transfer?
  • What does the receiver require?
  • Which dependencies remain?
  • What state is each dependency in?
  • What context must travel?
  • What validation applies?
  • Is independent review required?
  • What risk applies?
  • What permissions apply?
  • What should stop the workflow?
  • What triggers rescue?
  • Who owns the next action?
  • Has the receiver accepted the transfer?
  • What must be logged?
  • What knowledge should be committed?
  • How will the Exchange Zone close?

When MWMS controls Exchange Zones properly, it can scale from manual collaboration into governed automation without losing context, ownership, safety or continuity.

Strategic Summary

The v1.1 update strengthens the MWMS AI Exchange Zone And Dependency Control Framework by adding:

  • Exchange Zone IDs
  • Work Unit continuity
  • sender and receiver authority
  • model-to-model exchanges
  • independent-review exchanges
  • Rescue Agent exchanges
  • persistent-agent exchanges
  • external-knowledge exchanges
  • session-to-session exchanges
  • dependency state controls
  • Critical Dependencies
  • failure-state dependencies
  • outcome dependencies
  • knowledge-commitment dependencies
  • receiver acceptance
  • deterministic rescue thresholds
  • tool-execution evidence
  • cross-interface continuity
  • formal closure

The key shift is:

A handoff is not safe merely because information was sent.

It is safe only when the receiver has accepted a complete package with the context, authority, evidence, dependencies, validation and next action required to continue correctly.

Final Rule

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

No Work Unit continuity, no reliable transfer.

No source authority, no trustworthy input.

No dependency state, no valid readiness claim.

No validation state, no safe routing.

No acceptance, no completed handoff.

No failure history, no valid rescue.

No tool evidence, no execution claim.

No approved knowledge destination, no durable commitment.

No closure, no reliable continuity.

Change Log

Version: v1.1
Date: 2026-06-18
Author: HeadOffice

Change:

Updated the MWMS AI Exchange Zone And Dependency Control Framework using the AI Automations by Jack block covering multi-agent orchestration, model routing, independent review, rescue routing, persistent agents, external knowledge systems, tool verification and session continuity.

Added:

  • Exchange Zone State Rule
  • Model To Model Exchange
  • Producer To Independent Reviewer Exchange
  • Failed Route To Rescue Agent Exchange
  • Persistent Agent To Human Exchange
  • External Knowledge To Reasoning Exchange
  • Session To Session Exchange
  • Source Authority Dependency
  • Independent Review Dependency
  • Failure-State Dependency
  • Outcome Dependency
  • Knowledge Commitment Dependency
  • Dependency State Model
  • Critical Dependency Rule
  • expanded Exchange Zone Record Template
  • Exchange Zone Acceptance
  • Dependency Escalation Rule
  • Deterministic Rescue Rule
  • Tool Execution Evidence Rule
  • Cross-Interface Continuity Rule
  • Relationship To SIT Brain
  • Relationship To Data Brain
  • Exchange Zone Drift Signals
  • Minimum Compliance Standard
  • Strategic Summary
  • Final Rule

Expanded:

  • Purpose
  • Scope
  • Core Definition
  • Core Principle
  • Exchange Zone Types
  • Dependency Control
  • Control Checklist
  • examples
  • readiness checklist
  • failure modes
  • future UI fields
  • governance
  • drift protection
  • architectural intent

Corrected canonical references from AI Business Systems Brain to AIBS Brain.

Version: v1.0
Date: Initial Draft
Author: HeadOffice

Change:

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.

Change Impact Declaration

This v1.1 update expands the AI Exchange Zone And Dependency Control Framework from a general handoff-control framework into a complete transition-governance layer covering Work Unit continuity, dependency states, model changes, independent review, rescue routing, persistent agents, external knowledge, tool verification, receiver acceptance and session continuity.

Pages Created

None

Pages Updated

MWMS AI Exchange Zone And Dependency Control Framework

Pages Deprecated

None

Standalone Pages Not Created

MWMS Exchange Zone Acceptance Standard

MWMS Dependency State Standard

MWMS Critical Dependency Control Protocol

MWMS Model Route Exchange Standard

MWMS Persistent Agent Exchange Protocol

MWMS Session Continuity Exchange Standard

Registries Requiring Update

HeadOffice Page Registry

MWMS Canon Index

MWMS Course Absorption Decision Registry

Canon Version Update Required

No

Change Log Entry Required

Yes

Strategic Absorption Result

MWMS gains a stronger transition-control framework that ensures work cannot move between AI Employees, Brains, models, tools, queues, humans, persistent agents, sessions or client systems without complete context, visible dependencies, correct validation, clear ownership, receiver acceptance and controlled recovery.

END OF FULL FILE OUTPUT