System: MWMS
Document Type: 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 Agent Deployment Readiness Checklist.

This checklist determines whether an AI Employee, AI workflow, agentic process, Brain automation, reporting workflow, task workflow, or future client-facing AI system is ready to move from concept into controlled operation.

MWMS must not deploy AI Employees or workflows simply because the idea sounds useful.

Before an AI Employee or workflow becomes operational, it must be checked for:

role clarity
task clarity
Brain ownership
workflow structure
input quality
output quality
validation rules
handoff rules
failure handling
escalation path
tool permissions
human review requirements
logging
outcome measurement
developer boundary safety
HeadOffice visibility

This checklist exists to prevent immature AI workflows from entering live operations too early.

Scope

This checklist applies before deploying or activating any meaningful AI Employee, AI workflow, automation, agentic system, or client-facing AI process inside MWMS.

This includes deployment into:

HeadOffice Brain
Brain Room
AI Manager
AI Employee Router
Task Executor systems
Dev Console
Newsletter Intelligence
Course Absorption workflows
Opportunity System workflows
Affiliate Brain
Research Brain
Experimentation Brain
Finance Brain
Content Brain
Ads Brain
AI Business Systems Brain
Supabase task systems
WordPress plugin systems
Make.com or n8n workflows
future AIBS client systems

This checklist applies to manual, assisted, semi-automated, and automated deployments.

A manual AI workflow may still need deployment readiness if it becomes a repeatable MWMS process.

An automated workflow must always pass readiness checks before it is trusted.

Core Definition

AI Agent Deployment Readiness means the AI Employee or workflow is sufficiently defined, governed, tested, validated, and controlled to operate safely within its intended scope.

Deployment does not always mean fully automated.

Deployment may mean:

approved for manual use
approved for assisted use
approved for draft generation
approved for queue processing
approved for dashboard display
approved for controlled automation
approved for supervised client use
approved for future technical build

An AI workflow may be useful but not ready.

A workflow is ready only when its operating boundaries are clear.

Core Principle

The core principle of this checklist is:

No AI Employee or agentic workflow should become operational until it can be assigned, validated, handed off, measured, and safely stopped if it fails.

This protects MWMS from:

premature automation
vague AI Employees
weak task design
unvalidated outputs
unsafe tool access
poor handoffs
dashboard noise
duplicate work
developer confusion
live-system risk
client-facing risk
false confidence

Deployment readiness is the gate between good idea and safe operation.

Deployment Readiness Levels

MWMS should classify readiness into five levels.

Level 0 — Concept Only

The AI Employee or workflow is only an idea.

It may have potential, but it is not ready for use.

Allowed activity:

brainstorm
outline
park for later
compare with existing system
decide whether it is worth developing

Not allowed:

live use
automation
task assignment
dashboard use
client use
M implementation request

Level 1 — Draft Ready

The AI Employee or workflow has enough structure to be drafted manually.

Allowed activity:

create role card draft
create workflow draft
create sample output
test manually with low-risk input
review with HeadOffice

Not allowed:

automated execution
unsupervised use
live system changes
client-facing use
high-risk decision support

Level 2 — Manual Operation Ready

The AI Employee or workflow can be used manually with human supervision.

Allowed activity:

manual processing
human-reviewed outputs
draft reports
queue review
MCR page drafts
controlled internal use

Requirements:

role defined
workflow defined
output format defined
human review required
failure handling known

Not allowed:

autonomous execution
direct live system changes
external action without approval

Level 3 — Assisted Automation Ready

The workflow can be partially automated, but human review remains required before important action.

Allowed activity:

structured intake
automated extraction
draft task creation
queue item generation
dashboard candidate creation
AI-assisted routing
validation-assisted outputs

Requirements:

stable inputs
clear output format
validation checklist
logging
escalation path
human review gate

Not allowed:

high-risk autonomous action
live irreversible changes
client-facing final outputs without review

Level 4 — Controlled Automation Ready

The workflow can operate automatically inside approved boundaries.

Allowed activity:

repeatable low-to-medium risk automation
automated classification
automated routing to review queue
automated status updates
automated internal reports
automated logging

Requirements:

proven manual workflow
predictable input
stable output
validation rule
failure handling
logging
human review for exceptions
HeadOffice visibility

Not allowed:

critical-risk autonomous action
financial approval
paid traffic launch
legal/compliance-sensitive final action
live system changes without explicit approval

Level 5 — Restricted Autonomous Operation Ready

The workflow can operate without immediate human review only inside tightly controlled low-risk boundaries.

Allowed activity:

formatting
tagging
low-risk classification
internal cleanup
routine status updates
non-public draft preparation
repeated validated transformations

Requirements:

very stable workflow
low risk
strong logs
known failure modes
stop condition
escalation path
periodic review
HeadOffice awareness

This level should be rare.

MWMS should prefer controlled automation with review gates until workflows have proven reliability.

Deployment Readiness Checklist

Before deployment, check each section.

1. Purpose Readiness

The AI Employee or workflow must have a clear purpose.

Check:

What problem does it solve?
Which workflow does it improve?
Which Brain benefits?
What manual work does it reduce?
What decision does it support?
What risk does it reduce?
What business outcome does it create?

Pass condition:

The purpose is specific and connected to MWMS value.

Fail condition:

The role sounds interesting but does not clearly improve the system.

2. Brain Ownership Readiness

The owning Brain must be clear.

Check:

Which Brain owns this AI Employee or workflow?
Which Brains support it?
Does HeadOffice need visibility?
Is it cross-Brain?
Is it MCR governance or operational Brain work?
Is ownership documented?

Pass condition:

One primary owning Brain is identified.

Fail condition:

Several Brains could own it but none are clearly responsible.

3. Role Card Readiness

Every formal AI Employee must have a role card.

Check:

Employee Name defined
Owning Brain defined
Authority Level defined
Purpose defined
Primary Responsibilities defined
Non Responsibilities defined
Input Types defined
Required Context defined
Output Types defined
Approved Tools defined
Forbidden Actions defined
Handoff Destinations defined
Escalation Rules defined
Validation Rules defined
Success Metrics defined
Failure Modes defined
Logging Requirement defined

Pass condition:

The AI Employee has a complete enough role card for its risk level.

Fail condition:

The AI Employee is only a name or vague idea.

4. Work Unit Readiness

The workflow must be able to create or use Agentic Work Units.

Check:

task title can be defined
task type can be defined
source can be captured
owning Brain can be assigned
AI Employee can be assigned
input payload can be attached
context pack can be attached
task instruction can be written
output format can be defined
validation standard can be selected
handoff destination can be identified
business outcome can be stated
priority and risk can be assigned

Pass condition:

The work can be represented as a structured Agentic Work Unit.

Fail condition:

The workflow relies on vague prompts or undocumented instructions.

5. Input Readiness

The workflow must have usable inputs.

Check:

input source is known
input format is predictable enough
required fields are defined
missing input can be detected
messy input can be normalized
source is preserved
source completeness can be checked
input risk is understood

Pass condition:

Inputs are clean enough or normalization exists.

Fail condition:

AI is expected to analyze noisy, incomplete, or unpredictable input without controls.

6. Pipeline Readiness

The workflow must have a defined process.

Check:

input capture stage exists
cleaning or normalization stage exists where needed
classification stage exists
task creation stage exists where needed
AI Employee assignment stage exists
processing stage is clear
validation stage exists
decision state exists
routing stage exists
logging stage exists
learning update exists where required

Pass condition:

The workflow has a clear sequence from input to outcome.

Fail condition:

One AI prompt is expected to handle the whole workflow without structure.

7. Context Readiness

The AI Employee must receive the right context.

Check:

relevant Brain rules are available
related standards are known
current save point is known if development-related
developer boundary is known
user preference is known where relevant
page naming and document structure rules are known where relevant
source of truth is identified
previous decisions are attached where needed

Pass condition:

The AI Employee has enough context to avoid isolated output.

Fail condition:

The workflow depends on the AI guessing MWMS context.

8. Tool Permission Readiness

Tool access must be clearly defined.

Check:

approved tools are listed
forbidden tools/actions are listed
tool access matches authority level
live system access is restricted
database writes require approval
email sending requires approval
WordPress changes require approval
external action boundaries are clear
current data access is verified if claimed

Pass condition:

Tool access is explicit and safe.

Fail condition:

The AI Employee assumes it can use tools or take actions without permission boundaries.

9. Output Readiness

The required output must be defined.

Check:

output type is known
output format is known
report structure is known
required fields are known
dashboard format is known where relevant
full page output is required where relevant
developer instruction format is known where relevant
client report format is known where relevant

Pass condition:

The AI Employee knows what to produce before work begins.

Fail condition:

The AI Employee can produce any style of output it chooses.

10. Validation Readiness

The workflow must include validation.

Check:

validation level is defined
validation checklist exists
validation owner is defined
human review rule is defined
source grounding check exists where needed
Brain routing check exists
risk check exists
output format check exists
duplication check exists where relevant
developer boundary check exists where relevant
compliance check exists where relevant

Pass condition:

Output can be checked before being trusted.

Fail condition:

Output becomes operational just because AI generated it.

11. Handoff Readiness

The workflow must define where outputs go next.

Check:

handoff destination is known
receiving Brain or role is known
required next action is known
validation status travels with output
risk level travels with output
source context travels with output
unresolved issues are passed forward
receiving party can act without guessing

Pass condition:

Handoffs preserve context and next action.

Fail condition:

Outputs float in space or are passed without enough context.

12. Failure Handling Readiness

The workflow must know what happens when something goes wrong.

Check:

likely failure modes are listed
severity levels are known
stop condition exists
escalation path exists
revision path exists
reroute path exists
reject/park option exists
failure logging exists where needed
Kaizen learning path exists

Pass condition:

The workflow can fail safely.

Fail condition:

Failure creates confusion, hidden errors, or unsafe continuation.

13. Escalation Readiness

Escalation rules must be clear.

Check:

when to escalate to Martyn
when to escalate to HeadOffice
when to escalate to M
when to escalate to Research Brain
when to escalate to Finance Brain
when to escalate to Compliance or Risk Review
when to request human review
when to stop automation

Pass condition:

High-risk or uncertain work has a clear escalation route.

Fail condition:

AI continues beyond its authority because escalation is undefined.

14. Logging Readiness

Important work must be logged.

Check:

task log exists where needed
event log exists where needed
handoff log exists where needed
validation result can be recorded
failure can be recorded
outcome can be recorded
learning can be recorded
status can be updated

Pass condition:

The workflow leaves an audit trail.

Fail condition:

Important work happens but cannot be reviewed later.

15. Outcome Measurement Readiness

The workflow must define what success means.

Check:

expected outcome is defined
outcome category is known
outcome state can be recorded
success metric exists
failure metric exists
quality metric exists
business value can be judged
workflow can be reviewed later

Pass condition:

MWMS can tell whether the workflow was useful.

Fail condition:

Workflow produces output but no measurable outcome.

16. Human Review Readiness

Human review rules must be clear.

Human review is required when the workflow affects:

MCR canon
Brain architecture
developer implementation
M’s active build areas
live WordPress systems
Supabase writes
external emails
paid traffic decisions
financial decisions
compliance-sensitive outputs
public content
client-facing reports
high-risk automation

Pass condition:

Human review is required where risk demands it.

Fail condition:

High-risk work can proceed without review.

17. Developer Boundary Readiness

The workflow must not interfere with M’s active build unless specifically assigned.

Check:

does it touch Brain Room systems?
does it touch executor hooks?
does it touch Opportunity system wiring?
does it touch Affiliate workflow systems?
does it touch HeadOffice reporting build?
does it touch live plugin files?
does it create instructions for M?
does it require exact file paths or screenshots?
is the current save point known?

Pass condition:

Developer boundary is clear and safe.

Fail condition:

The workflow creates build risk or vague instructions.

18. Dashboard Readiness

If the workflow outputs to a dashboard, dashboard standards must be met.

Check:

dashboard item is specific
action type is clear
priority is believable
urgency is believable
owning Brain is clear
owner is clear where relevant
status is clear
source is clear
next action is clear
item is not noise

Pass condition:

Dashboard output is command-ready.

Fail condition:

Dashboard output is vague or clutter.

19. Automation Readiness

Automation should only happen after manual workflow quality is proven.

Check:

manual workflow has been tested
input pattern is predictable
output structure is stable
validation rules exist
failure modes are known
logs exist
human review gates exist
stop conditions exist
rollback/correction path exists where needed
business value is proven

Pass condition:

Automation reduces work without increasing risk.

Fail condition:

Automation is being added because it is exciting, not because the workflow is ready.

20. Client Readiness

For future AIBS client systems, extra checks are required.

Check:

client input is normalized
client output is plain-language
approval gates exist
risk notes are included
human review is defined
business value is clear
client can understand next action
no unsupported claims are made
logging and accountability exist
workflow can be explained simply

Pass condition:

Client-facing AI workflow is useful, safe, and understandable.

Fail condition:

Client receives confusing or overconfident AI output.

Deployment Verdicts

After the checklist is completed, assign one verdict.

Not Ready

The AI Employee or workflow is still only a concept.

Use when:

purpose is vague
role card missing
workflow unclear
validation missing
risk too high
no outcome defined

Decision:

Do not deploy.

Draft Only

The workflow may be drafted but not used operationally.

Use when:

idea is useful
structure is incomplete
role or pipeline needs more work
output format not proven

Decision:

Continue designing.

Manual Use Only

The workflow can be used manually with human supervision.

Use when:

purpose is clear
output is useful
validation is human-led
automation is premature

Decision:

Use manually and observe.

Assisted Use Approved

The workflow can support structured work, but humans still approve key steps.

Use when:

role card exists
pipeline exists
validation exists
handoff exists
human review remains required

Decision:

Use in controlled workflow with review.

Controlled Automation Approved

The workflow can be automated within approved boundaries.

Use when:

manual version is proven
inputs are predictable
outputs are stable
logging exists
failures are handled
human review catches exceptions

Decision:

Automate carefully.

Restricted Autonomous Use Approved

The workflow can run without immediate review inside low-risk boundaries.

Use only when:

task is low risk
workflow is stable
output is predictable
failures are safe
logs are reliable
periodic review exists

Decision:

Allow limited autonomous operation.

Deployment Readiness Scorecard

MWMS may score readiness from 0 to 5.

0 — Concept Only

Not ready.

1 — Draft Ready

Can be documented.

2 — Manual Use Ready

Can be used with human supervision.

3 — Assisted Automation Ready

Can create structured outputs or queue items with review.

4 — Controlled Automation Ready

Can run inside approved operational boundaries.

5 — Restricted Autonomous Ready

Can run in low-risk boundaries without immediate review.

Default rule:

New AI Employees should begin at Level 1 or Level 2 unless proven otherwise.

Deployment Readiness Template

Use this template before approving a new AI Employee or workflow.

AI Employee Or Workflow Name:
Owning Brain:
Supporting Brains:
Purpose:
Deployment Type:
Current Readiness Level:
Requested Readiness Level:
Primary Use Case:
Input Sources:
Output Types:
Role Card Complete:
Agentic Work Unit Defined:
Pipeline Defined:
Validation Defined:
Handoff Defined:
Failure Handling Defined:
Escalation Path Defined:
Tool Permissions Defined:
Human Review Required:
Logging Available:
Outcome Measurement Defined:
Developer Boundary Checked:
Dashboard Impact:
Client Impact:
Risks:
Missing Pieces:
Deployment Verdict:
Next Action:
Reviewer:
Date:

Application To Newsletter Intelligence

Before deploying or upgrading a Newsletter Intelligence AI workflow, check:

newsletter input source is stable
body extraction is reliable enough
cleaning rules exist
signal extraction prompt is specific
Brain routing rules exist
action types are defined
validation catches generic insights
queue review exists
dashboard output is not noisy
human review required before downstream tasks
Supabase logging exists
failure states are visible

Recommended readiness:

current stage: Manual/Assisted/Controlled Automation depending on system stability
no autonomous downstream task creation yet

Newsletter deployment rule:

Newsletter AI can extract and queue intelligence, but should not create major downstream actions without review.

Application To Course Absorption

Before deploying a Course Absorption AI Employee, check:

uploaded file source is clear
course value filter exists
framework extraction is defined
MWMS mapping is defined
duplication check exists
full page output rules are known
MCR placement rules are known
human review required before saving
weak material can be ignored or parked
learning can be logged

Recommended readiness:

manual use approved
assisted use approved
controlled automation only after repeated success

Course deployment rule:

Course absorption should stay human-reviewed because MCR quality matters.

Application To Brain Room

Before deploying Brain Room AI task conversion, check:

Brain Room messages can be captured
request classification exists
owning Brain can be assigned
task builder role exists
Agentic Work Unit fields are defined
AI Manager route is clear
validation step exists
human review required for medium/high-risk tasks
event logs work
no interference with M’s active build

Recommended readiness:

assisted use first
controlled automation only for low-risk task drafts

Brain Room deployment rule:

Brain Room should become operational slowly, with strong review gates.

Application To Offer Evaluation

Before deploying Offer Evaluation AI workflow, check:

offer intake fields exist
vendor claims are separated from evidence
web/current research rules exist
Research Brain handoff exists
Ads Brain compliance fit exists
Finance Brain break-even review exists
Experimentation Brain test fit exists
HeadOffice verdict review exists
human review is mandatory before spend

Recommended readiness:

manual or assisted only
no autonomous test approval

Offer deployment rule:

No offer evaluation workflow should approve spend without human and Finance/Experimentation review.

Application To M Developer Support

Before deploying developer-support AI workflows, check:

exact site is known
exact file path is known where applicable
screenshot/file evidence is available
current save point is known
full file output rule is followed
insertion/replacement location is exact
what not to touch is stated
test steps are included
M review is required
live system changes are not automated

Recommended readiness:

manual use only
assisted use for drafting
no autonomous developer changes

Developer deployment rule:

Developer AI support must never require M to guess.

Application To AIBS Client Systems

Before deploying client-facing AI workflows, check:

client process is mapped
AI Employee roles are clear
input sources are understood
approval gates exist
report format is simple
client risk is assessed
human review is defined
logs exist
value outcome is measurable
failure handling is safe

Recommended readiness:

manual or assisted client pilot first
controlled automation after proof
restricted autonomous only for low-risk internal tasks

Client deployment rule:

AIBS client systems must prove value and safety before automation is expanded.

Deployment Failure Modes

MWMS must watch for deployment failure.

Common failure modes include:

Deploying an AI Employee without a role card
Automating a workflow before manual process is stable
Allowing AI output without validation
Giving tools before permissions are defined
Creating dashboard items before usefulness is proven
Skipping human review for high-risk outputs
Sending M vague implementation tasks
Creating client-facing reports before approval gates exist
Failing to define outcome measurement
Ignoring failure handling
Letting AI Employees overlap responsibilities
Treating a good prompt as a complete system
Deploying because the course concept is exciting
Moving from MCR concept to build too fast
Forgetting M’s active development boundary

Any deployment showing these signs should be paused.

Deployment Gate

Before any AI Employee or workflow is deployed, HeadOffice should confirm:

Purpose is clear.
Owning Brain is clear.
Role card exists where needed.
Work unit structure exists.
Pipeline exists.
Input process is understood.
Output format exists.
Validation exists.
Handoff exists.
Failure handling exists.
Escalation exists.
Tool permission exists.
Human review is defined.
Logging exists.
Outcome measurement exists.
Developer boundary is safe.
Dashboard impact is controlled.
Client impact is safe.
Automation level matches risk.
HeadOffice approves the readiness level.

If any critical item is missing, deployment should not proceed.

Governance Role

HeadOffice owns the MWMS AI Agent Deployment Readiness Checklist.

HeadOffice is responsible for:

approving AI Employee readiness levels
approving workflow deployment levels
preventing premature automation
ensuring role cards exist
ensuring validation gates exist
ensuring handoffs are safe
ensuring failure handling exists
ensuring outcome measurement exists
protecting M’s active build areas
protecting MCR from immature system pages
protecting dashboards from noise
protecting future AIBS clients from unsafe AI workflows

Individual Brains may propose deployments, but HeadOffice must govern readiness for cross-Brain, high-risk, or client-facing workflows.

Relationship To Other MWMS Standards

This checklist supports and must align with:

MWMS AI Agent Operations Core
MWMS Agentic Work Unit Standard
MWMS AI Employee Role Card Standard
MWMS AI Agent Orchestration Framework
MWMS AI Workflow Pipeline Standard
MWMS AI Output Validation Standard
MWMS Messy Input Normalization Framework
MWMS Agentic Reporting Standard
MWMS AI Employee Handoff Protocol
MWMS AI Agent Failure Handling And Escalation Protocol
MWMS AI Agent Outcome Measurement Framework
MWMS AI Agent Operations Core Page Registry
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 System Data Flow Map
MWMS Supabase Event Schema
HeadOffice Newsletter Intelligence Operating Protocol
MWMS Course Absorption Operating Rule
MWMS Opportunity System Operating Protocol
AI Business Systems Brain Blueprint

This checklist acts as the readiness gate before the principles in those documents become operational workflows.

Drift Protection

This checklist protects MWMS from the following forms of drift:

Deploying AI roles before defining them
Automating vague workflows
Trusting outputs without validation
Skipping human review on high-risk work
Creating live system risk through premature AI action
Giving tools to AI without permission boundaries
Creating dashboard noise
Creating client-facing AI workflows before safety gates exist
Confusing a course concept with a deployable system
Letting Brain Room automation move too fast
Asking M to build from incomplete standards
Treating output quality as outcome proof
Allowing AI Employees to overlap or duplicate work
Forgetting failure handling
Moving from MCR governance to implementation without readiness review

Any AI Employee or workflow that does not pass this checklist should remain draft, parked, or manual-only.

Architectural Intent

The architectural intent of the MWMS AI Agent Deployment Readiness Checklist is to create a controlled bridge between AI system design and AI system operation.

MWMS will continue creating powerful AI Employee concepts, workflows, standards, and automation opportunities.

Not all of them should be deployed immediately.

The system must know the difference between:

idea
draft
manual workflow
assisted workflow
controlled automation
restricted autonomous operation

This checklist protects that progression.

The long-term goal is that every AI Employee and workflow inside MWMS can answer:

Is it clearly defined?
Is it owned by a Brain?
Is it assigned to a role?
Is the workflow structured?
Are inputs clean enough?
Are outputs defined?
Is validation present?
Are handoffs safe?
Can failure be handled?
Is escalation clear?
Are permissions controlled?
Is human review defined?
Is logging available?
Are outcomes measurable?
Is it safe to deploy at this level?

When MWMS can answer those questions, it can grow its AI workforce without losing control.

Change Log

v1.0 — Initial Draft

Created the MWMS AI Agent Deployment Readiness Checklist as the readiness gate for moving AI Employees, agentic workflows, Brain automations, task workflows, reporting systems, and future AIBS client systems from concept into controlled operation.

This checklist supports the MWMS AI Agent Operations Core and its related standards by defining readiness levels, deployment verdicts, required checks, workflow-specific application rules, deployment gates, drift protection, and governance requirements.