System: MWMS
Document Type: Framework
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Version: v1.1
Last Reviewed: 2026-06-28
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, MWMS Brain, Brain Room, AI Manager, AI Employee Router, Task Executor Systems, Newsletter Intelligence, Routed Actions, HeadOffice Dashboard, 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 Recurring Intelligence And Reporting Pipeline Framework.
This framework explains how MWMS should create recurring intelligence reports, operational summaries, weekly digests, system reviews, action summaries, and future client reports through a controlled AI pipeline.
MWMS does not need recurring reports that simply repeat information.
MWMS needs recurring reports that help HeadOffice:
see what happened
understand what matters
identify risks
prioritize actions
monitor progress
detect failures
review outcomes
improve AI Employees
support M safely
prepare future AIBS client reporting systems
Recurring reports must be useful, validated, and decision-ready.
The goal is not to automate reports for the sake of automation.
The goal is to create a repeatable reporting system that turns ongoing MWMS activity into clear operational intelligence.
Scope
This framework applies to all recurring reporting workflows across MWMS.
This includes:
Weekly HeadOffice reports
Weekly Kaizen Digest
Newsletter Intelligence digest
Routed Actions summary
AI Employee outcome review
AI Employee failure review
Brain Room activity summary
Opportunity pipeline summary
Affiliate offer review summary
Experimentation summary
Finance exposure summary
Content Brain production summary
Ads Brain performance summary
M developer progress summary
system stability report
dashboard health report
future AIBS client weekly reports
future AIBS client operational reviews
recurring competitor intelligence reports
competitor website change monitoring
competitor reputation and sentiment summaries
market positioning change reviews
This framework applies across:
HeadOffice Brain
Brain Room
AI Manager
Newsletter Intelligence
Routed Actions
Opportunity System
Affiliate Brain
Research Brain
Experimentation Brain
Finance Brain
Content Brain
Ads Brain
Operations Brain
AI Business Systems Brain
future client systems
This framework does not authorize automatic delivery, automatic external reporting, client reporting, or developer build work.
It defines the recurring reporting logic that must be manually proven before scheduling, automation, plugin/UI build, or client use.
Core Definition
A Recurring Intelligence And Reporting Pipeline is a controlled workflow that gathers information from approved sources, cleans it, analyzes it, formats it into a useful report, validates it, routes it to the correct destination, monitors failures, and captures learning.
The default pipeline is:
Source Intake → Cleaning → Classification → Analysis → Report Generation → Validation → Review Or Delivery → Logging → Outcome Review → Kaizen Update
A recurring report is not just a scheduled summary.
A recurring report must answer:
What changed?
What matters?
What needs action?
What should be monitored?
What failed?
What improved?
Who owns the next step?
What did MWMS learn?
Core Principle
The core principle of this framework is:
Recurring reports must create operational intelligence, not recurring noise.
A report that runs every week but does not create clarity becomes clutter.
A report that creates clarity, priority, accountability, and learning becomes a HeadOffice control system.
Recurring reporting must therefore be:
source-grounded
action-aware
risk-aware
outcome-focused
validated before use
monitored for failure
improved through Kaizen
Recurring Reporting Pipeline Stages
The MWMS Recurring Intelligence And Reporting Pipeline has ten stages:
Report Purpose Definition
Source Intake
Input Cleaning
Classification And Grouping
Analysis And Meaning Extraction
Report Generation
Validation And Review
Delivery Or Routing
Failure Monitoring
Outcome Logging And Kaizen Update
- Report Purpose Definition
Every recurring report must have a clear purpose before it is created.
A report may exist to:
summarize activity
identify urgent actions
monitor system health
review AI Employee outcomes
detect repeated failures
summarize newsletter intelligence
track routed actions
review M development progress
review offer pipeline progress
prepare HeadOffice decisions
support client reporting
Report Purpose Rule:
If the purpose is unclear, the report should not become recurring.
Recurring reports must not exist just because they are easy to generate.
- Source Intake
Source intake defines where the report gets its information.
Possible sources include:
newsletter_intelligence rows
Newsletter Queue Review
Routed Actions
Brain Room messages
AI Agent Failure Logs
AI Agent Outcome Logs
Course Absorption records
MCR Change Log
Supabase task events
HeadOffice dashboard data
Opportunity pipeline records
Experimentation results
Finance notes
M developer updates
user notes
manually provided summaries
future client system data
approved competitor websites
public product, pricing, offer, and positioning pages
approved review platforms
approved public social and content sources
prior source snapshots
competitor registry records
Source Intake Rule:
Recurring reports must use known sources, not vague memory.
If source data is incomplete, stale, or unverified, the report must say so.
- Input Cleaning
Input cleaning removes noise before the report is generated.
Cleaning may include:
removing duplicate items
removing irrelevant newsletter content
removing low-value system noise
filtering parked or rejected items
excluding completed items where not needed
identifying missing fields
grouping similar items
flagging stale records
separating facts from assumptions
excluding unvalidated claims
removing dynamic page noise
removing cosmetic variation
normalizing source text before comparison
removing duplicated reviews
separating old reviews from new reviews
identifying missing previous captures
flagging unusually small evidence samples
Input Cleaning Rule:
Dirty data creates dirty reports.
A recurring report should not amplify raw clutter.
- Classification And Grouping
After cleaning, report inputs must be grouped into useful categories.
Possible categories include:
ACT NOW
TEST
MONITOR
PARKED
REJECTED
open actions
completed actions
blocked actions
failures
risks
decisions needed
M tasks
HeadOffice tasks
Brain-specific tasks
system stability items
Kaizen improvements
revenue-support items
client-facing items
Classification Rule:
Recurring reports should organize information by decision usefulness.
A report that lists everything equally does not help HeadOffice decide.
- Analysis And Meaning Extraction
Analysis explains what the information means.
This stage identifies:
patterns
changes
repeated failures
recurring opportunities
urgent risks
blocked work
ownerless actions
high-value signals
weak signals
system drift
progress made
next decisions needed
competitor positioning changes
offer and pricing changes
customer sentiment patterns
unmet market needs
differentiation opportunities
cross-competitor trends
Analysis Rule:
A recurring report must interpret information, not only list it.
The report should make MWMS smarter each time it runs.
- Report Generation
Report generation turns cleaned and analyzed information into the correct report format.
Possible report formats include:
Weekly HeadOffice Report
Weekly Kaizen Digest
Newsletter Intelligence Digest
Routed Actions Summary
AI Employee Outcome Review
AI Employee Failure Review
Brain Room Weekly Summary
Opportunity Pipeline Summary
M Developer Progress Summary
System Stability Report
AIBS Client Weekly Report Draft
Report Generation Rule:
Report format must match the audience and decision need.
HeadOffice reports should be sharp, prioritized, and action-ready.
Client reports should be simple, safe, business-friendly, and reviewed before delivery.
- Validation And Review
Recurring reports must be validated before they are trusted.
Validation may check:
source completeness
source freshness
duplicate removal
correct classification
action accuracy
owner clarity
risk level
unsupported claims
missing decisions
dashboard consistency
client safety
human review requirement
Validation Rule:
Scheduled output is not automatically trusted.
A report can run successfully and still be weak, incomplete, or misleading.
- Delivery Or Routing
After validation, the report should go to the correct destination.
Possible destinations include:
HeadOffice review
HeadOffice Dashboard
Brain Room
Routed Actions
Martyn review
M developer review
relevant Brain owner
Parking System
Archive
future client review queue
future client delivery after approval
Delivery Rule:
A report must have a destination and a next action.
Reports should not be generated and forgotten.
- Failure Monitoring
Recurring reports must be monitored for failure.
Failure may include:
report did not run
source data missing
report generated empty output
report generated generic output
source fields missing
classification failed
output contained unsupported claims
report routed to wrong destination
report repeated stale items
report created no action
report created dashboard noise
Failure Monitoring Rule:
Recurring workflows must be watched because silent failure creates false confidence.
A recurring report that quietly fails can become more dangerous than no report.
- Outcome Logging And Kaizen Update
The final stage records whether the report created value.
Outcome questions:
Did the report create a decision?
Did it create an action?
Did it identify a risk?
Did it reduce noise?
Did it help HeadOffice prioritize?
Did it help M?
Did it improve a workflow?
Did it reveal a repeated failure?
Did it produce reusable learning?
Kaizen questions:
Should the report format change?
Should sources be improved?
Should filters be tightened?
Should weak sections be removed?
Should a new section be added?
Should the report remain recurring?
Outcome Rule:
A recurring report should be reviewed by the value it creates, not by whether it ran.
Core Recurring Report Types
- Weekly HeadOffice Report
Purpose:
Give HeadOffice a clear weekly view of priorities, risks, signals, decisions, and next actions.
Typical Sources:
Newsletter Intelligence
Routed Actions
Brain Room
AI Agent Failure Logs
AI Agent Outcome Logs
MCR Change Log
system stability notes
M updates
active build notes
Core Sections:
Executive Summary
ACT NOW
TEST
MONITOR
Risks
Blockers
Decisions Needed
M Notes
System Health
Outcomes
Kaizen Improvements
Next Week Focus
Human Review Required:
Yes.
Status:
Manual first, scheduled later only after proof.
- Weekly Kaizen Digest
Purpose:
Capture system improvements, repeated failures, workflow refinements, AI Employee improvements, and rule updates.
Typical Sources:
Failure Logs
Outcome Logs
user corrections
MCR changes
validation failures
repeated workflow issues
AI Employee performance notes
Core Sections:
Top Improvements
Repeated Failure Patterns
Updated Rules
AI Employee Improvements
Workflow Refinements
Tool Or Permission Issues
Next Kaizen Actions
Human Review Required:
Yes.
Status:
Manual first.
- Newsletter Intelligence Digest
Purpose:
Summarize business-relevant external signals without newsletter noise.
Typical Sources:
newsletter_intelligence
Newsletter Queue Review
Routed Actions
parked signals
rejected signals
Core Sections:
ACT NOW Signals
TEST Signals
MONITOR Signals
PARKED Signals
Rejected Noise
Repeated Market Patterns
Tool And Platform Signals
Compliance Signals
Brain Routing Summary
Human Review Required:
Yes before actions.
Status:
Assisted use later.
- Routed Actions Summary
Purpose:
Show what actions are open, blocked, completed, parked, or escalated.
Typical Sources:
Routed Actions
Brain Room
HeadOffice Dashboard
task/event logs
owner updates
Core Sections:
Open Actions
Blocked Actions
Completed Actions
Overdue Actions
Ownerless Actions
High Priority Actions
Actions Needing Decision
Actions To Park Or Close
Human Review Required:
Yes for priority changes.
Status:
Useful for HeadOffice dashboard.
- AI Employee Outcome Review
Purpose:
Review whether AI Employees are creating useful outcomes or only output volume.
Typical Sources:
Outcome Logs
Failure Logs
Validation Reports
completed work
user feedback
Core Sections:
Best Outcomes
Weak Outcomes
High-Value Employees
Low-Value Workflows
Repeated Corrections
Skills To Improve
Roles To Split Or Merge
Automation Readiness Notes
Human Review Required:
Yes.
Status:
Manual review before automation.
- AI Employee Failure Review
Purpose:
Identify repeated failures and prevent them from recurring.
Typical Sources:
AI Agent Failure Logs
validation failures
tool failures
handoff failures
ambiguity records
developer handoff issues
Core Sections:
Top Failure Patterns
Severity Review
Root Causes
Containment Actions
Standards To Update
Skills To Improve
Tool Permissions To Tighten
Kaizen Actions
Human Review Required:
Yes.
Status:
Manual first.
- M Developer Progress Summary
Purpose:
Summarize M’s development progress, blockers, safe save points, and next tasks without interfering with build work.
Typical Sources:
M updates
Brain Room
Dev Console
task/event logs
user notes
current save point
Core Sections:
Work Completed
Current Save Point
Open Blockers
Next Safe Task
What Not To Touch
Risk Notes
Questions For Martyn
Developer Boundary Notes
Human Review Required:
Yes.
Status:
Manual only until development reporting is stable.
- Future AIBS Client Weekly Report
Recurring Competitor Intelligence Report
Competitor Website Change Report
Competitor Reputation And Sentiment Report
Market Positioning Change Report
Purpose:
Give a future client a simple, safe, reviewed summary of business process activity, recommendations, risks, and next steps.
Typical Sources:
approved client data
client workflow records
client task logs
client support records
client approval notes
Core Sections:
Plain English Summary
What Changed
Key Issues
Recommended Actions
Risks
Decisions Needed
Work Completed
Next Steps
Human Review Required:
Always before client delivery.
Status:
Future draft only.
Recurring Competitor Intelligence Reporting Mode
Purpose
The purpose of the Recurring Competitor Intelligence Reporting Mode is to allow MWMS and future AIBS systems to monitor approved external competitors and public market signals through a controlled, evidence-grounded recurring reporting pipeline.
The purpose is not surveillance for its own sake.
The purpose is to reduce manual research, detect meaningful market movement, identify customer pain points, support offer refinement, support content and sales positioning, identify test opportunities, improve client retention, and create recurring decision support.
The default competitor intelligence workflow is:
Client Definition → Competitor Registry → Baseline Capture → Scheduled Recapture → Material Change Comparison → Reputation Signal Analysis → Cross-Source Synthesis → Report Validation → Human Review → Delivery Or Routing → Outcome Logging
Competitor intelligence reports must be judged by the decisions and actions they create, not by the number of pages, competitors, or sources monitored.
- Client And Competitor Definition
Before recurring competitor monitoring begins, the workflow must define:
the client or MWMS business being supported
the relevant market
the approved competitor list
the competitor websites
the approved review sources
the approved public social or content sources where required
the reason each organisation is considered a competitor
the geographic relevance
the customer-market relevance
the monitoring frequency
the permitted source boundaries
A competitor must not be included simply because an AI system named it.
Competitor inclusion should be supported by one or more of the following:
overlapping customer intent
overlapping product or service category
overlapping search visibility
overlapping geography
overlapping price or positioning
direct commercial substitution
Competitor Definition Rule:
Every monitored competitor must have a clear inclusion rationale.
- Competitor Registry
Each monitored competitor should have a controlled record containing:
competitor name
official website
approved source URLs
inclusion rationale
source type
baseline date
most recent capture date
monitoring status
source availability
last meaningful change
confidence level
evidence location
client or internal report relationship
The competitor registry becomes the source of truth for what is monitored.
Competitor Registry Rule:
Only sources listed in the approved competitor registry should enter the recurring monitoring pipeline.
- Baseline Capture
A baseline must be created before recurring comparisons begin.
Possible baseline material includes:
homepage copy
product or service pages
pricing pages
offer pages
positioning statements
guarantees
calls to action
important announcements
review sentiment
customer complaints
customer praise
selected public social or content signals
A comparison without a stable baseline creates unreliable change claims.
Baseline Capture Rule:
No change report should be generated unless a valid previous capture exists or the report clearly states that only an initial baseline was created.
- Scheduled Recapture
Approved sources may be recaptured:
weekly
fortnightly
monthly
per campaign
after a known market event
on demand
The frequency should match:
expected rate of change
business value
data cost
source stability
client agreement
report usefulness
More frequent monitoring is not automatically more valuable.
Scheduled Recapture Rule:
Monitoring frequency must be justified by decision value, not technical convenience.
- Material Change Detection
The comparison stage must separate meaningful commercial changes from superficial variation.
Meaningful changes may include:
new product or service
removed product or service
pricing change
positioning change
offer change
guarantee change
audience change
geographic expansion
new promotion
new claim
new partnership
major content shift
changed call to action
changed acquisition path
significant customer sentiment change
The system should normally ignore:
minor formatting changes
image-order changes
rotating banners
timestamps
dynamic counters
tracking parameters
navigation movement
minor wording without changed meaning
automatically generated page noise
Material Change Rule:
A recurring competitor report must not inflate trivial visual or technical variation into a strategic business change.
- Previous-To-Current Comparison Contract
Each comparison should produce a structured result containing:
source
previous capture date
current capture date
change detected
materiality
change category
concise explanation
supporting evidence
confidence
possible business meaning
recommended action
human-review requirement
The system must distinguish:
confirmed change
probable change
uncertain change
no meaningful change
source failure
Comparison Contract Rule:
The report must clearly separate observed evidence from interpretation and recommendation.
- Reputation And Review Signal Analysis
Recurring competitor reports may analyse approved review sources for:
overall sentiment
customer praise
common complaints
unmet expectations
service failures
pricing concerns
usability concerns
customer-support concerns
delivery concerns
product-quality concerns
emerging needs
repeated competitor advantages
repeated competitor weaknesses
Review analysis must distinguish:
isolated complaint
repeated complaint
temporary event
persistent pattern
source bias
insufficient sample size
Review Signal Rule:
A small or biased review sample must not be presented as a confirmed market-wide pattern.
- Cross-Competitor Synthesis
The report should not merely list each competitor separately.
It should identify:
repeated market patterns
emerging category expectations
new positioning trends
common customer frustrations
underserved needs
offer convergence
market gaps
possible differentiation opportunities
risks to the client
opportunities worth testing
The system must separate:
micro signals
recurring patterns
broader market trends
unsupported speculation
Cross-Competitor Synthesis Rule:
The report must show why a repeated pattern matters and what action, test, or monitoring decision it supports.
- Multi-Source Expansion
The competitor intelligence mode may later support:
website monitoring
review monitoring
social-content monitoring
advertising signal monitoring
search-position monitoring
email or newsletter monitoring
product-catalogue monitoring
offer monitoring
public pricing monitoring
public job-posting monitoring
Every source must have:
a clear business purpose
lawful access
an approved collection method
evidence retention
failure handling
confidence treatment
Multi-Source Rule:
Additional sources should be added only when they improve a defined decision or report outcome.
- Competitor Intelligence Report Sections
A recurring competitor intelligence report may contain:
Executive Summary
What Changed
No Meaningful Change
Major Competitor Moves
Offer And Positioning Changes
Customer Sentiment
Common Praise
Common Complaints
Emerging Customer Expectations
Market Patterns
Risks
Opportunities
Recommended Actions
Items To Monitor
Evidence And Source Notes
Data Gaps
Human Review Notes
Report Structure Rule:
The report should prioritize commercially meaningful changes, risks, opportunities, and recommended actions rather than raw monitoring volume.
- Evidence And Traceability
Every material claim should link back to:
source URL
captured content
capture date
previous version
current version
review sample
comparison output
confidence level
The report should not present an AI interpretation as a confirmed competitor strategy.
Evidence Rule:
Every meaningful claim must be traceable to the underlying public source or captured evidence.
- Human Review And Delivery
Competitor intelligence reports should remain drafts until reviewed for:
false-positive changes
weak evidence
trivial changes
unsupported strategic conclusions
outdated sources
inappropriate recommendations
commercially sensitive claims
client suitability
External delivery always requires approval until the workflow has been independently proven and an explicit delivery policy exists.
Human Review Rule:
Scheduled generation does not authorize scheduled external delivery.
- Source Failure Handling
Possible failures include:
website unavailable
page structure changed
access blocked
review source unavailable
insufficient reviews
previous capture missing
current capture incomplete
false change caused by dynamic content
duplicated competitor
wrong competitor
stale source
conflicting signals
The report should state source failures rather than silently treating missing data as no change.
Source Failure Rule:
Missing or failed data must be labelled as unavailable, incomplete, or uncertain.
- Commercial And Operational Value
Competitor monitoring may support:
reducing manual research
detecting market movement
identifying customer pain points
supporting offer refinement
supporting content planning
supporting sales positioning
identifying test opportunities
improving client retention
creating recurring decision support
Commercial Value Rule:
The recurring competitor intelligence mode must be assessed by the decisions, tests, actions, or risk reductions it creates.
Recurring Competitor Intelligence Report
Purpose:
Monitor approved competitors and turn meaningful external changes into evidence-grounded business intelligence.
Typical Sources:
competitor registry
approved competitor websites
previous and current source captures
approved review sources
public offers and pricing
approved public social or content sources
Core Sections:
Executive Summary
Material Changes
Offer And Positioning Changes
Customer Sentiment
Common Praise
Common Complaints
Emerging Needs
Market Patterns
Risks
Opportunities
Recommended Actions
Monitor List
Evidence Notes
Source Failures
Human Review Required:
Always before external delivery.
Status:
Manual proof first. Scheduled candidate only after source comparison and false-positive controls are validated.
Recurring Report Record Template
Use this template when defining a recurring report.
Report Name
Field:
Report Name:
Report Type
Field:
Report Type:
Recommended values:
Weekly HeadOffice Report
Weekly Kaizen Digest
Newsletter Intelligence Digest
Routed Actions Summary
AI Employee Outcome Review
AI Employee Failure Review
M Developer Progress Summary
System Stability Report
Opportunity Pipeline Summary
AIBS Client Weekly Report
Report Purpose
Field:
Report Purpose:
Owning Brain
Field:
Owning Brain:
Supporting Brains
Field:
Supporting Brains:
Report Frequency
Field:
Report Frequency:
Recommended values:
Daily
Weekly
Fortnightly
Monthly
Per Sprint
Per Campaign
Per Client Cycle
On Demand
Trigger Type
Field:
Trigger Type:
Recommended values:
Manual Command
Time Based Trigger
Event Based Trigger
Conditional Trigger
Source Systems
Field:
Source Systems:
Required Inputs
Field:
Required Inputs:
Cleaning Rules
Field:
Cleaning Rules:
Classification Rules
Field:
Classification Rules:
Analysis Rules
Field:
Analysis Rules:
Report Sections
Field:
Report Sections:
Validation Requirement
Field:
Validation Requirement:
Human Review Requirement
Field:
Human Review Requirement:
Delivery Or Routing Destination
Field:
Delivery Or Routing Destination:
Failure Conditions
Field:
Failure Conditions:
Failure Handling
Field:
Failure Handling:
Logging Destination
Field:
Logging Destination:
Expected Outcome
Field:
Expected Outcome:
Report Status
Field:
Report Status:
Recommended values:
Proposed
Draft
Manual Use
Proven Manual Use
Assisted Use
Scheduled Candidate
Scheduled
Parked
Deprecated
Retired
Last Reviewed
Field:
Last Reviewed:
Quick Use Version
Report Name:
Report Type:
Report Purpose:
Owning Brain:
Supporting Brains:
Report Frequency:
Trigger Type:
Source Systems:
Required Inputs:
Cleaning Rules:
Classification Rules:
Analysis Rules:
Report Sections:
Validation Requirement:
Human Review Requirement:
Delivery Or Routing Destination:
Failure Conditions:
Failure Handling:
Logging Destination:
Expected Outcome:
Report Status:
Last Reviewed:
Example 1: Weekly HeadOffice Report
Report Name:
MWMS Weekly HeadOffice Report
Report Type:
Weekly HeadOffice Report
Report Purpose:
Give HeadOffice a weekly operational view of signals, risks, priorities, decisions, system health, and next actions.
Owning Brain:
HeadOffice Brain
Supporting Brains:
All active MWMS Brains as needed.
Report Frequency:
Weekly
Trigger Type:
Manual Command first. Time Based Trigger later only after proof.
Source Systems:
Newsletter Intelligence
Routed Actions
Brain Room
MCR Change Log
AI Agent Failure Logs
AI Agent Outcome Logs
system stability notes
M updates
Required Inputs:
open actions
urgent signals
blocked work
completed work
failures
outcomes
current risks
next decisions needed
Cleaning Rules:
remove duplicated items
remove stale noise
remove weak newsletter signals
mark unverified items
separate action from monitoring
Classification Rules:
ACT NOW
TEST
MONITOR
BLOCKED
COMPLETED
DECISION NEEDED
PARK
Analysis Rules:
identify priority actions
identify repeated patterns
identify risks
identify ownerless tasks
identify next-week focus
Report Sections:
Executive Summary
ACT NOW
TEST
MONITOR
Blockers
Decisions Needed
M Notes
System Health
Outcomes
Kaizen Improvements
Next Week Focus
Validation Requirement:
Operational Validation.
Human Review Requirement:
Yes.
Delivery Or Routing Destination:
HeadOffice review / HeadOffice Dashboard / Brain Room.
Failure Conditions:
missing source data
generic summary
no actions
no owners
outdated information
unsupported claims
Failure Handling:
Mark as draft, request missing data, revise, or park.
Logging Destination:
HeadOffice report archive / Brain Room / outcome log where applicable.
Expected Outcome:
HeadOffice knows what matters this week and what to do next.
Report Status:
Draft / Manual Use
Last Reviewed:
YYYY-MM-DD
Example 2: Weekly Kaizen Digest
Report Name:
MWMS Weekly Kaizen Digest
Report Type:
Weekly Kaizen Digest
Report Purpose:
Summarize system improvements, repeated failures, workflow refinements, and AI Employee upgrades.
Owning Brain:
HeadOffice Brain
Supporting Brains:
All active MWMS Brains.
Report Frequency:
Weekly
Trigger Type:
Manual Command first. Time Based Trigger later.
Source Systems:
Failure Logs
Outcome Logs
validation reports
user corrections
MCR changes
workflow notes
Brain Room
Required Inputs:
failures
corrections
successful outcomes
repeated issues
updated rules
new learning
improvement actions
Cleaning Rules:
group repeated failures
remove one-off noise
separate serious issues from minor polish
identify patterns
Classification Rules:
Process Improvement
Validation Improvement
Handoff Improvement
Tool Permission Improvement
AI Employee Improvement
Documentation Improvement
Developer Support Improvement
Analysis Rules:
identify highest-value improvements
identify repeated problems
identify standards needing update
identify skills needing refinement
Report Sections:
Top Improvements
Repeated Failure Patterns
Updated Rules
AI Employee Improvements
Workflow Refinements
Tool And Permission Issues
Next Kaizen Actions
Validation Requirement:
Structured Validation.
Human Review Requirement:
Yes.
Delivery Or Routing Destination:
HeadOffice review / MCR update candidates / Brain Room.
Failure Conditions:
no specific improvements
vague “we did better” language
no owner
no next action
Failure Handling:
Revise or park.
Logging Destination:
Kaizen archive / MCR change candidates / outcome log.
Expected Outcome:
MWMS becomes harder to break each week.
Report Status:
Manual Use
Last Reviewed:
YYYY-MM-DD
Example 3: Newsletter Intelligence Digest
Report Name:
MWMS Newsletter Intelligence Digest
Report Type:
Newsletter Intelligence Digest
Report Purpose:
Summarize useful newsletter signals and separate them from noise.
Owning Brain:
HeadOffice Brain
Supporting Brains:
Ads Brain, Affiliate Brain, Content Brain, Research Brain, Finance Brain, AI Business Systems Brain.
Report Frequency:
Daily or Weekly
Trigger Type:
Manual Command / Time Based Trigger Candidate
Source Systems:
newsletter_intelligence
Newsletter Queue Review
Routed Actions
HeadOffice Dashboard
Required Inputs:
extracted insights
primary Brain
supporting Brains
action type
priority
urgency
status
recommended action
Cleaning Rules:
remove duplicate signals
remove weak generic AI news
remove sponsor noise
mark unverified claims
group repeated patterns
Classification Rules:
ACT NOW
TEST
MONITOR
PARK
REJECT
Compliance
Tool Intelligence
Market Signal
Platform Signal
Affiliate Opportunity
Analysis Rules:
identify repeated market patterns
identify action-worthy signals
identify noise
identify Brain routing needs
Report Sections:
ACT NOW Signals
TEST Signals
MONITOR Signals
PARKED Signals
Rejected Noise
Repeated Patterns
Brain Routing Summary
Recommended Next Actions
Validation Requirement:
Operational Validation.
Human Review Requirement:
Yes before downstream action.
Delivery Or Routing Destination:
HeadOffice review / Newsletter Queue Review / Dashboard candidate.
Failure Conditions:
generic summary
no Brain routing
no action type
weak priority logic
unverified urgent claims
false website-change detection
competitor source unavailable
comparison made without a valid baseline
cosmetic change interpreted as strategic change
review analysis based on insufficient evidence
speculation presented as fact
evidence cannot be traced to source
Failure Handling:
Park, revise, reject, or send to Research Brain.
Logging Destination:
Newsletter Intelligence records / Routed Actions / outcome log where useful.
Expected Outcome:
HeadOffice sees useful external intelligence without newsletter noise.
Report Status:
Assisted Use Candidate
Last Reviewed:
YYYY-MM-DD
Example 4: AI Employee Outcome Review
Report Name:
MWMS AI Employee Outcome Review
Report Type:
AI Employee Outcome Review
Report Purpose:
Review which AI Employees and workflows are creating useful outcomes.
Owning Brain:
HeadOffice Brain
Supporting Brains:
All Brains with active AI Employees.
Report Frequency:
Weekly or Monthly
Trigger Type:
Manual Command first.
Source Systems:
AI Agent Outcome Logs
Failure Logs
validation reports
completed tasks
Brain Room feedback
user corrections
Required Inputs:
outcomes created
outcome scores
decisions made
actions created
risks reduced
learning captured
failures corrected
Cleaning Rules:
remove output-only activity
group outcomes by AI Employee
separate high-value outcomes from low-value activity
identify repeated weak outcomes
Classification Rules:
Decision Outcome
Action Outcome
Risk Reduction Outcome
Time Saving Outcome
Quality Improvement Outcome
Revenue Support Outcome
Learning Outcome
System Reliability Outcome
Analysis Rules:
identify useful AI Employees
identify weak AI Employees
identify role overlap
identify skill improvement needs
identify automation readiness
Report Sections:
Best Outcomes
Weak Outcomes
High-Value AI Employees
Low-Value Workflows
Repeated Corrections
Skills To Improve
Roles To Split Or Merge
Automation Readiness Notes
Validation Requirement:
Structured Validation.
Human Review Requirement:
Yes.
Delivery Or Routing Destination:
HeadOffice review / AI Workforce review / Kaizen Digest.
Failure Conditions:
measures output volume instead of outcome
inflates value
missing examples
no next action
Failure Handling:
Revise report and improve outcome logging.
Logging Destination:
AI Workforce review archive / outcome log.
Expected Outcome:
MWMS improves AI workforce usefulness and removes low-value work.
Report Status:
Draft / Manual Use
Last Reviewed:
YYYY-MM-DD
Example 5: Future AIBS Client Weekly Report
Report Name:
AIBS Client Weekly Operations Report
Report Type:
AIBS Client Weekly Report
Report Purpose:
Provide a future client with a simple, reviewed summary of workflow activity, risks, decisions, and recommended actions.
Owning Brain:
AI Business Systems Brain
Supporting Brains:
HeadOffice Brain, Operations Brain, client-specific Brain.
Report Frequency:
Weekly
Trigger Type:
Time Based Trigger only after manual proof and client approval rules are defined.
Source Systems:
approved client workflow data
approved client task records
approved client reports
client-specific logs
client-approved data sources
Required Inputs:
work completed
open issues
risks
recommendations
decisions needed
next steps
Cleaning Rules:
remove irrelevant data
isolate client context
mark uncertain claims
remove unsupported assumptions
protect sensitive information
Classification Rules:
Completed
In Progress
Blocked
Risk
Decision Needed
Recommended Action
Monitor
Analysis Rules:
explain business meaning clearly
avoid technical overload
avoid unsupported claims
identify practical next steps
Report Sections:
Plain English Summary
What Changed
Key Issues
Recommended Actions
Risks
Decisions Needed
Work Completed
Next Steps
Validation Requirement:
High Risk Validation.
Human Review Requirement:
Always before client delivery.
Delivery Or Routing Destination:
Client Review Queue / HeadOffice approval / client delivery only after approval.
Failure Conditions:
client data outside scope
unsupported claim
privacy concern
no approval gate
unclear recommendation
overly technical language
Failure Handling:
Stop, revise, escalate to HeadOffice, do not deliver.
Logging Destination:
Client audit log / AIBS review archive.
Expected Outcome:
Client receives useful, safe, reviewed business reporting.
Report Status:
Future Draft Only
Last Reviewed:
YYYY-MM-DD
Recurring Report Readiness Checklist
Before a recurring report is approved, check:
Is the report purpose clear?
Is the owning Brain clear?
Are supporting Brains listed?
Is the frequency justified?
Is the trigger type defined?
Are source systems known?
Are required inputs listed?
Are cleaning rules defined?
Are classification rules defined?
Are analysis rules defined?
Are report sections useful?
Is validation required?
Is human review required where needed?
Is delivery or routing destination clear?
Are failure conditions listed?
Is failure handling defined?
Is logging destination known?
Is expected outcome clear?
Has the report been manually proven?
Is scheduling premature?
Could the report create recurring noise?
Could it affect M’s active build?
Could it affect client trust?
Could it create action without review?
Should the report remain on-demand?
If several answers are unclear, the report is not ready for recurring use.
Common Recurring Reporting Failure Modes
Recurring reporting has failed if:
The report has no clear purpose.
The report runs because it can, not because it should.
Source data is missing or stale.
Cleaning rules are absent.
The report repeats noise.
The report lists everything equally.
The report has no actions.
The report has no owner.
The report includes unvalidated claims.
The report creates dashboard clutter.
The report hides failures.
The report runs successfully but produces weak output.
The report is scheduled before manual proof.
Human review is skipped.
Client reports are delivered without approval.
Manual Use Rule
Recurring reports should be created manually before they become scheduled or automated.
Manual use helps MWMS learn:
which report sections are actually useful
which sources are reliable
which sources create noise
which report frequency is appropriate
which reports should be weekly, daily, monthly, or on-demand
which outputs need validation
which reports create decisions
which reports create no value
which failure conditions repeat
which reports may later become dashboards or scheduled pipelines
Manual recurring reporting discipline comes before scheduled automation.
Future Plugin Or UI Relevance
This framework may later support:
recurring report registry
HeadOffice weekly report generator
Weekly Kaizen Digest generator
Newsletter Intelligence digest system
Routed Actions summary dashboard
AI Employee outcome review dashboard
AI Employee failure review dashboard
M developer progress summary
client weekly report generator
AI Manager scheduled report routing
Task Executor scheduled report jobs
Possible future fields:
recurring_report_id
report_name
report_type
report_purpose
owning_brain
supporting_brains
report_frequency
trigger_type
source_systems
required_inputs
cleaning_rules
classification_rules
analysis_rules
report_sections
validation_requirement
human_review_requirement
delivery_destination
failure_conditions
failure_handling
logging_destination
expected_outcome
report_status
last_reviewed
created_at
updated_at
client_id
competitor_id
competitor_registry_id
source_url
source_type
baseline_capture_id
current_capture_id
previous_capture_date
current_capture_date
change_detected
change_category
materiality
confidence_level
evidence_location
sentiment_summary
repeated_strengths
repeated_complaints
unmet_needs
recommended_actions
source_failure_status
No technical build is authorized by this framework alone.
Governance Role
HeadOffice owns the MWMS Recurring Intelligence And Reporting Pipeline Framework.
HeadOffice is responsible for:
approving recurring report types
preventing recurring report clutter
deciding which reports should be manual, scheduled, parked, or retired
ensuring report sources are known
ensuring cleaning and validation rules exist
ensuring reports produce useful decisions or actions
ensuring human review is preserved where required
ensuring scheduled reports have failure monitoring
protecting M’s active build areas
protecting MCR source of truth
protecting future AIBS client reporting quality
Individual Brains may propose recurring reports, but HeadOffice governs cross-Brain, high-risk, scheduled, client-facing, dashboard-related, and automation-related reporting pipelines.
Relationship To Other MWMS Standards
This framework supports and must align with:
MWMS AI Agent Operations Core
MWMS AI Command And Trigger Framework
MWMS AI Multi Agent Role Design Framework
MWMS AI Exchange Zone And Dependency Control Framework
MWMS AI Ambiguity And Partial Failure Containment Framework
MWMS AI Agent Skill Library Framework
MWMS AI Plugin Orchestration Framework
MWMS AI Documentation Automation Pipeline Framework
MWMS Agentic Reporting Standard
MWMS Agentic Reporting Template
MWMS AI Workflow Pipeline Standard
MWMS AI Workflow Pipeline Checklist
MWMS AI Output Validation Standard
MWMS AI Output Validation Checklist
MWMS AI Agent Failure Handling And Escalation Protocol
MWMS AI Agent Failure Log Record
MWMS AI Agent Outcome Measurement Framework
MWMS AI Agent Outcome Log Record
MWMS AI Agent Deployment Readiness Checklist
MWMS AI Agent Deployment Readiness Review Template
MWMS AI Tool Permission And Access Framework
MWMS AI Tool Permission Record Template
MWMS Brain Routing Rule
MWMS Brain To Brain Request Protocol
MWMS Supabase Event Schema
AI Business Systems Brain Blueprint
This framework adds the recurring intelligence and reporting layer to the MWMS AI Agent Operations Core.
Drift Protection
This framework protects MWMS from:
Creating recurring reports with no purpose
Automating weak summaries
Scheduling reports before manual proof
Treating successful report generation as useful reporting
Repeating dashboard noise
Including stale or unverified information
Creating reports with no owner or next action
Hiding failures inside recurring workflows
Creating HeadOffice clutter
Producing AI Employee reports based on output volume instead of outcomes
Delivering client reports without review
Letting scheduled workflows bypass validation
Creating recurring work for M without clear need
Measuring reporting frequency instead of reporting value
Forgetting Kaizen learning from repeated reporting failures
Monitoring competitors without an approved registry
Comparing sources without a valid baseline
Treating cosmetic page changes as strategic movement
Presenting AI interpretation as confirmed competitor intent
Using weak review samples as market-wide evidence
Hiding source failure as no change
Delivering competitor reports without human review
Any recurring report without purpose, source control, validation, destination, and outcome value should remain draft, manual, parked, or retired.
Architectural Intent
The architectural intent of the MWMS Recurring Intelligence And Reporting Pipeline Framework is to turn ongoing MWMS activity into useful operational intelligence.
MWMS will produce a large amount of activity across Brains, AI Employees, newsletters, courses, offers, tasks, dashboards, development, failures, and outcomes.
Without recurring reporting discipline, that activity becomes noise.
With recurring reporting discipline, HeadOffice can see:
what matters
what changed
what failed
what improved
what needs action
what needs review
what should be parked
what should be escalated
what should be learned
The long-term goal is that every recurring report can answer:
Why does this report exist?
What sources does it use?
How is the data cleaned?
How is it classified?
What analysis is performed?
What output is created?
How is it validated?
Where does it go?
What happens if it fails?
What outcome should it create?
Should it continue, change, or be retired?
When MWMS can answer those questions, recurring reports become a control system, not administrative noise.
Change Log
v1.1 — Recurring Competitor Intelligence Reporting Enhancement
Added the Recurring Competitor Intelligence Reporting Mode.
Established controlled client and competitor definition, competitor registry records, baseline capture, scheduled recapture, material change detection, previous-to-current comparison contracts, reputation and review signal analysis, cross-competitor synthesis, multi-source expansion, evidence traceability, human review, source failure handling, and commercial outcome measurement.
Expanded the framework to support future MWMS and AIBS competitor website monitoring, reputation monitoring, market-positioning reviews, and recurring decision-ready competitor reports without creating a separate overlapping framework.
Expanded scope, approved sources, cleaning rules, analysis rules, failure conditions, report types, future fields, drift protection, and client-reporting controls for recurring competitor intelligence.
v1.0 — Initial Draft
Created the MWMS Recurring Intelligence And Reporting Pipeline Framework to define how MWMS creates recurring operational intelligence reports, weekly reports, digests, summaries, AI Employee reviews, failure reviews, routed action summaries, HeadOffice reports, and future AIBS client reports.
This framework establishes recurring reporting pipeline stages, core report types, report record templates, examples, readiness checks, failure modes, future plugin/UI relevance, governance role, drift protection, and architectural intent.
It establishes that recurring reports must create operational intelligence, not recurring noise.
END OF FULL FILE OUTPUT