MWMS AI Workflow Pipeline Standard

System: MWMS
Document Type: Operating Standard
Authority Level: MCR Source Of Truth
Status: Active
Version: v1.1
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, MWMS Brain, Brain Room, AI Manager, AI Employee Router, Task Executor Systems, Automation Brain, AIBS Brain
Parent Page: HeadOffice
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR
Last Reviewed: 2026-06-17
Source / Origin: MWMS AI Workflow Pipeline Standard v1.0 + AI Automations by Jack — ClaudeOS, Multi-Model Routing, Persistent Agents, Independent Review, Rescue Routing, External Knowledge And Session Closure Block
MWMS Classification: AI Workflow Governance Standard / Agentic Pipeline Design Standard / AI Operating System Execution Framework / Persistent Workflow Control Standard
Primary Brain: HeadOffice Brain
Supporting Brains: MWMS Brain, Automation Brain, AIBS Brain, Operations Brain, Data Brain, Risk Brain, Compliance Brain, SIT Brain
Related Pages: MWMS AI Agent Operations Core, MWMS Agentic Work Unit Standard, MWMS AI Employee Role Card Standard, MWMS AI Agent Orchestration Framework, MWMS AI Agent Failure Handling And Escalation Protocol, MWMS Independent Model Review And Rescue Routing Framework, MWMS AI Agent Memory And Context Framework, MWMS External Knowledge Engine And Reasoning Agent Separation Framework, MWMS AI Work Session Closure And Knowledge Commitment Protocol, MWMS AI Tool Permission And Access Framework, MWMS AI Observability Metadata Standard, MWMS AI Usage And Cost Visibility Standard, MWMS Brain Routing Rule, MWMS Brain To Brain Request Protocol, MWMS Supabase Event Schema
Source Evidence: The existing MWMS AI Workflow Pipeline Standard defines the default pipeline for moving AI work through input capture, cleaning, classification, task creation, AI Employee assignment, context attachment, processing, validation, decision, routing, logging and learning. The newly absorbed AI Automations by Jack block strengthens this pipeline with model and capability routing, agent-pattern selection, independent review, deterministic failure thresholds, rescue routing, external knowledge retrieval, persistent and scheduled execution, remote-command control, cost boundaries, observability, outcome verification, session closure and durable knowledge commitment.

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, observable and recoverable 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.

It is not suitable as the operating model for serious MWMS workflows such as:

offer evaluation
newsletter intelligence
course absorption
Brain Room task routing
finance analysis
research synthesis
content operations
experimentation
compliance review
security review
developer support
persistent monitoring
client-facing AI business systems
remotely triggered workflows
multi-agent 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 AI Employees
tool use
external knowledge retrieval
persistent execution
meaningful risk
external action
client impact
business consequences

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
Automation Brain workflows
Risk Brain workflows
Compliance Brain workflows
SIT Brain workflows
Dev Console support workflows
Supabase task and event workflows
MCR page creation workflows
background workers
scheduled routines
persistent AI Employees
remote-command workflows
external knowledge workflows
future AIBS client systems

This standard applies to:

manual workflows
AI-assisted workflows
semi-automated workflows
controlled automated workflows
multi-agent workflows
persistent workflows
remotely triggered workflows
client-facing workflows

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

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

Automated workflows may be performed by:

AI Employees
APIs
Make
n8n
Supabase
WordPress plugins
MCP services
local tools
hosted agents
background workers
scheduled systems
future MWMS automation infrastructure

Core Definition

An AI Workflow Pipeline is a structured sequence of stages that converts input into a validated, routed, outcome-linked and recorded business result.

A pipeline defines:

what enters the workflow
who or what triggered it
how the input is cleaned
how the request is classified
which Brain owns the work
which agent pattern is used
which AI Employee performs each stage
which model or capability route is used
what context is required
whether external knowledge retrieval is needed
what tools may be used
what output must be produced
how the output is validated
whether independent review is required
what happens after repeated failure
where the result is routed
what business outcome is expected
what gets logged
what knowledge is committed
how the workflow closes
how the workflow can be stopped

A pipeline is not merely automation.

A pipeline is a governed process.

Automation executes steps.

A pipeline defines the correct:

order
ownership
role
context
permissions
checks
decision gates
failure routes
destinations
closure

Core Principle

The core principle of this standard is:

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

MWMS should avoid asking one AI prompt or AI Employee to perform too many unrelated roles at once.

A single AI prompt should not be expected to:

understand the source
clean the input
classify the request
retrieve context
select a model
analyse the material
make a decision
validate itself
independently review itself
route the result
perform external action
update the system
log the outcome
commit knowledge
close the session

That creates weak, inconsistent and risky output.

MWMS pipelines must separate these jobs into clear stages.

Pipeline Simplicity Rule

Not every task requires a large pipeline.

MWMS must use the simplest pipeline that reliably produces the required business outcome.

A pipeline should become more complex only when complexity is justified by:

risk
workflow scale
specialist requirements
multi-Brain ownership
validation needs
persistent execution
client impact
external action
business value

Rule

Pipeline stages must earn their place.

More stages are not automatically better.

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
unsuitable model selection
poor validation
self-approval
duplicated work
uncontrolled retries
unlogged actions
dashboard noise
automation drift
unreliable AI Employees
persistent-agent failure
rising cost
knowledge loss
false completion

With pipelines, MWMS gains:

repeatable execution
clear ownership
better quality assurance
stronger quality control
independent review
safer automation
easier debugging
failure recovery
better reporting
stronger observability
cleaner handoffs
verified outcomes
durable learning
controlled shutdown

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

Default MWMS AI Workflow Pipeline

The default MWMS AI Workflow Pipeline contains twenty stages.

Trigger Capture
Input Capture
Input Cleaning
Classification
Brain Ownership
Risk Classification
Agent Pattern Selection
Task Creation
AI Employee Assignment
Context Attachment
Model Or Capability Routing
Tool Permission Gate
Processing
Synthesis Where Required
Validation
Independent Review Where Required
Decision
Routing And Execution
Logging And Outcome Verification
Knowledge Commitment And Closure

Not every workflow requires every stage.

High-value, high-risk, cross-Brain, persistent or client-facing workflows must not skip critical stages without an explicit reason.

Trigger Capture

Trigger Capture identifies how the workflow began.

Possible triggers include:

user instruction
Brain Room message
scheduled task
webhook
system event
monitoring alert
incoming email
uploaded file
failed validation
repeated failure
remote command
client request
database change
external knowledge signal

Trigger Capture should record:

trigger type
initiating source
sender identity
source channel
timestamp
related task or thread
authentication status
initial requested action

Trigger Rule

A trigger begins classification.

It does not automatically authorise action.

A remote message, webhook or schedule must still pass normal governance.

Input Capture

Input Capture preserves the raw material entering the workflow.

Inputs may include:

user instruction
Brain Room message
newsletter
email
course file
transcript
PDF
sales page
affiliate offer
campaign data
database row
WordPress page
automation output
Google Sheet data
research source
screenshot
developer note
client request
system log
error output

Input Capture should preserve:

source identity
source location
source date
source version
client ownership
original content
provenance
authority level where known

Input Capture Rule

MWMS must know what entered the system before it processes it.

Input Cleaning

Input Cleaning removes noise and prepares the source for analysis.

Cleaning may include:

removing duplicated content
removing newsletter footers
removing tracking clutter
removing HTML noise
correcting broken formatting
extracting readable text
separating useful material from filler
standardising dates and fields
splitting large documents
preserving headings
preserving source metadata
normalising structured data
redacting unnecessary sensitive information

Input Cleaning is especially important for:

newsletters
course transcripts
copied website text
sales pages
scraped content
PDFs
long emails
spreadsheets
AI-generated drafts
logs
multi-source records

Input Cleaning Rule

Dirty input creates dirty intelligence.

MWMS must not trust analysis performed on incomplete, duplicated, corrupted or poorly structured input.

Classification

Classification identifies what kind of work is required.

Classification should determine:

request type
topic
workflow type
source type
urgency
priority
risk
likely Owning Brain
Supporting Brains
likely AI Employee
human-review requirement
output type
tool requirement
external-knowledge requirement
persistent-operation requirement

Common 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
security review
monitoring
rescue
session closure
client workflow

Classification Rule

MWMS must classify work before assigning work.

Bad classification creates bad routing.

Bad routing creates weak outcomes.

Brain Ownership

Brain Ownership determines:

Originating Brain
Owning Brain
Supporting Brains
final decision authority
escalation authority

The Owning Brain is responsible for:

workflow selection
Employee assignment
output requirements
validation
decision
routing
outcome
closure

Brain Ownership Rule

Every important pipeline must have one primary Owning Brain.

Supporting Brains may contribute.

Shared support is acceptable.

Unclear ownership is not.

Risk Classification

Risk Classification determines potential damage if the workflow is wrong.

Recommended levels:

Low

Examples:

internal brainstorming
low-risk notes
non-canonical drafts

Moderate

Examples:

internal reports
page drafts
research summaries
task creation

High

Examples:

offer decisions
finance recommendations
developer instructions
client-facing drafts
public content
compliance review

Critical

Examples:

live system changes
financial transactions
production deployments
destructive actions
highly sensitive data
legal or regulated external communication

Risk Classification should determine:

validation strength
independent review
human review
tool permissions
logging
observability
rescue path
rollback
shutdown requirement

Risk Rule

The higher the risk, the stronger the control requirements.

Agent Pattern Selection

Agent Pattern Selection determines how the work will be performed.

Approved patterns include:

Single Agent
Agent Plus Checker
Router Plus Specialist
Research Plus Synthesis
Multi-Specialist Plus Synthesis Plus Checker
Master Agent Plus Sub-Workflows
Primary Agent Plus Independent Reviewer
Primary Agent Plus Rescue Route

Selection should consider:

complexity
risk
number of Brains
need for specialist evidence
need for independent review
cost
expected value
workflow maturity

Agent Pattern Rule

Use the simplest pattern that reliably produces the required outcome.

Do not create multi-agent complexity for appearance.

Task Creation

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

The task should define:

Work Unit ID
title
type
trigger
request source
source material
Originating Brain
Owning Brain
Supporting Brains
Assigned AI Employee
agent pattern
model route
input
context
output
permissions
forbidden actions
validation
review
failure threshold
rescue route
handoff
outcome
logging
knowledge commitment
closure

Task Creation Rule

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

AI Employee Assignment

AI Employee Assignment determines which role performs each stage.

Assignment should be based on:

Owning Brain
role-card fit
authority
task type
required skill
model capability
tool permissions
risk
output type
review requirement
persistent-operation status

Examples:

Newsletter Signal Extraction Agent
Course Absorption Agent
Offer Evaluation Agent
Research Evidence Collection Agent
Finance Break-Even Analysis Agent
HeadOffice Validation Agent
Independent Model Review Agent
Workflow Rescue Agent
Brain Room Task Builder Agent
Persistent System Monitoring Agent
Knowledge Retrieval Agent

AI Employee Assignment Rule

Assign work to a governed role, not to generic AI.

Context Attachment

Context Attachment provides the selected information required for correct work.

Context may include:

MCR standards
Brain rules
current save point
developer boundary
source-of-truth location
naming rules
document standards
course absorption rules
offer protocols
newsletter protocols
active build restrictions
previous decisions
risk rules
user preferences
workflow state
failure history
client context
role card
tool permissions
current evidence

Context Attachment should distinguish:

current evidence
source material
source of truth
project memory
retrieved context
stale context
prohibited context
sensitive context

Context Rule

AI Employees should not perform meaningful MWMS work without the required context.

Use the right context for the task, not all available memory.

Model Or Capability Routing

Model Or Capability Routing determines which model, system or processing route should handle each stage.

Possible routes include:

advanced reasoning model
long-context model
multimodal model
coding model
research model
low-cost bulk processor
local private model
deterministic validator
external knowledge engine
independent reviewer
rescue model

Routing should consider:

task complexity
modality
context length
privacy
cost
tool compatibility
reliability
reviewer independence
latency
risk

Model Routing Rule

The most expensive model is not always required.

The cheapest model is not always acceptable.

The same model should not automatically be the sole producer and final reviewer of high-risk work.

Tool Permission Gate

The Tool Permission Gate confirms what systems the assigned AI Employee may access.

Possible permissions include:

no external tools
uploaded files only
MCR read
web research
database read
controlled database write
WordPress read
WordPress controlled write
Gmail draft
Gmail send with approval
browser automation
MCP function
local CLI
external knowledge retrieval
file generation
monitoring access

The Tool Permission Gate must check:

Employee Role Card
task authority
risk
client boundary
data sensitivity
approved endpoints
human approval
credential custody
logging
revocation

Tool Permission Rule

Tool availability does not create permission.

No pipeline should continue into tool use without a clear permission boundary.

Processing

Processing is where the assigned AI Employee performs the task.

Processing may include:

extracting insights
analysing source material
comparing options
retrieving evidence
drafting a page
evaluating an offer
identifying risk
generating structured output
preparing action
mapping to Brains
creating a handoff
monitoring system state

Processing must follow:

the Agentic Work Unit
the Role Card
the Context Pack
tool permissions
output requirements
stop conditions

Processing Rule

AI work must follow the task.

It must not wander beyond its role, scope or authority.

Synthesis Where Required

Synthesis combines outputs from multiple agents, Brains, tools or evidence sources.

Synthesis may include:

merging findings
removing duplication
reconciling conflict
organising sections
preserving warnings
identifying disagreement
preparing a final report
preparing an MCR-ready output
preparing a decision package

Synthesis is required where:

several specialists contribute
multiple models contribute
several Brains contribute
evidence and interpretation are separated
parallel work occurs

Synthesis Rule

Multi-agent output must not be handed forward as a pile of disconnected responses.

Validation

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

Validation may include:

completeness
source grounding
format
specificity
Brain routing
duplication
risk
compliance
security
naming
parent page
developer boundary
business usefulness
hallucination
actionability
context sufficiency
model suitability
tool-permission compliance
cost
outcome alignment

Validation may be performed by:

the producing Employee for low-risk checks
a separate Validation Agent
deterministic tests
SIT Brain
HeadOffice
Martyn
M
a human specialist

Validation Rule

AI output is not operational truth until it passes the required validation.

Independent Review Where Required

Independent Review is required when:

MCR may change
Canon may change
governance is affected
finance is involved
compliance is involved
security is involved
client delivery is involved
live systems are affected
external communication is involved
destructive action is possible
repeated failure occurred

Independent review may be performed by:

a different model family
a specialist AI Employee
another Brain
a deterministic validator
a human

Independent Review should assess:

evidence
assumptions
governance
risk
contradictions
missing context
unsupported conclusions
permission fit
outcome fit

Independent Review Rule

The producing route must not be the sole final reviewer of high-risk work.

Decision

Decision determines what happens after validation and review.

Possible decisions include:

accept
revise
reject
park
route
escalate
create task
create page
update existing page
update registry
send to dashboard
request more research
prepare developer brief
execute approved action
trigger rescue
mark complete
commit learning

Decision Rule

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

Routing And Execution

Routing sends the result to the correct destination.

Execution performs an approved action where authorised.

Possible destinations include:

HeadOffice Dashboard
Brain Room
Newsletter Queue Review
Routed Actions
MCR
Brain page
Supabase task table
Supabase event log
Google Sheet
Affiliate Brain
Research Brain
Experimentation Brain
Finance Brain
Content Brain
Ads Brain
Automation Brain
Risk Brain
Compliance Brain
SIT Brain
Human Review Queue
Parking System
archive
client delivery
developer handoff
external knowledge engine

Routing and Execution must remain separate where risk requires approval.

Examples:

draft email → approval → send
page draft → review → publish
database update proposal → approval → write
campaign recommendation → approval → launch

Routing Rule

Every important output must have a destination.

Execution must not occur merely because routing succeeded.

Logging And Outcome Verification

Logging records what happened.

A pipeline log may include:

trigger received
input captured
task created
Brain assigned
Employee assigned
agent pattern selected
model route selected
context attached
tool access activated
processing started
output generated
validation completed
review completed
failure recorded
rescue triggered
decision made
approval recorded
action executed
handoff completed
status changed
cost recorded
outcome verified

Outcome Verification confirms that the intended result actually occurred.

Possible proof includes:

published page
database record
successful test
accepted report
completed task
verified file
user confirmation
client acceptance
successful handoff
current system state

Logging Rule

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

Outcome Verification Rule

Prepared is not executed.

Executed is not verified.

Completed must be supported by evidence.

Knowledge Commitment And Closure

Knowledge Commitment determines what durable learning or state should be preserved.

Possible destinations include:

MWMS Blueprint
Brain Canon
MCR
Kaizen Log
System Change Log
Decision Record
Failure Record
Course Absorption Decision Registry
Newsletter Signal Log
Experimentation record
Research record
AI Employee Role Card
Tool Permission Record
project save point
external knowledge engine
session-history repository

Closure should record:

final status
outcome
verification
validation status
review status
human approval
handoff
knowledge committed
open issues
next action
closure owner
closure date

Knowledge Commitment Rule

Generating output and committing durable knowledge are separate actions.

Closure Rule

A pipeline is not complete merely because an AI response was produced.

Pipeline Types

MWMS may use different pipeline types depending on the task.

Simple Support Pipeline

Used for low-risk internal support.

Stages:

Input
Response
Optional Review

Examples:

explanation
brainstorm
internal note
low-risk rewrite
simple checklist

Rule

Do not over-engineer low-risk support.

Structured Drafting Pipeline

Used when AI prepares something for review.

Stages:

Trigger
Input Capture
Classification
Context Attachment
AI Employee Assignment
Processing
Validation
Human Review
Final Output
Closure

Examples:

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

Intelligence Extraction Pipeline

Used for converting messy information into useful intelligence.

Stages:

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

Examples:

newsletter intelligence
course absorption
market research
competitor analysis
tool evaluation

Decision Support Pipeline

Used for high-impact business decisions.

Stages:

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

Examples:

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

Cross-Brain Pipeline

Used when several Brains contribute.

Stages:

Input Capture
Owning Brain Classification
Supporting Brain Identification
Brain-to-Brain Request
Specialist Processing
Synthesis
Combined Validation
Independent Review Where Required
HeadOffice Decision
Routing
Logging
Learning

Examples:

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

Client-Facing AIBS Pipeline

Used for client AI systems.

Stages:

Client Process Intake
Workflow Mapping
Client Data Classification
Role Definition
Context Design
Tool Permission Design
AI Employee Assignment
Model Routing
Validation Gate Design
Human Approval Rules
Reporting Layer
Controlled Deployment
Monitoring
Logging
Kaizen
Offboarding

Rule

AIBS delivers governed AI workflow systems, not random automations.

Persistent Agent Pipeline

Used for scheduled or background AI Employees.

Stages:

Schedule Or Trigger
Authentication
Context Refresh
Permission Check
Cost Check
Processing
Validation
Alert Or Action
Logging
Outcome Verification
Failure Check
Shutdown Or Next Schedule

Persistent workflows must define:

owner
environment
frequency
runtime
cost limit
retry limit
rescue route
monitoring
shutdown
review date

Rule

Persistent pipelines require more governance than session-bound pipelines.

Rescue Pipeline

Used after the standard failure threshold.

Stages:

Failure Threshold Reached
Current Route Stopped
Failure History Preserved
Rescue Packet Created
Independent Diagnosis
Alternative Route Selected
Tool And Permission Recheck
New Verification Gate Defined
Rescue Attempt Performed
Result Validated
Continue, Escalate, Park Or Stop

Rule

A rescue pipeline must use a materially different approach.

External Knowledge Pipeline

Used when evidence must be retrieved from a large knowledge system.

Stages:

Query Definition
Source Scope
Client Filter
Authority Filter
Freshness Filter
Retrieval
Source Provenance Capture
Relevance Review
Context Injection
Reasoning
Validation
Decision
Knowledge Commitment Where Approved

Rule

Retrieval is not authority.

Retrieved evidence must remain traceable and governed.

Pipeline Examples

Example 1: Newsletter Intelligence Pipeline

Newsletter received

Trigger and source captured

Subject, sender, date, body and metadata preserved

Cleaning removes junk, tracking and repeated sections

Signal Extraction Agent extracts business-relevant intelligence

Brain Routing Agent identifies primary and supporting Brains

Action Classification Agent assigns ACT NOW, TEST, MONITOR, PARK or REJECT

Validation Agent checks usefulness, specificity and routing

Independent review occurs for high-impact signals

Output is stored in the approved internal system

Queue Review displays the item

HeadOffice reviews priority intelligence

Outcome is routed, parked, rejected or converted into action

Recurring patterns are committed to durable learning

Example 2: Course Absorption Pipeline

Course material uploaded

Trigger and source recorded

Course Intake Agent identifies file type, lesson and topic

Value Filter Agent determines whether material is worth absorbing

Framework Extraction Agent extracts reusable operational value

MWMS Mapping Agent maps material to existing Brains and pages

Duplication Check Agent searches current MCR

Upgrade Decision Agent decides update, create, park or ignore

Page Builder Agent prepares MCR-ready output where justified

Validation Agent checks source grounding, structure, parent page, naming and duplication

Independent review occurs for major governance updates

Martyn reviews before publication

Registry and Change Log requirements are identified

Exact save point and next course action are recorded

Example 3: Brain Room Pipeline

Brain Room message received

Sender and thread identity captured

Request classified

Owning Brain identified

Risk classified

Agentic Work Unit created

Agent pattern selected

AI Employee assigned

Context attached

Model route selected

Tool permissions checked

Work processed

Output synthesised where needed

Validation and review completed

Response returned to Brain Room

Follow-up action routed

Event logged

Session outcome committed

Example 4: Offer Evaluation Pipeline

Offer enters Affiliate Brain

Offer Intake Agent records core offer data

Research Agent gathers current evidence

Vendor Intelligence Agent checks credibility

Market Demand Agent evaluates demand

Funnel Analysis Agent checks mechanism and claims

Ads Brain checks platform fit

Compliance Brain checks risk

Finance Brain checks break-even logic

Experimentation Brain checks test suitability

Synthesis Agent prepares the full case

Independent Reviewer challenges assumptions

HeadOffice Verdict Agent prepares YES, Conditional YES or NO

Martyn approves or rejects

Offer is routed to test planning, research, parking or Offer Graveyard

Strategic learning is committed

Example 5: M Developer Support Pipeline

Development issue enters Brain Room or Dev Console

Request is classified as developer support

Exact site, page, plugin, file or system area is identified

Current visible evidence is attached

Current save point is verified

Developer boundary is checked

AI prepares exact instructions or complete file output

Validation checks:

current evidence
exact scope
file or screen location
insertion point
testing
rollback
what not to touch

Independent review is used where production risk is material

M receives a controlled implementation brief

Result is tested

Outcome is verified

Event and save point are updated

Rule

Memory alone is not enough for developer instructions.

Persistent Monitoring Pipeline

Schedule triggers the workflow

Sender and schedule identity are verified

Current monitoring context is refreshed

Read-only permissions are confirmed

Approved health checks run

Exceptions are classified by severity

Duplicate alerts are suppressed

Critical alerts receive independent review where possible

Notification is routed to the correct owner

Outcome is logged

Repeated monitoring failure triggers rescue

The workflow either closes or waits for the next approved schedule

External Knowledge Retrieval Pipeline

Task defines the question

Approved knowledge source is selected

Client and Brain filters are applied

Retrieval query is recorded

Relevant chunks are returned with provenance

Authority and freshness are checked

Weak or conflicting retrieval is flagged

Reasoning Agent interprets the evidence

Validation checks source support

Decision is made

Durable knowledge is committed only with approval

Pipeline Quality Checklist

Before a pipeline becomes operational, check:

Is the trigger clear?
Is the request source authenticated where required?
Is the input source clear?
Is source provenance preserved?
Is the workflow purpose clear?
Is the Owning Brain defined?
Are Supporting Brains justified?
Is risk classified?
Is the agent pattern appropriate?
Is the AI Employee assigned by role?
Is the model route appropriate?
Is required context attached?
Is external knowledge required?
Are tools and permissions clear?
Are credentials protected?
Are forbidden actions clear?
Is the output format defined?
Is synthesis required?
Is validation included?
Is independent review required?
Is the failure threshold defined?
Is the rescue route defined?
Is human review required?
Is the destination clear?
Is the business outcome clear?
Is outcome verification defined?
Is logging required?
Is observability sufficient?
Is cost controlled?
Is learning captured?
Is knowledge commitment defined?
Is closure defined?
Is shutdown possible?
Is the pipeline too complex for the value?
Is the pipeline safe for the current build stage?
Does it avoid M’s active work?
Can the process be repeated?
Can the workflow be audited?

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

Pipeline Failure Modes

MWMS must watch for the following pipeline failures.

Failure Mode 1 — Input Is Incomplete Or Dirty

Correction:

Stop and clean or request missing input.

Failure Mode 2 — Request Is Misclassified

Correction:

Reclassify before assignment.

Failure Mode 3 — Wrong Brain Owns The Work

Correction:

Apply Brain Routing Rule and transfer ownership.

Failure Mode 4 — Wrong AI Employee Is Assigned

Correction:

Check the Employee Role Card and reassign.

Failure Mode 5 — Agent Pattern Is Overbuilt

Correction:

Reduce to the simplest reliable pattern.

Failure Mode 6 — Agent Pattern Is Too Weak

Correction:

Add specialist, checker or independent review where justified.

Failure Mode 7 — Wrong Model Route

Correction:

Route by capability, risk, privacy, modality and cost.

Failure Mode 8 — Context Is Missing

Correction:

Pause and retrieve, ask or escalate.

Failure Mode 9 — Tool Permission Is Unclear

Correction:

Stop tool use until permission is defined.

Failure Mode 10 — Output Format Is Vague

Correction:

Define the required structure before processing continues.

Failure Mode 11 — Validation Is Skipped

Correction:

Do not route or execute the output.

Failure Mode 12 — AI Self-Approves High-Risk Work

Correction:

Route to independent review.

Failure Mode 13 — Human Review Is Removed Too Early

Correction:

Restore review until reliability is proven.

Failure Mode 14 — Output Has No Destination

Correction:

Park, reject or define the handoff.

Failure Mode 15 — Repeated Failure Loops

Correction:

Count failures and trigger rescue after two materially identical failures.

Failure Mode 16 — Rescue Repeats The Same Approach

Correction:

Assign a different model, specialist or deterministic route.

Failure Mode 17 — Logging Is Missing

Correction:

Pause scaling until events are recorded.

Failure Mode 18 — Outcome Is Claimed But Not Verified

Correction:

Check the actual system state or result.

Failure Mode 19 — Learning Is Not Captured

Correction:

Create the appropriate learning, failure or decision record.

Failure Mode 20 — Automation Is Added Too Early

Correction:

Return to the manual workflow until stages are stable.

Failure Mode 21 — Persistent Agent Has No Stop Control

Correction:

Disable until shutdown and revocation are defined.

Failure Mode 22 — Remote Command Bypasses Authority

Correction:

Authenticate, classify and apply normal approval gates.

Failure Mode 23 — Retrieval Is Treated As Authority

Correction:

Check source status, freshness, Brain ownership and evidence.

Failure Mode 24 — Pipeline Cost Exceeds Value

Correction:

Simplify, reroute or stop the workflow.

Failure Mode 25 — Client Context Leaks

Correction:

Stop the workflow, isolate data and escalate.

Any pipeline showing these failures should be reviewed before further execution or automation.

Failure Counter And Rescue Rule

The standard failure threshold is:

Two materially identical failures without verified progress.

At the threshold:

the current route stops
failure history is preserved
the Work Unit status becomes Rescue Required
a Rescue Packet is created
a materially different route is assigned
the next verification gate is defined

The failure count must not reset because:

wording changed
the same model started a new conversation
the same action was reformatted
confidence increased
the system claims it now understands

Rule

Persistence means continuing toward the outcome.

It does not mean endlessly repeating the same failed action.

Pipeline Automation Rule

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

A workflow should be automated only when:

the manual process is understood
stages are stable
ownership is clear
inputs are predictable enough
outputs are structured
validation exists
failure modes are known
rescue exists
human review is defined
logging exists
observability exists
cost is controlled
shutdown exists
business outcome is clear
automation reduces work without increasing unacceptable risk

The automation rule is:

Manual discipline first.

Automation second.

Persistent autonomy last.

Human Review Rule

Human review is required when a pipeline affects:

MCR
Canon
live WordPress systems
database writes
external communications
public content
paid traffic
financial decisions
compliance-sensitive output
security-sensitive output
client delivery
developer implementation
Brain architecture
permissions
production systems
destructive action

Human review may be reduced only after the workflow proves:

stable
measurable
observable
recoverable
low risk
consistently validated

Persistent Pipeline Rule

Persistent pipelines must define:

owner
environment
purpose
schedule or trigger
allowed tools
data boundary
cost limit
maximum runtime
retry limit
failure threshold
rescue route
monitoring
notification
review date
shutdown
revocation

Rule

Persistent operation increases governance requirements.

It does not reduce them.

Remote Command Pipeline Rule

Remote command pipelines must define:

approved channel
authenticated sender
permitted task types
prohibited actions
risk limit
approval gates
tool limits
external-action limits
logging
revocation
shutdown

Rule

Remote access is an interface.

It is not an authority override.

External Knowledge Pipeline Rule

Where a pipeline uses an external knowledge engine, it must define:

approved source
query
filters
authority
freshness
client boundary
provenance
retrieval failure behaviour
validation
commitment rules

Rule

The knowledge engine retrieves.

The reasoning agent interprets.

MCR and current governance remain authoritative.

Cost And Efficiency Rule

Every serious pipeline should consider:

model cost
number of agent calls
tool cost
runtime
expected business value
validation cost
maintenance cost
rescue cost

Use higher-cost models and deeper pipelines where:

risk is high
value is high
capability is required
independent review is required

Use lower-cost routes where:

work is repetitive
rules are stable
validation is strong
risk is low
output is structured

Rule

Cost reduction must not remove required control.

Observability Rule

MWMS should be able to see:

pipeline ID
current stage
current status
Owning Brain
Assigned Employee
model route
tools used
runtime
cost
failure count
last error
validation status
review status
approval status
destination
outcome
knowledge-commitment status
shutdown state

Rule

A pipeline that cannot be observed should not receive high authority.

Governance Role

HeadOffice owns the MWMS AI Workflow Pipeline Standard.

HeadOffice is responsible for:

approving high-impact pipelines
defining validation requirements
ensuring Brain ownership
governing model routing
governing independent review
enforcing failure thresholds
governing rescue routes
preventing unsafe automation
governing persistent pipelines
governing remote commands
ensuring outputs have destinations
ensuring outcomes are verified
ensuring learning is captured
ensuring cost is visible
protecting M’s active build areas
reviewing cross-Brain workflows
maintaining MCR as 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
role clarity
context
permissions
validation
failure handling
observability
HeadOffice visibility

Relationship To SIT Brain

SIT Brain may:

inspect pipeline completeness
validate Brain ownership
detect role mismatch
detect tool-permission drift
detect model-routing drift
verify independent review
enforce failure thresholds
trigger rescue
inspect persistent-agent controls
verify shutdown
inspect outcome evidence
detect false completion
block unsafe execution
inspect knowledge commitment

Relationship To Data Brain

Data Brain supports:

source capture
pipeline IDs
event records
input provenance
context storage
client isolation
observability metadata
status history
outcome records
knowledge commitment
archive
retention
retrieval

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 Agent Failure Handling And Escalation Protocol
MWMS Independent Model Review And Rescue Routing Framework
MWMS AI Agent Memory And Context Framework
MWMS External Knowledge Engine And Reasoning Agent Separation Framework
MWMS AI Work Session Closure And Knowledge Commitment Protocol
MWMS AI Tool Permission And Access Framework
MWMS AI Observability Metadata Standard
MWMS AI Usage And Cost Visibility 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
AIBS Brain Blueprint

Drift Protection

This standard protects MWMS from:

relying on one-shot prompts for complex work
treating AI responses as complete workflows
skipping input cleaning
skipping classification
assigning work without ownership
assigning generic AI instead of governed roles
using unsuitable models
using tools without permission
processing without context
producing output without validation
allowing self-review of high-risk work
repeating failed actions
missing rescue routes
output with no destination
automation before workflow stability
unreviewed dashboard output
lost task history
unverified outcomes
lost learning
brittle automations
unnecessary pipeline complexity
unmanaged persistent agents
remote commands bypassing authority
external retrieval overriding governance
uncontrolled cost
client-data leakage
AI speed being mistaken for operational maturity

Any workflow that violates this standard should be:

simplified
paused
reviewed
rescued
or redesigned

Pipeline Drift Signals

MWMS should watch for:

trigger is unknown
sender identity is missing
source is untraceable
input is dirty
classification is vague
Owning Brain is unclear
agent pattern is unjustified
Assigned Employee has no Role Card
model route is arbitrary
context is incomplete
tool permissions are undefined
output format is unclear
validation is missing
independent review is missing
failure count is not tracked
rescue is not triggered
output has no destination
status does not reflect reality
action is executed without approval
outcome is not verified
cost cannot be seen
persistent workflow has no owner
shutdown is missing
remote command has no authenticated source
knowledge is committed without approval
workflow closes without a save point or next action

Rule

Pipeline drift must be corrected before automation or authority increases.

Minimum Compliance Standard

A serious MWMS pipeline is compliant only when it defines:

trigger
request source
source material
input cleaning
classification
Owning Brain
Supporting Brains where required
risk
agent pattern
Agentic Work Unit
Assigned AI Employee
model route
context
external knowledge requirement
tool permissions
forbidden actions
output format
synthesis where required
validation
independent review where required
failure threshold
rescue route
decision
routing
human review
approval
logging
observability
cost
business outcome
outcome verification
knowledge commitment
closure
shutdown where relevant

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
many AI Employees
many models
many workflows
dashboards
task systems
client systems
persistent agents
external knowledge systems
automation layers
remote command channels
reporting systems

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:

Trigger
→ Input Capture
→ Cleaning
→ Classification
→ Brain Ownership
→ Risk
→ Agent Pattern
→ Task
→ Employee
→ Context
→ Model Route
→ Tool Permission
→ Processing
→ Synthesis
→ Validation
→ Independent Review
→ Decision
→ Routing And Execution
→ Logging And Outcome Verification
→ Knowledge Commitment And Closure

A mature MWMS pipeline should always be able to answer:

What triggered the work?
Who requested it?
What entered the system?
Was the input clean?
What type of work was it?
Which Brain owned it?
What risk applied?
Which agent pattern was used?
Which AI Employee performed it?
Which model or capability route was used?
What context was supplied?
What tools were allowed?
What output was required?
Was synthesis needed?
Was the output validated?
Was independent review required?
What happened after failure?
What decision was made?
Where did the result go?
Was the outcome verified?
What was logged?
What did it cost?
What did MWMS learn?
What knowledge was committed?
How did the workflow close?
How could the workflow be stopped?

When MWMS can answer those questions consistently, AI work becomes:

manageable
auditable
recoverable
improvable
governable
valuable

Strategic Summary

The v1.1 upgrade expands the MWMS AI Workflow Pipeline Standard from a twelve-stage workflow structure into a complete AI operations pipeline.

The upgraded standard now governs:

trigger identity
source provenance
Brain ownership
risk
agent-pattern selection
model and capability routing
tool-permission gates
synthesis
independent review
deterministic failure thresholds
rescue routing
persistent execution
remote commands
external knowledge
cost
observability
outcome verification
durable knowledge commitment
closure
shutdown

The key shift is:

A pipeline is not complete because a model produced output.

A pipeline is complete only when the work is:

correctly triggered
classified
owned
assigned
contextualised
permissioned
processed
validated
reviewed where required
routed
outcome-linked
verified
logged
learned from
closed

Final Rule

Complex AI work must be decomposed into governed pipeline stages before it becomes operational work.

No classification, no assignment.

No owner, no accountability.

No context, no reliable processing.

No permission, no tool use.

No validation, no trust.

No independent review, no high-risk approval.

No failure threshold, no controlled retry.

No rescue route, no resilient automation.

No destination, no completion.

No outcome verification, no progress claim.

No logging, no auditability.

No knowledge commitment, no continuity.

No closure, no finished workflow.

Change Log

Version: v1.1
Date: 2026-06-17
Author: HeadOffice

Change:

Updated the MWMS AI Workflow Pipeline Standard using the AI Automations by Jack block covering ClaudeOS, multi-model orchestration, independent model review, rescue routing, persistent agents, scheduled routines, remote command channels, external knowledge engines, operational monitoring, cost visibility and session closure.

Expanded the default pipeline from twelve stages to twenty stages.

Added:

Trigger Capture
Brain Ownership
Risk Classification
Agent Pattern Selection
Model Or Capability Routing
Tool Permission Gate
Synthesis Where Required
Independent Review Where Required
Routing And Execution
Logging And Outcome Verification
Knowledge Commitment And Closure

Added Pipeline Simplicity Rule.

Added Persistent Agent Pipeline.

Added Rescue Pipeline.

Added External Knowledge Pipeline.

Added Failure Counter And Rescue Rule.

Added Persistent Pipeline Rule.

Added Remote Command Pipeline Rule.

Added External Knowledge Pipeline Rule.

Added Cost And Efficiency Rule.

Added Observability Rule.

Expanded the Pipeline Quality Checklist.

Expanded Pipeline Failure Modes.

Added examples for:

Persistent Monitoring Pipeline
External Knowledge Retrieval Pipeline

Expanded examples for:

Newsletter Intelligence
Course Absorption
Brain Room
Offer Evaluation
M Developer Support

Added Relationship To SIT Brain.

Added Relationship To Data Brain.

Expanded Governance Role, Drift Protection, Pipeline Drift Signals, Minimum Compliance Standard, Architectural Intent, Strategic Summary and Final Rule.

Aligned this update with:

MWMS AI Agent Operations Core
MWMS Agentic Work Unit Standard
MWMS AI Employee Role Card Standard
MWMS AI Agent Orchestration Framework
MWMS AI Agent Failure Handling And Escalation Protocol
MWMS Independent Model Review And Rescue Routing Framework
MWMS AI Agent Memory And Context Framework
MWMS External Knowledge Engine And Reasoning Agent Separation Framework
MWMS AI Work Session Closure And Knowledge Commitment Protocol
MWMS AI Tool Permission And Access Framework
MWMS AI Observability Metadata Standard
MWMS AI Usage And Cost Visibility Standard

Purpose of update:

To evolve the MWMS AI Workflow Pipeline Standard from a general multi-stage AI process into the complete governed execution path for session-bound, multi-agent, persistent, remotely triggered, independently reviewed, failure-resilient, observable and outcome-verified AI work across MWMS and future AIBS client systems.

Version: v1.0
Date: Initial Draft
Author: HeadOffice

Change:

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

The initial standard defined:

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

Change Impact Declaration

This v1.1 update expands the AI Workflow Pipeline Standard from a twelve-stage process into a complete execution, validation, rescue, observability, outcome-verification and knowledge-commitment framework.

Pages Created

None

Pages Updated

MWMS AI Workflow Pipeline Standard

Pages Deprecated

None

Standalone Pages Not Created

MWMS ClaudeOS Workflow Pipeline
MWMS Persistent Agent Pipeline Standard
MWMS Multi-Model Workflow Standard
MWMS Rescue Pipeline Standard
MWMS Remote Command Pipeline Standard
MWMS External Knowledge Retrieval Pipeline
MWMS Session Closure Pipeline
MWMS Background Worker Pipeline Standard

Registries Requiring Update

HeadOffice Page Registry
MWMS Canon Index
MWMS Course Absorption Decision Registry

Canon Version Update Required

Change Log Entry Required

Strategic Absorption Result

MWMS gains a stronger pipeline standard governing the full lifecycle of complex AI work from trigger, source capture and classification through Brain ownership, agent-pattern selection, model routing, tool permission, processing, synthesis, validation, independent review, deterministic rescue, routing, outcome verification, durable learning and final closure.

END OF FULL FILE OUTPUT