MWMS MCR

MWMS AI Output Validation Standard

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

This standard establishes how MWMS checks AI-generated outputs before they are accepted, routed, saved, displayed, acted upon, or treated as operational truth.

MWMS is building a governed AI business ecosystem.

That means AI output cannot be trusted simply because it is well-written, confident, detailed, or fast.

AI output must be checked.

Validation is the process that determines whether an AI output is:

  • complete
  • accurate enough
  • source-grounded
  • useful
  • correctly routed
  • correctly formatted
  • safe
  • non-duplicative
  • aligned with MWMS standards
  • connected to a business outcome

This standard exists to prevent MWMS from mistaking AI activity for reliable business progress.

Scope

This standard applies to all important AI outputs created inside MWMS.

This includes outputs from:

  • HeadOffice Brain
  • Brain Room
  • AI Manager
  • AI Employee Router
  • Task Executor systems
  • Dev Console
  • Newsletter Intelligence
  • Course Absorption
  • Offer Evaluation
  • Affiliate Brain
  • Research Brain
  • Experimentation Brain
  • Finance Brain
  • Content Brain
  • Ads Brain
  • Strategy Brain
  • Data Brain
  • Operations Brain
  • AI Business Systems Brain
  • future client-facing AI workflows

This standard applies to both manual and automated AI outputs.

Manual outputs include MCR page drafts, course absorption reports, strategy notes, research summaries, developer briefs, offer evaluations, and HeadOffice recommendations.

Automated outputs include Supabase task results, newsletter intelligence rows, dashboard items, routed actions, queue records, AI Employee results, and future client workflow outputs.

Core Definition

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

An output is valid only when it meets the standard required for its risk level, destination, and business purpose.

A low-risk draft may only need a simple sense check.

A high-risk output may require source checking, human review, compliance review, format validation, Brain routing review, and logging before it can be used.

Validation does not mean the output is perfect.

Validation means the output is good enough, safe enough, and structured enough for its next stage.

Core Principle

The core principle of this standard is:

No important AI output becomes operational truth until it passes validation.

This protects MWMS from:

  • hallucinated information
  • invented structure
  • wrong Brain routing
  • vague recommendations
  • weak course absorption
  • misleading reports
  • unsafe developer instructions
  • poor offer decisions
  • dashboard noise
  • compliance risk
  • financial risk
  • duplicate pages
  • automation drift
  • false confidence

AI can assist.

AI can draft.

AI can recommend.

AI can process.

But validation determines whether the output is trusted.

Quality Assurance Versus Quality Control

MWMS must separate Quality Assurance from Quality Control.

Both are required.

Quality Assurance

Quality Assurance prevents bad output before it happens.

In MWMS, Quality Assurance includes:

  • clear AI Employee role cards
  • strong task instructions
  • correct context packs
  • defined output formats
  • Brain ownership rules
  • tool permission rules
  • forbidden action rules
  • document structure standards
  • page naming standards
  • workflow pipeline standards
  • course absorption rules
  • newsletter intelligence protocols
  • offer evaluation protocols
  • developer boundaries

Quality Assurance asks:

Did we set the AI up to succeed before it generated the output?

Good Quality Assurance reduces bad outputs.

Quality Control

Quality Control checks the output after it is created.

In MWMS, Quality Control includes:

  • validation checklists
  • pass/fail review
  • source grounding checks
  • risk checks
  • routing checks
  • format checks
  • human review
  • rejection reasons
  • revision requests
  • dashboard review
  • event logs
  • action history

Quality Control asks:

Is this output good enough to use?

Quality Assurance prevents mistakes.

Quality Control catches mistakes.

MWMS needs both.

AI Output Validation Levels

MWMS should use different validation levels depending on the risk and importance of the output.

Level 1 — Light Validation

Used for low-risk internal support.

Examples:

  • quick brainstorm
  • rough note
  • simple explanation
  • low-risk rewrite
  • informal planning idea

Checks:

  • does it make sense?
  • is it useful?
  • is it obviously wrong?
  • does it stay within the request?

Human review:

  • optional

Level 2 — Structured Validation

Used for structured internal work.

Examples:

  • course absorption report
  • internal summary
  • Brain Room response
  • newsletter review draft
  • content draft
  • simple research note
  • workflow suggestion

Checks:

  • completeness
  • specificity
  • correct format
  • correct Brain mapping
  • no obvious invented facts
  • useful next step

Human review:

  • recommended before saving, routing, or acting

Level 3 — Operational Validation

Used for outputs that may enter MWMS workflows.

Examples:

  • MCR page draft
  • Agentic Work Unit
  • AI Employee role card
  • pipeline output
  • dashboard item
  • routed action draft
  • developer brief
  • offer evaluation draft
  • finance report draft

Checks:

  • source grounding
  • output format
  • Brain ownership
  • business outcome
  • risk level
  • handoff destination
  • duplication
  • MWMS standard alignment
  • human approval requirement

Human review:

  • required before operational use

Level 4 — High Risk Validation

Used for outputs that affect money, compliance, development, public content, or business decisions.

Examples:

  • paid traffic recommendation
  • offer test approval
  • compliance review
  • financial decision
  • developer implementation instruction
  • live system change recommendation
  • client-facing report
  • public claim
  • automated external action

Checks:

  • all Level 3 checks
  • source verification
  • risk review
  • compliance review where relevant
  • developer boundary check
  • financial logic check where relevant
  • final human approval

Human review:

  • mandatory

Level 5 — Critical Validation

Used for irreversible, external, live, or legally sensitive actions.

Examples:

  • database write
  • WordPress live update
  • external email send
  • client delivery
  • financial transaction
  • ad campaign launch
  • legal or compliance-sensitive action
  • automation that changes live systems

Checks:

  • all Level 4 checks
  • explicit approval
  • logging requirement
  • rollback or correction plan where possible
  • named owner
  • final status confirmation

Human review:

  • mandatory before execution

Default MWMS Validation Checklist

Every important AI output should be checked against the following checklist.

1. Completeness Check

Does the output answer the full task?

Check:

  • Did it cover all requested sections?
  • Did it skip anything important?
  • Did it stop too early?
  • Did it ignore constraints?
  • Did it answer the actual question?

Failure sign:

The output looks polished but misses part of the job.

2. Source Grounding Check

Is the output based on the available source material?

Check:

  • Is it supported by the uploaded file, user instruction, known standard, or verified source?
  • Did it invent facts?
  • Did it overstate what the source said?
  • Did it confuse assumptions with evidence?
  • Did it reference content that was not provided?

Failure sign:

The output sounds convincing but cannot be traced back to the input.

3. Specificity Check

Is the output specific enough to be useful?

Check:

  • Is it actionable?
  • Does it avoid generic advice?
  • Does it name the relevant Brain, workflow, page, or action?
  • Does it explain what should happen next?
  • Does it give enough detail for a human or system to use?

Failure sign:

The output sounds smart but does not help MWMS move forward.

4. Format Check

Does the output follow the required format?

Check:

  • Is it a full page output when required?
  • Does it follow the MWMS document structure?
  • Does it use the correct title style?
  • Does it include Purpose, Scope, Governance Role, Drift Protection, Architectural Intent, and Change Log where required?
  • Does it match the expected report, task, JSON, dashboard, or page format?

Failure sign:

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

5. Brain Routing Check

Is the output assigned to the correct Brain?

Check:

  • Which Brain owns the work?
  • Which Brains support the work?
  • Does HeadOffice need visibility?
  • Is this cross-Brain?
  • Does it belong in MCR, a Brain site, dashboard, task queue, or archive?

Failure sign:

Good output, wrong location.

6. Business Outcome Check

Does the output support a business outcome?

Check:

  • Does it create a decision?
  • Does it create a task?
  • Does it improve a workflow?
  • Does it update a standard?
  • Does it support revenue, risk reduction, speed, quality, or learning?
  • Does it avoid becoming “notes for the sake of notes”?

Failure sign:

Output exists, but nothing useful happens because of it.

7. Handoff Check

Does the output have a clear next destination?

Check:

  • Where does this go next?
  • Is it saved to MCR?
  • Is it copied to a Brain site?
  • Is it routed to a queue?
  • Is it sent to a dashboard?
  • Is it parked?
  • Is it rejected?
  • Is it converted into a task?

Failure sign:

The output is good but floats in space.

8. Risk Check

What damage could happen if this output is wrong?

Check:

  • Does it affect money?
  • Does it affect live systems?
  • Does it affect M’s development work?
  • Does it affect public content?
  • Does it affect compliance?
  • Does it affect client-facing material?
  • Does it affect canonical MWMS standards?

Failure sign:

High-risk output treated like a casual note.

9. Compliance Check

Does the output create legal, advertising, privacy, financial, or platform risk?

Check:

  • Does it make unsupported claims?
  • Does it suggest unsafe advertising?
  • Does it ignore platform policy?
  • Does it create misleading financial expectations?
  • Does it include sensitive data issues?
  • Does it need jurisdiction-specific review?

Failure sign:

The output may be useful but unsafe to act on.

10. Duplication Check

Does this output duplicate existing MWMS structure?

Check:

  • Does a similar page already exist?
  • Is this a new standard or an update to an existing one?
  • Does it belong inside a current framework?
  • Is it creating unnecessary extra pages?
  • Is it adding complexity without new value?

Failure sign:

A new page is created when an existing page should have been updated.

11. Naming And Structure Check

Does the output follow MWMS naming and structure rules?

Check:

  • Title Case
  • no unnecessary dashes
  • no symbols where forbidden
  • correct Brain prefix where required
  • correct document type
  • correct parent page
  • correct MCR placement
  • correct hierarchy

Failure sign:

Good content that creates WordPress or MCR structure mess.

12. Developer Boundary Check

Does this output interfere with M’s active work?

Check:

  • Does it touch Brain Room systems?
  • Does it touch executor hooks?
  • Does it touch Affiliate workflow systems?
  • Does it touch Opportunity system wiring?
  • Does it change live plugin logic?
  • Does it create tasks for M without approval?
  • Does it create conflicting build instructions?

Failure sign:

Good idea, wrong timing.

13. Tool Permission Check

Did the AI output assume tool access it did not have?

Check:

  • Did it claim to read something it did not read?
  • Did it assume live data access?
  • Did it assume database state?
  • Did it imply a system change was made when it was only drafted?
  • Did it use web/current data without verification?

Failure sign:

The AI presents assumed access as fact.

14. Human Review Check

Does this output require human approval?

Human review is required for:

  • MCR canon updates
  • high-risk decisions
  • financial recommendations
  • compliance-sensitive outputs
  • developer implementation
  • live system changes
  • public content
  • client-facing material
  • automation changes
  • external communication

Failure sign:

The AI output acts final when it should be reviewed.

15. Learning Check

Should MWMS learn something from this output?

Check:

  • Did it reveal a new standard?
  • Did it improve a workflow?
  • Did it expose a failure mode?
  • Did it refine an AI Employee role?
  • Did it add to Blueprint?
  • Did it reveal a useful course concept?
  • Did it improve M’s future build logic?

Failure sign:

Useful insight is produced but not captured.

Validation Decision States

After validation, every important AI output should be assigned one of the following states.

Accepted

The output is good enough for its intended use.

It may be saved, routed, displayed, or used according to its risk level.

Accepted With Minor Edits

The output is mostly correct but needs small fixes.

Examples:

  • wording cleanup
  • formatting correction
  • minor structure improvement
  • title adjustment

Revise

The output has useful value but is not ready.

Reasons may include:

  • incomplete
  • too generic
  • wrong format
  • missing context
  • weak validation
  • unclear destination
  • needs more detail

Park

The output may be useful later but should not be acted on now.

Reasons may include:

  • not current priority
  • overlaps future build
  • depends on unfinished system
  • useful but not urgent
  • needs more evidence

Reject

The output should not be used.

Reasons may include:

  • weak value
  • unsupported claims
  • wrong direction
  • duplicate structure
  • compliance risk
  • bad source
  • misleading conclusion
  • outside MWMS scope

Escalate

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

Reasons may include:

  • high risk
  • unclear ownership
  • developer impact
  • financial impact
  • compliance concern
  • conflicting standards
  • live system effect

Validation Examples

Example 1: Course Absorption Output

Validation checks:

  • Does it extract system value, not general summary?
  • Does it improve MWMS Brain or Blueprint?
  • Does it avoid duplicating existing standards?
  • Does it suggest correct Brain placement?
  • Does it include employee creation suggestions if useful?
  • Does it identify what to ignore?
  • Does it respect M’s development boundary?

Possible decision:

  • Accept
  • Revise
  • Park
  • Ignore weak material

Example 2: Newsletter Intelligence Output

Validation checks:

  • Is the insight business-relevant?
  • Is it specific?
  • Is the primary Brain correct?
  • Is the action type sensible?
  • Is urgency believable?
  • Is it ACT NOW, TEST, MONITOR, PARK, or REJECT correctly?
  • Does it avoid generic AI news?
  • Does it create a useful next step?

Possible decision:

  • Route
  • Park
  • Reject
  • Monitor
  • Convert to action

Example 3: Offer Evaluation Output

Validation checks:

  • Is the verdict evidence-based?
  • Are vendor claims treated carefully?
  • Is current data verified where needed?
  • Is compliance risk checked?
  • Is traffic fit considered?
  • Is finance logic included?
  • Is testability clear?
  • Is the Green, Yellow, or Red verdict justified?

Possible decision:

  • Reject offer
  • Park offer
  • Request research
  • Send to Finance Brain
  • Send to Experimentation Brain
  • HeadOffice review

Example 4: Developer Instruction Output

Validation checks:

  • Is the file path exact?
  • Is the insertion or replacement location exact?
  • Is it based on visible file contents or screenshots?
  • Does it avoid vague search instructions?
  • Does it protect current save point?
  • Does it avoid touching unrelated systems?
  • Does it provide full file output where required?
  • Does it include testing steps?

Possible decision:

  • Send to M
  • Revise
  • Escalate
  • Hold until screenshot or file is confirmed

Example 5: MCR Page Output

Validation checks:

  • Does it follow MWMS Document Structure Standard?
  • Is the title correct?
  • Is the parent page correct?
  • Is it MCR Source Of Truth?
  • Does it avoid duplication?
  • Does it include Governance Role?
  • Does it include Drift Protection?
  • Does it include Architectural Intent?
  • Does it include Change Log?
  • Does it align with existing pages?

Possible decision:

  • Save to MCR
  • Revise before saving
  • Merge with existing page
  • Park for later

Validation Roles

Different roles may perform validation depending on workflow maturity and risk level.

Self Validation

The AI Employee checks its own output before handoff.

Useful for:

  • low-risk outputs
  • drafts
  • formatting
  • internal summaries

Limit:

Self-validation is not enough for high-risk work.

Validation Agent

A separate AI Employee checks the output.

Useful for:

  • newsletter outputs
  • course absorption
  • offer evaluation
  • Brain Room responses
  • reports
  • developer briefs

Limit:

Still requires human review for high-risk tasks.

HeadOffice Validation

HeadOffice checks alignment with system goals, governance, routing, and business value.

Useful for:

  • cross-Brain workflows
  • high-value decisions
  • system architecture
  • dashboards
  • Blueprint updates

Martyn Review

Martyn reviews strategic, business, MCR, and direction-setting outputs.

Required for:

  • canon updates
  • major standards
  • course absorption page creation
  • offer test decisions
  • paid traffic moves
  • strategic direction changes
  • high-risk workflow changes

M Review

M reviews technical implementation outputs where code, plugins, APIs, Supabase, WordPress, or live system behavior is involved.

Required for:

  • developer instructions
  • implementation details
  • code changes
  • plugin updates
  • Supabase schema changes
  • live system fixes

Validation Failure Handling

When an output fails validation, MWMS should not simply discard the failure.

The failure should be handled properly.

If Output Is Incomplete

Action:

  • send back for revision
  • identify missing sections
  • clarify expected output
  • update task instruction if needed

If Output Is Too Generic

Action:

  • request more specific business application
  • require Brain mapping
  • require next action
  • reject if no practical value exists

If Output Is Unsupported

Action:

  • request source grounding
  • verify with file, web, database, or human input
  • mark assumptions clearly
  • reject unsupported claims

If Output Is Misrouted

Action:

  • correct Brain ownership
  • update routing rule if needed
  • log recurring routing problem

If Output Is Duplicative

Action:

  • merge with existing page
  • update existing standard instead of creating new one
  • reject new page creation
  • log duplication risk

If Output Is High Risk

Action:

  • escalate to human review
  • prevent automatic action
  • require validation evidence
  • create review task

If Output Reveals A Workflow Weakness

Action:

  • log Kaizen improvement
  • update role card or pipeline
  • update validation checklist
  • improve future prompt or process

Validation Logging

Important validation decisions should be logged.

A validation log should include:

  • output title
  • source
  • owning Brain
  • AI Employee
  • validation level
  • validation result
  • reason
  • required revision
  • final decision
  • reviewer
  • date
  • related task or event
  • learning captured

Validation logging helps MWMS identify:

  • unreliable workflows
  • weak AI Employees
  • repeated failure modes
  • routing problems
  • unclear standards
  • training needs
  • automation readiness

Automation Readiness Rule

A workflow should not be automated until its outputs can be validated reliably.

Before automation, confirm:

  • input is predictable enough
  • output format is stable
  • validation checklist exists
  • failure modes are known
  • human review rule exists
  • logging exists
  • risk level is acceptable
  • outcome is clear
  • rollback or correction path exists where needed

The automation readiness rule is:

If MWMS cannot validate the output, MWMS should not automate the workflow.

Dashboard Validation Rule

Dashboard items require extra care.

A dashboard should not display every AI output.

It should display validated, prioritized, useful intelligence.

Before an item appears on a dashboard, check:

  • Is it specific?
  • Is it current?
  • Is it business-relevant?
  • Is the priority believable?
  • Is the action type correct?
  • Is the Brain routing correct?
  • Is the source clear?
  • Is the next step obvious?
  • Is it noise?

Dashboard rule:

A dashboard filled with unvalidated AI output becomes clutter, not command intelligence.

Course Absorption Validation Rule

Course absorption outputs must be judged by MWMS value, not by course enthusiasm.

A course lesson is worth absorbing only if it improves:

  • MWMS Brain
  • MWMS Blueprint
  • AI Employee design
  • workflow structure
  • validation
  • orchestration
  • reporting
  • governance
  • AIBS delivery
  • future business expansion

Weak, duplicated, tool-specific, or hype-based material should be ignored or parked.

Course rule:

Do not absorb content because it exists. Absorb it because it improves MWMS.

Developer Output Validation Rule

Developer outputs must be extra strict.

Any instruction for M or live systems must include:

  • exact site
  • exact file path where applicable
  • exact screen or page where applicable
  • exact insertion/replacement location
  • full file output where required
  • current save point awareness
  • what not to touch
  • testing steps
  • rollback awareness where appropriate

Developer rule:

Vague developer instructions are not valid MWMS outputs.

Governance Role

HeadOffice owns the MWMS AI Output Validation Standard.

HeadOffice is responsible for:

  • defining validation expectations
  • setting risk-based validation levels
  • deciding when human review is required
  • preventing unvalidated AI outputs from becoming operational truth
  • protecting dashboards from noise
  • protecting MCR from duplicate or weak pages
  • protecting M’s active build areas
  • ensuring outputs connect to business outcomes
  • maintaining validation discipline across Brains

Individual Brains may define additional validation rules for their own workflows, but they must not remove the core validation requirements of 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 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
  • Experimentation Brain Canon
  • AI Business Systems Brain Blueprint

This standard defines how MWMS checks whether outputs from those systems are reliable enough to use.

Drift Protection

This standard protects MWMS from the following forms of drift:

  1. Trusting AI output because it sounds confident
  2. Accepting summaries that produce no action
  3. Saving weak course material into MCR
  4. Creating duplicate pages
  5. Routing outputs to the wrong Brain
  6. Displaying dashboard noise
  7. Acting on unsupported claims
  8. Automating workflows before validation exists
  9. Allowing AI Employees to validate high-risk work alone
  10. Sending vague instructions to M
  11. Making financial or compliance decisions without review
  12. Treating drafts as final outputs
  13. Losing validation history
  14. Allowing tool-specific hype into MWMS canon
  15. Mistaking volume of output for system progress

Any output showing these drift signs should be revised, parked, rejected, or escalated.

Architectural Intent

The architectural intent of the MWMS AI Output Validation Standard is to make MWMS trustworthy.

As MWMS grows, AI will produce more:

  • reports
  • decisions
  • drafts
  • tasks
  • dashboard items
  • recommendations
  • analyses
  • workflows
  • page outputs
  • client materials

The danger is not lack of output.

The danger is unvalidated output.

MWMS must be able to trust what enters its system, what gets routed, what gets displayed, what gets saved, and what gets acted upon.

Validation is the control layer that makes that trust possible.

A mature MWMS validation system should be able to answer:

  • What output was created?
  • Who or what created it?
  • What task did it answer?
  • What source was used?
  • What validation level applied?
  • Did it pass?
  • What failed?
  • Who reviewed it?
  • What decision was made?
  • Where did it go?
  • Was it logged?
  • What did MWMS learn?

When MWMS can answer those questions, it can scale AI work without losing quality, control, or trust.

Change Log

v1.0 — Initial Draft

Created the MWMS AI Output Validation Standard as the core quality control framework for checking AI-generated outputs before they are accepted, routed, saved, displayed, automated, or acted upon.

This standard supports the MWMS AI Agent Operations Core, MWMS Agentic Work Unit Standard, MWMS AI Employee Role Card Standard, MWMS AI Agent Orchestration Framework, and MWMS AI Workflow Pipeline Standard by defining validation levels, validation checks, decision states, failure handling, logging, dashboard protection, course absorption validation, developer output validation, and automation readiness rules.