MWMS MCR

MWMS AI Agent Deployment Readiness Review Template

System: MWMS
Document Type: Operational Template
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 Review Template.

This template is used before an AI Employee, AI workflow, AI-assisted process, Brain workflow, automation, dashboard process, task pipeline, tool-enabled process, or future AIBS client workflow moves from concept or manual use into operational use.

MWMS must not deploy AI workflows simply because they sound powerful.

Before deployment, MWMS must confirm:

  • the role is clear
  • the workflow is proven
  • the context is known
  • the input is controlled
  • the output is defined
  • the validation is strong enough
  • the handoff is clear
  • the tool permission is safe
  • the risk is understood
  • the human review gate is defined
  • the logging path exists
  • the outcome is measurable
  • the failure path is known
  • the system is not interfering with M’s active build

This template is the practical daily-use version of the MWMS AI Agent Deployment Readiness Checklist.

Scope

This template applies before deploying or expanding:

  • AI Employees
  • Agentic Work Units
  • AI Manager workflows
  • AI Employee Router workflows
  • Task Executor workflows
  • Brain Room task conversion
  • Newsletter Intelligence upgrades
  • Course Absorption workflows
  • Opportunity System AI workflows
  • Affiliate Brain workflows
  • Research Brain workflows
  • Experimentation Brain workflows
  • Finance Brain workflows
  • Content Brain workflows
  • Ads Brain workflows
  • Developer Support workflows
  • HeadOffice dashboard workflows
  • validation queues
  • handoff queues
  • tool-enabled workflows
  • future AIBS client workflows

This template does not authorize build work by itself.

It decides whether the system is ready to move to the next level.

Core Definition

An AI Agent Deployment Readiness Review is a structured review that decides whether an AI Employee or workflow is ready for a higher level of operational use.

Deployment does not always mean full automation.

Deployment may mean moving from:

  • concept to draft
  • draft to manual use
  • manual use to assisted use
  • assisted use to controlled automation
  • controlled automation to restricted low-risk autonomous operation

The readiness review prevents MWMS from moving too fast.

Core Principle

The core principle of this template is:

Manual discipline first. Automation second.

Before AI work becomes automated, it must first prove value manually.

Before an AI Employee gets tool access, its role and capability must be defined.

Before output is trusted, validation must exist.

Before work is routed, handoff must be clear.

Before dashboards display AI outputs, signal quality must be proven.

Before client use, approval gates must exist.

AI Agent Deployment Readiness Review Template

1. Review Title

Field:
Review Title:

Purpose:
Names the deployment readiness review.

Good Examples:

  • Deployment Readiness Review For Newsletter Signal Extraction Agent
  • Deployment Readiness Review For Brain Room Task Builder Workflow
  • Deployment Readiness Review For Course Absorption Agent Manual Use
  • Deployment Readiness Review For AI Tool Permission Workflow
  • Deployment Readiness Review For AIBS Client Reporting Agent

Bad Examples:

  • Ready Check
  • AI Review
  • Deployment
  • Go Live
  • Test This

Rule:
The title should show what is being reviewed.

2. Review Date

Field:
Review Date:

Format:
YYYY-MM-DD

Purpose:
Records when readiness was reviewed.

Rule:
Readiness can expire if the workflow changes.

3. Deployment Candidate

Field:
Deployment Candidate:

Purpose:
Identifies what is being reviewed.

Examples:

  • AI Employee
  • workflow
  • task pipeline
  • validation queue
  • handoff process
  • dashboard process
  • tool permission
  • automation
  • client workflow
  • report template
  • Brain Room process
  • AI Manager route

Rule:
The candidate must be specific.

4. Candidate Name

Field:
Candidate Name:

Examples:

  • Course Absorption Agent
  • Newsletter Signal Extraction Agent
  • Brain Room Task Builder Agent
  • Developer Support Agent
  • Offer Evaluation Workflow
  • Newsletter Intelligence Review Queue
  • Brain Room To AI Manager Handoff
  • AI Agent Outcome Log Workflow
  • AIBS Client Reporting Workflow

Rule:
Do not review vague concepts. Review named candidates.

5. Owning Brain

Field:
Owning Brain:

Purpose:
Identifies the Brain responsible for the candidate.

Examples:

  • HeadOffice Brain
  • Affiliate Brain
  • Research Brain
  • Finance Brain
  • Experimentation Brain
  • Content Brain
  • Ads Brain
  • Sales Brain
  • Conversion Brain
  • Operations Brain
  • AI Business Systems Brain

Rule:
Every deployment candidate must have an owner.

6. Supporting Brains

Field:
Supporting Brains:

Purpose:
Lists other Brains involved or affected.

Examples:

A Newsletter workflow may affect:

  • HeadOffice Brain
  • Ads Brain
  • Content Brain
  • Affiliate Brain
  • Research Brain
  • Finance Brain

An Offer workflow may affect:

  • Affiliate Brain
  • Research Brain
  • Ads Brain
  • Finance Brain
  • Experimentation Brain
  • HeadOffice Brain

Rule:
Cross-Brain impact must be visible before deployment.

7. Deployment Type

Field:
Deployment Type:

Recommended Values:

  • Concept To Draft
  • Draft To Manual Use
  • Manual Use To Assisted Use
  • Assisted Use To Controlled Automation
  • Controlled Automation To Restricted Autonomous
  • Permission Expansion
  • Dashboard Display
  • Developer Build Readiness
  • Client Workflow Readiness
  • Park / Not Ready

Rule:
Deployment type must be clear.

8. Requested Deployment Level

Field:
Requested Deployment Level:

Recommended Values:

  • Level 0 — Concept Only
  • Level 1 — Draft Ready
  • Level 2 — Manual Operation Ready
  • Level 3 — Assisted Automation Ready
  • Level 4 — Controlled Automation Ready
  • Level 5 — Restricted Autonomous Operation Ready

Rule:
Do not skip levels without strong evidence.

Deployment Level Definitions

Level 0 — Concept Only

The idea exists but is not ready for operational use.

Allowed:

  • brainstorm
  • draft rough role
  • park
  • compare with existing structure

Not allowed:

  • operational use
  • tool access
  • automation
  • dashboard use

Level 1 — Draft Ready

The candidate has enough structure to draft.

Allowed:

  • role draft
  • template draft
  • workflow draft
  • test examples

Not allowed:

  • live use
  • tool-enabled action
  • automated routing

Level 2 — Manual Operation Ready

The candidate can be used manually under human review.

Allowed:

  • manual AI Employee use
  • manual workflow use
  • draft output
  • human validation
  • manual handoff

Not allowed:

  • uncontrolled automation
  • high-risk tool access
  • autonomous operation

Level 3 — Assisted Automation Ready

The candidate may use limited automation or structured assistance.

Allowed:

  • structured intake
  • queue creation
  • draft generation
  • controlled internal records
  • human review before important action

Not allowed:

  • high-risk autonomous actions
  • external action without approval
  • paid traffic action
  • public publishing

Level 4 — Controlled Automation Ready

The candidate can operate inside a controlled workflow.

Allowed:

  • approved internal writes
  • controlled queue transitions
  • validation workflow
  • status updates
  • repeatable automation with logs

Requirements:

  • validation
  • logging
  • stop conditions
  • human review for high-risk actions
  • HeadOffice visibility

Level 5 — Restricted Autonomous Operation Ready

The candidate may act without immediate review only inside low-risk, tightly controlled boundaries.

Allowed:

  • low-risk internal classification
  • formatting
  • routine status updates
  • internal logging

Not allowed:

  • live system change
  • external communication
  • paid traffic
  • finance action
  • client final delivery
  • compliance-sensitive action

Rule:
Level 5 should be rare.

9. Current Status

Field:
Current Status:

Recommended Values:

  • Proposed
  • Drafted
  • Defined
  • Manual Use
  • Assisted Use
  • Controlled Automation
  • Restricted Autonomous
  • Parked
  • Retired
  • Merged
  • Deprecated

Rule:
Current status must be honest.

10. Deployment Goal

Field:
Deployment Goal:

Purpose:
Explains what MWMS is trying to achieve by moving this candidate forward.

Examples:

  • reduce manual newsletter review effort
  • improve Brain Room task routing
  • make course absorption more repeatable
  • improve developer handoffs for M
  • reduce dashboard noise
  • create safe client reporting workflow
  • prepare future AI Manager routing
  • improve validation consistency

Rule:
If the goal is unclear, deployment should pause.

11. Business Outcome Expected

Field:
Business Outcome Expected:

Purpose:
Defines the useful result the deployment should create.

Examples:

  • time saved
  • risk reduced
  • decision quality improved
  • workflow made repeatable
  • dashboard signal improved
  • M receives clearer work
  • weak offers rejected earlier
  • client reporting becomes safer
  • manual work becomes easier

Rule:
Deployment must be justified by outcome, not excitement.

Readiness Review Sections

12. Role Card Exists

Field:
Role Card Exists: Yes / No / Not Applicable

Check:

  • Employee name defined
  • owning Brain defined
  • responsibilities clear
  • non-responsibilities clear
  • inputs and outputs defined
  • tools and forbidden actions defined
  • validation and handoff rules clear

Pass Condition:
Role Card exists or is not needed for non-Employee workflow.

Fail Condition:
AI Employee is being deployed as a vague agent.

13. Capability Stack Exists

Field:
Capability Stack Exists: Yes / No / Not Applicable

Check:

  • role capability defined
  • input capability defined
  • context capability defined
  • tool capability defined
  • output capability defined
  • validation capability defined
  • handoff and escalation capability defined
  • forbidden capabilities defined

Pass Condition:
Capability stack matches the role and risk.

Fail Condition:
Capability is assumed rather than defined.

14. Agentic Work Unit Structure Exists

Field:
Agentic Work Unit Structure Exists: Yes / No / Not Applicable

Check:

  • task title
  • source
  • owning Brain
  • assigned AI Employee
  • input payload
  • context pack
  • output format
  • validation level
  • handoff destination
  • business outcome

Pass Condition:
Work can be structured before execution.

Fail Condition:
Workflow begins from vague prompts.

15. Workflow Pipeline Exists

Field:
Workflow Pipeline Exists: Yes / No / Not Applicable

Check:

  • input capture
  • input cleaning
  • classification
  • task creation
  • assignment
  • context attachment
  • processing
  • validation
  • decision
  • routing
  • logging
  • learning

Pass Condition:
The workflow stages are known.

Fail Condition:
Workflow depends on one-shot AI output.

16. Messy Input Normalization Exists

Field:
Messy Input Normalization Exists: Yes / No / Not Applicable

Check:

  • source type identified
  • source completeness checked
  • noise detected
  • useful content extracted
  • gaps marked
  • assumptions marked
  • Brain ownership identified

Pass Condition:
Input quality is controlled.

Fail Condition:
Raw or noisy input enters serious workflow.

17. Context Pack Exists

Field:
Context Pack Exists: Yes / No / Not Applicable

Check:

  • source of truth known
  • relevant standards listed
  • current workflow stage known
  • tool boundary known
  • developer boundary if relevant
  • output required known
  • current evidence listed
  • known gaps stated

Pass Condition:
The AI Employee has the right context.

Fail Condition:
Employee must rely on vague memory or guesswork.

18. Tool Permission Record Exists

Field:
Tool Permission Record Exists: Yes / No / Not Applicable

Check:

  • tool named
  • permission purpose clear
  • access level defined
  • approved actions listed
  • forbidden actions listed
  • human approval stage defined
  • validation and logging defined
  • stop conditions defined

Pass Condition:
Tool access is governed.

Fail Condition:
Tool access is assumed or too broad.

19. Output Format Defined

Field:
Output Format Defined: Yes / No

Check:

  • output type known
  • required sections known
  • destination format known
  • dashboard/report/page/developer format clear
  • no vague output expectation

Pass Condition:
The output is shaped before creation.

Fail Condition:
AI produces whatever it wants.

20. Validation Standard Exists

Field:
Validation Standard Exists: Yes / No

Check:

  • validation level assigned
  • validation checklist applies
  • pass/fail criteria defined
  • human review trigger known
  • high-risk checks included

Pass Condition:
Output can be checked before use.

Fail Condition:
Output is trusted because it sounds good.

21. Handoff Package Exists

Field:
Handoff Package Exists: Yes / No / Not Applicable

Check:

  • receiver defined
  • owner of next action defined
  • context to preserve listed
  • validation status travels
  • risk level travels
  • next action defined

Pass Condition:
Work can move without losing meaning.

Fail Condition:
Output has no safe destination.

22. Failure Handling Exists

Field:
Failure Handling Exists: Yes / No

Check:

  • failure categories known
  • stop conditions known
  • escalation destination known
  • failure log available
  • containment action defined
  • Kaizen learning possible

Pass Condition:
Workflow can fail safely.

Fail Condition:
Failure would be hidden, repeated, or unsafe.

23. Outcome Measurement Exists

Field:
Outcome Measurement Exists: Yes / No

Check:

  • expected outcome defined
  • outcome category known
  • outcome score possible
  • decision/action/risk reduction measurable
  • outcome log available

Pass Condition:
MWMS can judge whether deployment created value.

Fail Condition:
Deployment would be measured only by output volume.

24. Human Review Gate Exists

Field:
Human Review Gate Exists: Yes / No / Not Required

Check:

  • review required before MCR save
  • review required before developer handoff
  • review required before external action
  • review required before spend
  • review required before client delivery
  • review required before high-risk automation

Pass Condition:
Human review matches risk.

Fail Condition:
High-risk action can bypass review.

25. Logging Path Exists

Field:
Logging Path Exists: Yes / No / Not Required

Check:

  • task log
  • event log
  • failure log
  • outcome log
  • dashboard log
  • MCR change log
  • Make.com execution history
  • Supabase event row
  • client audit log

Pass Condition:
Important action leaves a trace.

Fail Condition:
MWMS cannot audit what happened.

26. Dashboard Or Review Visibility Exists

Field:
Dashboard Or Review Visibility Exists: Yes / No / Not Required

Check:

  • HeadOffice can see status
  • queue is visible
  • review page exists
  • dashboard card is specific
  • validation state visible
  • owner visible
  • next action visible

Pass Condition:
Operational work is visible.

Fail Condition:
Workflow becomes hidden automation.

27. Developer Boundary Protected

Field:
Developer Boundary Protected: Yes / No / Not Applicable

Check:

  • does not interfere with M’s active build
  • does not touch unrelated systems
  • does not create vague work for M
  • does not require file/path guessing
  • does not modify live code
  • does not alter Supabase schema unless approved

Pass Condition:
M’s work and live systems are protected.

Fail Condition:
Deployment creates development risk or distraction.

28. Client Safety Boundary Protected

Field:
Client Safety Boundary Protected: Yes / No / Not Applicable

Check:

  • client data isolated
  • approval gates defined
  • tool permissions limited
  • client-facing output reviewed
  • privacy risk considered
  • no unsupported claims
  • no uncontrolled external action

Pass Condition:
Client workflow is safe enough for its stage.

Fail Condition:
Client-facing AI is under-governed.

29. Compliance And Risk Check Completed

Field:
Compliance And Risk Check Completed: Yes / No / Not Applicable

Check:

  • advertising risk
  • finance risk
  • health/claim risk
  • privacy risk
  • public content risk
  • platform policy risk
  • client risk
  • legal-sensitive risk

Pass Condition:
Relevant risk has been checked.

Fail Condition:
Deployment ignores compliance or business risk.

30. Manual Proof Completed

Field:
Manual Proof Completed: Yes / No / Not Required

Check:

  • workflow has been used manually
  • outputs have been validated
  • repeated pattern exists
  • failure modes are understood
  • handoffs work manually
  • outcome value is visible

Pass Condition:
There is evidence the workflow is useful.

Fail Condition:
MWMS is trying to automate theory.

31. Automation Readiness

Field:
Automation Readiness:

Recommended Values:

  • Not Ready
  • Manual Only
  • Assisted Drafting Only
  • Queue Creation Ready
  • Controlled Internal Automation Ready
  • Restricted Low Risk Autonomous Ready

Rule:
Automation readiness must not exceed manual proof.

32. Readiness Verdict

Field:
Readiness Verdict:

Recommended Values:

  • Ready For Requested Level
  • Ready At Lower Level Only
  • Manual Use Only
  • Needs Revision
  • Park
  • Not Ready
  • Escalate To HeadOffice
  • Requires Developer Brief
  • Requires More Manual Proof

Rule:
Verdict must be clear and conservative.

33. Conditions Before Deployment

Field:
Conditions Before Deployment:

Purpose:
Lists what must happen before deployment proceeds.

Examples:

  • create role card
  • create capability stack
  • define tool permission
  • add validation checklist
  • define handoff destination
  • create failure log path
  • prove manually 3 more times
  • confirm MCR duplicate risk
  • prepare developer brief
  • get human approval
  • confirm no impact on M’s active build

Rule:
If deployment is conditional, conditions must be explicit.

34. Approved Deployment Scope

Field:
Approved Deployment Scope:

Purpose:
Defines exactly what is approved.

Examples:

  • manual use only
  • draft creation only
  • read-only access only
  • internal queue creation only
  • one workflow only
  • one Brain only
  • one low-risk test
  • no downstream automation
  • no external action
  • no client delivery

Rule:
Approval must be limited and clear.

35. Forbidden Deployment Scope

Field:
Forbidden Deployment Scope:

Purpose:
Defines what is not approved.

Examples:

  • no live system changes
  • no MCR writing
  • no Supabase schema changes
  • no external email
  • no paid traffic action
  • no client final delivery
  • no automatic downstream tasks
  • no write access
  • no deletion
  • no cross-Brain automation yet

Rule:
What is forbidden must be as clear as what is allowed.

36. Owner Of Next Action

Field:
Owner Of Next Action:

Examples:

  • Martyn
  • HeadOffice
  • M
  • AI Manager
  • Human Review Queue
  • Validation Agent
  • relevant Brain owner
  • Future Client Operator

Rule:
Readiness review should not create ownerless work.

37. Next Step

Field:
Next Step:

Examples:

  • approve manual use
  • revise role card
  • create missing context pack
  • create developer brief
  • run manual proof test
  • park for later
  • send to HeadOffice review
  • update related standard
  • prepare limited build scope
  • stop deployment

Rule:
Next step must be specific.

38. Review Owner

Field:
Review Owner:

Examples:

  • HeadOffice
  • Martyn
  • M
  • Human Review Queue
  • Brain owner

Rule:
A readiness review should have an accountable reviewer.

39. Re Review Trigger

Field:
Re Review Trigger:

Purpose:
Defines when the candidate must be reviewed again.

Examples:

  • after failure
  • before tool permission expansion
  • before automation
  • before client use
  • after three manual runs
  • before M build
  • after workflow change
  • after risk change
  • monthly
  • no scheduled re-review yet

Rule:
Readiness is not permanent.

Quick Use Version

Use this shorter version for daily readiness reviews.

Review Title:
Review Date:
Deployment Candidate:
Candidate Name:
Owning Brain:
Supporting Brains:
Deployment Type:
Requested Deployment Level:
Current Status:
Deployment Goal:
Business Outcome Expected:

Role Card Exists:
Capability Stack Exists:
Agentic Work Unit Structure Exists:
Workflow Pipeline Exists:
Messy Input Normalization Exists:
Context Pack Exists:
Tool Permission Record Exists:
Output Format Defined:
Validation Standard Exists:
Handoff Package Exists:
Failure Handling Exists:
Outcome Measurement Exists:
Human Review Gate Exists:
Logging Path Exists:
Dashboard Or Review Visibility Exists:
Developer Boundary Protected:
Client Safety Boundary Protected:
Compliance And Risk Check Completed:
Manual Proof Completed:
Automation Readiness:

Readiness Verdict:
Conditions Before Deployment:
Approved Deployment Scope:
Forbidden Deployment Scope:
Owner Of Next Action:
Next Step:
Review Owner:
Re Review Trigger:

Deployment Readiness Examples

Example 1: Course Absorption Agent Manual Use Readiness

Review Title:
Deployment Readiness Review For Course Absorption Agent Manual Use

Deployment Candidate:
AI Employee

Candidate Name:
Course Absorption Agent

Owning Brain:
HeadOffice Brain

Deployment Type:
Draft To Manual Use

Requested Deployment Level:
Level 2 — Manual Operation Ready

Deployment Goal:
Make course absorption consistent, value-focused, and non-duplicative.

Business Outcome Expected:
Useful course material improves MWMS Brain/Blueprint; weak material is rejected.

Role Card Exists:
Yes

Capability Stack Exists:
Yes

Workflow Pipeline Exists:
Yes

Messy Input Normalization Exists:
Yes

Context Pack Exists:
Yes

Tool Permission Record Exists:
Yes — Provided Input Only

Output Format Defined:
Yes

Validation Standard Exists:
Yes

Handoff Package Exists:
Yes

Failure Handling Exists:
Yes

Outcome Measurement Exists:
Yes

Human Review Gate Exists:
Yes — before MCR save

Logging Path Exists:
Yes if absorbed

Developer Boundary Protected:
Yes

Manual Proof Completed:
Yes

Automation Readiness:
Manual Only

Readiness Verdict:
Ready For Requested Level

Approved Deployment Scope:
Manual course absorption and page drafting only.

Forbidden Deployment Scope:
No automatic MCR page creation. No live WordPress changes. No M development tasks.

Next Step:
Continue manual use.

Example 2: Newsletter Signal Extraction Assisted Use Readiness

Review Title:
Deployment Readiness Review For Newsletter Signal Extraction Assisted Use

Deployment Candidate:
Workflow / AI Employee

Candidate Name:
Newsletter Signal Extraction Agent

Owning Brain:
HeadOffice Brain

Deployment Type:
Manual Use To Assisted Use

Requested Deployment Level:
Level 3 — Assisted Automation Ready

Deployment Goal:
Extract newsletter signals into structured review records.

Business Outcome Expected:
HeadOffice sees useful external signals without newsletter noise.

Role Card Exists:
Draft / Yes

Capability Stack Exists:
Yes

Workflow Pipeline Exists:
Yes

Messy Input Normalization Exists:
Yes

Context Pack Exists:
Yes

Tool Permission Record Exists:
Yes — Gmail read and controlled Supabase write

Output Format Defined:
Yes

Validation Standard Exists:
Yes

Handoff Package Exists:
Partial

Failure Handling Exists:
Yes

Outcome Measurement Exists:
Partial

Human Review Gate Exists:
Yes before downstream action

Logging Path Exists:
Yes

Dashboard Or Review Visibility Exists:
Yes

Manual Proof Completed:
Partially

Automation Readiness:
Queue Creation Ready

Readiness Verdict:
Ready At Lower Level Only

Conditions Before Deployment:
Keep downstream task creation manual. Validate output quality before dashboard escalation.

Approved Deployment Scope:
Newsletter extraction into review queue only.

Forbidden Deployment Scope:
No automatic downstream Brain task creation. No ACT NOW action without review.

Next Step:
Continue controlled tests and review signal quality.

Example 3: Brain Room Task Builder Workflow Readiness

Review Title:
Deployment Readiness Review For Brain Room Task Builder Workflow

Deployment Candidate:
Workflow

Candidate Name:
Brain Room To Agentic Work Unit Conversion

Owning Brain:
HeadOffice Brain

Deployment Type:
Concept To Draft

Requested Deployment Level:
Level 1 — Draft Ready

Deployment Goal:
Convert important Brain Room messages into structured work.

Business Outcome Expected:
Brain Room discussion becomes trackable work instead of lost conversation.

Role Card Exists:
Draft

Capability Stack Exists:
Draft

Agentic Work Unit Structure Exists:
Yes

Workflow Pipeline Exists:
Draft

Context Pack Exists:
Draft

Tool Permission Record Exists:
No / Not yet

Output Format Defined:
Yes

Validation Standard Exists:
Yes

Handoff Package Exists:
Yes

Failure Handling Exists:
Yes

Outcome Measurement Exists:
Yes

Human Review Gate Exists:
Yes

Logging Path Exists:
Not fully confirmed

Developer Boundary Protected:
Must be confirmed before build

Manual Proof Completed:
No

Automation Readiness:
Not Ready

Readiness Verdict:
Draft Ready Only

Conditions Before Deployment:
Use manually first. Do not build automation yet.

Approved Deployment Scope:
Manual task conversion planning.

Forbidden Deployment Scope:
No automatic Task Executor routing. No live build request to M yet.

Next Step:
Run manual examples first.

Example 4: AIBS Client Reporting Workflow Readiness

Review Title:
Deployment Readiness Review For AIBS Client Reporting Workflow

Deployment Candidate:
Client Workflow

Candidate Name:
AIBS Client Reporting Agent Workflow

Owning Brain:
AI Business Systems Brain

Deployment Type:
Concept To Draft

Requested Deployment Level:
Level 1 — Draft Ready

Deployment Goal:
Define safe future client reporting workflow.

Business Outcome Expected:
Future client reports become useful, permissioned, reviewed, and business-friendly.

Role Card Exists:
Draft

Capability Stack Exists:
Draft

Context Pack Exists:
Draft

Tool Permission Record Exists:
Draft

Output Format Defined:
Yes

Validation Standard Exists:
Yes

Handoff Package Exists:
Yes

Failure Handling Exists:
Yes

Outcome Measurement Exists:
Yes

Human Review Gate Exists:
Yes

Client Safety Boundary Protected:
Needs further design

Compliance And Risk Check Completed:
Not yet

Manual Proof Completed:
No

Automation Readiness:
Not Ready

Readiness Verdict:
Draft Ready Only

Conditions Before Deployment:
Client approval gates, context isolation, tool permissions, and reporting validation must be defined before use.

Approved Deployment Scope:
Internal planning only.

Forbidden Deployment Scope:
No client deployment. No client data access. No external delivery.

Next Step:
Park until AIBS client workflow build phase.

Readiness Verdict Guide

Ready For Requested Level

Use when all required readiness checks are passed.

The candidate can move to the requested level.

Ready At Lower Level Only

Use when the candidate has value but is not ready for the requested level.

Example:

Requested controlled automation, but only manual or assisted use is safe.

Manual Use Only

Use when workflow is useful but not ready for automation.

Needs Revision

Use when missing structure must be fixed first.

Park

Use when useful later but not current priority or not ready.

Not Ready

Use when deployment would create risk, confusion, or noise.

Escalate To HeadOffice

Use when deployment affects cross-Brain governance, MCR, tool permissions, live systems, compliance, finance, paid traffic, or client systems.

Requires Developer Brief

Use only after workflow is stable enough to translate into exact build instructions for M.

Requires More Manual Proof

Use when the idea is promising but unproven.

Deployment Readiness Quality Checklist

Before approving deployment, check:

  1. Is the candidate clearly named?
  2. Is the owning Brain clear?
  3. Are supporting Brains listed?
  4. Is deployment type clear?
  5. Is requested level realistic?
  6. Is the deployment goal clear?
  7. Is expected business outcome clear?
  8. Does the Role Card exist?
  9. Does the Capability Stack exist?
  10. Does the Work Unit structure exist?
  11. Does the workflow pipeline exist?
  12. Does messy input normalization exist?
  13. Does the Context Pack exist?
  14. Does the Tool Permission Record exist where needed?
  15. Is output format defined?
  16. Is validation standard defined?
  17. Is handoff package defined?
  18. Is failure handling defined?
  19. Is outcome measurement defined?
  20. Is human review gate defined?
  21. Is logging path defined?
  22. Is dashboard/review visibility defined where needed?
  23. Is developer boundary protected?
  24. Is client safety protected where relevant?
  25. Has manual proof been completed?
  26. Is automation readiness conservative?
  27. Are deployment conditions explicit?
  28. Is approved scope limited?
  29. Is forbidden scope clear?
  30. Is next action owned?

If several answers are unclear, deployment is not ready.

Common Deployment Failure Modes

Deployment readiness has failed if:

  1. AI Employee role is vague.
  2. Capability stack is missing.
  3. Tool access is assumed.
  4. Workflow has not been manually proven.
  5. Output format is unclear.
  6. Validation is missing.
  7. Human review gate is missing.
  8. Handoff destination is unclear.
  9. Failure path is missing.
  10. Outcome is not measurable.
  11. Dashboard visibility is not defined.
  12. M’s active build may be affected.
  13. Client safety is not defined.
  14. Automation is requested too early.
  15. The deployment goal is excitement rather than business value.

Manual Use Rule

This template should be used manually before it becomes technical infrastructure.

Manual readiness review helps MWMS learn:

  • which workflows are truly ready
  • which AI Employees need more definition
  • which tool permissions are too risky
  • where validation is missing
  • where handoffs fail
  • where dashboards need better visibility
  • which workflows are worth automating
  • which workflows should remain manual
  • which deployment fields may later become Supabase or dashboard fields

Manual readiness review comes before build.

Future Plugin Or UI Relevance

This template may later become:

  • AI Deployment Readiness Review screen
  • HeadOffice AI Workforce readiness dashboard
  • AI Employee Registry readiness field
  • workflow readiness checker
  • tool permission approval gate
  • Brain Room automation readiness review
  • AI Manager deployment gate
  • AIBS client workflow readiness screen

Possible future fields:

  • readiness_review_id
  • review_title
  • review_date
  • deployment_candidate
  • candidate_name
  • owning_brain
  • supporting_brains
  • deployment_type
  • requested_deployment_level
  • current_status
  • deployment_goal
  • business_outcome_expected
  • role_card_exists
  • capability_stack_exists
  • work_unit_structure_exists
  • workflow_pipeline_exists
  • messy_input_normalization_exists
  • context_pack_exists
  • tool_permission_record_exists
  • output_format_defined
  • validation_standard_exists
  • handoff_package_exists
  • failure_handling_exists
  • outcome_measurement_exists
  • human_review_gate_exists
  • logging_path_exists
  • dashboard_visibility_exists
  • developer_boundary_protected
  • client_safety_boundary_protected
  • compliance_risk_check_completed
  • manual_proof_completed
  • automation_readiness
  • readiness_verdict
  • conditions_before_deployment
  • approved_deployment_scope
  • forbidden_deployment_scope
  • owner_next_action
  • next_step
  • review_owner
  • re_review_trigger
  • created_at
  • updated_at

No technical build is authorized by this template alone.

Governance Role

HeadOffice owns the MWMS AI Agent Deployment Readiness Review Template.

HeadOffice is responsible for:

  • deciding when readiness review is required
  • approving deployment level
  • preventing premature automation
  • ensuring AI Employees have role cards and capability stacks
  • ensuring tool permissions are controlled
  • ensuring validation, handoff, failure, and outcome systems exist
  • protecting M’s active build areas
  • protecting MCR source of truth
  • protecting paid traffic, finance, compliance, public content, and client systems
  • deciding when a workflow is ready for developer briefing
  • deciding when a workflow must remain manual, parked, or rejected

Individual Brains may request deployment, but HeadOffice governs readiness for cross-Brain, high-risk, tool-enabled, client-facing, or automation-related workflows.

Relationship To Other MWMS Standards

This template supports and must align with:

  • MWMS AI Agent Deployment Readiness Checklist
  • MWMS AI Agent Operations Core
  • MWMS Agentic Work Unit Standard
  • MWMS Agentic Work Unit Template
  • MWMS AI Employee Role Card Standard
  • MWMS AI Employee Role Card Template
  • MWMS AI Employee Capability Stack Framework
  • MWMS AI Employee Capability Stack Template
  • MWMS AI Tool Permission And Access Framework
  • MWMS AI Tool Permission Record Template
  • MWMS AI Agent Memory And Context Framework
  • MWMS AI Agent Context Pack Template
  • MWMS AI Workflow Pipeline Standard
  • MWMS AI Workflow Pipeline Checklist
  • MWMS AI Output Validation Standard
  • MWMS AI Output Validation Checklist
  • MWMS Messy Input Normalization Framework
  • MWMS Messy Input Normalization Record
  • MWMS Agentic Reporting Standard
  • MWMS Agentic Reporting Template
  • MWMS AI Employee Handoff Protocol
  • MWMS AI Employee Handoff Package Template
  • MWMS AI Agent Failure Handling And Escalation Protocol
  • MWMS AI Agent Failure Log Record
  • MWMS AI Agent Outcome Measurement Framework
  • MWMS AI Agent Outcome Log Record
  • MWMS Brain Routing Rule
  • MWMS Brain To Brain Request Protocol
  • MWMS Supabase Event Schema
  • AI Business Systems Brain Blueprint

This template is the practical application of the MWMS AI Agent Deployment Readiness Checklist.

Drift Protection

This template protects MWMS from the following forms of drift:

  1. Deploying AI Employees before roles are defined
  2. Deploying workflows before manual proof
  3. Automating vague prompts
  4. Giving tool access before permission boundaries exist
  5. Trusting outputs before validation exists
  6. Routing work without handoff structure
  7. Building dashboards before signal quality is proven
  8. Creating developer work for M from unclear concepts
  9. Moving to client-facing use without approval gates
  10. Treating long documentation as readiness
  11. Confusing MCR governance with operational deployment
  12. Letting excitement override risk controls
  13. Skipping outcome measurement
  14. Allowing automation to expand without HeadOffice review
  15. Moving to higher deployment levels without evidence

Any AI Employee or workflow that fails readiness review should remain draft, manual, parked, or under revision.

Architectural Intent

The architectural intent of the MWMS AI Agent Deployment Readiness Review Template is to make AI deployment controlled, staged, and evidence-based.

MWMS is building a governed AI workforce.

A governed AI workforce cannot move from idea to automation in one jump.

It must move through readiness stages.

The long-term goal is that every AI Employee or workflow can answer:

  • What is being deployed?
  • Why is it being deployed?
  • Which Brain owns it?
  • What level is requested?
  • Is the role defined?
  • Are capabilities defined?
  • Is the workflow proven?
  • Is input controlled?
  • Is context packaged?
  • Are tools permissioned?
  • Is output defined?
  • Is validation in place?
  • Is handoff clear?
  • Can it fail safely?
  • Is outcome measurable?
  • Is human review required?
  • Is automation justified?
  • What scope is approved?
  • What scope is forbidden?

When MWMS can answer those questions before deployment, the AI workforce can grow without losing control.

Change Log

v1.0 — Initial Draft

Created the MWMS AI Agent Deployment Readiness Review Template as the practical operational template for reviewing whether AI Employees, AI workflows, tool-enabled processes, task pipelines, dashboards, handoffs, automations, and future AIBS client workflows are ready to move from concept to draft, draft to manual use, manual use to assisted use, assisted use to controlled automation, or controlled automation to restricted low-risk autonomous operation.

This template operationalizes the MWMS AI Agent Deployment Readiness Checklist and protects MWMS from premature automation, unclear roles, unsafe tool access, weak validation, poor handoffs, missing