MWMS MCR

MWMS AI Agent Failure Log Record

System: MWMS
Document Type: Operational Template
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 Log Record.

This record is used when an AI Employee, AI workflow, Brain workflow, task pipeline, report, validation step, handoff, automation, dashboard item, or future client-facing AI process fails or produces a weak, unsafe, incomplete, unclear, misrouted, or unusable result.

MWMS must not treat AI failures as one-off annoyances.

Failure is intelligence.

A failure can show:

  • input was weak
  • context was missing
  • Brain routing was wrong
  • the AI Employee role was unclear
  • validation was too weak
  • handoff was incomplete
  • the output was generic
  • the dashboard item created noise
  • M received vague instructions
  • tool permissions were unclear
  • automation ran too early
  • the workflow needs improvement

This record captures what went wrong, why it happened, what was done, who needs to review it, and what MWMS should learn.

This is the practical daily-use version of the MWMS AI Agent Failure Handling And Escalation Protocol.

Scope

This record applies to failures across:

  • HeadOffice Brain
  • Brain Room
  • AI Manager
  • AI Employee Router
  • Task Executor systems
  • Dev Console
  • Newsletter Intelligence
  • Course Absorption
  • Opportunity System
  • Affiliate Brain
  • Research Brain
  • Experimentation Brain
  • Finance Brain
  • Content Brain
  • Ads Brain
  • Sales Brain
  • Conversion Brain
  • Operations Brain
  • AI Business Systems Brain
  • Supabase task and event systems
  • Make.com workflows
  • WordPress Brain sites
  • MCR page workflows
  • developer handoffs
  • future AIBS client systems

This record can be used manually first.

Later, parts of this record may become Supabase failure fields, task status records, validation queue records, dashboard alerts, AI Employee performance logs, automation stop-condition records, or future AIBS client safety logs.

Core Definition

An AI Agent Failure Log Record is a structured record of something that went wrong in an AI-supported workflow.

The failure may be technical.

Examples:

  • automation error
  • missing Supabase field
  • failed Gmail body extraction
  • broken JSON
  • WordPress issue
  • tool access issue

The failure may also be operational.

Examples:

  • output too generic
  • wrong Brain routing
  • weak report
  • missing handoff
  • no next action
  • poor source grounding
  • duplicate MCR page risk
  • vague developer instruction
  • dashboard noise
  • skipped validation

Both types matter.

MWMS logs failures so they can be corrected, escalated, and converted into system learning.

Core Principle

The core principle of this record is:

A failure should not disappear after it is fixed. It should improve the system.

MWMS should not only ask:

How do we fix this?

It should also ask:

How do we prevent this from happening again?

That is how failure becomes Kaizen.

AI Agent Failure Log Record Template

1. Failure Title

Field:
Failure Title:

Purpose:
Gives the failure a clear name.

Good Examples:

  • Newsletter Output Too Generic For Dashboard
  • Developer Handoff Missing Exact File Path
  • Course Absorption Created Duplicate Page Risk
  • Brain Room Message Routed To Wrong Brain
  • Offer Evaluation Missing Finance Review
  • AI Claimed Tool Access It Did Not Have
  • Validation Skipped Before MCR Page Draft
  • Make.com JSON Parse Failed On Newsletter Body

Bad Examples:

  • Error
  • Problem
  • Bad Output
  • It Failed
  • Needs Fixing

Rule:
The failure title should make the issue understandable at a glance.

2. Date Logged

Field:
Date Logged:

Format:
YYYY-MM-DD

Purpose:
Records when the failure was identified.

Rule:
The date matters for pattern tracking, review cycles, and Kaizen logs.

3. Source

Field:
Source:

Purpose:
Identifies where the failure came from.

Examples:

  • course absorption output
  • newsletter intelligence row
  • Brain Room message
  • developer brief
  • MCR page draft
  • offer evaluation report
  • Supabase task
  • Make.com scenario
  • HeadOffice dashboard item
  • validation report
  • WordPress page list
  • user instruction
  • AI Employee output
  • future client workflow

Rule:
MWMS must know where the failure originated.

4. Source Reference

Field:
Source Reference:

Purpose:
Records the exact source where available.

Examples:

  • file name
  • page title
  • newsletter subject
  • task ID
  • Supabase record ID
  • Brain Room thread
  • screenshot reference
  • workflow name
  • AI Employee name
  • report title
  • date/time of failure

Rule:
Use this field when the failure may need to be checked later.

5. Workflow

Field:
Workflow:

Purpose:
Identifies which workflow was affected.

Examples:

  • Course Absorption Workflow
  • Newsletter Intelligence Workflow
  • Brain Room Task Conversion Workflow
  • Offer Evaluation Workflow
  • Developer Support Workflow
  • MCR Page Creation Workflow
  • Validation Workflow
  • Handoff Workflow
  • Finance Review Workflow
  • Experimentation Review Workflow
  • HeadOffice Dashboard Workflow
  • AIBS Client Workflow

Rule:
Failures should be mapped to workflows so repeated issues can be found.

6. Owning Brain

Field:
Owning Brain:

Purpose:
Identifies which Brain owns the failure review.

Examples:

  • HeadOffice Brain
  • Affiliate Brain
  • Research Brain
  • Finance Brain
  • Experimentation Brain
  • Content Brain
  • Ads Brain
  • Sales Brain
  • Conversion Brain
  • Operations Brain
  • AI Business Systems Brain

Rule:
Every meaningful failure needs an owner.

7. Supporting Brains Affected

Field:
Supporting Brains Affected:

Purpose:
Lists other Brains impacted by the failure.

Examples:

A failed offer evaluation may affect:

  • Affiliate Brain
  • Research Brain
  • Ads Brain
  • Finance Brain
  • Experimentation Brain
  • HeadOffice Brain

A failed developer handoff may affect:

  • HeadOffice Brain
  • Operations Brain
  • Dev Console
  • Brain Room

Rule:
Cross-Brain impact must be visible.

8. AI Employee Involved

Field:
AI Employee Involved:

Purpose:
Identifies the AI Employee or role involved in the failure.

Examples:

  • Course Absorption Agent
  • Newsletter Signal Extraction Agent
  • Brain Room Task Builder Agent
  • Offer Evaluation Agent
  • Research Evidence Collection Agent
  • HeadOffice Validation Agent
  • Finance Break Even Analysis Agent
  • Developer Support Agent
  • Handoff Agent
  • Reporting Agent
  • AI Manager
  • Unknown / Not Assigned

Rule:
If no AI Employee was assigned, that may itself be part of the failure.

9. Failure Category

Field:
Failure Category:

Recommended Values:

  • Input Failure
  • Classification Failure
  • Brain Routing Failure
  • Role Boundary Failure
  • Tool Permission Failure
  • Output Quality Failure
  • Source Grounding Failure
  • Validation Failure
  • Handoff Failure
  • Outcome Failure
  • Automation Failure
  • Governance Failure
  • Dashboard Failure
  • Developer Instruction Failure
  • Client Safety Failure
  • Unknown

Rule:
The failure category helps MWMS decide what to improve.

10. Severity Level

Field:
Severity Level:

Recommended Values:

  • Level 1 — Minor
  • Level 2 — Moderate
  • Level 3 — Serious
  • Level 4 — Critical

Level 1 — Minor

Low impact.

Examples:

  • formatting issue
  • minor missing detail
  • wording issue
  • low-risk output needs polish

Level 2 — Moderate

Workflow usefulness affected, but no major risk.

Examples:

  • report too generic
  • weak Brain mapping
  • incomplete handoff
  • output needs revision

Level 3 — Serious

Could affect system quality, development, business decisions, MCR, or workflow reliability.

Examples:

  • wrong Brain routing
  • duplicate MCR page risk
  • skipped validation
  • vague developer instruction
  • offer verdict missing finance review

Level 4 — Critical

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

Examples:

  • unsafe live system change
  • wrong database write
  • paid traffic decision based on bad data
  • client-facing report error
  • external email sent incorrectly

Rule:
Severity determines escalation and review.

11. What Went Wrong

Field:
What Went Wrong:

Purpose:
Clearly describes the failure.

Examples:

  • The output summarized the course but did not extract reusable MWMS system value.
  • The report had no executive verdict or recommended action.
  • The developer brief did not include an exact file path.
  • The newsletter item was too generic for dashboard use.
  • The offer evaluation treated vendor claims as evidence.
  • The handoff did not identify the receiving Brain.
  • The AI assumed a WordPress page existed without current confirmation.
  • The automation produced a row with missing required fields.

Rule:
Describe the failure plainly, not emotionally.

12. Why It Failed

Field:
Why It Failed:

Purpose:
Identifies the likely cause.

Possible Causes:

  • messy input
  • missing context
  • weak task instruction
  • wrong AI Employee
  • no role card
  • wrong Brain routing
  • validation skipped
  • output format unclear
  • tool permission unclear
  • source incomplete
  • old memory used as current fact
  • automation added too early
  • handoff template not used
  • no human review
  • unclear owner
  • user instruction misunderstood

Rule:
Do not stop at the symptom. Identify the cause.

13. Immediate Action Taken

Field:
Immediate Action Taken:

Purpose:
Records what was done immediately after failure was found.

Examples:

  • revised output
  • parked item
  • rejected item
  • rerouted to correct Brain
  • requested more input
  • asked for source reupload
  • stopped automation
  • corrected page parent
  • trashed duplicate page
  • escalated to Martyn
  • prepared new developer brief
  • marked human review required

Rule:
Failure response should be visible.

14. Containment Action

Field:
Containment Action:

Purpose:
Defines how possible damage was contained.

Examples:

  • did not send to M
  • did not save to MCR
  • did not add to dashboard
  • did not create downstream task
  • did not approve spend
  • did not make live changes
  • did not treat output as final
  • moved to Parking System
  • marked as failed validation
  • paused workflow

Rule:
Containment prevents small failures from becoming bigger failures.

15. Escalation Destination

Field:
Escalation Destination:

Recommended Values:

  • Martyn
  • HeadOffice
  • M
  • Human Review Queue
  • Validation Agent
  • Research Brain
  • Finance Brain
  • Experimentation Brain
  • Compliance Or Risk Review
  • Developer Review
  • Parking System
  • No Escalation Required

Rule:
High-risk failures must have a clear escalation destination.

16. Final Decision

Field:
Final Decision:

Recommended Values:

  • Revised
  • Rerouted
  • Revalidated
  • Parked
  • Rejected
  • Escalated
  • Logged Only
  • Fixed
  • Monitoring Required
  • Awaiting Input
  • Awaiting Human Review

Rule:
The failure record should show the current decision state.

17. Correction Applied

Field:
Correction Applied:

Purpose:
Records what correction was made.

Examples:

  • updated the report with a clear verdict
  • corrected Brain ownership
  • added source grounding
  • added missing handoff destination
  • merged duplicate page content
  • trashed duplicate page
  • added human review requirement
  • revised developer instruction with exact file path
  • changed validation status
  • updated workflow rule
  • stopped using weak input

Rule:
Corrections should be specific.

18. Validation Status After Correction

Field:
Validation Status After Correction:

Recommended Values:

  • Not Revalidated
  • Self Checked
  • Needs Validation
  • Validated
  • Failed Again
  • Human Review Required
  • Source Verification Required
  • Developer Review Required
  • Compliance Review Required

Rule:
A corrected failure should not be assumed fixed until validation status is clear.

19. Outcome Impact

Field:
Outcome Impact:

Purpose:
Describes how the failure affected the intended outcome.

Examples:

  • delayed MCR page creation
  • prevented weak page from being saved
  • protected M from vague instructions
  • prevented dashboard noise
  • delayed offer evaluation
  • reduced confidence in newsletter signal
  • required duplicate cleanup
  • created new validation rule
  • no business impact
  • client-facing risk avoided

Rule:
A failure should be judged by outcome impact, not just inconvenience.

20. Learning Captured

Field:
Learning Captured:

Purpose:
Records the reusable lesson.

Examples:

  • correct parent wins first during duplicate cleanup
  • do not judge keeper pages only by internal version date
  • file comparison must check whether files are identical before recommending delete
  • newsletter dashboard items need specificity threshold
  • developer instructions require visible evidence
  • course absorption must distinguish framework from template
  • source grounding must be checked before claiming current state

Rule:
This is the most important field for Kaizen.

21. Related Standard To Update

Field:
Related Standard To Update:

Purpose:
Identifies which MWMS standard, checklist, template, or protocol should be updated if the failure reveals a rule gap.

Examples:

  • MWMS AI Output Validation Checklist
  • MWMS AI Employee Handoff Package Template
  • MWMS Messy Input Normalization Record
  • MWMS AI Workflow Pipeline Checklist
  • MWMS AI Tool Permission And Access Framework
  • MWMS AI Agent Memory And Context Framework
  • MWMS Page Naming Standard
  • MCR To Brain Copy Rule
  • Course Absorption Operating Rule
  • Developer Support Rule
  • Newsletter Intelligence Operating Protocol

Rule:
Repeated failures should update standards.

22. Kaizen Action

Field:
Kaizen Action:

Purpose:
Defines the improvement to prevent recurrence.

Examples:

  • add checklist item
  • tighten prompt
  • update template
  • add validation rule
  • clarify role boundary
  • improve handoff package
  • improve source comparison step
  • add dashboard filter
  • require human review earlier
  • create better evidence rule
  • park automation until manual workflow is stable

Rule:
Every meaningful failure should produce a Kaizen action.

23. Owner Of Follow Up

Field:
Owner Of Follow Up:

Examples:

  • Martyn
  • HeadOffice
  • M
  • Validation Agent
  • Course Absorption Agent
  • Newsletter Signal Extraction Agent
  • Developer Support Agent
  • Research Brain
  • Finance Brain
  • AI Manager
  • Human Review Queue

Rule:
Failure improvement should not be ownerless.

24. Follow Up Status

Field:
Follow Up Status:

Recommended Values:

  • Open
  • In Progress
  • Waiting For Input
  • Waiting For Review
  • Fixed
  • Parked
  • Rejected
  • Monitoring
  • Closed

Rule:
Failure follow-up should be trackable.

25. Logging Requirement

Field:
Logging Requirement: Yes / No

Logging Required For:

  • repeated failures
  • high-risk failures
  • developer failures
  • MCR failures
  • dashboard failures
  • offer evaluation failures
  • finance failures
  • compliance failures
  • client-facing failures
  • automation failures
  • validation failures

Rule:
Important failures should always be logged.

Quick Use Version

Use this shorter version for daily failure capture.

Failure Title:
Date Logged:
Source:
Source Reference:
Workflow:
Owning Brain:
Supporting Brains Affected:
AI Employee Involved:
Failure Category:
Severity Level:
What Went Wrong:
Why It Failed:
Immediate Action Taken:
Containment Action:
Escalation Destination:
Final Decision:
Correction Applied:
Validation Status After Correction:
Outcome Impact:
Learning Captured:
Related Standard To Update:
Kaizen Action:
Owner Of Follow Up:
Follow Up Status:
Logging Requirement:

Failure Category Guides

1. Input Failure

Use when the source input was weak, incomplete, noisy, expired, corrupted, or unclear.

Examples:

  • source file expired
  • screenshot partial
  • newsletter body truncated
  • transcript cut off
  • pasted content incomplete
  • offer data missing

Common Correction:

  • request more input
  • reupload file
  • normalize again
  • mark assumptions
  • analyze with caution only

2. Classification Failure

Use when the task type was misunderstood.

Examples:

  • course absorption treated as general summary
  • developer issue treated as strategy advice
  • newsletter signal treated as generic news
  • offer evaluation treated as copywriting

Common Correction:

  • reclassify work type
  • assign correct workflow
  • create Agentic Work Unit

3. Brain Routing Failure

Use when work went to the wrong Brain or supporting Brains were missed.

Examples:

  • offer not routed to Finance Brain
  • compliance issue not sent to Risk review
  • newsletter ad signal not routed to Ads Brain
  • MCR governance issue treated as operational site work

Common Correction:

  • reroute
  • update handoff
  • correct owning Brain
  • log routing lesson

4. Role Boundary Failure

Use when an AI Employee acted outside its role.

Examples:

  • Validation Agent made final spend decision
  • Course Absorption Agent created duplicate canon
  • Reporting Agent created task without approval
  • AI acted like developer without evidence

Common Correction:

  • revise role card
  • add forbidden action
  • escalate to HeadOffice

5. Tool Permission Failure

Use when AI assumed or used tool access incorrectly.

Examples:

  • claimed database was checked when it was not
  • implied page was updated when only drafted
  • assumed current web data without checking
  • recommended live system action without permission

Common Correction:

  • correct claim
  • mark tool boundary
  • require verification
  • update permission rule

6. Output Quality Failure

Use when the output was weak, generic, incomplete, vague, or not useful.

Examples:

  • no verdict
  • no next action
  • too generic
  • missing Brain ownership
  • wrong format
  • no business meaning

Common Correction:

  • revise output
  • apply validation checklist
  • strengthen task instruction

7. Source Grounding Failure

Use when the output was not supported by the source.

Examples:

  • invented page existence
  • exaggerated course content
  • treated vendor claims as facts
  • used old memory as current truth
  • assumed screenshot details not visible

Common Correction:

  • separate evidence from assumptions
  • verify source
  • revise or reject output

8. Validation Failure

Use when validation failed or was skipped.

Examples:

  • high-risk output not reviewed
  • MCR page draft not checked for duplication
  • developer handoff missing test steps
  • dashboard item not checked for usefulness

Common Correction:

  • apply correct validation level
  • revise
  • escalate if high risk

9. Handoff Failure

Use when work moved without enough context.

Examples:

  • no receiving Brain
  • no next action
  • validation status missing
  • M receives vague instruction
  • dashboard item has no owner

Common Correction:

  • rebuild handoff package
  • add owner, context, risk, and next action

10. Outcome Failure

Use when output was created but no useful result happened.

Examples:

  • report produced but no decision
  • summary created but nothing absorbed
  • dashboard updated but no action
  • research gathered but not used

Common Correction:

  • define outcome
  • route to decision
  • revise or park

11. Automation Failure

Use when an automation breaks or runs unsafely.

Examples:

  • Make.com scenario fails
  • JSON parse fails
  • Supabase insert incomplete
  • duplicate records created
  • workflow loops
  • wrong label applied

Common Correction:

  • pause automation
  • isolate failing module
  • test controlled input
  • log safe save point

12. Governance Failure

Use when standards, source-of-truth rules, or boundaries are violated.

Examples:

  • MCR bypassed
  • wrong parent used
  • page naming ignored
  • M’s active build touched
  • client workflow proposed without approval gates

Common Correction:

  • pause workflow
  • correct structure
  • escalate to HeadOffice
  • update standard if needed

Failure Severity Examples

Level 1 — Minor

Example:

  • formatting problem in a low-risk draft

Action:

  • revise and continue

Level 2 — Moderate

Example:

  • course report missing integration notes

Action:

  • revise before using

Level 3 — Serious

Example:

  • duplicate MCR page recommended for creation

Action:

  • stop, compare existing pages, correct, log learning

Level 4 — Critical

Example:

  • AI recommends live system or ad spend action based on bad data

Action:

  • stop immediately, escalate, preserve evidence, log failure, update safeguards

Failure Decision States

Revised

Output was corrected and can continue after validation.

Rerouted

Work was sent to the correct Brain, AI Employee, or workflow.

Revalidated

Output was checked again after correction.

Parked

Work may be useful later but should not proceed now.

Rejected

Output or input should not be used.

Escalated

Failure requires higher review.

Logged Only

Failure was minor but worth recording.

Fixed

Issue was corrected.

Monitoring Required

Workflow should be watched for repeat failure.

Example 1: Duplicate Page Cleanup Failure

Failure Title:
Duplicate Cleanup Recommendation Used Wrong Keeper Logic

Date Logged:
YYYY-MM-DD

Source:
MCR duplicate page cleanup

Workflow:
MCR Page Validation Workflow

Owning Brain:
HeadOffice Brain

AI Employee Involved:
HeadOffice Validation Agent

Failure Category:
Validation Failure / Source Grounding Failure

Severity Level:
Level 2 — Moderate

What Went Wrong:
The recommendation used internal version/date logic before fully respecting visible WordPress parent placement and identical-content comparison.

Why It Failed:
The validation process did not first confirm whether both duplicate pages had the same parent and identical content.

Immediate Action Taken:
Corrected the cleanup rule.

Containment Action:
Stopped relying only on version/date and switched to correct parent plus identical-content confirmation.

Final Decision:
Fixed

Learning Captured:
During WordPress duplicate cleanup, first check exact page title, parent, and whether content is identical. If content is identical and parent is same, keep either one. If parent differs, correct parent wins first, but preserve newer content if needed.

Kaizen Action:
Add duplicate cleanup rule to MCR validation workflow.

Follow Up Status:
Closed

Example 2: Newsletter Dashboard Noise Failure

Failure Title:
Newsletter Insight Too Generic For Dashboard

Date Logged:
YYYY-MM-DD

Source:
Newsletter Intelligence output

Workflow:
Newsletter Intelligence Workflow

Owning Brain:
HeadOffice Brain

AI Employee Involved:
Newsletter Signal Extraction Agent

Failure Category:
Output Quality Failure / Dashboard Failure

Severity Level:
Level 2 — Moderate

What Went Wrong:
The extracted insight was too generic and did not create a clear action, test, monitoring item, or Brain-specific signal.

Why It Failed:
The extraction prompt did not filter strongly enough for MWMS business relevance.

Immediate Action Taken:
Parked the item instead of adding it to dashboard.

Containment Action:
Prevented dashboard noise.

Final Decision:
Parked

Learning Captured:
Newsletter dashboard items must include specific signal, affected Brain, action type, urgency, priority, and recommended next action.

Kaizen Action:
Tighten Newsletter Intelligence validation checklist.

Example 3: Developer Handoff Failure

Failure Title:
Developer Brief Missing Exact File Path

Date Logged:
YYYY-MM-DD

Source:
Developer support output

Workflow:
Developer Support Workflow

Owning Brain:
HeadOffice Brain

AI Employee Involved:
Developer Support Agent

Failure Category:
Developer Instruction Failure / Handoff Failure

Severity Level:
Level 3 — Serious

What Went Wrong:
The developer brief gave general instructions but did not include exact file path, exact insertion point, or test steps.

Why It Failed:
The current file evidence was missing and the output moved too quickly into instructions.

Immediate Action Taken:
Paused developer handoff and requested file contents or screenshot.

Containment Action:
Did not send vague instructions to M.

Final Decision:
Awaiting Input

Learning Captured:
If M has to guess, the developer handoff has failed.

Kaizen Action:
Require Developer Support Agent to include exact site, file path, current issue, required change, what not to touch, and test steps.

Example 4: Offer Evaluation Failure

Failure Title:
Offer Evaluation Treated Vendor Claims As Evidence

Date Logged:
YYYY-MM-DD

Source:
Affiliate offer page

Workflow:
Offer Evaluation Workflow

Owning Brain:
Affiliate Brain

Supporting Brains Affected:
Research Brain, Ads Brain, Finance Brain, Experimentation Brain

AI Employee Involved:
Offer Evaluation Agent

Failure Category:
Source Grounding Failure

Severity Level:
Level 3 — Serious

What Went Wrong:
The evaluation accepted vendor claims without verifying external evidence, payout quality, funnel risk, or traffic fit.

Why It Failed:
Vendor hype was not separated from evidence during normalization.

Immediate Action Taken:
Rerouted to Research Brain and Finance Brain before any test decision.

Containment Action:
No test budget approved.

Final Decision:
Rerouted

Learning Captured:
Vendor claims are not evidence. Offer evaluation must separate claims, proof, risk, traffic fit, and finance logic.

Kaizen Action:
Strengthen Offer Evaluation validation rule.

Example 5: Course Absorption Failure

Failure Title:
Course Output Summarized Instead Of Extracting System Value

Date Logged:
YYYY-MM-DD

Source:
Uploaded course lesson

Workflow:
Course Absorption Workflow

Owning Brain:
HeadOffice Brain

AI Employee Involved:
Course Absorption Agent

Failure Category:
Output Quality Failure

Severity Level:
Level 2 — Moderate

What Went Wrong:
The output explained the lesson but did not extract reusable MWMS frameworks, workflows, AI Employee upgrades, validation rules, or Blueprint improvements.

Why It Failed:
The task instruction was too summary-focused and did not apply Course Absorption System v2 strongly enough.

Immediate Action Taken:
Revised extraction using MWMS system-value filter.

Containment Action:
Did not create MCR page from weak summary.

Final Decision:
Revised

Learning Captured:
Course absorption must create system value, not passive notes.

Kaizen Action:
Apply course absorption value filter before drafting pages.

Failure Quality Checklist

Before closing a Failure Log Record, check:

  1. Is the failure title clear?
  2. Is the date logged?
  3. Is the source identified?
  4. Is the source reference included where needed?
  5. Is the workflow identified?
  6. Is the owning Brain clear?
  7. Are affected Brains listed?
  8. Is the AI Employee involved identified?
  9. Is the failure category selected?
  10. Is severity level assigned?
  11. Is what went wrong clearly stated?
  12. Is likely cause identified?
  13. Is immediate action recorded?
  14. Is containment action recorded?
  15. Is escalation destination clear if needed?
  16. Is final decision stated?
  17. Is correction applied?
  18. Is validation status after correction clear?
  19. Is outcome impact described?
  20. Is learning captured?
  21. Is related standard update needed?
  22. Is Kaizen action defined?
  23. Is follow-up owner assigned?
  24. Is follow-up status clear?
  25. Is logging requirement met?

If several answers are unclear, the failure record is incomplete.

Manual Use Rule

This record should be used manually before it becomes technical infrastructure.

Manual failure logging helps MWMS learn:

  • which failures repeat
  • which AI Employees need better role cards
  • which workflows need better validation
  • which handoffs lose context
  • which dashboard items create noise
  • which input types cause problems
  • which automations are premature
  • which developer instructions need stronger evidence
  • which fields may later become Supabase failure logs

Manual proof comes before automation.

Future Plugin Or UI Relevance

This record may later become:

  • AI failure log table
  • validation failure record
  • task failure state
  • HeadOffice failure dashboard
  • automation stop-condition log
  • AI Employee performance review record
  • Brain Room failure review panel
  • Developer handoff failure tracker
  • AIBS client workflow safety log

Possible future fields:

  • failure_id
  • failure_title
  • date_logged
  • source
  • source_reference
  • workflow
  • owning_brain
  • supporting_brains_affected
  • ai_employee_involved
  • failure_category
  • severity_level
  • what_went_wrong
  • why_it_failed
  • immediate_action_taken
  • containment_action
  • escalation_destination
  • final_decision
  • correction_applied
  • validation_status_after_correction
  • outcome_impact
  • learning_captured
  • related_standard_to_update
  • kaizen_action
  • owner_of_follow_up
  • follow_up_status
  • logging_required
  • created_at
  • updated_at

No technical build is authorized by this record alone.

Governance Role

HeadOffice owns the MWMS AI Agent Failure Log Record.

HeadOffice is responsible for:

  • deciding which failures must be logged
  • classifying failure categories
  • assigning severity levels
  • requiring escalation where needed
  • ensuring failures are contained
  • ensuring repeated failures create Kaizen improvements
  • protecting MCR from weak outputs
  • protecting dashboards from noise
  • protecting M from vague developer handoffs
  • protecting paid traffic and finance decisions
  • protecting future AIBS clients from unsafe workflows
  • deciding when this record is ready for operational copy or plugin/UI transformation

Individual Brains may keep their own failure records, but they must align with HeadOffice failure categories and severity rules.

Relationship To Other MWMS Standards

This record supports and must align with:

  • MWMS AI Agent Failure Handling And Escalation Protocol
  • MWMS AI Agent Operations Core
  • MWMS Agentic Work Unit Standard
  • MWMS Agentic Work Unit Template
  • MWMS AI Employee Role Card Standard
  • MWMS AI Employee Role Card Template
  • MWMS AI Workflow Pipeline Standard
  • MWMS AI Workflow Pipeline Checklist
  • MWMS AI Output Validation Standard
  • MWMS AI Output Validation Checklist
  • MWMS Messy Input Normalization Framework
  • MWMS Messy Input Normalization Record
  • MWMS Agentic Reporting Standard
  • MWMS Agentic Reporting Template
  • MWMS AI Employee Handoff Protocol
  • MWMS AI Employee Handoff Package Template
  • MWMS AI Agent Outcome Measurement Framework
  • MWMS AI Agent Memory And Context Framework
  • MWMS AI Tool Permission And Access Framework
  • MWMS Brain Routing Rule
  • MWMS Brain To Brain Request Protocol
  • MWMS Supabase Event Schema
  • AI Business Systems Brain Blueprint

This record is the practical application of the MWMS AI Agent Failure Handling And Escalation Protocol.

Drift Protection

This record protects MWMS from the following forms of drift:

  1. Ignoring failures because the output sounded confident
  2. Fixing failures without learning from them
  3. Repeating the same AI workflow mistakes
  4. Treating failed outputs as final
  5. Allowing weak course material into MCR
  6. Allowing vague developer instructions to reach M
  7. Allowing dashboard noise to accumulate
  8. Allowing wrong Brain routing to continue
  9. Skipping validation after failure
  10. Automating workflows that fail unsafely
  11. Hiding errors instead of logging them
  12. Letting tool permission failures become live-system risks
  13. Failing to escalate high-risk issues
  14. Missing Kaizen improvements from repeated failures
  15. Allowing client-facing failures without review and correction

Any meaningful failure that is not logged risks repeating itself.

Architectural Intent

The architectural intent of the MWMS AI Agent Failure Log Record is to make failure useful.

MWMS is building a governed AI workforce.

A serious workforce needs a way to record what goes wrong.

Failure logging allows MWMS to improve:

  • AI Employee roles
  • task instructions
  • workflow pipelines
  • validation gates
  • handoff packages
  • tool permissions
  • dashboards
  • developer support
  • course absorption
  • newsletter intelligence
  • offer evaluation
  • future AIBS client workflows

The long-term goal is that every meaningful AI failure can answer:

  • What failed?
  • Where did it fail?
  • Which Brain owned it?
  • Which AI Employee was involved?
  • Why did it fail?
  • How serious was it?
  • What was done immediately?
  • Was damage contained?
  • Was it escalated?
  • What correction was applied?
  • Was it revalidated?
  • What did MWMS learn?
  • What should improve so it does not happen again?

When MWMS can answer those questions, failure becomes system intelligence.

Change Log

v1.0 — Initial Draft

Created the MWMS AI Agent Failure Log Record as the practical operational template for logging, classifying, correcting, escalating, and learning from failures across MWMS AI Employees, workflows, validation systems, reports, handoffs, dashboards, automation systems, developer support, course absorption, newsletter intelligence, offer evaluation, and future AIBS client workflows.

This record operationalizes the MWMS AI Agent Failure Handling And Escalation Protocol and supports the MWMS Kaizen loop by converting failure into reusable system improvement.