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 Agent Failure Handling And Escalation Protocol.

This protocol establishes how MWMS identifies, handles, records, escalates, and learns from failures inside AI Employee workflows, Brain workflows, task pipelines, reporting systems, validation systems, handoffs, and future client-facing AI business systems.

MWMS is being designed as a governed AI workforce system.

A governed workforce must not assume every AI output, workflow, route, or task will succeed.

AI systems can fail in many ways.

They may misunderstand the task, use poor input, route to the wrong Brain, produce vague output, invent unsupported details, skip validation, exceed authority, duplicate existing work, create unsafe recommendations, or fail to hand off correctly.

This protocol exists so MWMS can treat failure as part of the operating system rather than as a surprise.

The goal is not to eliminate every failure.

The goal is to detect failure early, prevent damage, escalate correctly, preserve context, and improve the system after the failure is handled.

Scope

This protocol applies to all MWMS workflows where AI performs, supports, validates, routes, reports, or automates work.

This includes:

HeadOffice Brain
Brain Room
AI Manager
AI Employee Router
Task Executor systems
Dev Console
Newsletter Intelligence
Course Absorption
Offer Evaluation
Affiliate Brain
Research Brain
Experimentation Brain
Finance Brain
Content Brain
Ads Brain
Strategy Brain
Data Brain
Operations Brain
AI Business Systems Brain
Supabase task and event systems
MCR page creation workflows
developer support workflows
future client-facing AIBS workflows

This protocol applies to manual, assisted, and automated AI workflows.

Manual workflows include course absorption, page creation, research, strategy, daily task planning, developer instructions, and HeadOffice decision support.

Automated workflows include newsletter processing, queue routing, dashboard items, Supabase tasks, AI Employee execution, task status changes, and future client workflow automation.

Core Definition

An AI Agent Failure is any event where an AI Employee, AI workflow, Brain workflow, task pipeline, validation step, report, handoff, or automation does not produce a safe, useful, accurate, complete, properly routed, or operationally valid result.

A failure may be obvious.

Examples:

output is wrong
task crashes
automation errors
data is missing
validation fails

A failure may also be subtle.

Examples:

output sounds good but is generic
report has no business action
insight goes to the wrong Brain
AI invents a page that does not exist
task is marked complete but nothing useful happened
dashboard item creates noise
handoff loses important context
AI oversteps its authority
weak course material enters the Blueprint
M receives vague instructions

Both obvious and subtle failures matter.

MWMS must detect and handle both.

Core Principle

The core principle of this protocol is:

AI failure must be detected, contained, escalated, logged, and converted into system learning.

Failure is not only a problem.

Failure is a signal.

A failure shows where a role card, workflow, prompt, validation rule, handoff, input process, routing rule, or tool permission needs improvement.

MWMS must not hide failures.

MWMS must use them to make the system stronger.

Why Failure Handling Matters

As MWMS grows, AI will perform more work.

More AI work means more possible failure points.

Without failure handling, MWMS risks:

trusting bad outputs
routing work incorrectly
duplicating pages
wasting M’s time
wasting advertising budget
missing compliance risks
sending weak work to dashboards
breaking live systems
confusing clients
losing important context
repeating the same mistakes
scaling unreliable workflows

With failure handling, MWMS gains:

safer automation
better validation
clearer escalation
better role boundaries
stronger workflows
more reliable dashboards
cleaner developer instructions
improved AI Employee design
better Kaizen learning
higher trust in the system

Failure handling is therefore a core operating layer.

Failure Categories

MWMS recognizes several major categories of AI failure.

1. Input Failure

Input Failure occurs when the AI Employee receives poor, incomplete, noisy, corrupted, unclear, or insufficient input.

Examples:

uploaded file is incomplete
transcript is badly formatted
newsletter body is truncated
screenshot does not show enough context
sales page data is missing
course lesson lacks the core content
user instruction is ambiguous
Supabase row lacks required fields
copied text contains junk or broken formatting

Common cause:

messy input was not normalized before processing.

Required response:

pause processing
identify missing or weak input
request more input where needed
normalize again
mark assumptions clearly
do not generate final output from weak input

Escalation trigger:

input weakness affects decision quality, MCR canon, developer instructions, finance, compliance, offer testing, or client output.

2. Classification Failure

Classification Failure occurs when the system misunderstands what type of work is being requested.

Examples:

course absorption is treated as a general summary
developer support is treated as strategy advice
newsletter signal is treated as generic news
offer evaluation is treated as copywriting
Brain Room chat is not converted into a task
finance issue is routed to Affiliate Brain only
compliance risk is missed

Common cause:

weak request classification or missing Brain routing rule.

Required response:

correct the classification
identify the correct workflow type
reassign owning Brain
revise the Agentic Work Unit
log recurring classification error

Escalation trigger:

wrong classification could affect business decisions, live systems, paid traffic, compliance, M’s work, or MCR structure.

3. Brain Routing Failure

Brain Routing Failure occurs when work is assigned to the wrong Brain or supporting Brains are missed.

Examples:

offer is evaluated without Finance Brain
ad compliance issue is routed only to Content Brain
research evidence is not sent to Research Brain
HeadOffice visibility is skipped on cross-Brain work
Content Brain receives an item that belongs to Ads Brain
Experimentation Brain is skipped before testing

Common cause:

unclear Brain ownership or weak routing logic.

Required response:

pause or reroute the task
identify correct owning Brain
identify supporting Brains
update handoff
correct routing record if needed

Escalation trigger:

cross-Brain work, high-risk work, finance, compliance, paid traffic, MCR, or live-system implications.

4. Role Boundary Failure

Role Boundary Failure occurs when an AI Employee performs work outside its role card.

Examples:

Validation Agent makes a final business decision
Reporting Agent creates tasks without approval
Course Absorption Agent creates pages from weak material
Offer Evaluation Agent approves ad spend
Research Agent treats assumptions as facts
Brain Room Task Builder executes instead of only structuring
AI gives developer implementation advice without exact evidence

Common cause:

unclear role card or ignored authority level.

Required response:

stop the output from becoming final
review the role card
revise the task boundary
reroute to correct AI Employee or human
add forbidden action if needed

Escalation trigger:

any role boundary failure involving live systems, money, compliance, public content, developer work, or MCR canon.

5. Tool Permission Failure

Tool Permission Failure occurs when an AI Employee uses, assumes, or recommends tool access beyond its permitted boundary.

Examples:

AI claims it checked Supabase when it did not
AI implies a WordPress page was updated when it only drafted text
AI recommends database writes without approval
AI sends or drafts external communication outside permission
AI uses current web assumptions without verification
AI suggests changing live plugin files without confirmed context

Common cause:

unclear tool permission or AI overclaiming access.

Required response:

correct the claim
mark what was actually done
require human/tool verification
update tool permission boundary
log the failure if operationally important

Escalation trigger:

any tool permission failure involving live systems, data changes, external communication, client systems, financial action, or M’s development work.

6. Output Quality Failure

Output Quality Failure occurs when the AI output is incomplete, vague, generic, inaccurate, poorly structured, or not useful.

Examples:

report is long but does not say what to do
summary misses the key system value
page draft does not follow MWMS structure
output lacks Brain mapping
output has no verdict
output has no next action
developer instruction is vague
course absorption output summarizes instead of extracting frameworks

Common cause:

weak task instruction, missing output standard, or insufficient validation.

Required response:

revise output
apply output validation checklist
request clearer structure
assign Validation Agent or human review
improve task instruction or role card

Escalation trigger:

output is about MCR canon, developer implementation, offer decisions, finance, compliance, paid traffic, or client-facing work.

7. Source Grounding Failure

Source Grounding Failure occurs when the AI output is not properly supported by the source material.

Examples:

AI invents facts not in the file
AI references a page not confirmed to exist
AI exaggerates course content
AI treats vendor claims as verified evidence
AI uses old memory as current truth
AI assumes data not present in screenshots
AI gives legal, financial, or platform advice without current verification

Common cause:

poor validation, missing source citation, or over-reliance on assumptions.

Required response:

separate evidence from assumptions
correct unsupported claims
verify source where needed
revise output
mark uncertainty clearly

Escalation trigger:

source grounding failure in high-risk work or any user-facing/client-facing/live-system context.

8. Validation Failure

Validation Failure occurs when output fails a validation check or validation is skipped when required.

Examples:

high-risk output has no human review
dashboard item is shown without usefulness check
offer verdict lacks finance review
MCR page is created without duplication check
developer instruction lacks exact file path
newsletter item gets routed without priority validation

Common cause:

workflow lacks validation gate or validation rule was ignored.

Required response:

stop workflow progression
apply required validation level
revise or reject output
log validation failure
update pipeline if failure is repeated

Escalation trigger:

any skipped validation for high-risk or critical-risk workflows.

9. Handoff Failure

Handoff Failure occurs when work moves to another Brain, Employee, human, queue, or system without enough context.

Examples:

M receives incomplete instructions
Research Brain receives offer task without source
dashboard item has no next action
Brain Room request is answered but not logged
course absorption output has no page placement
finance review receives no assumptions
task moves to completed without clear outcome

Common cause:

missing handoff package.

Required response:

rebuild handoff
add source, status, risk, next action, owner
confirm receiver
log handoff issue where important

Escalation trigger:

developer, finance, compliance, MCR, client, or cross-Brain handoff failures.

10. Outcome Failure

Outcome Failure occurs when AI work produces output but no meaningful business result.

Examples:

report has no decision
summary has no next step
dashboard item creates no action
course absorption produces notes but no Blueprint upgrade
offer evaluation does not route to reject, park, research, or test
task completes but does not move the system forward

Common cause:

weak reporting, missing outcome definition, or poor workflow design.

Required response:

define required outcome
revise report or task
route to decision state
park or reject if no outcome exists

Escalation trigger:

repeated outcome failure in the same workflow.

11. Automation Failure

Automation Failure occurs when an automated workflow breaks, misfires, loops, sends bad data, duplicates records, or runs before the process is stable.

Examples:

Make.com scenario fails
Supabase insert is incomplete
Gmail labels do not update
queue record missing fields
automated task is created incorrectly
dashboard displays duplicate rows
workflow runs on bad input
AI loops without final decision

Common cause:

automation added before manual workflow is stable, poor error handling, weak data mapping, or missing validation.

Required response:

pause automation if needed
identify failing module or stage
confirm last good state
test with small controlled input
restore safe state
update logging
avoid broad changes until failure is isolated

Escalation trigger:

live data, dashboards, user-facing systems, M’s active build, client systems, or repeated automated failure.

12. Governance Failure

Governance Failure occurs when AI work bypasses HeadOffice, MCR, Brain ownership, review rules, developer boundaries, or system standards.

Examples:

new standard created without placement clarity
Brain creates workflow outside HeadOffice visibility
M’s build area is touched by unrelated work
page naming rules are ignored
MCR source of truth is bypassed
course content is absorbed without value testing
client workflow is proposed without approval gates

Common cause:

rushing, unclear authority, missing governance check.

Required response:

pause workflow
identify violated standard
correct structure
escalate to HeadOffice
update drift protection if needed

Escalation trigger:

all governance failures should be visible to HeadOffice.

Failure Severity Levels

MWMS should classify failures by severity.

Level 1 — Minor Failure

Low impact.

Examples:

small formatting issue
minor wording problem
incomplete non-critical section
low-risk output needs polish

Response:

revise
no escalation required unless repeated

Level 2 — Moderate Failure

Workflow usefulness affected, but no major risk.

Examples:

report too generic
missing Brain mapping
weak handoff
low-risk classification error
course output needs stronger extraction

Response:

revise
apply validation
log if repeated

Level 3 — Serious Failure

Could affect system quality, decisions, MCR, development, or business direction.

Examples:

wrong Brain routing
unsupported claim in important output
weak developer instruction
duplicate MCR page risk
skipped validation
bad dashboard item
offer verdict missing risk review

Response:

stop progression
escalate to HeadOffice or human review
revise before use
log failure

Level 4 — Critical Failure

Could affect live systems, money, compliance, public content, client trust, or irreversible data.

Examples:

unsafe live system change
wrong database write
external email sent incorrectly
paid traffic decision based on bad data
compliance-sensitive mistake
client-facing report error
critical automation misfire

Response:

stop workflow immediately
escalate to HeadOffice and relevant human
preserve evidence
correct or roll back where possible
log failure
create Kaizen improvement
review workflow before restarting

Standard Failure Handling Flow

When failure is detected, MWMS should follow this flow:

Detect failure
Classify failure category
Assign severity level
Pause workflow if needed
Contain possible damage
Identify source cause
Decide revise, reroute, park, reject, or escalate
Assign owner
Correct output or workflow
Validate correction
Log failure
Capture learning
Update role card, pipeline, validation, prompt, or standard if required

Failure handling must be structured.

Do not just “try again” blindly.

Failure Decision States

After review, a failure should receive one of these decisions.

Revise

The output has value but needs correction.

Use when:

incomplete
vague
wrong format
missing section
needs better Brain mapping

Reroute

The work belongs somewhere else.

Use when:

wrong Brain
wrong AI Employee
wrong workflow
wrong destination

Revalidate

The output may be usable but must pass stronger validation.

Use when:

risk is higher than expected
source grounding is weak
human approval is required
decision impact is significant

Park

The work may be useful later but should not move now.

Use when:

current timing is wrong
system is not ready
M’s build area would be affected
more evidence is needed
not current priority

Reject

The output should not be used.

Use when:

weak value
unsupported
duplicate
unsafe
wrong direction
not MWMS relevant

Escalate

The issue needs HeadOffice, Martyn, M, or human review.

Use when:

high-risk
compliance-sensitive
live-system related
developer-sensitive
financial
client-facing
ownership unclear

Escalation Rules

Escalation is required when failure affects:

MCR canon
HeadOffice governance
M’s active build areas
developer implementation
live systems
Supabase writes
WordPress updates
external emails
paid traffic decisions
finance decisions
compliance-sensitive material
public-facing content
client-facing outputs
cross-Brain ownership
repeated workflow failures
unclear authority
tool permission boundaries

Escalation protects the system from compounding errors.

Escalation Destinations

Depending on the failure, escalate to the correct destination.

Escalate To Martyn

Use when:

strategic decision required
MCR page should be approved
course absorption value is uncertain
offer test decision needed
budget or risk decision needed
business direction affected
human judgment required

Escalate To HeadOffice

Use when:

cross-Brain governance issue
routing conflict
dashboard quality issue
system standard issue
workflow design issue
repeated AI failure
AI Employee role boundary issue

Escalate To M

Use when:

technical implementation issue
code, plugin, API, Supabase, WordPress, or live system behavior affected
testing required
file-level review needed
developer save point impacted

Escalate To Validation Agent

Use when:

output quality is uncertain
source grounding needs checking
Brain routing needs review
risk level needs assessment
output may be usable after validation

Escalate To Research Brain

Use when:

more evidence required
source claims are uncertain
market data is missing
vendor claims need verification
current information is required

Escalate To Finance Brain

Use when:

budget impact exists
break-even logic needed
financial risk exists
scaling decision is involved
investment decision is involved

Escalate To Compliance Or Risk Review

Use when:

advertising policy risk exists
legal or privacy issue exists
health/finance claims are involved
client-facing risk exists
platform policy uncertainty exists

Failure Log Record

Important failures should be logged.

A Failure Log Record should include:

Failure Title:
Date:
Source:
Workflow:
Owning Brain:
AI Employee:
Failure Category:
Severity Level:
What Went Wrong:
Cause:
Immediate Action Taken:
Escalation Destination:
Final Decision:
Correction Applied:
Validation Status:
Learning Captured:
Related Standard Updated:
Status:

Failure logging allows MWMS to improve instead of repeating errors.

Failure Learning Loop

Every meaningful failure should feed the MWMS Kaizen loop.

The failure learning loop is:

Reflect
Reduce
Refine
Record

Reflect

What failed?

Why did it fail?

Was the problem input, classification, routing, role boundary, prompt, validation, handoff, tool permission, or automation?

Reduce

How can MWMS reduce the chance of repeat failure?

Can the workflow be simplified?

Can a prompt be tightened?

Can a field be required?

Can a validation gate be added?

Can a role boundary be clarified?

Refine

Update the relevant standard, checklist, workflow, role card, or protocol.

Possible updates:

AI Employee role card
Agentic Work Unit template
workflow pipeline
validation checklist
handoff template
reporting standard
normalization process
developer instruction rule
dashboard filter

Record

Log the learning.

Possible destinations:

Kaizen Log
System Change Log
Brain-specific Canon
Course Absorption Decision Registry
Newsletter Intelligence Signal Log
Experimentation learning records
Research Brain signal records
Developer save point notes

Application To Course Absorption

Course absorption failure happens when MWMS absorbs weak, duplicated, generic, or tool-specific material that does not improve the system.

Failure examples:

summarizing course instead of extracting system value
creating too many pages
duplicating existing standards
absorbing tool hype
missing a valuable framework
failing to map to Brain
failing to identify what to ignore

Required response:

revise extraction
apply Course Absorption System v2
check duplication
park weak material
absorb only clear system upgrades

Course failure rule:

Course material should not enter MWMS canon unless it improves MWMS.

Application To Newsletter Intelligence

Newsletter failure happens when low-value or generic information becomes dashboard noise.

Failure examples:

vague insights
wrong Brain routing
false urgency
generic AI news
missing recommended action
weak priority logic
duplicate signals
useful trend not captured

Required response:

tighten extraction prompt
improve validation
adjust action classification
route weak items to parking
log recurring pattern failures

Newsletter failure rule:

Newsletter intelligence must be specific enough to act on or it should not reach the command layer.

Application To Brain Room

Brain Room failure happens when useful conversation is not converted into structured work.

Failure examples:

important instruction not logged
task not created
wrong Brain assigned
AI replies casually when task structure is needed
developer boundary missed
no follow-up destination
repeated context lost

Required response:

create Agentic Work Unit
assign owning Brain
define next action
log important context
escalate if development-sensitive

Brain Room failure rule:

Brain Room must not lose operational value inside chat flow.

Application To M Developer Support

Developer failure is high risk.

Failure examples:

vague file instructions
wrong site referenced
exact insertion point missing
screenshot ignored
save point not respected
unrelated systems touched
partial file output given when full file required
testing steps missing

Required response:

stop implementation handoff
rebuild developer instruction
anchor to visible evidence
include exact file/path/screen
include what not to touch
include testing steps

Developer failure rule:

If M has to guess, the AI output has failed.

Application To Offer Evaluation

Offer evaluation failure can waste money.

Failure examples:

vendor hype trusted
compliance risk missed
traffic fit ignored
finance review skipped
Green verdict too easily given
weak market evidence
test budget not considered
no experimentation handoff

Required response:

reroute to Research, Finance, Ads, or Experimentation Brain
revise verdict
require evidence
escalate to HeadOffice before testing

Offer failure rule:

No offer should move toward spend without evidence, risk review, and financial logic.

Application To AIBS Client Systems

Client-facing AI failure can damage trust.

Failure examples:

confusing report
unsupported recommendation
unsafe automation
missing approval gate
poor input cleanup
client data misread
unclear next action
automation acts before approval

Required response:

stop client-facing action
validate source and output
require human approval
simplify report
log failure
update client workflow controls

AIBS failure rule:

Client-facing AI workflows must fail safely, clearly, and with human review where needed.

Failure Prevention Checklist

Before a workflow runs, check:

Is the input clean enough?
Is the task classified correctly?
Is the owning Brain clear?
Is the AI Employee role defined?
Is the task inside the role boundary?
Are tool permissions clear?
Are forbidden actions clear?
Is the output format defined?
Is validation required?
Is human review required?
Is the handoff destination clear?
Is the business outcome clear?
Is logging required?
Are known failure modes documented?
Is this safe for the current build stage?
Does this affect M’s active work?
Does HeadOffice need visibility?
Is automation premature?
Is source grounding required?
Is escalation path clear?

Human Review Rule

Human review is mandatory when failure affects:

MCR canon
live systems
developer implementation
Supabase writes
WordPress changes
external emails
paid traffic decisions
financial decisions
compliance-sensitive outputs
public-facing content
client-facing output
high-risk automation
cross-Brain governance
M’s active build areas

Human review can be optional for low-risk internal drafting failures.

Automation Failure Rule

Automation must fail safely.

Automated workflows should be designed so that failure does not automatically cause damage.

Automation should:

stop on missing required fields
mark failed validation clearly
avoid creating downstream tasks from weak output
preserve original input
log error state
notify or surface review need
avoid repeated looping
avoid overwriting good data with bad data

Automation rule:

Automated AI workflows must pause safely when confidence, validation, input quality, or permissions are insufficient.

Governance Role

HeadOffice owns the MWMS AI Agent Failure Handling And Escalation Protocol.

HeadOffice is responsible for:

defining failure categories
setting severity levels
approving escalation paths
ensuring failures are logged
ensuring repeated failures create system improvements
protecting MCR from weak or failed outputs
protecting M’s active build areas
protecting dashboards from unreliable intelligence
protecting future client systems from unsafe automation
ensuring failure becomes learning

Individual Brains may define additional failure handling rules for their own workflows, 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 AI Employee Handoff Protocol
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
HeadOffice Newsletter Intelligence Output Validation Protocol
MWMS Course Absorption Operating Rule
MWMS Opportunity System Operating Protocol
AI Business Systems Brain Blueprint

This protocol defines how MWMS handles failure across the systems, roles, workflows, reports, validation gates, and handoffs defined by those standards.

Drift Protection

This protocol protects MWMS from the following forms of drift:

Ignoring AI failures because outputs sound confident
Repeating the same workflow mistakes
Treating failed outputs as final
Allowing weak course material into MCR
Allowing vague developer instructions to reach M
Allowing dashboard noise to accumulate
Allowing wrong Brain routing to continue
Skipping validation after failure
Automating workflows that fail unsafely
Hiding errors instead of logging them
Over-trusting AI Employees outside their role boundaries
Letting tool permission failures become live-system risks
Treating activity as progress even when outcomes fail
Failing to escalate high-risk issues
Missing Kaizen improvements from repeated failures

Any workflow that repeatedly fails without producing system improvement should be reviewed, simplified, or paused.

Architectural Intent

The architectural intent of the MWMS AI Agent Failure Handling And Escalation Protocol is to make MWMS resilient.

A serious AI business operating system must expect failure and handle it well.

The long-term goal is not a system that never fails.

The goal is a system where failures are:

detected early
contained safely
escalated correctly
logged clearly
corrected properly
converted into learning
used to strengthen future workflows

MWMS should be able to answer the following questions for every meaningful failure:

What failed?
Where did it fail?
Which Brain owned it?
Which AI Employee was involved?
What caused it?
How severe was it?
Was the damage contained?
Who reviewed it?
What decision was made?
What was corrected?
What was logged?
What did MWMS learn?
What standard, workflow, role card, or validation rule should improve?

When MWMS can answer those questions consistently, failure stops being chaos.

Failure becomes intelligence.

Change Log

v1.0 — Initial Draft

Created the MWMS AI Agent Failure Handling And Escalation Protocol as the standard for identifying, classifying, containing, escalating, correcting, logging, and learning from failures across AI Employees, Brain workflows, task pipelines, reports, validation systems, handoffs, automation systems, developer support, course absorption, newsletter intelligence, offer evaluation, and future AIBS client workflows.

This protocol completes the first major operating layer of the MWMS AI Agent Operations Core by defining how failure becomes a controlled, auditable, and improvable part of the governed AI workforce system.