System: MWMS
Document Type: Operating Standard
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, 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 Agentic Reporting Standard.

This standard establishes how AI-generated reports inside MWMS must be created, structured, validated, routed, and connected to business action.

MWMS does not need more summaries for the sake of summaries.

MWMS needs reports that help HeadOffice, Brains, AI Employees, Martyn, M, and future operators make better decisions, take better actions, reduce risk, and improve the system.

An Agentic Report is not a normal AI summary.

An Agentic Report is a decision-ready operating output produced by an AI Employee or workflow.

It must explain:

what happened
what was found
why it matters
which Brain is affected
what decision is needed
what action is recommended
what risk exists
what should happen next
what should be logged or learned

This standard ensures that AI-generated reports become useful operational intelligence instead of polished but passive documents.

Scope

This standard applies to all AI-generated reports, summaries, briefs, dashboards, recommendations, intelligence outputs, review notes, and decision-support documents created inside MWMS.

This includes reports created for:

HeadOffice Brain
Brain Room
Newsletter Intelligence
Course Absorption
Affiliate Brain
Research Brain
Experimentation Brain
Finance Brain
Content Brain
Ads Brain
Strategy Brain
Data Brain
Operations Brain
AI Business Systems Brain
Dev Console
M Developer Support
Supabase task and event workflows
future client-facing AIBS systems

This standard applies to both manual and automated reporting.

Manual reporting includes course absorption outputs, page reviews, offer verdicts, task summaries, daily task reviews, developer briefs, and strategy notes.

Automated reporting includes newsletter dashboard items, queue summaries, routed action cards, task completion reports, AI Employee reports, experiment reports, finance reports, and client workflow reports.

Core Definition

An Agentic Report is a structured AI-generated report that connects information to action.

It is different from a normal summary.

A normal summary says:

Here is what this content said.

An Agentic Report says:

Here is what was found, why it matters to MWMS, which Brain owns it, what action should be taken, what risks exist, where it should go next, and what the system should learn.

An Agentic Report must be usable by a human or system after it is generated.

If a report does not support a decision, action, routing event, validation step, task, dashboard item, or learning update, it should not be treated as an operational MWMS report.

Core Principle

The core principle of this standard is:

MWMS reports must be decision-ready, not merely descriptive.

This means a report must do more than explain.

It must help the system move forward.

A useful MWMS report should answer:

What is the source?
What is the main finding?
What does it mean?
Which Brain is affected?
What should happen next?
Who or what system owns the next step?
What risk or uncertainty exists?
Should it be accepted, revised, parked, rejected, or escalated?
What should MWMS learn from it?

Why Agentic Reporting Matters

MWMS will eventually generate many outputs.

Without a reporting standard, those outputs can become clutter.

Reports may become:

long but unclear
polished but passive
interesting but unactionable
difficult to route
hard to validate
disconnected from business outcomes
impossible to compare
useless for dashboards
risky for automation

Agentic Reporting prevents this.

It ensures that reports are:

structured
actionable
routed
validated
business-relevant
outcome-connected
dashboard-ready where needed
useful for future learning

MWMS must not mistake “a lot of writing” for intelligence.

Agentic Report Requirements

Every important MWMS Agentic Report should include the following core elements.

1. Report Title

The report title must clearly state the purpose of the report.

Weak title:

Newsletter Summary

Strong title:

Newsletter Intelligence Report For AI Tool Adoption Signals

Weak title:

Course Notes

Strong title:

Course Absorption Report For AI Agent Workflow Principles

Weak title:

Offer Review

Strong title:

Affiliate Offer Evaluation Report For Test Suitability

The title should make the output’s function obvious.

2. Source

The report must identify the source of the information.

Sources may include:

uploaded course file
newsletter
Brain Room message
affiliate offer page
Google Ads data
Supabase row
experiment result
finance data
research source
developer note
WordPress page list
dashboard item
client document
user instruction

The source must be clear enough that the report can be traced later.

The Source rule is:

A report without source clarity is weak intelligence.

3. Report Type

The report must identify the type of work performed.

Examples include:

course absorption report
newsletter intelligence report
offer evaluation report
research report
finance scenario report
experiment result report
dashboard summary
developer support report
Brain Room task report
validation report
client workflow report
system improvement report

The report type helps determine format, validation level, and destination.

4. Owning Brain

The report must identify which Brain owns the result.

Examples:

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

Supporting Brains may also be listed.

The Owning Brain rule is:

Every report needs a responsible Brain.

5. Executive Verdict

The report should include a short verdict near the top.

The verdict should state the conclusion clearly.

Examples:

Absorb
Ignore
Park
Green Light
Yellow Light
Red Light
Needs Human Review
Route To Research Brain
Send To Finance Brain
Add To Dashboard
Reject As Noise
Escalate To HeadOffice
Safe To Proceed
Do Not Proceed

The verdict helps MWMS avoid hiding the decision inside a long report.

The Executive Verdict rule is:

The decision should be visible before the detail.

6. Key Findings

The report should list the most important findings.

A finding should not be a vague observation.

It should be specific and useful.

Weak finding:

AI agents are important.

Strong finding:

AI workflow value comes from role separation, task decomposition, validation gates, and handoff control rather than one-shot prompting.

A finding should support a decision, action, or system update.

7. Business Meaning

Each major finding should explain why it matters to MWMS.

Business meaning may include:

improves a Brain workflow
strengthens AI Employee design
reduces manual workload
improves decision quality
protects budget
reduces compliance risk
improves M’s build clarity
strengthens HeadOffice visibility
creates future AIBS client value
improves reporting
improves validation
improves automation readiness

The Business Meaning rule is:

MWMS does not need information unless it knows why the information matters.

8. Recommended Action

The report must state what should happen next.

Recommended actions may include:

absorb into Blueprint
create MCR page
update existing MCR page
route to Brain
create task
send to queue
send to dashboard
request research
validate further
park for later
reject
escalate
prepare developer brief
add to AIBS future module
log as Kaizen improvement

The Recommended Action rule is:

A report without a next action is usually not operational.

9. Risk Notes

The report should identify risks, uncertainty, or limits.

Risk notes may include:

source is incomplete
data may be outdated
requires human review
compliance risk exists
financial assumptions are uncertain
developer implementation risk exists
possible duplication with existing page
current build timing is not suitable
input was messy or partial
source is vendor-biased
external verification required

Risk notes protect MWMS from over-trusting AI output.

10. Validation Status

The report should identify whether it has been validated.

Validation states may include:

Draft
Self Checked
Needs Validation
Validated
Failed Validation
Human Review Required
Source Verification Required
Parked Pending More Input

The Validation Status rule is:

Reports should not silently pretend to be final.

11. Handoff Destination

The report must identify where it goes next.

Possible destinations include:

MCR
HeadOffice Dashboard
Brain Room
Newsletter Queue Review
Routed Actions
Affiliate Brain
Research Brain
Experimentation Brain
Finance Brain
Content Brain
Ads Brain
AI Business Systems Brain
Supabase task record
Supabase event log
Google Sheet
Parking System
Archive
Human Review Queue

The Handoff rule is:

A report must know where it belongs.

12. Learning Capture

The report should identify whether MWMS should save a reusable lesson.

Learning may include:

new standard
new workflow
new failure mode
new validation rule
new AI Employee role
new dashboard improvement
new course absorption insight
new offer evaluation pattern
new AIBS packaging idea
new M developer rule
new Kaizen improvement

The Learning Capture rule is:

Good reports should improve future system behavior.

Standard Agentic Report Structure

The default structure for an Agentic Report is:

Report Title:
Source:
Report Type:
Owning Brain:
Supporting Brains:
Executive Verdict:
Key Findings:
Business Meaning:
Recommended Action:
Risk Notes:
Validation Status:
Handoff Destination:
Learning Capture:

This structure may be expanded depending on the report type.

It should not be reduced for high-impact reports.

Report Types

MWMS should use different report types for different workflows.

1. Course Absorption Report

Used when analyzing uploaded course content.

Required sections:

Clear Summary
Benefits To MWMS Brain
Integration Notes
Employee Creation Suggestions
Trends And Concerns
Absorb / Park / Ignore Verdict
Possible MCR Pages
What To Ignore

Purpose:

To decide whether course material should improve MWMS.

Rule:

Course reports must extract system value, not just summarize content.

2. Newsletter Intelligence Report

Used when analyzing newsletters.

Required sections:

Source Newsletter
Main Signal
Business Relevance
Primary Brain
Supporting Brains
Recommended Action
Confidence
Urgency
Priority
ACT NOW / TEST / MONITOR / PARK / REJECT
Routing Destination

Purpose:

To turn newsletters into operational intelligence.

Rule:

Newsletter reports must separate signal from noise.

3. Offer Evaluation Report

Used when evaluating affiliate, CPA, CPL, PPL, or product offers.

Required sections:

Offer Name
Network
Niche
Funnel Type
Vendor Quality
Market Demand
Compliance Risk
Traffic Fit
Finance Notes
Experimentation Fit
Green / Yellow / Red Verdict
Recommended Next Step

Purpose:

To protect MWMS from weak, risky, or unprofitable offers.

Rule:

Offer reports must be evidence-based and test-focused.

4. Research Report

Used when Research Brain evaluates a topic, market, competitor, product, tool, or source.

Required sections:

Research Question
Sources Reviewed
Key Evidence
Conflicting Evidence
Confidence Level
Business Meaning
Brain Impact
Recommended Action
Further Research Needed

Purpose:

To separate evidence from opinion.

Rule:

Research reports must distinguish facts, assumptions, and uncertainty.

5. Finance Scenario Report

Used when Finance Brain reviews budgets, break-even points, risk, cash flow, or forecast scenarios.

Required sections:

Scenario
Inputs
Assumptions
Break-Even Logic
Best Case
Base Case
Worst Case
Risk Notes
Decision Implication
Recommended Budget Action

Purpose:

To protect capital and support better business decisions.

Rule:

Finance reports must show assumptions clearly.

6. Experiment Result Report

Used when Experimentation Brain reviews test outcomes.

Required sections:

Test Name
Hypothesis
Variables
Results
Signal Quality
Confidence
Learning
Decision
Next Test
Stop / Iterate / Scale / Park Verdict

Purpose:

To prevent tests from becoming disconnected data.

Rule:

Experiment reports must capture learning, not just performance.

7. Developer Support Report

Used when supporting M or future developers.

Required sections:

Site/System
File/Screen
Issue
Visible Evidence
Current Save Point
Required Change
Exact Instruction
What Not To Touch
Test Steps
Risk Notes
Result Status

Purpose:

To give M precise, safe, usable instructions.

Rule:

Developer reports must be exact and anchored to visible evidence.

8. Validation Report

Used when checking another AI output.

Required sections:

Output Reviewed
Source
Validation Level
Checks Performed
Pass/Fail Result
Issues Found
Required Revision
Final Decision
Handoff Destination

Purpose:

To determine whether output is trusted.

Rule:

Validation reports must produce a decision state.

9. HeadOffice Dashboard Report

Used when preparing dashboard-ready intelligence.

Required sections:

Signal
Brain
Action Type
Priority
Urgency
Owner
Due Timing
Reason
Next Step
Status

Purpose:

To make dashboards useful for action.

Rule:

Dashboard reports must be short, specific, and action-ready.

10. AIBS Client Report

Used for future client-facing AI Business Systems workflows.

Required sections:

Client Process
Input Source
AI Workflow Used
Findings
Recommended Action
Risk Notes
Human Approval Need
Business Impact
Next Step

Purpose:

To make client AI workflows explainable, useful, and safe.

Rule:

Client reports must be clear enough for a non-technical business owner to act on.

Report Quality Levels

MWMS should judge reports by quality level.

Level 1 — Descriptive Report

Explains what happened.

Useful for low-risk internal understanding.

Weakness:

May not include action.

Level 2 — Analytical Report

Explains what happened and why it matters.

Useful for research, summaries, and internal review.

Weakness:

May still lack routing or decision.

Level 3 — Operational Report

Explains what happened, why it matters, what should happen next, and where it goes.

This is the minimum standard for serious MWMS reporting.

Level 4 — Decision Report

Provides evidence, options, risk, and a clear decision recommendation.

Used for high-value workflows such as offer evaluation, finance, experiments, and tool purchases.

Level 5 — Command Report

A high-priority HeadOffice report that includes action, owner, urgency, destination, and status.

Used for dashboards, routed actions, operational control, and high-priority system decisions.

Default Report Verdicts

MWMS reports should use clear verdicts.

Recommended verdicts include:

Accept
Revise
Reject
Park
Monitor
Test
Route
Escalate
Create Page
Update Page
Create Task
Send To M
Send To HeadOffice
Send To Research Brain
Send To Finance Brain
Send To Experimentation Brain
Add To Dashboard
Archive

Verdicts should be plain and visible.

Agentic Reporting Pipeline

A mature MWMS reporting workflow should follow this pipeline:

Source Captured
Input Normalized
Report Type Classified
Owning Brain Identified
Relevant AI Employee Assigned
Key Findings Extracted
Business Meaning Added
Recommended Action Defined
Risk Notes Added
Validation Status Assigned
Handoff Destination Selected
Learning Captured
Report Routed
Event Logged

This pipeline ensures reports do not become passive documents.

Application To HeadOffice

HeadOffice reports must focus on command intelligence.

They should help answer:

What needs attention?
What is urgent?
What can be tested?
What should be monitored?
What should be rejected?
What is blocked?
What is risky?
What should M know?
What should Martyn decide?
What should be logged?

HeadOffice does not need long generic reports.

HeadOffice needs controlled visibility and decision support.

HeadOffice reporting rule:

HeadOffice reports should turn system activity into management action.

Application To Brain Room

Brain Room reports should convert conversation into work.

A Brain Room report may include:

request summary
owning Brain
suggested AI Employee
required task
risk level
context needed
next step
status

Brain Room reporting rule:

Brain Room reporting should prevent useful discussion from being lost.

Application To Newsletter Intelligence

Newsletter reports must filter aggressively.

A newsletter report should not include every interesting item.

It should include only what matters to MWMS.

Newsletter report output should identify:

signal
pattern
Brain impact
action type
urgency
priority
confidence
next step

Newsletter reporting rule:

Newsletter reporting should create operational signal, not reading notes.

Application To Course Absorption

Course reports must be judged by system value.

Course report output should identify:

what is worth absorbing
what improves MWMS
what duplicates existing standards
what should become a page
what should be ignored
what AI Employees are affected
what future client value exists

Course reporting rule:

Course reports must feed the Blueprint, not create passive notes.

Application To M Developer Support

Reports for M must be practical and exact.

A developer report should avoid vague phrasing.

It must include:

exact site
exact file or screen
exact current issue
exact required action
exact place to edit if code is involved
what not to touch
test steps
expected result

Developer reporting rule:

If M cannot act on it safely, the report is not good enough.

Application To Future AIBS Systems

AIBS reports must be client-usable.

Future client-facing reports should be:

clear
practical
non-technical where possible
action-focused
risk-aware
approval-aware
tied to business outcomes

AIBS reporting rule:

Client AI reports should make business work easier, not create more confusion.

Reporting Failure Modes

MWMS must watch for reporting failure.

Common failure modes include:

Report is only a summary
No verdict is given
No owning Brain is identified
No next action is included
Risk is ignored
Output is too long to use
Output is too vague to act on
Report has no destination
Dashboard item is generic
Source is unclear
Assumptions are presented as facts
Report duplicates another page
Report does not support a decision
Report is not validated
Report creates work but no owner
Report hides the important point too far down
Report sounds impressive but changes nothing

Any report showing these failure modes should be revised, parked, or rejected.

Agentic Reporting Quality Checklist

Before accepting an MWMS report, check:

Is the report title clear?
Is the source identified?
Is the report type clear?
Is the owning Brain listed?
Is there a clear verdict?
Are the key findings specific?
Does it explain why the findings matter?
Is there a recommended action?
Are risks or limits included?
Is the validation status clear?
Is the handoff destination clear?
Is learning captured if needed?
Is the report too long for its purpose?
Is the report actionable?
Does it avoid unsupported claims?
Does it align with MWMS standards?
Does it protect M’s active build areas?
Does it avoid duplication?
Does it support a decision or workflow?
Can the next person or system use it?

Dashboard Reporting Rule

Dashboard reporting must be stricter than normal reporting.

Dashboards are command surfaces.

They should not show every AI-generated insight.

They should show only items that are:

specific
validated enough
current
business-relevant
correctly routed
priority-ranked
action-ready
not duplicated
not noise

Dashboard categories should remain simple.

Examples:

ACT NOW
TEST
MONITOR
PARK
REJECT
BLOCKED
NEEDS REVIEW

Dashboard reporting rule:

A dashboard is not a storage area. It is a control surface.

Report Length Rule

A report should be as long as needed but not longer than useful.

Different reports need different lengths.

Short reports are best for:

dashboards
task updates
quick validation
status cards
routed actions

Longer reports are acceptable for:

MCR page drafts
course absorption
architecture standards
offer evaluations
finance scenarios
research reports
developer briefs

Report length should match the decision being supported.

The length rule is:

Depth is useful only when it improves action, understanding, or safety.

Human Review Rule

Human review is required before an Agentic Report becomes final when it affects:

MCR canon
paid traffic
finance decisions
compliance-sensitive outputs
live systems
public content
developer implementation
client-facing reports
Brain architecture
cross-Brain governance
major business strategy

Human review may be optional for low-risk internal reports.

Reporting Automation Rule

Reporting should be automated only when the report structure is stable.

Before automating a report, confirm:

input source is predictable
report type is clear
output format is stable
validation rules exist
destination is known
risk level is acceptable
human review rules are defined
logging exists
report is genuinely useful

The automation rule is:

Do not automate reports that humans do not find useful manually.

Governance Role

HeadOffice owns the MWMS Agentic Reporting Standard.

HeadOffice is responsible for:

defining report quality expectations
maintaining decision-ready reporting standards
protecting dashboards from noise
ensuring reports have business outcomes
ensuring reports are routed correctly
requiring validation where needed
protecting MCR from passive or duplicative reports
protecting M’s active build areas from vague developer reports
ensuring client-facing AIBS reports are safe and useful

Individual Brains may create specialized report formats, but those formats must align with this standard.

Relationship To Other MWMS Standards

This document supports and must align with:

MWMS AI Agent Operations Core
MWMS Agentic Work Unit Standard
MWMS AI Employee Role Card Standard
MWMS AI Agent Orchestration Framework
MWMS AI Workflow Pipeline Standard
MWMS AI Output Validation Standard
MWMS Messy Input Normalization Framework
MWMS Brain Routing Rule
MWMS Brain To Brain Request Protocol
MWMS AI Output Standard Full File Delivery Rule
MWMS Brain Header Schema Standard
MWMS Page Naming Standard
MWMS Document Structure Standard
MWMS Architecture Registry
MWMS Brain Interaction Map
MWMS System Data Flow Map
MWMS Supabase Event Schema
HeadOffice Newsletter Intelligence Operating Protocol
HeadOffice Newsletter Intelligence Output Validation Protocol
MWMS Course Absorption Operating Rule
MWMS Opportunity System Operating Protocol
AI Business Systems Brain Blueprint

This standard defines how MWMS turns processed information into useful reports, decisions, dashboards, actions, and learning records.

Drift Protection

This standard protects MWMS from the following forms of drift:

Creating summaries instead of operational reports
Producing long outputs with no decision
Hiding verdicts inside excessive detail
Creating dashboard noise
Writing reports with no owner
Writing reports with no destination
Writing reports with no business meaning
Treating AI-generated reports as final without validation
Creating reports that duplicate existing standards
Sending vague reports to M
Creating client reports that are too technical or unclear
Capturing information without action
Mistaking volume of reports for progress
Failing to log useful learning
Allowing weak reporting to drive automation

Any report showing these drift signs should be revised, shortened, validated, parked, or rejected.

Architectural Intent

The architectural intent of the MWMS Agentic Reporting Standard is to make reports useful inside an AI business operating ecosystem.

MWMS will increasingly depend on reports from AI Employees, Brains, dashboards, workflows, and client systems.

The value of those reports is not in how impressive they sound.

The value is in whether they help MWMS act, decide, route, validate, learn, or improve.

The long-term goal is that every important MWMS report can answer:

What is this report?
Where did it come from?
Which Brain owns it?
What did it find?
Why does it matter?
What should happen next?
What is the risk?
Has it been validated?
Where does it go?
What should MWMS learn?

When MWMS reporting can answer those questions consistently, reporting becomes a management layer, not just documentation.

Change Log

v1.0 — Initial Draft

Created the MWMS Agentic Reporting Standard as the operating standard for AI-generated reports, summaries, briefs, dashboard items, decision reports, validation reports, developer reports, and future AIBS client reports.

This standard supports the MWMS AI Agent Operations Core, Agentic Work Unit Standard, AI Employee Role Card Standard, AI Agent Orchestration Framework, AI Workflow Pipeline Standard, AI Output Validation Standard, and Messy Input Normalization Framework by defining how reports must connect findings to business meaning, recommended action, validation status, handoff destination, and learning capture.