MWMS MCR

MWMS Recurring Intelligence And Reporting Pipeline Framework

System: MWMS
Document Type: Framework
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, MWMS Brain, Brain Room, AI Manager, AI Employee Router, Task Executor Systems, 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

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:

  1. Report Purpose Definition
  2. Source Intake
  3. Input Cleaning
  4. Classification And Grouping
  5. Analysis And Meaning Extraction
  6. Report Generation
  7. Validation And Review
  8. Delivery Or Routing
  9. Failure Monitoring
  10. Outcome Logging And Kaizen Update

1. 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.

2. 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

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.

3. 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

Input Cleaning Rule:

Dirty data creates dirty reports.

A recurring report should not amplify raw clutter.

4. 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.

5. 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

Analysis Rule:

A recurring report must interpret information, not only list it.

The report should make MWMS smarter each time it runs.

6. 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.

7. 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.

8. 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.

9. 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.

10. 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

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

8. Future AIBS Client Weekly 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 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:

  1. Executive Summary
  2. ACT NOW
  3. TEST
  4. MONITOR
  5. Blockers
  6. Decisions Needed
  7. M Notes
  8. System Health
  9. Outcomes
  10. Kaizen Improvements
  11. 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:

  1. Top Improvements
  2. Repeated Failure Patterns
  3. Updated Rules
  4. AI Employee Improvements
  5. Workflow Refinements
  6. Tool And Permission Issues
  7. 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:

  1. ACT NOW Signals
  2. TEST Signals
  3. MONITOR Signals
  4. PARKED Signals
  5. Rejected Noise
  6. Repeated Patterns
  7. Brain Routing Summary
  8. 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

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:

  1. Best Outcomes
  2. Weak Outcomes
  3. High-Value AI Employees
  4. Low-Value Workflows
  5. Repeated Corrections
  6. Skills To Improve
  7. Roles To Split Or Merge
  8. 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:

  1. Plain English Summary
  2. What Changed
  3. Key Issues
  4. Recommended Actions
  5. Risks
  6. Decisions Needed
  7. Work Completed
  8. 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:

  1. Is the report purpose clear?
  2. Is the owning Brain clear?
  3. Are supporting Brains listed?
  4. Is the frequency justified?
  5. Is the trigger type defined?
  6. Are source systems known?
  7. Are required inputs listed?
  8. Are cleaning rules defined?
  9. Are classification rules defined?
  10. Are analysis rules defined?
  11. Are report sections useful?
  12. Is validation required?
  13. Is human review required where needed?
  14. Is delivery or routing destination clear?
  15. Are failure conditions listed?
  16. Is failure handling defined?
  17. Is logging destination known?
  18. Is expected outcome clear?
  19. Has the report been manually proven?
  20. Is scheduling premature?
  21. Could the report create recurring noise?
  22. Could it affect M’s active build?
  23. Could it affect client trust?
  24. Could it create action without review?
  25. 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:

  1. The report has no clear purpose.
  2. The report runs because it can, not because it should.
  3. Source data is missing or stale.
  4. Cleaning rules are absent.
  5. The report repeats noise.
  6. The report lists everything equally.
  7. The report has no actions.
  8. The report has no owner.
  9. The report includes unvalidated claims.
  10. The report creates dashboard clutter.
  11. The report hides failures.
  12. The report runs successfully but produces weak output.
  13. The report is scheduled before manual proof.
  14. Human review is skipped.
  15. 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

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:

  1. Creating recurring reports with no purpose
  2. Automating weak summaries
  3. Scheduling reports before manual proof
  4. Treating successful report generation as useful reporting
  5. Repeating dashboard noise
  6. Including stale or unverified information
  7. Creating reports with no owner or next action
  8. Hiding failures inside recurring workflows
  9. Creating HeadOffice clutter
  10. Producing AI Employee reports based on output volume instead of outcomes
  11. Delivering client reports without review
  12. Letting scheduled workflows bypass validation
  13. Creating recurring work for M without clear need
  14. Measuring reporting frequency instead of reporting value
  15. Forgetting Kaizen learning from repeated reporting failures

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.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.