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 Workflow Pipeline Standard.

This standard establishes how complex AI work inside MWMS must be broken into structured, repeatable, validatable workflow stages.

MWMS must not rely on one large prompt to perform important business work.

One-shot prompting may be acceptable for simple, low-risk support tasks, but it is not suitable for serious MWMS workflows such as offer evaluation, newsletter intelligence, course absorption, Brain Room task routing, financial analysis, research synthesis, content operations, experimentation, or client-facing AI business systems.

A pipeline is the structure that turns AI from a response generator into a repeatable business operating system.

This standard defines the default pipeline structure MWMS should use whenever AI work has multiple stages, multiple outputs, multiple Brains, multiple Employees, or meaningful business risk.

Scope

This standard applies to all MWMS workflows where AI performs structured work across more than one step.

This includes:

HeadOffice Brain workflows
Brain Room workflows
AI Manager workflows
AI Employee Router workflows
Task Executor workflows
Newsletter Intelligence workflows
Course Absorption workflows
Offer Evaluation workflows
Affiliate Brain workflows
Research Brain workflows
Experimentation Brain workflows
Finance Brain workflows
Content Brain workflows
Ads Brain workflows
Data Brain workflows
Operations Brain workflows
Dev Console support workflows
Supabase task and event workflows
MCR page creation workflows
future AIBS client systems

This standard applies to manual, assisted, and automated workflows.

Manual workflows may be performed by Martyn or HeadOffice with AI support.

Assisted workflows may be suggested by AI and approved by a human.

Automated workflows may be performed by AI Employees, APIs, Make.com, n8n, Supabase, WordPress plugins, or future MWMS automation systems.

Core Definition

An AI Workflow Pipeline is a structured sequence of steps that converts input into a validated business output.

A pipeline defines:

what enters the workflow
how the input is cleaned
how the request is classified
which Brain owns the work
which AI Employee performs each stage
what context is required
what tools may be used
what output must be produced
how the output is validated
where the result is routed
what business outcome is expected
what gets logged
what learning is captured

A pipeline is not just automation.

A pipeline is a governed process.

Automation executes steps.

A pipeline defines the correct order, controls, checks, and destinations for those steps.

Core Principle

The core principle of this standard is:

Complex AI work must be decomposed into controlled workflow stages before it becomes operational work.

This means MWMS should avoid asking AI to perform too many roles at once.

A single AI prompt should not be expected to:

understand the source
clean the input
classify the request
analyze the material
make a decision
validate itself
route the result
create a report
update the system
log the learning

That creates weak, inconsistent, and risky outputs.

MWMS pipelines must separate these jobs into clear stages.

Why Pipelines Matter

Pipelines matter because they make AI work repeatable.

Without pipelines, MWMS risks:

vague prompts
inconsistent outputs
missed context
weak decisions
wrong Brain routing
poor validation
duplicated work
unlogged actions
dashboard noise
automation drift
unreliable AI Employees

With pipelines, MWMS gains:

repeatable execution
clearer ownership
better quality control
stronger validation
safer automation
easier debugging
better reporting
more useful dashboards
cleaner handoffs
stronger learning loops

Pipelines are how MWMS moves from AI assistance to AI operations.

Default MWMS AI Workflow Pipeline

The default MWMS AI Workflow Pipeline contains twelve stages.

Input Capture
Input Cleaning
Classification
Task Creation
AI Employee Assignment
Context Attachment
Processing
Validation
Decision
Routing
Logging
Learning Update

Not every workflow requires every stage.

However, high-value, high-risk, or cross-Brain workflows should not skip critical stages without a clear reason.

1. Input Capture

Input Capture is the stage where MWMS receives the raw material.

Inputs may include:

user instruction
Brain Room message
newsletter
email
course file
transcript
PDF
sales page
affiliate offer
Google Ads data
Supabase row
WordPress page content
Make.com output
Google Sheet data
research source
screenshot
developer note
client request

The purpose of Input Capture is to preserve what came in, where it came from, and why it matters.

The Input Capture rule is:

MWMS must know what entered the system before it tries to process it.

2. Input Cleaning

Input Cleaning removes noise and prepares the source material for useful analysis.

Cleaning may include:

removing duplicated content
removing newsletter footers
removing tracking clutter
removing HTML noise
correcting broken formatting
extracting readable text
separating useful content from filler
standardizing names, dates, fields, and sections
converting messy input into structured form

Input Cleaning is especially important for:

newsletters
course transcripts
copied website text
sales pages
scraped content
PDF extracts
long emails
messy spreadsheets
AI-generated drafts

The Input Cleaning rule is:

Dirty input creates dirty intelligence.

MWMS should not trust analysis that was performed on noisy, incomplete, or poorly structured input.

3. Classification

Classification identifies what kind of work is required.

Classification should determine:

request type
topic
owning Brain
supporting Brains
urgency
priority
risk level
required workflow
human review requirement
likely output type

Common MWMS classifications include:

course absorption
newsletter intelligence
offer evaluation
research request
validation request
MCR page creation
Brain Room task
developer support
finance analysis
experiment review
content production
compliance review
dashboard item
routed action
client workflow

The Classification rule is:

MWMS must classify work before assigning work.

Bad classification creates bad routing.

Bad routing creates weak outcomes.

4. Task Creation

Task Creation converts the classified request into an Agentic Work Unit.

The task should define:

task title
task type
source
owning Brain
assigned AI Employee
input payload
context requirements
output format
validation standard
handoff destination
business outcome
status
priority
risk level
review requirement
logging requirement

Task Creation protects MWMS from vague execution.

The Task Creation rule is:

A vague request should become a structured task before AI performs serious work.

5. AI Employee Assignment

AI Employee Assignment determines which AI Employee or role should perform the work.

Assignment should be based on:

owning Brain
task type
required skill
authority level
tool permission
risk level
output type
validation requirement
role card fit

Examples:

Newsletter Signal Extraction Agent
Course Absorption Agent
Offer Evaluation Agent
Research Evidence Collection Agent
Finance Break Even Analysis Agent
HeadOffice Validation Agent
Brain Room Task Builder Agent
Reporting Agent
Handoff Agent
Compliance Review Agent

The AI Employee Assignment rule is:

Assign work to a role, not to generic AI.

6. Context Attachment

Context Attachment provides the AI Employee with the rules, standards, history, and boundaries needed to perform correctly.

Context may include:

relevant MCR standards
Brain rules
current save point
developer boundary
source of truth location
page naming rules
document structure rules
course absorption rules
affiliate offer protocol
newsletter intelligence protocol
active build restrictions
previous decisions
known risks
user preference
expected output standard

Context Attachment prevents isolated AI output.

The Context Attachment rule is:

AI Employees should not perform meaningful MWMS work without system context.

7. Processing

Processing is the stage where the assigned AI Employee performs the actual work.

Processing may include:

extracting insights
analyzing source material
comparing options
creating a report
drafting a page
evaluating an offer
identifying risks
generating structured output
summarizing results
creating action items
mapping to Brains
preparing a handoff
building a recommendation

Processing should follow the assigned task instruction and required output format.

The Processing rule is:

AI work must follow the task, not wander beyond it.

8. Validation

Validation checks whether the output is good enough to trust, route, display, save, or act upon.

Validation may include:

completeness check
source grounding check
format check
specificity check
Brain routing check
duplication check
risk check
compliance check
naming check
parent page check
developer boundary check
business usefulness check
hallucination check
actionability check

Validation may be performed by:

the original AI Employee
a separate Validation Agent
HeadOffice
Martyn
M
a technical test
a dashboard review
a future human operator

The Validation rule is:

AI output is not operational truth until it passes validation.

9. Decision

Decision determines what happens after validation.

Possible decisions include:

accept
revise
reject
park
route
escalate
create task
create page
update registry
send to dashboard
send to review queue
request more research
prepare developer brief
mark complete
log learning

Decision is where AI output becomes business movement.

The Decision rule is:

Every useful AI output should lead to a clear decision state.

10. Routing

Routing sends the result to the correct destination.

Possible destinations include:

HeadOffice Dashboard
Brain Room
Newsletter Queue Review
Routed Actions
MCR page
Brain site page
Supabase task table
Supabase event log
Google Sheet
Affiliate Brain
Research Brain
Experimentation Brain
Finance Brain
Content Brain
Ads Brain
Human Review Queue
Parking System
Archive

Routing prevents valuable work from disappearing.

The Routing rule is:

Every important output must have a destination.

11. Logging

Logging records what happened.

A log may include:

input received
task created
Brain assigned
AI Employee assigned
output generated
validation completed
decision made
handoff completed
status changed
human review completed
error detected
learning captured

Logging is essential for auditability, debugging, reporting, and improvement.

The Logging rule is:

If important AI work is not logged, MWMS cannot learn from it or audit it.

12. Learning Update

Learning Update captures what MWMS should remember or improve because of the workflow.

Learning may include:

new framework extracted
workflow weakness found
prompt improvement identified
Brain routing improved
validation rule improved
course insight absorbed
offer rejected for strategic reason
compliance issue discovered
market trend detected
dashboard improvement identified
AI Employee role clarified
repeated failure mode identified
future automation opportunity found

Learning may be routed to:

MWMS Blueprint
Brain Canon
Kaizen Log
System Change Log
Newsletter Signal Log
Course Absorption Decision Registry
Experimentation learning records
Research Brain signal records
Parking System

The Learning Update rule is:

MWMS should improve from completed work.

Pipeline Types

MWMS may use different pipeline types depending on the task.

1. Simple Support Pipeline

Used for low-risk internal support.

Stages:

Input
Response
Optional Review

Examples:

quick explanation
brainstorm
internal note
low-risk rewrite
simple checklist

This pipeline does not require heavy structure.

2. Structured Drafting Pipeline

Used when AI prepares something for human review.

Stages:

Input Capture
Classification
Context Attachment
Processing
Validation
Human Review
Final Output

Examples:

MCR page draft
developer brief
report draft
content draft
course absorption output

3. Intelligence Extraction Pipeline

Used for turning messy information into useful intelligence.

Stages:

Input Capture
Cleaning
Extraction
Classification
Brain Mapping
Validation
Routing
Logging
Learning Update

Examples:

newsletter intelligence
course absorption
market research
competitor analysis
tool evaluation

4. Decision Support Pipeline

Used for high-impact business decisions.

Stages:

Input Capture
Cleaning
Classification
Evidence Gathering
Analysis
Risk Review
Finance Review
Validation
HeadOffice Decision
Routing
Logging
Learning Update

Examples:

offer evaluation
ad campaign decision
product testing
tool purchase decision
new system direction

5. Cross-Brain Pipeline

Used when multiple Brains must contribute.

Stages:

Input Capture
Owning Brain Classification
Supporting Brain Identification
Brain-to-Brain Request Creation
Specialist AI Employee Processing
Combined Validation
HeadOffice Review
Final Decision
Routing
Logging
Learning Update

Examples:

Affiliate Brain → Research Brain → Experimentation Brain → Finance Brain
Newsletter signal → Content Brain + Ads Brain + HeadOffice
AIBS system design → Operations Brain + Data Brain + HeadOffice

6. Client-Facing AIBS Pipeline

Used for future AI Business Systems client workflows.

Stages:

Client Process Intake
Workflow Mapping
Role Definition
Tool Permission Design
AI Employee Assignment
Validation Gate Design
Human Approval Rules
Reporting Layer
Controlled Deployment
Logging
Kaizen Improvement

This pipeline supports the future MWMS client promise:

Governed AI workflow systems, not random automations.

Pipeline Examples

Example 1: Newsletter Intelligence Pipeline

Gmail receives newsletter
Input captured from subject, sender, date, body, snippet, and metadata
Content cleaning removes junk, footers, and repeated sections
Signal Extraction Agent extracts business-relevant insights
Brain Routing Agent assigns primary and supporting Brains
Action Classification Agent assigns ACT NOW, TEST, MONITOR, PARK, or REJECT
Validation Agent checks usefulness, specificity, and routing
Output is stored in Supabase
Queue Review displays item
HeadOffice Dashboard displays priority intelligence
Human review routes, parks, rejects, or converts to action
Learning Agent tracks recurring patterns

Example 2: Course Absorption Pipeline

Course file uploaded
Course Intake Agent identifies file type, lesson, module, and topic
Value Filter Agent decides if the lesson is worth absorbing
Framework Extraction Agent extracts reusable system principles
MWMS Mapping Agent maps concepts to Brains and Blueprint
Duplication Check Agent checks against existing standards
Upgrade Decision Agent decides absorb, park, ignore, or replace
Page Builder Agent prepares MCR-ready output where needed
Validation Agent checks structure, naming, usefulness, and fit
Martyn reviews before saving
Registry update need is identified
Learning is logged

Example 3: Brain Room Pipeline

Brain Room message received
Task Builder Agent reads message and thread context
Request is classified
Owning Brain is identified
Agentic Work Unit is created
AI Employee is assigned
Required context is attached
Risk level is set
AI Manager routes task
AI Employee completes work
Validation Agent checks output
Response is returned to Brain Room
Follow-up action is routed if needed
Event is logged

Example 4: Offer Evaluation Pipeline

Offer enters Affiliate Brain
Offer Intake Agent records basic offer data
Vendor Intelligence Agent checks credibility
Market Demand Agent checks demand
Competitor Scan Agent checks crowding
Funnel Analysis Agent checks mechanism and claims
Ads Brain checks platform fit
Compliance Review Agent flags risk
Finance Brain checks break-even logic and test budget
Experimentation Brain checks test suitability
HeadOffice Verdict Agent prepares Green, Yellow, or Red verdict
Martyn reviews final decision
Offer is routed to test planning, research, parking, or rejection
Learning is logged

Example 5: M Developer Support Pipeline

Development issue enters Dev Console or Brain Room
Request is classified as developer support
Relevant site, plugin, file, or system area is identified
Current safe save point is attached
Developer boundary is checked
AI prepares exact instructions or full file output
Validation checks visible evidence, file path, and insertion point
M receives controlled implementation brief
Result is tested
Event is logged
Save point is updated if successful

This protects M from vague instructions and protects MWMS from unsafe code drift.

Pipeline Quality Checklist

Before a pipeline becomes part of MWMS operations, check:

Is the input source clear?
Is the workflow purpose clear?
Is the owning Brain defined?
Are supporting Brains identified where needed?
Is the task type defined?
Is the AI Employee assigned by role?
Is required context attached?
Are tools and permissions clear?
Are forbidden actions clear?
Is the output format defined?
Is validation included?
Is human review required?
Is the handoff destination clear?
Is the business outcome clear?
Is the event log required?
Is learning captured?
Is the pipeline too complex for the value of the task?
Is the pipeline safe for the current build stage?
Does it avoid interfering with M’s active work?
Can the workflow be repeated?

A pipeline should not be automated until it passes this checklist.

Pipeline Failure Modes

MWMS must watch for pipeline failure.

Common failure modes include:

The input is incomplete or dirty
The task is not classified correctly
The wrong Brain owns the work
The wrong AI Employee is assigned
Context is missing
The output format is vague
Validation is skipped
Human review is skipped too early
The output has no destination
Logging is missing
Learning is not captured
Too many stages are used for a simple task
Too few stages are used for a high-risk task
One AI Employee performs too many roles
The pipeline becomes activity without business outcome
The workflow interferes with M’s active build
Automation is added before the manual process is proven

Any pipeline showing these failure modes should be reviewed before further automation.

Pipeline Automation Rule

MWMS should not automate a workflow simply because it can be automated.

A workflow should only be automated when:

the manual process is understood
the pipeline stages are stable
inputs are predictable enough
outputs are structured
validation rules exist
failure modes are known
human review rules are defined
logging is available
the business outcome is clear
automation will reduce work without increasing risk

The automation rule is:

Manual discipline first. Automation second.

This protects MWMS from building brittle systems too early.

Human Review Rule

Human review is required when a pipeline affects:

MCR canon
live WordPress systems
Supabase writes
external communications
public content
paid traffic decisions
financial decisions
compliance-sensitive outputs
client deliverables
developer implementation
Brain architecture changes
system-wide standards

Human review may be reduced only after the workflow proves reliable.

Governance Role

HeadOffice owns the MWMS AI Workflow Pipeline Standard.

HeadOffice is responsible for:

approving high-impact pipelines
defining validation expectations
ensuring Brain ownership is clear
preventing unsafe automation
ensuring outputs have destinations
ensuring learning is captured
protecting M’s active build areas
reviewing cross-Brain workflows
maintaining MCR as the source of truth

Individual Brains may design their own pipelines, but those pipelines must align with this standard.

No Brain should automate complex AI work without pipeline clarity, validation, and HeadOffice visibility.

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 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 the repeatable pipeline structure that allows those governance rules to operate in real workflows.

Drift Protection

This standard protects MWMS from the following forms of drift:

Relying on one-shot prompts for complex work
Treating AI responses as complete workflows
Skipping input cleaning
Skipping classification
Assigning work without Brain ownership
Assigning work to generic AI instead of role-based Employees
Producing outputs without validation
Producing outputs with no destination
Automating workflows before they are stable
Creating dashboards full of unreviewed output
Losing task history
Failing to capture learning
Building complex automations that cannot be debugged
Letting course absorption create unnecessary pages
Allowing Brain Room to become unmanaged chat
Allowing client-facing systems to run without approval gates
Confusing AI speed with operational maturity

Any workflow that violates this standard should be simplified, paused, reviewed, or redesigned.

Architectural Intent

The architectural intent of the MWMS AI Workflow Pipeline Standard is to make MWMS reliable at scale.

MWMS will eventually contain many Brains, AI Employees, task systems, dashboards, client workflows, and automation layers.

That complexity must be managed through repeatable pipelines.

The long-term goal is that MWMS can take any meaningful input and move it through a controlled path:

input → cleaning → classification → task → Employee → processing → validation → decision → routing → logging → learning

This creates the foundation for a real AI business operating system.

A mature MWMS pipeline should always be able to answer:

What entered the system?
Was the input clean enough?
What type of work was it?
Which Brain owned it?
Which AI Employee handled it?
What context was used?
What output was required?
Was the output validated?
What decision was made?
Where did the output go?
What was logged?
What did MWMS learn?

When MWMS can answer those questions consistently, AI work becomes manageable, auditable, improvable, and valuable.

Change Log

v1.0 — Initial Draft

Created the MWMS AI Workflow Pipeline Standard as the default structure for decomposing complex AI work into controlled workflow stages.

This standard supports the MWMS AI Agent Operations Core, MWMS Agentic Work Unit Standard, MWMS AI Employee Role Card Standard, and MWMS AI Agent Orchestration Framework by defining how AI work should move from input capture through cleaning, classification, task creation, AI Employee assignment, context attachment, processing, validation, decision, routing, logging, and learning update.