MWMS Automation Build Planning Framework

Document Type: Framework
Status: Active
Version: v1.0
Authority: MWMS HeadOffice
Parent Page: HeadOffice
Applies To: Automation Brain, AIBS Brain, Operations Brain, AI Employees, AI Operating Systems, internal MWMS automations, future client automation builds
Last Reviewed: 2026-05-31
Source / Origin: AI Automations by Jack — Make.com / AI Automation Foundations Section
MWMS Classification: Automation Planning Framework / Workflow Design Standard / AIOS Build Discipline
Primary Brain: Automation Brain
Supporting Brains: HeadOffice Brain, AIBS Brain, Operations Brain, Product Brain, Data Brain, Risk Brain, Compliance Brain, SIT Brain, Sales Brain
Related Pages: Automation Brain Canon, MWMS AI Operating System Architecture Framework, MWMS Constraint Based Learning And Build Focus Rule, MWMS AI Automation Security And Risk Checklist, MWMS AI Tool Permission And Access Framework, MWMS AI Agent Operations Core, MWMS AI Agent Memory And Context Framework, HeadOffice Kaizen Continuous Improvement Loop
Source Evidence: AI Automations by Jack teaches that automation planning should begin with the problem being solved, then define input, output, required technology, structure, and system/refinement thinking before building. The course also reinforces Make scenario structure, trigger logic, module naming, scheduling, routing, error handling, and practical AI/API usage inside automations.

Purpose

The MWMS Automation Build Planning Framework defines how MWMS should plan, design, evaluate, and prepare automations before building them in Make, n8n, Zapier, custom code, WordPress, Supabase, or future AI Operating Systems.

This framework exists because automation should not begin with tools.

Automation should begin with the problem.

A weak automation builder asks:

What can I automate?

A stronger automation builder asks:

What problem needs solving, what outcome is required, and what is the simplest reliable workflow that can produce that outcome?

MWMS must not build automations simply because they are interesting, impressive, or possible.

MWMS must build automations when they reduce friction, improve reliability, increase speed, strengthen reporting, support AI Employees, create client value, or remove a current constraint.

This framework becomes the planning rule before any serious automation work begins.

Strategic Importance

Automation is now one of the core execution layers inside MWMS.

It supports:

Newsletter Intelligence
Brain Room
AI Manager
Task Executor workflows
Course Absorption
Opportunity System
Affiliate Brain workflows
HeadOffice dashboards
Content Brain workflows
AIBS client systems
future AI Operating Systems
client-facing automation packages

As MWMS grows, the risk is not that MWMS will lack automation ideas.

The risk is that MWMS will build the wrong automations, overbuild too early, connect too many tools, skip planning, or create fragile workflows that are hard to maintain.

This framework protects MWMS from automation drift.

It ensures every automation is planned around:

problem clarity
input clarity
output clarity
technology requirement
workflow structure
data movement
error handling
ownership
testing
refinement
system value

Automation planning is therefore not optional.

It is the first governance layer before automation build.

Core Doctrine

The MWMS doctrine is:

Automate the right problem, not the first idea.

Many automation failures happen because the builder solves a problem that should not exist, solves the wrong part of the process, or starts wiring tools before understanding the actual business outcome.

MWMS must spend more time understanding the problem than rushing into tool setup.

The correct sequence is:

Understand the problem.
Define the desired outcome.
Identify the input.
Identify the output.
Select the minimum required technology.
Design the simplest reliable structure.
Add AI only where it improves the workflow.
Add automation only where it creates repeatable value.
Add monitoring and error handling before trusting it.
Improve through Kaizen.

Definition

Automation build planning is the structured process of defining what an automation should solve, what enters the workflow, what should come out, what technology is required, how the workflow should be structured, how failures should be handled, and how the automation connects to a larger system outcome.

MWMS Definition

Automation build planning is:

The discipline of designing the problem, input, output, tool path, workflow structure, risk boundary, and refinement loop before building the automation.

The MWMS Automation Planning Sequence

Every serious automation should follow this sequence.

Step 1: Define The Problem

The first question is not:

What tool should we use?

The first question is:

What problem are we solving?

The course makes this point strongly: the automation should start with the problem, because solving the wrong thing can produce an impressive workflow that still does not matter.

Problem Questions

Ask:

What is broken, slow, manual, repetitive, confusing, risky, or inconsistent?
Who experiences the problem?
How often does it happen?
What does it cost in time, money, missed opportunity, or friction?
What happens if the problem is not solved?
Is this problem worth automating?
Is this problem actually a symptom of a deeper issue?
Can the problem be removed instead of automated?
Is automation the right answer, or is simplification better?

MWMS Rule

Do not automate a bad process before questioning whether the process should exist.

Step 2: Define The Desired Outcome

Every automation must have an outcome.

The outcome is the end result the automation should produce.

Examples:

create a qualified lead record
generate an internal report
summarize an email
route a newsletter insight
create a draft WordPress post
update a dashboard
send a human-reviewed email draft
classify a Brain Room request
create a task for review
prepare a client onboarding report
trigger a compliance review
return a custom HTML response to a form submission

Outcome Questions

Ask:

What should exist at the end of the workflow?
Who uses the output?
What decision or action does it support?
Is the output draft, final, reviewed, or automated?
Where should the output go?
What format is required?
What quality standard must it meet?
What would make the output useful?
What would make the output useless?

MWMS Rule

No automation should be built until the output is clear.

Step 3: Define The Input

The input is what starts or feeds the automation.

Inputs may include:

form submission
Google Sheet row
email
Gmail label
webhook
uploaded file
WordPress form
CRM record
task row
Supabase event
Brain Room message
scheduled trigger
API response
Google Ads data
newsletter body
client intake form
transcript
webpage scrape

In Make, the course describes this as the trigger or module that starts the scenario, such as watching for rows, receiving data, or scheduling runs.

Input Questions

Ask:

What starts the workflow?
Is the input manual, scheduled, event-based, or webhook-based?
Is the input reliable?
Does the input contain enough data?
Is the input structured or messy?
Is the input trusted or external?
Is sensitive data involved?
What should happen if the input is incomplete?
What should happen if the input repeats?
What should happen if the input is malformed?

MWMS Rule

Bad inputs create bad automations.

Input quality must be understood before build.

Step 4: Map Input To Output

Before choosing tools, map the path from input to output.

This is the basic automation equation:

Input → Processing → Output

Simple automations may have one processing step.

Advanced automations may include:

cleaning
classification
AI reasoning
data enrichment
filtering
routing
approval
database write
report generation
notification
logging
error handling

Mapping Questions

Ask:

What needs to happen between input and output?
Does the input need cleaning?
Does AI need to interpret anything?
Does the workflow need branching logic?
Does the workflow need to store data?
Does the workflow need a human review step?
Does the workflow need to call another workflow?
Does the workflow need to return a response?
Does the workflow need logging?

MWMS Rule

If the input-to-output path cannot be explained clearly, the automation is not ready to build.

Step 5: Identify Required Technology

Only after the problem, input, and output are clear should tools be selected.

The course recommends thinking about what technology is required, but also keeping the tech simple and avoiding unnecessary tool sprawl.

Possible tools include:

Make
n8n
Zapier
Supabase
Airtable
Google Sheets
Gmail
Google Drive
WordPress
OpenAI
Claude
FireCrawl
Typeform
Carrd
GoHighLevel
Vercel
GitHub
Cloudinary
APIs
webhooks
custom plugins

Tool Questions

Ask:

What tools are absolutely required?
Can existing MWMS tools do this?
Is Make enough?
Is n8n better because AI agents, self-hosting, or multi-trigger workflows are needed?
Is Supabase needed as the record layer?
Is WordPress needed as the front-end layer?
Is AI needed?
Is an API needed?
Does this tool add cost?
Does this tool add risk?
Does this tool add a dependency?
Can this be built simpler?

MWMS Rule

Use the fewest tools that can reliably solve the problem.

Make Versus n8n Planning Rule

MWMS should not choose Make or n8n emotionally.

The course positions Make as more beginner-friendly, highly visual, and strong for integrations, while n8n is stronger for AI agents, self-hosting, multi-trigger environments, and scale economics. It also warns against ditching working Make systems just because n8n is exciting.

Use Make When

the workflow is integration-heavy
the build needs speed
the user needs beginner-friendly visual design
native integrations matter
the automation is straightforward
Make already handles the system well
speed of implementation matters more than self-hosting
client demonstration needs visual simplicity

Use n8n When

AI agents are central
self-hosting matters
cost at scale matters
multiple triggers in one workflow are helpful
more developer-style control is needed
workflow logic benefits from advanced technical flexibility
MWMS needs deeper AI agent orchestration

Use Both When

Make already contains valuable scenarios
n8n needs to call Make scenarios through webhooks
MWMS wants to preserve proven Make workflows while adding n8n agent capability
migration would be wasteful
hybrid orchestration is more practical than rebuilding

MWMS Rule

Choose the tool that fits the constraint.

Do not rebuild working automations because a new platform is more exciting.

Step 6: Design The Workflow Structure

Workflow structure defines how the automation is arranged.

In Make, structure may include:

trigger module
action modules
routers
filters
scheduled runs
sleep/delay modules
error handlers
imported blueprints
named modules
notes
scenario naming
mapped fields
outputs from previous modules
execution testing from later modules

The course reinforces that Make scenarios move left-to-right, can use routers for branching, filters for conditions, schedule controls for run frequency, and named modules/notes to keep scenarios understandable.

Structure Questions

Ask:

What is the simplest structure?
Does the workflow need one scenario or multiple?
Does the workflow need branching?
Does the workflow need filters?
Does the workflow need delays?
Does the workflow need a database handoff?
Does the workflow need a sub-workflow?
Does the workflow need human review?
Does the workflow need an error route?
Does the structure remain readable?
Could someone else understand it later?

MWMS Rule

Automation structure must remain understandable after the first build session.

Simple Structure Rule

MWMS should build the simplest reliable structure first.

This protects against:

overbuilding
too many tools
too many modules
unclear debugging
high operation cost
difficult handoff
fragile client systems
unnecessary workflow complexity

Simple does not mean weak.

Simple means clear, testable, and fit for purpose.

MWMS Rule

A simple workflow that works reliably is better than a complex workflow that nobody can maintain.

Scenario Naming And Documentation Rule

Every important scenario should be named clearly.

Every important module should be renamed clearly.

Notes or sticky documentation should be used where the workflow could confuse a future operator.

The course recommends naming modules, naming scenarios, adding notes, using emojis for visual recognition, and saving scenarios regularly.

Naming Questions

Ask:

Does the scenario name describe the business purpose?
Does each key module name describe what it does?
Would M understand this later?
Would a future operator understand this later?
Would a client-facing handover be understandable?
Is there a note explaining unusual logic?
Are branches labelled clearly?
Are error paths labelled clearly?

MWMS Naming Rule

Name the workflow after the business function, not the tool.

Good:

Newsletter Intake To Review Queue
Lead Form To Qualification Draft
WordPress Content Draft Generator
Client Intake To Report Draft
AIOS Launch Review Intake

Weak:

Test Scenario 1
ChatGPT Automation
Make Bot
Random Workflow
Final Final Version

Step 7: Define Data Movement

Data movement explains how information travels through the workflow.

Automation often fails not because the idea is wrong, but because data is poorly structured, poorly mapped, or not stored at the right point.

Data may move through:

module output fields
mapped variables
JSON
Google Sheets
Airtable
Supabase
WordPress fields
webhook payloads
API responses
binary files
Cloudinary links
task tables
event logs

The course references using Airtable as an intermediate storage layer when complex workflows need to pass data between scenarios.

Data Movement Questions

Ask:

What data enters the workflow?
What fields are required?
What data is transformed?
What data is stored?
Where is the source of truth?
Does this workflow need a database?
Does data need to pass between scenarios?
Should data be stored temporarily or permanently?
Does the output need JSON?
Is sensitive data involved?
What happens if data is missing?
What happens if data is malformed?

MWMS Rule

Automation is only as reliable as the data movement behind it.

JSON And Structured Output Rule

When AI output feeds another system, structured output may be required.

The course highlights JSON output as useful when AI needs to return multiple fields that can be parsed and sent into separate spreadsheet columns or downstream modules.

Use Structured Output When

AI output feeds a database
AI output feeds a spreadsheet
AI output triggers routing
AI output creates multiple fields
AI output must be validated
AI output must be parsed
AI output feeds a dashboard
AI output creates tasks
AI output enters a client report

MWMS Rule

If AI output needs to feed automation, prefer structured output over loose prose.

Step 8: Define AI Usage

AI should be used where it improves the workflow.

AI may be used for:

summarization
classification
extraction
transformation
drafting
scoring
routing
reasoning
tone generation
content generation
image analysis
transcription
translation
report generation
JSON structuring

The course explains that AI can be used inside Make through API-based models and can handle text, vision, audio/Whisper, image generation, and JSON outputs.

AI Usage Questions

Ask:

Why is AI needed here?
What exact AI task is being performed?
Does this need ChatGPT, Claude, or another model?
Does the task need human-like writing?
Does the task need structured JSON?
Does the task need vision?
Does the task need audio transcription?
Does the task need a system prompt?
Does the task need user input separated from system instructions?
What token/cost exposure exists?
What happens if AI output is wrong?
Does this need validation?

MWMS Rule

Use AI deliberately.

Do not add AI where normal logic, filters, or simple transformation can do the job better.

Model And API Cost Awareness Rule

AI automation uses API access, not normal consumer chat usage.

The course explains that API usage is charged per use, often based on tokens, and that context length, max tokens, and model selection affect cost and output.

Cost Questions

Ask:

Which model is being used?
Is this model necessary?
How many times can this workflow run?
What is the maximum input size?
What is the maximum output size?
Is max token control required?
Could long user input create cost spikes?
Does this workflow need a rate limit?
Does this workflow need cost monitoring?
Is there retry behavior that could multiply cost?
Is this safe for client use?

MWMS Rule

Every paid AI automation must consider cost exposure before production use.

Step 9: Define Permissions And Credentials

Automation requires connections.

Connections may use:

OAuth
API keys
tokens
account authorization
webhooks
credentials
app-specific permissions

The course teaches that Make connections commonly work through OAuth or API keys, and warns not to share API keys.

Permission Questions

Ask:

What accounts need connecting?
Is OAuth available?
Is an API key required?
Who owns the credential?
Is the credential stored securely?
Is access limited?
Does the workflow need read access or write access?
Does it need access to all records or only one source?
Is this client-specific?
Should each client have a separate API key?
What happens if the key is exposed?
Can the key be revoked or rotated?

MWMS Rule

Credentials are not setup details.

Credentials are risk boundaries.

Step 10: Define Error Handling

Errors are normal.

Error handling determines whether the automation fails safely or creates chaos.

The course repeatedly emphasizes solving Make errors, reading runtime error messages, using ChatGPT or support for troubleshooting, using error handlers, retries, and debugging from specific modules.

Error Questions

Ask:

What can fail?
What happens if a module fails?
What happens if an API is down?
What happens if AI returns invalid output?
What happens if credentials expire?
What happens if the input is missing?
What happens if the workflow times out?
What happens if the workflow loops?
What happens if data cannot be written?
What happens if the client-facing result fails?
Is there a retry?
Is there an alert?
Is there a log?
Is there a fallback?

MWMS Rule

A workflow without a failure path is not production-ready.

Testing And Debugging Rule

Before an automation is trusted, it must be tested.

Testing may include:

run once
run module only
start from later modules
test with sample input
test with missing input
test with bad input
test with duplicate input
test API connection
test output parsing
test error handler
test human review path
test final destination
test logs

The course shows practical debugging habits such as running from later modules, reading runtime errors, using screenshots with ChatGPT, and asking support/community when needed.

MWMS Rule

If it has not been tested with realistic input and failure cases, it is not ready.

Step 11: Define Human Review And Approval

Not every automation should act automatically.

Some outputs should remain drafts.

Some outputs should require review.

Some outputs should never be automated.

Human Review Required When

external email is sent
public content is published
client report is delivered
database records affect downstream systems
campaign spend is affected
compliance-sensitive claims are involved
customer data is involved
production systems are changed
M’s development work is affected
tool permissions are expanded
data is deleted
AI output is uncertain

MWMS Rule

Draft first.

Automate final action only when the workflow is safe, tested, logged, and approved.

Step 12: Define Logging And Monitoring

Important automations must leave a trace.

Logs may include:

trigger time
input summary
module success/failure
AI model used
prompt version
token/cost estimate
output produced
destination
human approval state
error message
retry count
final status

Monitoring Questions

Ask:

Where can we see if it worked?
Where are errors shown?
Who checks the logs?
Does HeadOffice need visibility?
Does the client need a report?
Does this feed a dashboard?
Does this support Kaizen improvement?
Does this support auditability?

MWMS Rule

No important automation should run invisibly.

Step 13: Define System Relationship

Every automation must be understood as part of a larger system.

The course’s later planning model includes “systems and refinement,” meaning automations should be connected and improved rather than treated as isolated tricks.

System Questions

Ask:

Is this a standalone task automation?
Is this part of an AI Operating System?
Which Brain owns it?
What workflow does it support?
What data does it create?
What dashboard does it feed?
What decision does it support?
What client outcome does it improve?
What future system might depend on it?
Does it create a reusable pattern?
Does it need documentation for handoff?

MWMS Rule

Automation should strengthen the system, not create isolated workflow fragments.

Step 14: Refine Through Kaizen

Once an automation is built, it should improve.

Kaizen may improve:

trigger reliability
input cleaning
output format
prompt quality
JSON structure
tool permissions
error handling
routing logic
logging
speed
cost
client experience
documentation
module naming
workflow simplicity

Kaizen Questions

Ask:

What caused friction?
What failed?
What took too long?
What was confusing?
What caused rework?
What should be simplified?
What should be documented?
What can be removed?
What should be improved before scaling?

MWMS Rule

Automation is not finished when it works once.

Automation improves through use, testing, and refinement.

MWMS Automation Planning Template

Use this template before building any serious automation.

Automation Name:
Owning Brain:
Supporting Brains:
Business Problem:
Desired Outcome:
Primary User:
Trigger / Input:
Final Output:
Workflow Summary:
Tools Required:
AI Required: Yes / No
AI Role:
Data Source:
Data Destination:
Human Review Required:
Permission Level:
Sensitive Data Involved:
Risk Level:
Error Handling Required:
Logging Required:
System Relationship:
AIOS Layer Affected:
Success Metric:
Minimum Viable Version:
Do Not Build Yet:
Testing Plan:
Owner:
Next Action:

Minimum Viable Automation Standard

Before building the full version, MWMS should define the smallest useful automation.

A Minimum Viable Automation should include:

one clear trigger
one clear input
one clear output
one core workflow path
one destination
one owner
basic test data
basic error awareness
basic logging
clear manual review where needed

The goal is to prove usefulness before expanding.

MWMS Rule

Build the smallest useful automation that proves the workflow creates value.

Automation Maturity Levels

MWMS classifies automation maturity as follows.

Level 1: Manual Process

The task is performed manually.

Use this when the process is not yet understood.

Level 2: Assisted Workflow

AI or tools help with parts of the process, but a human drives the workflow.

Use this when testing the process.

Level 3: Draft Automation

Automation produces draft output for review.

Use this when the process is useful but not trusted enough to act.

Level 4: Controlled Internal Automation

Automation can create or update internal records inside approved boundaries.

Use this when the workflow is tested and low to medium risk.

Level 5: Governed AI Automation

Automation includes AI reasoning, permissions, validation, logging, and escalation.

Use this for important MWMS internal systems.

Level 6: AIOS Component

Automation is part of a larger AI Operating System with data, interface, reporting, governance, and feedback loops.

Use this for production MWMS systems and future AIBS packages.

Level 7: Client-Grade Automation Component

Limited strategic value.

Correction:

Map the automation into a Brain workflow, dashboard, AIOS, or client outcome.

Application To MWMS Brains

Automation Brain

Automation Brain owns this framework as the build planning standard.

Responsibilities:

enforce problem-first planning
classify automation maturity
define workflow structure
review trigger/input/output clarity
check reliability and maintainability

HeadOffice Brain

HeadOffice uses this framework to decide whether automation work is worth building now.

Responsibilities:

check current constraint
approve important automation direction
prevent shiny object automation
enforce cross-Brain alignment

AIBS Brain

AIBS uses this framework to plan future client automation systems.

Responsibilities:

define client problem
define business outcome
define AIOS layer
define minimum viable client automation
ensure retention and reporting value

Operations Brain

Operations Brain uses this framework to ensure automation supports real process continuity.

Responsibilities:

define handoffs
define ownership
define operating cadence
reduce process friction

Data Brain

Data Brain uses this framework to define data flow, source of truth, and reporting reliability.

Responsibilities:

define fields
define records
define data destination
define source of truth
validate structured outputs

Risk Brain

Risk Brain uses this framework to identify automation failure modes.

Responsibilities:

classify risk
define failure scenarios
identify dependency risk
recommend controls

Compliance Brain

Compliance Brain uses this framework when automations involve data, claims, privacy, advertising, or client-facing outputs.

Responsibilities:

review sensitive data
review public claims
review jurisdiction issues
define approval requirements

SIT Brain

SIT Brain uses this framework to test automation readiness.

Responsibilities:

validate input/output
test failure handling
test data paths
test production readiness

Related Employee Capabilities

Automation Planner

Defines the problem, input, output, tools, structure, and minimum viable automation.

Workflow Architect

Maps automation structure, modules, triggers, routers, branches, and handoffs.

Data Flow Mapper

Defines how data enters, moves, transforms, stores, and exits the automation.

AI Automation Prompt Designer

Defines AI role, system prompt, user input, output format, JSON requirement, and validation rules.

Automation Debugger

Reviews errors, runtime failures, broken mappings, API issues, and retry logic.

Automation Risk Reviewer

Checks permissions, credentials, sensitive data, prompt injection, external actions, and approval gates.

Automation Kaizen Reviewer

Improves workflow simplicity, reliability, cost, documentation, and maintainability after use.

Implementation Rules

Rule 1: Problem Before Platform

Do not choose Make, n8n, Zapier, or code before defining the problem.

Rule 2: Input And Output Before Modules

Do not start building modules until input and output are clear.

Rule 3: Minimum Useful Version First

Build the smallest automation that proves value.

Rule 4: Fewest Tools Possible

Avoid unnecessary tools and dependencies.

Rule 5: AI Only Where It Adds Value

Do not use AI for simple deterministic logic.

Rule 6: Structured Output For Downstream Automation

Use JSON or structured fields when AI output feeds another system.

Rule 7: Permissions Before Connection

Do not connect tools before understanding access risk.

Rule 8: Error Handling Before Production

A production workflow needs a known failure path.

Rule 9: Logging Before Trust

Important automations must leave a trace.

Rule 10: Kaizen Before Scaling

Improve the workflow before expanding it.

Future Expansion

This framework should later connect to:

MWMS Automation Build Checklist
MWMS Make Scenario Design Standard
MWMS n8n Workflow Design Standard
MWMS AIOS Automation Layer Template
MWMS Automation Debugging Protocol
MWMS Automation Data Flow Map
MWMS Client Automation Planning Template
MWMS Automation Launch Readiness Checklist
MWMS Automation Client Handover Framework

Potential future pages:

MWMS Make Scenario Naming And Documentation Standard
MWMS Automation Error Handling Protocol
MWMS Automation JSON Output Standard
MWMS Automation Tool Selection Decision Tree
MWMS Automation Testing And Debugging Checklist

Strategic Summary

The MWMS Automation Build Planning Framework turns automation building into a governed planning discipline.

It prevents MWMS from rushing into Make, n8n, Zapier, APIs, or AI before understanding the actual problem and required outcome.

This framework strengthens MWMS by enforcing:

problem-first thinking
input/output clarity
simple structure
tool discipline
AI usage discipline
data movement clarity
permission awareness
error handling
testing
monitoring
Kaizen refinement
AIOS alignment

The strongest automation builders do not just know how to connect tools.

They know what should be connected, why it should be connected, what outcome it should create, and how to keep it reliable over time.

Final Standard

The MWMS standard is:

Start with the problem.
Define the input.
Define the output.
Choose the simplest tool path.
Build the minimum useful version.
Add AI only where useful.
Protect credentials.
Test failure paths.
Log important actions.
Refine through Kaizen.
Connect every automation to a real system outcome.

Automation is not the goal.

Reliable business movement is the goal.

Change Log

Version: v1.0
Date: 2026-05-31
Author: MWMS HeadOffice

Change:

Created the MWMS Automation Build Planning Framework from AI Automations by Jack — Make.com / AI Automation Foundations Section.

Captured the course’s automation planning model: problem, input, output, required technology, workflow structure, systems, and refinement.

Added MWMS automation planning sequence covering problem definition, desired outcome, input, input-to-output mapping, required technology, Make versus n8n decision logic, workflow structure, data movement, AI usage, API cost awareness, permissions, error handling, testing, human review, logging, system relationship, and Kaizen refinement.

Added Make versus n8n planning rule based on platform strengths: Make for beginner-friendly visual integration and n8n for AI agents, self-hosting, multi-trigger workflows, and scale economics.

Added structured output rule for AI-generated JSON and downstream automation.

Added Minimum Viable Automation Standard and Automation Maturity Levels.

Added common automation failure modes including tool-first build, wrong problem automated, unclear output, tool sprawl, no error handling, loose AI output, missing human review, poor naming, weak save discipline, and isolated automation.

Mapped framework responsibilities across Automation Brain, HeadOffice Brain, AIBS Brain, Operations Brain, Data Brain, Risk Brain, Compliance Brain, and SIT Brain.

Added related employee capabilities: Automation Planner, Workflow Architect, Data Flow Mapper, AI Automation Prompt Designer, Automation Debugger, Automation Risk Reviewer, and Automation Kaizen Reviewer.

Aligned this framework with:

Automation Brain Canon
MWMS AI Operating System Architecture Framework
MWMS Constraint Based Learning And Build Focus Rule
MWMS AI Automation Security And Risk Checklist
MWMS AI Tool Permission And Access Framework
MWMS AI Agent Operations Core
MWMS AI Agent Memory And Context Framework
HeadOffice Kaizen Continuous Improvement Loop

Purpose of creation:

To give MWMS a formal problem-first automation planning standard before building automations in Make, n8n, Zapier, WordPress, Supabase, custom code, or future AI Operating Systems.