System: MWMS
Document Type: Operational Template
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, MWMS Brain, Brain Room, AI Manager, AI Employee Router, Task Executor Systems, Newsletter Intelligence, Course Absorption System, Opportunity System, AI Business Systems Brain
Parent Page: HeadOffice
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR

Purpose

The purpose of this document is to define the MWMS Agentic Reporting Template.

This template is used whenever MWMS needs an AI-generated report that does more than summarize information.

MWMS does not need passive reports.

MWMS needs reports that help the system:

make decisions
route work
reduce risk
create action
validate outputs
improve workflows
update Brains
support M
strengthen HeadOffice visibility
prepare future AIBS client systems

An Agentic Report must clearly explain:

what was reviewed
what was found
why it matters
which Brain owns it
what action should happen next
what risk exists
whether validation is required
where the report should go
what MWMS should learn

This template is the practical daily-use version of the MWMS Agentic Reporting Standard.

Scope

This template applies to reports created across MWMS, including:

course absorption reports
newsletter intelligence reports
offer evaluation reports
research reports
finance reports
experiment reports
validation reports
developer support reports
HeadOffice dashboard reports
Brain Room task reports
routed action reports
MCR page review reports
failure reports
outcome reports
future AIBS client reports

This template may be used manually first.

Later, parts of this template may become report fields, dashboard cards, routed action structures, validation outputs, Supabase records, Brain Room summaries, or future client reporting formats.

Core Definition

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

A normal summary says:

Here is what this said.

An Agentic Report says:

Here is what was found, why it matters to MWMS, which Brain owns it, what should happen next, what risk exists, where it should go, and what MWMS should learn.

An Agentic Report is not finished until it supports a decision, action, handoff, validation, routing event, dashboard item, or learning update.

Core Principle

The core principle of this template is:

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

A report should not exist just to explain.

It should help MWMS move forward.

If a report does not create or support a useful outcome, it should be revised, shortened, parked, or rejected.

Agentic Reporting Template

1. Report Title

Field:
Report Title:

Purpose:
Gives the report a clear name.

Good Examples:

Course Absorption Report For AI Agent Workflow Principles
Newsletter Intelligence Report For Paid Traffic Platform Signal
Offer Evaluation Report For Test Suitability
Developer Support Report For Brain Room Issue
Validation Report For MCR Page Output
HeadOffice Dashboard Report For Urgent Signals

Bad Examples:

Summary
Notes
Report
This One
AI Thoughts

Rule:
The title should make the report’s function obvious.

2. Source

Field:
Source:

Purpose:
Identifies where the information came from.

Examples:

uploaded course file
course transcript
newsletter
Brain Room message
affiliate offer page
Supabase row
WordPress page list
developer screenshot
M note
Google Ads report
finance data
experiment result
client document

Rule:
A report without a clear source is weak intelligence.

3. Source Reference

Field:
Source Reference:

Purpose:
Records the exact source if available.

Examples:

file name
lesson title
newsletter subject
page title
screenshot file
Supabase record ID
Brain Room thread
dashboard row
offer name
date received

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

4. Report Type

Field:
Report Type:

Recommended Values:

Course Absorption Report
Newsletter Intelligence Report
Offer Evaluation Report
Research Report
Finance Scenario Report
Experiment Result Report
Developer Support Report
Validation Report
HeadOffice Dashboard Report
Brain Room Task Report
Failure Report
Outcome Report
AIBS Client Report

Rule:
The report type determines what detail, validation, and handoff are required.

5. Owning Brain

Field:
Owning Brain:

Purpose:
Identifies the Brain responsible for the report.

Examples:

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

Rule:
Every serious report needs a responsible Brain.

6. Supporting Brains

Field:
Supporting Brains:

Purpose:
Lists other Brains affected by the report.

Examples:

For an offer evaluation:

Research Brain
Ads Brain
Finance Brain
Experimentation Brain
HeadOffice Brain

For course absorption:

HeadOffice Brain
AI Business Systems Brain
relevant specialist Brain

For newsletter intelligence:

Ads Brain
Content Brain
Affiliate Brain
Research Brain
Finance Brain

Rule:
Cross-Brain impact should be visible.

7. Executive Verdict

Field:
Executive Verdict:

Recommended Verdicts:

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

Purpose:
States the decision near the top of the report.

Rule:
The decision should be visible before the detail.

8. Short Summary

Field:
Short Summary:

Purpose:
Gives a clear plain-English summary of the report.

Should Include:

what was reviewed
what was found
why it matters
what should happen next

Rule:
Keep this short and useful. Do not turn it into the full report.

9. Key Findings

Field:
Key Findings:

Purpose:
Lists the most important findings.

Good Finding Example:

The source shows that AI workflows need role separation, validation gates, context control, and handoff structure before automation.

Weak Finding Example:

AI agents are important.

Rule:
Findings must be specific enough to support a decision or action.

10. Business Meaning

Field:
Business Meaning:

Purpose:
Explains why the findings matter to MWMS.

Business Meaning May Include:

improves a Brain workflow
strengthens AI Employee design
improves decision quality
reduces risk
saves time
supports future AIBS packaging
improves M’s build clarity
improves HeadOffice visibility
protects budget
improves testing discipline
improves dashboard quality
improves client delivery later

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

11. Recommended Action

Field:
Recommended Action:

Purpose:
Defines what should happen next.

Recommended Actions May Include:

create MCR page
update existing MCR page
route to Brain
create Agentic Work Unit
send to validation
add to dashboard
send to M
prepare developer brief
request research
send to Finance Brain
send to Experimentation Brain
park for later
reject
log learning
create AIBS packaging note

Rule:
A report without a next action is usually not operational.

12. Risk Notes

Field:
Risk Notes:

Purpose:
Identifies risk, uncertainty, or limits.

Risk Notes May Include:

source is incomplete
source file expired
current verification needed
possible duplicate page
compliance risk
finance risk
developer risk
tool permission risk
M’s active build may be affected
public content risk
client-facing risk
assumptions not confirmed
vendor claims not verified

Rule:
Risk must be visible before action.

13. Evidence Or Source Grounding

Field:
Evidence Or Source Grounding:

Purpose:
Explains what the report is based on.

Examples:

uploaded transcript
pasted page content
screenshot evidence
WordPress page list
source document
current user instruction
verified workflow state
known MWMS standard

Rule:
Do not present unsupported claims as facts.

14. Assumptions

Field:
Assumptions:

Purpose:
Lists any assumptions made during the report.

Examples:

assuming uploaded file is the latest version
assuming page title matches MCR naming rules
assuming newsletter body is complete
assuming screenshot reflects current state
assuming offer source is accurate
assuming M’s active build is not affected

Rule:
Assumptions must be marked clearly.

15. Validation Status

Field:
Validation Status:

Recommended Values:

Draft
Self Checked
Needs Validation
Validated
Failed Validation
Human Review Required
Source Verification Required
Developer Review Required
Compliance Review Required
Finance Review Required

Rule:
Reports should not silently pretend to be final.

16. Validation Level

Field:
Validation Level:

Recommended Values:

Level 1 — Light Validation
Level 2 — Structured Validation
Level 3 — Operational Validation
Level 4 — High Risk Validation
Level 5 — Critical Validation

Rule:
The higher the risk, the stronger the validation.

17. Handoff Destination

Field:
Handoff Destination:

Possible Destinations:

MCR
HeadOffice review
Brain Room
AI Manager
Newsletter Queue Review
Routed Actions
HeadOffice Dashboard
Research Brain
Finance Brain
Experimentation Brain
Ads Brain
Content Brain
M developer handoff
Parking System
Archive
Human Review Queue
AIBS Client Review

Rule:
A report must know where it belongs.

18. Owner Of Next Action

Field:
Owner Of Next Action:

Examples:

Martyn
M
HeadOffice
Affiliate Brain
Research Brain
Finance Brain
Experimentation Brain
Content Brain
Ads Brain
AI Manager
Human Review Queue
Future Client Operator

Rule:
A report should not create orphaned action.

19. Priority

Field:
Priority:

Recommended Values:

Critical
High
Medium
Low
Parking Lot

Rule:
Priority should be based on business value and risk, not excitement.

20. Urgency

Field:
Urgency:

Recommended Values:

Immediate
Today
This Week
Next Session
Before Build
Before Launch
Monitor
No Urgency
Parked

Rule:
Urgency should be believable and justified.

21. Status

Field:
Status:

Recommended Values:

Draft
Ready For Review
Needs Validation
Validated
Routed
Action Created
Waiting For Input
Parked
Rejected
Escalated
Completed
Logged
Archived

Rule:
Status makes reporting trackable.

22. Learning Capture

Field:
Learning Capture:

Purpose:
Identifies whether MWMS should preserve reusable learning.

Learning May Include:

new framework
new workflow rule
new AI Employee role
new validation rule
new failure mode
new dashboard improvement
new offer rejection pattern
new newsletter signal pattern
new developer instruction rule
new AIBS packaging idea

Rule:
Good reports should improve future system behavior.

23. Logging Requirement

Field:
Logging Requirement: Yes / No

Logging Required For:

MCR page creation
developer handoffs
high-risk reports
validation failures
offer evaluations
finance decisions
cross-Brain reports
HeadOffice dashboard reports
important newsletter intelligence
client-facing workflow reports

Rule:
Important reports should leave a trace.

Quick Use Version

Use this shorter report form when working fast.

Report Title:
Source:
Source Reference:
Report Type:
Owning Brain:
Supporting Brains:
Executive Verdict:
Short Summary:
Key Findings:
Business Meaning:
Recommended Action:
Risk Notes:
Evidence Or Source Grounding:
Assumptions:
Validation Status:
Validation Level:
Handoff Destination:
Owner Of Next Action:
Priority:
Urgency:
Status:
Learning Capture:
Logging Requirement:

Report Type Templates

1. Course Absorption Report Template

Use when analyzing course material.

Required Sections:

Report Title
Source
Course / Module / Lesson
Executive Verdict
Clear Summary
MWMS System Value
Benefits To MWMS Brain
Integration Notes
Employee Creation Suggestions
Trends And Concerns
What To Ignore
Possible MCR Pages
Duplication Risk
Recommended Action
Validation Status
Handoff Destination
Learning Capture

Verdict Options:

Absorb
Absorb And Create Page
Update Existing Page
Park
Ignore
Reject

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

2. Newsletter Intelligence Report Template

Use when analyzing newsletters.

Required Sections:

Report Title
Newsletter Source
Subject / Date
Main Signal
Underlying Pattern
Business Relevance
Primary Brain
Supporting Brains
Recommended Action
Confidence
Urgency
Priority
ACT NOW / TEST / MONITOR / PARK / REJECT
Risk Notes
Routing Destination
Learning Capture

Rule:
Newsletter reports must separate business signal from noise.

3. Offer Evaluation Report Template

Use when evaluating affiliate, CPA, CPL, PPL, or digital product offers.

Required Sections:

Report Title
Offer Name
Network
Niche
Funnel Type
Vendor Quality
Market Demand
Claims And Proof
Compliance Risk
Traffic Fit
Finance Notes
Experimentation Fit
Green / Yellow / Red Verdict
Recommended Next Step
Risk Notes
Handoff Destination

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

4. Research Report Template

Use when Research Brain evaluates a topic, market, competitor, product, source, or claim.

Required Sections:

Report Title
Research Question
Sources Reviewed
Key Evidence
Conflicting Evidence
Confidence Level
Assumptions
Business Meaning
Brain Impact
Recommended Action
Further Research Needed
Handoff Destination

Rule:
Research reports must distinguish facts, assumptions, and uncertainty.

5. Finance Scenario Report Template

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

Required Sections:

Report Title
Scenario
Inputs
Assumptions
Break Even Logic
Best Case
Base Case
Worst Case
Risk Notes
Decision Implication
Recommended Budget Action
Human Review Requirement

Rule:
Finance reports must show assumptions clearly.

6. Experiment Result Report Template

Use when Experimentation Brain reviews test results.

Required Sections:

Report Title
Test Name
Hypothesis
Variables
Results
Signal Quality
Confidence
Learning
Decision
Next Test
Stop / Iterate / Scale / Park Verdict
Outcome Log Requirement

Rule:
Experiment reports must capture learning, not just performance.

7. Developer Support Report Template

Use when preparing work for M or future developers.

Required Sections:

Report Title
Site / System
File / Screen
Issue
Visible Evidence
Current Save Point
Required Change
Exact Instruction
What Not To Touch
Test Steps
Expected Result
Risk Notes
Handoff Destination
Human Review Requirement

Rule:
If M cannot act safely without guessing, the report is not good enough.

8. Validation Report Template

Use when checking another AI output.

Required Sections:

Report Title
Output Reviewed
Source
Output Type
Owning Brain
Validation Level
Checks Performed
Pass / Fail Result
Issues Found
Required Revision
Final Decision
Handoff Destination
Learning Capture

Rule:
Validation reports must produce a decision state.

9. HeadOffice Dashboard Report Template

Use when preparing dashboard-ready intelligence.

Required Sections:

Report Title
Signal
Owning Brain
Action Type
Priority
Urgency
Owner
Status
Reason
Next Step
Source
Risk Notes

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

10. AIBS Client Report Template

Use for future client-facing AI Business Systems workflows.

Required Sections:

Report Title
Client Process
Input Source
AI Workflow Used
Findings
Business Meaning
Recommended Action
Risk Notes
Human Approval Required
Business Impact
Next Step
Owner
Status

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

Agentic Report Quality Checklist

Before accepting a report, check:

Is the report title clear?
Is the source identified?
Is the source reference included where needed?
Is the report type clear?
Is the owning Brain listed?
Are supporting Brains included where needed?
Is the executive verdict visible?
Is the summary useful?
Are key findings specific?
Is business meaning included?
Is the recommended action clear?
Are risk notes included?
Is source grounding visible?
Are assumptions marked?
Is validation status clear?
Is validation level appropriate?
Is handoff destination clear?
Is the owner of next action clear?
Is priority believable?
Is urgency believable?
Is status clear?
Is learning capture considered?
Is logging required?
Is the report too long for its purpose?
Can the next person or system use it?

If several answers are unclear, the report is not ready.

Report Decision States

After review, assign one report decision state.

Accept

Report is useful and ready for next step.

Accept With Minor Edits

Report is mostly useful but needs small fixes.

Revise

Report has value but is incomplete, vague, or misformatted.

Park

Report may be useful later but should not move now.

Reject

Report is weak, unsupported, duplicated, or not useful.

Escalate

Report needs Martyn, HeadOffice, M, finance, compliance, or specialist review.

Route

Report should be sent to another Brain, queue, dashboard, or human.

Create Action

Report should become an Agentic Work Unit, task, developer brief, page update, or routed action.

Common Reporting Failure Modes

A report has failed if:

It only summarizes and does not support action.
It has no clear verdict.
It has no owning Brain.
It has no recommended action.
It ignores risk.
It has no handoff destination.
It has no business meaning.
It is too generic.
It hides the important point too far down.
It treats assumptions as facts.
It creates dashboard noise.
It sends vague instructions to M.
It creates no outcome.
It duplicates existing pages.
It does not say what MWMS should learn.

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

Manual Use Rule

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

Manual use helps MWMS learn:

which report sections matter most
which reports are too long
which report types repeat
which report formats are dashboard-ready
which reports need stronger validation
which reports should become tasks
which reports should be parked
which report fields may later become Supabase or WordPress fields

Manual proof comes before automation.

Future Plugin Or UI Relevance

This template may later become:

report generation screen
Brain Room report format
HeadOffice dashboard report card
Newsletter Intelligence report structure
Course Absorption report record
Offer Evaluation report record
Developer Support report screen
Validation report record
AIBS client report template
Supabase report table

Possible future fields:

report_id
report_title
source
source_reference
report_type
owning_brain
supporting_brains
executive_verdict
short_summary
key_findings
business_meaning
recommended_action
risk_notes
evidence_grounding
assumptions
validation_status
validation_level
handoff_destination
owner_next_action
priority
urgency
status
learning_capture
logging_required
created_at
updated_at

No technical build is authorized by this template alone.

Governance Role

HeadOffice owns the MWMS Agentic Reporting Template.

HeadOffice is responsible for:

deciding when reports require this template
ensuring reports are decision-ready
preventing passive summaries from becoming operational reports
ensuring Brain ownership is clear
ensuring risk is visible
ensuring reports have handoff destinations
protecting dashboards from noise
protecting M from vague developer reports
protecting future AIBS clients from confusing reports
deciding when this template is ready for operational copy or plugin/UI transformation

Individual Brains may use specialized report formats, but they must not remove core report controls for high-risk work.

Relationship To Other MWMS Standards

This template supports and must align with:

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

This template is the practical application of the MWMS Agentic Reporting Standard.

Drift Protection

This template protects MWMS from the following forms of drift:

Creating summaries instead of operational reports
Producing long reports with no decision
Hiding verdicts inside detail
Creating dashboard noise
Writing reports with no owner
Writing reports with no destination
Writing reports with no business meaning
Treating AI 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 report volume for progress
Failing to log useful learning
Allowing weak reporting to drive automation

Any important report that does not follow this template should be treated as draft only.

Architectural Intent

The architectural intent of the MWMS Agentic Reporting Template is to make reports useful inside the MWMS AI workforce system.

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

The value of those reports is not how polished they sound.

The value is whether they help MWMS:

decide
act
route
validate
learn
reduce risk
improve workflow
support M
prove client value later

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 answers those questions consistently, reports become a management layer, not just documentation.

Change Log

v1.0 — Initial Draft

Created the MWMS Agentic Reporting Template as the practical operational template for producing decision-ready reports across MWMS.

This template operationalizes the MWMS Agentic Reporting Standard and supports Course Absorption, Newsletter Intelligence, Offer Evaluation, Research, Finance, Experimentation, Developer Support, Validation, HeadOffice Dashboard reporting, Brain Room task reporting, and future AIBS client reporting.