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

Purpose

The purpose of this document is to define the MWMS AI Output Validation Checklist.

This checklist is used to decide whether an AI-generated output is good enough to accept, save, route, display, act on, send to M, use in a dashboard, convert into a task, or integrate into MWMS.

MWMS must not accept AI output just because it sounds confident, polished, long, or intelligent.

An AI output must be checked against the work it was supposed to perform.

This checklist turns validation into a repeatable process.

It is the practical daily-use version of the MWMS AI Output Validation Standard.

Scope

This checklist applies to all important AI-generated outputs across MWMS.

This includes:

MCR page outputs
course absorption reports
newsletter intelligence outputs
Brain Room responses
Agentic Work Units
AI Employee Role Cards
developer handoff briefs
offer evaluation reports
research reports
finance reports
experimentation reports
dashboard items
routed actions
validation reports
client-facing AIBS drafts
future automated AI Employee outputs

This checklist may be used manually first.

Later, parts of this checklist may become validation fields, review queues, approval screens, dashboard filters, or Supabase task validation records.

Core Definition

AI Output Validation is the process of checking whether an AI-generated output is fit for its intended use.

An output may be:

accepted
accepted with minor edits
revised
parked
rejected
escalated

The goal is not perfection.

The goal is to decide whether the output is safe, useful, specific, properly routed, and ready for its next stage.

Quick Validation Verdicts

Use one of these verdicts after review.

Accept

The output is good enough for its intended use.

Accept With Minor Edits

The output is mostly correct but needs small fixes.

Revise

The output has value but is not ready.

Park

The output may be useful later but should not move now.

Reject

The output should not be used.

Escalate

The output requires Martyn, HeadOffice, M, specialist review, or human approval.

Validation Checklist

1. Task Alignment Check

Question:
Did the output answer the actual task?

Check:

Did it follow the user instruction?
Did it follow the Work Unit?
Did it stay inside the requested scope?
Did it avoid wandering into unrelated areas?
Did it complete the requested output?

Pass Condition:
The output clearly answers the actual task.

Fail Condition:
The output sounds useful but does not complete the job.

Decision If Failed:
Revise.

2. Completeness Check

Question:
Is anything important missing?

Check:

Are required sections included?
Are required fields included?
Are required examples included?
Are required next steps included?
Are required warnings included?
Are required governance sections included?

Pass Condition:
The output includes all required parts.

Fail Condition:
The output is polished but incomplete.

Decision If Failed:
Revise before use.

3. Source Grounding Check

Question:
Is the output grounded in the available source?

Check:

Is it based on uploaded material, provided text, screenshots, confirmed pages, or current instruction?
Did it invent facts?
Did it claim to read something it did not read?
Did it treat assumptions as facts?
Did it exaggerate what the source said?
Did it reference unconfirmed pages, files, or fields?

Pass Condition:
The output can be traced to source material, known MWMS standards, or clearly marked assumptions.

Fail Condition:
The output sounds confident but cannot be traced.

Decision If Failed:
Revise, verify, or reject.

4. Specificity Check

Question:
Is the output specific enough to use?

Check:

Does it name the Brain involved?
Does it define the workflow?
Does it give a clear action?
Does it give a clear verdict?
Does it avoid generic filler?
Does it explain what should happen next?

Pass Condition:
The output is practical and usable.

Fail Condition:
The output sounds smart but does not move MWMS forward.

Decision If Failed:
Revise or reject if no practical value exists.

5. Format Check

Question:
Does the output follow the required format?

Check:

Is it a full page output when required?
Is it a checklist when requested?
Is it a template when requested?
Is it a developer brief when needed?
Is it a report when needed?
Does it follow MWMS document structure?
Does it include proper headings?
Does it include Change Log where needed?

Pass Condition:
The output is formatted for its intended destination.

Fail Condition:
The content may be useful but is not ready to save, route, or use.

Decision If Failed:
Revise format.

6. Brain Routing Check

Question:
Is the output assigned to the correct Brain?

Check:

Which Brain owns the work?
Are supporting Brains identified?
Does HeadOffice need visibility?
Is this MCR source-of-truth work?
Is this operational Brain work?
Is this plugin/UI work later?
Is this AIBS packaging later?

Pass Condition:
Brain ownership is clear.

Fail Condition:
Good output, wrong Brain or destination.

Decision If Failed:
Revise routing.

7. Business Outcome Check

Question:
Does the output support a real MWMS outcome?

Check:

Does it support a decision?
Does it create a task?
Does it improve a system?
Does it reduce risk?
Does it save time?
Does it improve M’s clarity?
Does it improve future AIBS delivery?
Does it create reusable learning?

Pass Condition:
The output has business value.

Fail Condition:
The output is only notes, summary, or activity.

Decision If Failed:
Park, reject, or revise for outcome.

8. Handoff Check

Question:
Does the output have a clear next destination?

Check:

Does it go to MCR?
Does it go to HeadOffice review?
Does it go to Brain Room?
Does it go to M?
Does it go to a queue?
Does it go to a dashboard?
Does it go to a Brain?
Does it go to Parking System?
Does it require human review?

Pass Condition:
The output has a clear next step.

Fail Condition:
The output floats in space.

Decision If Failed:
Revise with handoff destination.

9. Risk Level Check

Question:
What damage could happen if this output is wrong?

Risk Levels:

Low
Medium
High
Critical

High-Risk Areas:

MCR canon
developer implementation
live WordPress systems
Supabase writes
paid traffic decisions
finance decisions
compliance-sensitive content
public content
client-facing outputs
M’s active build

Pass Condition:
Risk level is identified and matched to validation strength.

Fail Condition:
High-risk output is treated like low-risk output.

Decision If Failed:
Escalate or revalidate.

10. Human Review Check

Question:
Does this output require human review?

Human Review Required For:

MCR canon updates
new standards
developer handoffs
live system changes
database writes
paid traffic decisions
financial decisions
compliance-sensitive outputs
public content
client-facing AIBS outputs
high-risk automation
uncertain source grounding

Pass Condition:
Human review requirement is clear.

Fail Condition:
The output acts final when it should be reviewed.

Decision If Failed:
Escalate.

11. Duplication Check

Question:
Does this output duplicate existing MWMS structure?

Check:

Does a similar page already exist?
Should this update an existing page instead?
Does this create unnecessary new structure?
Is this already covered by another standard?
Is this a template, framework, protocol, or checklist that overlaps?

Pass Condition:
The output adds clear new value or updates the right existing structure.

Fail Condition:
A new page is created when an existing page should be updated.

Decision If Failed:
Merge, revise, park, or reject.

12. Naming And Structure Check

Question:
Does the output follow MWMS naming and structure rules?

Check:

Title Case
no unnecessary dashes in actual page title
correct Brain prefix if required
correct document type
correct parent page
correct source-of-truth status
correct future destination
correct relationship to other pages
proper Change Log

Pass Condition:
The output fits MWMS structure cleanly.

Fail Condition:
Good content creates WordPress or MCR mess.

Decision If Failed:
Revise before saving.

13. Developer Boundary Check

Question:
Does this affect M’s active work?

Check:

Does it touch Brain Room systems?
Does it touch executor hooks?
Does it touch Opportunity System?
Does it touch Affiliate workflow wiring?
Does it touch Research Brain wiring?
Does it touch Finance Brain wiring?
Does it touch HeadOffice reporting build?
Does it touch plugin files?
Does it create work for M?

Pass Condition:
M’s active build is protected.

Fail Condition:
The output creates build risk or distraction.

Decision If Failed:
Park, revise, or escalate.

14. Developer Instruction Check

Use this only if the output is for M or future development.

Question:
Can M act safely without guessing?

Check:

exact site
exact plugin/module
exact file path where applicable
exact current issue
exact required change
full file output where required
exact insertion/replacement location
what not to touch
testing steps
expected result
save point awareness

Pass Condition:
M can act safely without guessing.

Fail Condition:
The instruction is vague, risky, or incomplete.

Decision If Failed:
Revise before sending to M.

15. Tool Permission Check

Question:
Did the output assume tool access or action permission incorrectly?

Check:

Did it claim a database was checked when it was not?
Did it claim a page was updated when it was only drafted?
Did it assume live system state?
Did it assume current web data without verification?
Did it imply AI can write, send, or publish without approval?
Did it cross tool permission boundaries?

Pass Condition:
Tool use and tool limits are clear.

Fail Condition:
The output overclaims access or action.

Decision If Failed:
Correct and revise.

16. Compliance And Policy Check

Question:
Could the output create legal, advertising, privacy, financial, platform, or client risk?

Check:

unsupported claims
misleading income claims
health/finance claims
advertising platform risk
privacy risk
client data risk
public-facing risk
jurisdiction-sensitive issue
affiliate compliance issue

Pass Condition:
Risks are flagged and handled.

Fail Condition:
Output may be useful but unsafe.

Decision If Failed:
Escalate or revise.

17. Dashboard Readiness Check

Use this only if the output may appear on a dashboard.

Question:
Is this dashboard-ready?

Check:

specific
current
business-relevant
correct Brain
clear action type
believable priority
believable urgency
owner or next action clear
not duplicated
not noise

Pass Condition:
The item helps command decisions.

Fail Condition:
The item clutters the dashboard.

Decision If Failed:
Park, revise, or reject.

18. Reporting Quality Check

Use this if the output is a report.

Question:
Is the report decision-ready?

Check:

source identified
report type clear
owning Brain clear
verdict visible
key findings specific
business meaning included
recommended action included
risk notes included
validation status included
handoff destination included
learning capture included if needed

Pass Condition:
The report supports action or decision.

Fail Condition:
The report is only a summary.

Decision If Failed:
Revise.

19. Course Absorption Check

Use this if the output comes from course material.

Question:
Does this improve MWMS enough to absorb?

Check:

improves Brain/Blueprint
improves AI Employee design
improves workflow
improves governance
improves validation
improves reporting
improves automation readiness
improves future AIBS delivery
avoids duplication
ignores weak/tool-hype material

Pass Condition:
The output adds clear MWMS system value.

Fail Condition:
It is only a general course summary.

Decision If Failed:
Park or reject.

20. Learning Capture Check

Question:
Should MWMS learn from this output?

Check:

new framework
new protocol
new checklist
new failure mode
new AI Employee role
new workflow rule
new validation rule
new handoff rule
new dashboard improvement
new AIBS packaging idea
new developer instruction rule

Pass Condition:
Useful learning is captured or routed.

Fail Condition:
Good insight is lost after the output.

Decision If Failed:
Add learning record or update related page.

Quick Validation Form

Use this fast form when reviewing an output.

Output Title:
Source:
Output Type:
Owning Brain:
Supporting Brains:
Intended Destination:
Risk Level:
Human Review Required:
Validation Level:

Task Alignment: Pass / Revise / Fail
Completeness: Pass / Revise / Fail
Source Grounding: Pass / Revise / Fail
Specificity: Pass / Revise / Fail
Format: Pass / Revise / Fail
Brain Routing: Pass / Revise / Fail
Business Outcome: Pass / Revise / Fail
Handoff: Pass / Revise / Fail
Duplication: Pass / Revise / Fail
Naming And Structure: Pass / Revise / Fail
Developer Boundary: Pass / Revise / Fail
Tool Permission: Pass / Revise / Fail
Compliance: Pass / Revise / Fail
Learning Capture: Pass / Revise / Fail

Final Verdict: Accept / Accept With Minor Edits / Revise / Park / Reject / Escalate
Required Next Action:
Reviewer:
Date:

Validation Levels

Level 1 — Light Validation

Use for:

quick internal support
rough ideas
simple explanations
low-risk notes

Checks:

makes sense
answers question
no obvious issue

Human review:

optional

Level 2 — Structured Validation

Use for:

internal summaries
course absorption reports
Brain Room responses
simple research notes
draft templates

Checks:

completeness
specificity
correct format
correct Brain mapping
no obvious invented facts

Human review:

recommended before saving or routing

Level 3 — Operational Validation

Use for:

MCR page drafts
Agentic Work Units
AI Employee Role Cards
dashboard candidates
routed action drafts
newsletter intelligence outputs
validation reports

Checks:

source grounding
Brain ownership
output format
risk
handoff destination
business outcome
duplication
standard alignment

Human review:

required before operational use

Level 4 — High Risk Validation

Use for:

developer handoffs
offer verdicts
finance analysis
compliance review
paid traffic recommendations
public content
client-facing drafts

Checks:

all Level 3 checks
source verification where needed
risk review
compliance review
developer boundary check
final human approval

Human review:

mandatory

Level 5 — Critical Validation

Use for:

live system changes
database writes
external email send
public publishing
ad launch
financial transaction
client final delivery
irreversible delete

Checks:

all Level 4 checks
explicit approval
named owner
logging
rollback or correction awareness where possible

Human review:

mandatory before execution

Validation Decision Guide

Accept

Use when:

output meets task
source is grounded
format is correct
risk is handled
handoff is clear
outcome is useful

Accept With Minor Edits

Use when:

small wording or formatting changes are needed
no major risk exists
destination is clear

Revise

Use when:

output is useful but incomplete
format is wrong
Brain routing needs correction
handoff is unclear
specificity is weak

Park

Use when:

idea is useful but not current priority
system is not ready
M’s build would be disrupted
more evidence is needed
future AIBS relevance exists but not now

Reject

Use when:

output is weak
unsupported
duplicated
unsafe
outside MWMS scope
no business value exists

Escalate

Use when:

high-risk
compliance-sensitive
developer-sensitive
financial
live-system related
ownership unclear
human decision required

Example 1: MCR Page Output Validation

Output Type:
Full page output

Required Checks:

title follows naming rules
parent page is correct
document type is correct
status is clear
MCR source of truth included
Purpose included
Scope included
Governance Role included
Relationship To Other Standards included
Drift Protection included
Architectural Intent included
Change Log included
no duplicate page risk
no unsupported claims
future operational destination clear

Likely Validation Level:
Level 3

Human Review:
Required before saving.

Example 2: Developer Brief Validation

Output Type:
Developer handoff for M

Required Checks:

exact site stated
exact system/module stated
exact file path included where available
exact issue stated
exact replacement/insertion instruction
full file output where required
what not to touch included
test steps included
expected result included
save point preserved
no guessed file path
no vague instruction

Likely Validation Level:
Level 4

Human Review:
Required.

Example 3: Newsletter Output Validation

Output Type:
Newsletter intelligence output

Required Checks:

signal is business-relevant
not generic news
primary Brain correct
supporting Brains sensible
action type correct
priority believable
urgency believable
source clear
recommended action included
dashboard-ready only if specific
no downstream task without review

Likely Validation Level:
Level 3

Human Review:
Required before downstream action.

Example 4: Course Absorption Output Validation

Output Type:
Course absorption report or page output

Required Checks:

extracts system value
does not merely summarize
identifies MWMS benefit
maps to Brain/Blueprint
avoids weak content
avoids duplicates
identifies what to ignore
includes employee creation suggestions where useful
respects M’s active build boundary
includes clear absorb/park/ignore verdict

Likely Validation Level:
Level 3

Human Review:
Required before MCR save.

Example 5: Offer Evaluation Output Validation

Output Type:
Affiliate offer evaluation report

Required Checks:

evidence-based verdict
vendor claims separated from facts
market demand considered
funnel quality considered
traffic fit considered
compliance risk considered
finance logic considered
experimentation fit considered
Green/Yellow/Red verdict justified
no ad spend approval without human review

Likely Validation Level:
Level 4

Human Review:
Required.

Validation Failure Handling

If validation fails, use one of these actions.

Incomplete Output

Action:

send back for revision
identify missing sections

Generic Output

Action:

request specificity
require business meaning
require next action

Unsupported Output

Action:

require source grounding
verify source
mark assumptions

Wrong Brain Routing

Action:

correct owning Brain
update handoff

Duplicate Output

Action:

merge with existing page
update existing standard
reject new page

High-Risk Output

Action:

pause workflow
escalate to human review
require stronger validation

Developer Ambiguity

Action:

request file/screenshot/current state
do not send to M until exact

No Business Outcome

Action:

revise with outcome
park or reject if no outcome exists

Manual Use Rule

This checklist should be used manually before it becomes a plugin feature or automated validation system.

Manual validation helps MWMS learn:

which checks are most useful
which checks are too heavy
which outputs fail often
which AI Employees need stronger role cards
which workflows need better prompts
which outputs are ready for dashboards
which outputs need human review
which validation fields may later become Supabase or WordPress fields

Manual proof comes before automation.

Future Plugin Or UI Relevance

This checklist may later become:

validation review screen
output approval checklist
HeadOffice validation queue
MCR page approval workflow
newsletter intelligence review fields
developer brief safety check
offer evaluation approval gate
AI Employee output scoring system
AIBS client report approval checklist

Possible future fields:

validation_id
related_output_id
output_type
owning_brain
validation_level
task_alignment_status
completeness_status
source_grounding_status
specificity_status
format_status
brain_routing_status
risk_status
human_review_required
duplication_status
developer_boundary_status
compliance_status
final_verdict
required_next_action
reviewer
reviewed_at

No technical build is authorized by this checklist alone.

Governance Role

HeadOffice owns the MWMS AI Output Validation Checklist.

HeadOffice is responsible for:

deciding which outputs require validation
setting validation level
protecting MCR from weak outputs
protecting dashboards from noise
protecting M from vague developer instructions
protecting MWMS from unsupported AI claims
protecting future AIBS clients from unsafe outputs
ensuring validation failures create learning where useful

Individual Brains may use specialized validation checks, but they must not remove the core validation requirements for high-risk work.

Relationship To Other MWMS Standards

This checklist supports and must align with:

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

This checklist is the practical application of the MWMS AI Output Validation Standard.

Drift Protection

This checklist protects MWMS from the following forms of drift:

Trusting AI output because it sounds good
Saving weak pages into MCR
Creating duplicate standards
Routing outputs to the wrong Brain
Producing reports with no action
Sending vague instructions to M
Filling dashboards with noise
Acting on unsupported claims
Ignoring compliance risk
Treating drafts as final
Automating before validation is proven
Accepting course summaries instead of system extraction
Allowing tool permission overreach
Skipping human review on high-risk work
Measuring output volume instead of quality

Any important AI output that has not passed this checklist should be treated as draft only.

Architectural Intent

The architectural intent of the MWMS AI Output Validation Checklist is to make AI output trustworthy enough to use.

MWMS will produce more AI-generated material over time.

The system needs a practical way to decide what is useful, what is risky, what should be revised, what should be rejected, and what should be escalated.

This checklist gives HeadOffice and each Brain a repeatable validation method.

The long-term goal is that every important AI output can answer:

Did it answer the task?
Is it complete?
Is it grounded?
Is it specific?
Is it formatted correctly?
Is it routed correctly?
Does it support a business outcome?
Is risk handled?
Is human review required?
Where does it go next?
Should MWMS learn from it?

When MWMS validates AI output consistently, the system becomes safer, cleaner, and more reliable.

Change Log

v1.0 — Initial Draft

Created the MWMS AI Output Validation Checklist as the practical operational checklist for reviewing AI-generated outputs before they are accepted, routed, saved, displayed, automated, sent to M, or acted upon.

This checklist operationalizes the MWMS AI Output Validation Standard and supports MCR page validation, course absorption validation, newsletter intelligence validation, developer brief validation, offer evaluation validation, dashboard validation, Brain Room validation, and future AIBS client output validation.