MWMS MCR

MWMS AI Workflow Pipeline Checklist

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

This checklist is used to design, review, and validate AI workflows before they become repeatable MWMS operating processes.

MWMS must not rely on one large prompt, one vague instruction, or one loose AI response for important business work.

Important AI work must move through a clear pipeline.

A pipeline makes sure the system knows:

  • what entered the workflow
  • how the input was cleaned
  • how the task was classified
  • which Brain owns the work
  • which AI Employee should perform it
  • what context is required
  • what output is expected
  • how the output is validated
  • what decision is needed
  • where the result goes
  • what is logged
  • what MWMS learns

This checklist is the practical daily-use version of the MWMS AI Workflow Pipeline Standard.

Scope

This checklist applies to any MWMS workflow where AI work has more than one step, more than one Brain, more than one AI Employee, meaningful risk, or a business outcome.

This includes:

  • Course Absorption workflows
  • Newsletter Intelligence workflows
  • Brain Room workflows
  • AI Manager workflows
  • Task Executor workflows
  • Offer Evaluation workflows
  • Research Brain workflows
  • Experimentation Brain workflows
  • Finance Brain workflows
  • Content Brain workflows
  • Ads Brain workflows
  • HeadOffice reporting workflows
  • Developer Support workflows
  • MCR page creation workflows
  • Dashboard review workflows
  • Routed Action workflows
  • future AIBS client workflows

This checklist can be used manually first.

Later, parts of this checklist may become workflow status fields, Supabase task stages, dashboard filters, AI Manager routing logic, or future client workflow controls.

Core Definition

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

A pipeline is not just automation.

A pipeline defines:

  • the order of work
  • the responsible Brain
  • the assigned AI Employee
  • the context required
  • the output required
  • the validation needed
  • the handoff destination
  • the decision state
  • the logging requirement
  • the learning update

Automation may later execute parts of a pipeline.

But the pipeline must exist before automation.

Default MWMS AI Workflow Pipeline

The default MWMS pipeline has twelve stages:

  1. Input Capture
  2. Input Cleaning
  3. Classification
  4. Task Creation
  5. AI Employee Assignment
  6. Context Attachment
  7. Processing
  8. Validation
  9. Decision
  10. Routing
  11. Logging
  12. Learning Update

Not every workflow needs every stage.

However, high-value, high-risk, cross-Brain, developer, finance, compliance, MCR, paid traffic, or client-facing work should not skip critical stages.

AI Workflow Pipeline Checklist

1. Input Capture

Question:
Has the input been captured clearly?

Check:

  • source type identified
  • source name recorded
  • source reference recorded where available
  • date received known
  • origin known
  • source completeness checked
  • source format known
  • raw input preserved where needed

Examples Of Inputs:

  • course transcript
  • newsletter email
  • Brain Room message
  • affiliate offer page
  • Supabase row
  • WordPress page list
  • screenshot
  • developer note
  • finance numbers
  • experiment result
  • client document

Pass Condition:
MWMS knows what entered the workflow and where it came from.

Fail Condition:
The AI workflow begins without knowing the source clearly.

Decision If Failed:
Pause and capture the input before analysis.

2. Input Cleaning

Question:
Has the input been cleaned enough to process?

Check:

  • duplicate clutter removed
  • irrelevant boilerplate removed
  • broken formatting repaired where possible
  • newsletter footers removed
  • transcript noise reduced
  • HTML clutter reduced
  • copied table fields clarified
  • incomplete areas marked
  • useful meaning preserved

Pass Condition:
The input is clean enough for analysis.

Fail Condition:
AI is analyzing noisy, broken, incomplete, or cluttered input.

Decision If Failed:
Normalize or clean the input before proceeding.

3. Classification

Question:
Has the work type been classified?

Check:

  • workflow type identified
  • task category identified
  • owning Brain identified
  • supporting Brains identified where needed
  • risk level assigned
  • priority assigned
  • output type identified
  • human review need identified

Common Workflow Types:

  • Course Absorption
  • Newsletter Intelligence
  • Brain Room Task Creation
  • Offer Evaluation
  • Research
  • Finance Review
  • Experimentation Review
  • Developer Support
  • MCR Page Creation
  • Dashboard Review
  • Handoff
  • Validation
  • Client Workflow

Pass Condition:
MWMS knows what kind of work this is.

Fail Condition:
The task is treated generically.

Decision If Failed:
Classify before assigning or processing.

4. Task Creation

Question:
Has the request been converted into a structured Agentic Work Unit if needed?

Check:

  • Work Unit title defined
  • source defined
  • owning Brain defined
  • assigned AI Employee suggested
  • task instruction written
  • input payload included
  • context pack identified
  • output format defined
  • validation level defined
  • handoff destination defined
  • business outcome defined
  • risk and priority assigned

Pass Condition:
The work is structured enough to execute.

Fail Condition:
The AI Employee receives a vague prompt.

Decision If Failed:
Create or revise the Agentic Work Unit.

5. AI Employee Assignment

Question:
Has the correct AI Employee been assigned?

Check:

  • AI Employee role matches task
  • owning Brain matches role
  • authority level matches risk
  • role card exists or draft exists
  • non-responsibilities respected
  • tool permissions fit role
  • human review rule known

Examples:

  • Course Absorption Agent
  • Newsletter Signal Extraction Agent
  • Brain Room Task Builder Agent
  • Offer Evaluation Agent
  • HeadOffice Validation Agent
  • Research Evidence Collection Agent
  • Finance Break Even Analysis Agent
  • Developer Support Agent

Pass Condition:
The work is assigned to a role, not vague AI.

Fail Condition:
The task is handled by generic AI without role boundaries.

Decision If Failed:
Assign the correct AI Employee or define the role first.

6. Context Attachment

Question:
Has the required context been attached?

Check:

  • relevant standards included
  • Brain rules included
  • current save point included if developer-related
  • MCR source-of-truth rule included where relevant
  • page naming rules included where relevant
  • document structure rules included where relevant
  • tool permission boundary included
  • risk context included
  • previous decisions included if relevant
  • current user instruction included

Pass Condition:
The AI Employee has enough context to work correctly.

Fail Condition:
The AI Employee must guess MWMS context.

Decision If Failed:
Build a context pack before processing.

7. Processing

Question:
Has the AI Employee performed the assigned work within scope?

Check:

  • task instruction followed
  • role boundary respected
  • output format followed
  • unsupported claims avoided
  • assumptions marked
  • forbidden actions avoided
  • no unnecessary expansion
  • business relevance maintained

Pass Condition:
The work was performed inside the defined scope.

Fail Condition:
The AI output wandered, overreached, or ignored the task.

Decision If Failed:
Revise or reroute.

8. Validation

Question:
Has the output been validated at the correct level?

Check:

  • task alignment checked
  • completeness checked
  • source grounding checked
  • specificity checked
  • format checked
  • Brain routing checked
  • business outcome checked
  • handoff checked
  • risk checked
  • duplication checked
  • developer boundary checked where relevant
  • compliance checked where relevant
  • human review requirement checked

Pass Condition:
The output is good enough for its next stage.

Fail Condition:
The output is treated as trusted without validation.

Decision If Failed:
Validate, revise, park, reject, or escalate.

9. Decision

Question:
Has a decision been made?

Possible Decisions:

  • Accept
  • Accept With Minor Edits
  • Revise
  • Park
  • Reject
  • Escalate
  • Route
  • Create Task
  • Create Page
  • Update Page
  • Send To M
  • Send To Brain
  • Add To Dashboard
  • Log Learning

Pass Condition:
The output has a clear decision state.

Fail Condition:
The output exists but nothing happens next.

Decision If Failed:
Assign a decision state before routing.

10. Routing

Question:
Has the output been routed to the correct destination?

Possible Destinations:

  • MCR page
  • HeadOffice review
  • Brain Room
  • AI Manager
  • Task Executor
  • 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

Pass Condition:
The output goes somewhere useful.

Fail Condition:
The output floats in space.

Decision If Failed:
Create a handoff package or routing decision.

11. Logging

Question:
Has important work been logged?

Logging May Include:

  • task created
  • output created
  • validation result
  • handoff completed
  • failure found
  • escalation triggered
  • decision made
  • outcome recorded
  • learning captured

Logging Required For:

  • MCR updates
  • developer handoffs
  • cross-Brain work
  • high-risk tasks
  • offer evaluations
  • finance decisions
  • validation failures
  • client-facing workflows
  • important HeadOffice decisions

Pass Condition:
Important work leaves a trace.

Fail Condition:
The system cannot audit what happened.

Decision If Failed:
Log the event or mark logging requirement.

12. Learning Update

Question:
Did MWMS learn something reusable?

Learning May Include:

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

Pass Condition:
Useful learning is captured or routed.

Fail Condition:
Good learning disappears after the task.

Decision If Failed:
Capture learning in the right place.

Quick Pipeline Review Form

Use this quick form to review a workflow.

Workflow Name:
Workflow Type:
Owning Brain:
Supporting Brains:
Primary AI Employee:
Input Source:
Output Type:
Risk Level:
Human Review Required:
Destination:

Input Capture: Pass / Revise / Fail
Input Cleaning: Pass / Revise / Fail
Classification: Pass / Revise / Fail
Task Creation: Pass / Revise / Fail
AI Employee Assignment: Pass / Revise / Fail
Context Attachment: Pass / Revise / Fail
Processing: Pass / Revise / Fail
Validation: Pass / Revise / Fail
Decision: Pass / Revise / Fail
Routing: Pass / Revise / Fail
Logging: Pass / Revise / Fail
Learning Update: Pass / Revise / Fail

Pipeline Verdict: Ready / Manual Only / Needs Revision / Park / Not Ready / Escalate
Required Next Action:
Reviewer:
Date:

Pipeline Verdicts

Ready

The workflow is clear, structured, validated, and safe for its intended use.

Manual Only

The workflow is useful but should remain manual until repeated patterns are proven.

Needs Revision

The workflow has value but one or more stages are unclear or weak.

Park

The workflow may be useful later but is not current priority or not ready.

Not Ready

The workflow lacks structure, ownership, validation, or safe handoff.

Escalate

The workflow involves high risk, developer work, money, compliance, live systems, or client-facing output and needs higher review.

Workflow Type Checklists

1. Course Absorption Pipeline Checklist

Use when processing course content.

Pipeline Stages:

  1. Capture course file, module, lesson, and source type.
  2. Clean transcript or lesson text.
  3. Classify topic and MWMS relevance.
  4. Create Work Unit if output is important.
  5. Assign Course Absorption Agent.
  6. Attach Course Absorption System v2, anti-duplication rule, and MCR rules.
  7. Extract frameworks, standards, workflows, and strategic value.
  8. Validate system value and duplication risk.
  9. Decide absorb, park, ignore, or create page.
  10. Route to MCR draft, Blueprint background, or Parking System.
  11. Log if absorbed.
  12. Capture learning if reusable.

Pipeline Rule:
Course absorption must extract MWMS system value, not general summaries.

2. Newsletter Intelligence Pipeline Checklist

Use when processing newsletters.

Pipeline Stages:

  1. Capture sender, subject, date, body, snippet, metadata.
  2. Clean footers, ads, repeated junk, and irrelevant sections.
  3. Classify signal type and Brain impact.
  4. Create intelligence record or review item.
  5. Assign Newsletter Signal Extraction Agent.
  6. Attach Newsletter Intelligence Protocol and Brain Routing Rule.
  7. Extract business-relevant signals only.
  8. Validate specificity, action type, priority, and routing.
  9. Decide ACT NOW, TEST, MONITOR, PARK, or REJECT.
  10. Route to Queue Review, Dashboard, Routed Actions, or Parking.
  11. Log record and status.
  12. Capture repeated signal patterns.

Pipeline Rule:
Newsletter intelligence must separate signal from noise.

3. Brain Room Pipeline Checklist

Use when converting Brain Room messages into structured work.

Pipeline Stages:

  1. Capture message, sender, timestamp, and thread context.
  2. Clean unclear wording or mixed topics.
  3. Classify request type and owning Brain.
  4. Create Agentic Work Unit if needed.
  5. Assign Brain Room Task Builder Agent.
  6. Attach Brain Routing Rule and active build boundary.
  7. Convert message into structured task or response.
  8. Validate risk, ownership, and handoff.
  9. Decide route, respond, park, reject, or escalate.
  10. Route to AI Manager, human review, Task Executor, or Parking.
  11. Log task or outcome.
  12. Capture repeated request pattern.

Pipeline Rule:
Brain Room discussion should become structured work when it matters.

4. Offer Evaluation Pipeline Checklist

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

Pipeline Stages:

  1. Capture offer name, network, niche, payout, source.
  2. Clean vendor hype and separate claims from evidence.
  3. Classify offer type, risk level, and traffic fit.
  4. Create Offer Evaluation Work Unit.
  5. Assign Offer Evaluation Agent.
  6. Attach Affiliate Product Intelligence Protocol, Ads Brain rules, Finance rules, Experimentation rules.
  7. Analyze vendor, funnel, market, traffic fit, compliance, finance, testability.
  8. Validate evidence, current data, risk, and verdict.
  9. Decide Green, Yellow, Red, Research, Finance Review, Park, or Reject.
  10. Route to Research, Finance, Experimentation, HeadOffice, Parking, or Rejected archive.
  11. Log verdict.
  12. Capture offer learning.

Pipeline Rule:
No offer should move toward spend without evidence, risk review, and finance logic.

5. Developer Support Pipeline Checklist

Use when preparing work for M.

Pipeline Stages:

  1. Capture site, screenshot, file, issue, and current save point.
  2. Clean problem statement and remove unrelated noise.
  3. Classify system area and risk.
  4. Create Developer Support Work Unit.
  5. Assign Developer Support Agent.
  6. Attach Full File Output Rule, exact instruction rule, and what not to touch.
  7. Prepare exact developer brief or full file output.
  8. Validate file path, visible evidence, test steps, and risk.
  9. Decide send to M, revise, request more info, park, or escalate.
  10. Route to M, Dev Console, Brain Room, or HeadOffice review.
  11. Log meaningful dev handoff.
  12. Capture new save point or instruction rule.

Pipeline Rule:
If M has to guess, the pipeline has failed.

6. MCR Page Creation Pipeline Checklist

Use when creating or updating MCR pages.

Pipeline Stages:

  1. Capture source and reason for page.
  2. Clean extracted material.
  3. Classify page type and parent.
  4. Create page Work Unit if important.
  5. Assign appropriate AI Employee.
  6. Attach Document Structure Standard, Page Naming Standard, MCR Source Of Truth rule.
  7. Draft full page output.
  8. Validate duplication, structure, naming, parent, and source grounding.
  9. Decide save, revise, merge, park, or reject.
  10. Route to MCR page creation and registry update.
  11. Log if saved.
  12. Capture learning or architecture update.

Pipeline Rule:
MCR pages must be created because they improve the system, not because content exists.

7. AIBS Client Workflow Pipeline Checklist

Use for future AI Business Systems client workflows.

Pipeline Stages:

  1. Capture client process, source, and business goal.
  2. Normalize client input.
  3. Classify workflow type and risk.
  4. Create client workflow Work Unit.
  5. Assign client AI Employee role.
  6. Attach client rules, approval gates, and tool permissions.
  7. Process into report, task, draft, or recommendation.
  8. Validate clarity, safety, source grounding, and client risk.
  9. Decide approve, revise, escalate, or send to client review.
  10. Route to client review, dashboard, or approval gate.
  11. Log action and outcome.
  12. Capture client workflow improvement.

Pipeline Rule:
Client AI workflows must be governed, permissioned, and reviewable.

Pipeline Quality Checklist

Before approving a workflow, check:

  1. Is the workflow purpose clear?
  2. Is the input source clear?
  3. Is the owning Brain clear?
  4. Are supporting Brains identified?
  5. Is the AI Employee assigned by role?
  6. Is the input cleaning stage defined?
  7. Is classification defined?
  8. Is a Work Unit required?
  9. Is context attached?
  10. Is output format defined?
  11. Is validation included?
  12. Is human review required where risk demands it?
  13. Is decision state defined?
  14. Is handoff destination clear?
  15. Is logging required?
  16. Is learning capture included?
  17. Is risk level known?
  18. Are failure triggers known?
  19. Does this affect M’s active build?
  20. Is automation premature?

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

Pipeline Failure Modes

A pipeline has failed if:

  1. Raw input is analyzed without cleaning.
  2. Work type is not classified.
  3. Owning Brain is unclear.
  4. Wrong AI Employee is assigned.
  5. Context is missing.
  6. Output format is undefined.
  7. Validation is skipped.
  8. Human review is skipped on high-risk work.
  9. No decision state is assigned.
  10. Output has no destination.
  11. Nothing is logged.
  12. No learning is captured.
  13. Workflow creates dashboard noise.
  14. Workflow creates vague developer instructions.
  15. Workflow automates before manual proof.

Manual Use Rule

This checklist should be used manually before any workflow becomes technical infrastructure.

Manual use helps MWMS learn:

  • which stages are essential
  • which stages are too heavy
  • which workflows repeat often
  • which AI Employees are useful
  • which handoffs are common
  • which validation steps matter most
  • which data fields may later be needed
  • which workflows are ready for automation
  • which workflows should stay manual

Manual proof comes before automation.

Future Plugin Or UI Relevance

This checklist may later become:

  • workflow design screen
  • AI Manager pipeline builder
  • Brain Room workflow review screen
  • Supabase workflow status fields
  • HeadOffice workflow dashboard
  • Validation Queue
  • Handoff Queue
  • Outcome Log
  • AIBS client workflow builder

Possible future fields:

  • workflow_id
  • workflow_name
  • workflow_type
  • owning_brain
  • supporting_brains
  • primary_ai_employee
  • input_source
  • output_type
  • risk_level
  • human_review_required
  • current_stage
  • validation_status
  • decision_state
  • handoff_destination
  • logging_required
  • learning_required
  • status
  • created_at
  • updated_at

No technical build is authorized by this checklist alone.

Governance Role

HeadOffice owns the MWMS AI Workflow Pipeline Checklist.

HeadOffice is responsible for:

  • deciding which workflows require pipeline structure
  • preventing one-shot prompting for serious work
  • ensuring Brain ownership is clear
  • ensuring AI Employee assignment is role-based
  • ensuring validation and handoff stages exist
  • protecting M’s active build areas
  • preventing premature automation
  • deciding when a workflow is ready for operational copy or plugin/UI transformation

Individual Brains may use specialized pipeline versions, but they must not remove critical pipeline stages for high-risk work.

Relationship To Other MWMS Standards

This checklist supports and must align with:

  • MWMS AI Agent Operations Core
  • MWMS AI Workflow Pipeline 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 Output Validation Standard
  • MWMS AI Output Validation Checklist
  • MWMS Messy Input Normalization Framework
  • MWMS Agentic Reporting Standard
  • 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 Deployment Readiness Checklist
  • MWMS AI Tool Permission And Access Framework
  • MWMS AI Agent Memory And Context Framework
  • MWMS Brain Routing Rule
  • MWMS Brain To Brain Request Protocol
  • MWMS Supabase Event Schema
  • AI Business Systems Brain Blueprint

This checklist is the practical application of the MWMS AI Workflow Pipeline Standard.

Drift Protection

This checklist protects MWMS from the following forms of drift:

  1. Using one-shot prompts for complex AI work
  2. Skipping input cleaning
  3. Skipping classification
  4. Assigning work without Brain ownership
  5. Assigning work to generic AI
  6. Processing without context
  7. Treating AI output as trusted without validation
  8. Producing output with no decision state
  9. Producing output with no handoff destination
  10. Failing to log important work
  11. Failing to capture learning
  12. Automating workflows before manual proof
  13. Sending vague developer instructions to M
  14. Filling dashboards with unvalidated output
  15. Treating activity as business progress

Any serious AI workflow that does not pass this checklist should remain manual, draft, parked, or under review.

Architectural Intent

The architectural intent of the MWMS AI Workflow Pipeline Checklist is to make AI work repeatable, controllable, and improvable.

MWMS is not building random AI outputs.

MWMS is building governed AI workflows.

This checklist ensures that important AI work moves through a controlled path:

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

The long-term goal is that every serious MWMS AI workflow can answer:

  • What entered the system?
  • Was it clean enough?
  • What type of work is it?
  • Which Brain owns it?
  • Which AI Employee performs it?
  • What context is required?
  • What output is expected?
  • How is it validated?
  • What decision was made?
  • Where does it go?
  • What is logged?
  • What does MWMS learn?

When MWMS can answer those questions consistently, AI workflows become reliable operating assets.

Change Log

v1.0 — Initial Draft

Created the MWMS AI Workflow Pipeline Checklist as the practical operational checklist for designing, reviewing, and validating AI workflows across MWMS.

This checklist operationalizes the MWMS AI Workflow Pipeline Standard and supports Course Absorption, Newsletter Intelligence, Brain Room, Offer Evaluation, Research, Finance, Experimentation, Developer Support, MCR page creation, HeadOffice reporting, and future AIBS client workflows.