Document Type: Canon
Status: Canon
Authority: MWMS HeadOffice
Applies To: All MWMS Brains, executors, and AI employees
Parent: MWMS Canon
Version: v1.1
Last Reviewed: 2026-03-15
Purpose
This document defines the standardised task types used within the MWMS ecosystem.
All work performed by Brains and AI employees must be represented as structured tasks inside the MWMS task system.
Standardised task types ensure:
• predictable system behaviour
• clear cross-brain communication
• consistent automation logic
• reliable executor behaviour
• complete operational audit trails
No new task types may be introduced without HeadOffice approval.
Scope
This canon applies to:
• all MWMS task-based execution flows
• Brains, executors, AI employees, and human operators creating governed tasks
• standard task-type naming and meaning across the ecosystem
• task status discipline and required task fields
• escalation handling when task execution breaches authority or integrity
This document governs the recognised language of work inside MWMS.
It does not govern:
• exact database schema by itself
• Brain authority boundaries by themselves
• request-routing logic by itself
• detailed executor implementation by itself
• UI layout for task views by itself
• non-task informal discussion outside the governed execution system
Those remain governed by the MWMS – Task Architecture Standard, MWMS – Supabase Task Schema Standard, MWMS – Brain Interaction Protocol, and related governance documents.
Definition / Rules
Core Principle
Work in MWMS does not occur through informal instructions.
Work occurs through structured tasks.
Tasks are the operational language of the ecosystem.
Every task must belong to a defined task type.
MWMS Task Architecture
The MWMS task system follows this structure:
Originating Brain
↓
Task Creation
↓
Task Stored in Supabase
↓
Executor / Brain Processes Task
↓
Result Logged
↓
HeadOffice Visibility Maintained
Tasks act as the communication layer between Brains.
Standard Task Types
The following task types are recognised by the MWMS ecosystem.
intelligence_request
Purpose
Request analysis, research, or market intelligence from another Brain.
Typical Use Cases
• market research
• competitor analysis
• offer intelligence
• audience insights
• keyword discovery
Example
Affiliate Brain requests product intelligence analysis.
Origin Brain
Affiliate Brain
Receiving Brain
Research & Intelligence Brain
compliance_check
Purpose
Verify that a campaign, system action, or process complies with MWMS governance rules.
Typical Use Cases
• advertising compliance
• policy verification
• risk review
• data protection checks
Example
Affiliate Brain submits ad concept for review by SIT Brain.
Origin Brain
Execution Brain
Receiving Brain
SIT Brain
budget_request
Purpose
Request capital allocation for campaigns or operational activity.
Typical Use Cases
• ad campaign budget approval
• scaling capital requests
• infrastructure spending
• tool subscriptions
Example
Media Buying Brain requests increased campaign budget.
Origin Brain
Media Buying Brain
Receiving Brain
Finance Brain
strategic_review
Purpose
Escalate decisions that exceed the authority of a single Brain.
Typical Use Cases
• entering new markets
• launching new products
• system architecture changes
• strategic partnerships
Example
Affiliate Brain proposes a new product category.
Origin Brain
Affiliate Brain
Receiving Authority
HeadOffice
Human approval required.
execution_task
Purpose
Perform operational work required by another Brain.
Typical Use Cases
• campaign launch
• content production
• funnel deployment
• automation configuration
Example
Media Buying Brain launches YouTube campaign.
Origin Brain
Media Buying Brain
Receiving System
Execution Executor
system_integrity_check
Purpose
Detect and respond to system health issues or policy violations.
Typical Use Cases
• automation failures
• schema inconsistencies
• API failures
• executor malfunction
Example
SIT Brain detects automation failure.
Origin Brain
SIT Brain
Receiving Authority
HeadOffice visibility triggered.
intelligence_update
Purpose
Update the ecosystem knowledge base.
Typical Use Cases
• newsletter insights
• course absorption results
• market trend updates
• performance insights
Example
Research Brain uploads new intelligence report.
Origin Brain
Research Brain
Receiving System
Knowledge Database
Task Status Standard
All tasks must include a status field.
Recognised statuses include:
• pending
• in_progress
• completed
• failed
• cancelled
• escalated
This ensures all work can be tracked.
Required Task Fields
Every MWMS task must include the following fields:
• Task ID
• Task Type
• Originating Brain
• Receiving Brain or System
• Task Description
• Status
• Timestamp Created
• Timestamp Updated
• Result or Output
These fields ensure complete system traceability.
Task Escalation Rule
If a task:
• fails repeatedly
• exceeds authority boundaries
• affects capital risk
• threatens system integrity
The task must be escalated to:
HeadOffice
Human review may be required.
Task Creation Authority
Tasks may be created by:
• Brains
• AI employees
• executors
• human operators
However, all tasks must follow the MWMS task type standard.
No free-form task types are allowed.
Relationship to Other Canon Documents
This document operates alongside:
• MWMS – Brain Interaction Protocol
• MWMS Authority Structure
• MWMS – System Architecture
• How to Start a Session – MWMS Operating Guide
These documents together define:
• who controls decisions
• how systems are wired
• how Brains interact
• how work is executed
Mental Model
Authority Structure
Defines control hierarchy.
System Architecture
Defines technical wiring.
Brain Interaction Protocol
Defines communication between Brains.
Task Types Standard
Defines the language of work.
Together they form the operational backbone of MWMS.
Final Principle
A structured system requires structured work.
Tasks are the operational language of MWMS.
Standard task types ensure the ecosystem functions as a coordinated AI organisation rather than disconnected tools.
Final Rule
If a task type is not formally recognised here, it is not part of the governed operational language of MWMS.
Convenience must not create unofficial task types.
Drift Protection
The system must prevent:
• free-form task types being invented ad hoc
• the same kind of work being labelled differently across Brains
• executors interpreting similar tasks inconsistently
• task routing ambiguity caused by vague or overlapping labels
• audit trails becoming unreliable because task meaning drifted
• informal work language replacing governed task language
Task types must remain stable, limited, and explicitly governed.
Architectural Intent
MWMS – Task Types Standard exists to give MWMS a shared operational language for work.
Its role is to ensure that requests, tasks, executors, and audit systems all refer to the same categories of work consistently so the ecosystem can scale with predictable behaviour instead of naming drift and execution ambiguity.
Change Log
Version: v1.1
Date: 2026-03-15
Author: MWMS HeadOffice
Change: Rebuilt page to align with the locked MWMS document standard for this cleanup pass. Preserved the original purpose, core principle, task-architecture view, recognised task types, task-status standard, required task fields, escalation rule, task-creation authority, related-document logic, mental model, and final principle. Added Document Type, Parent, Scope, Definition / Rules structure, Final Rule, Drift Protection, and Architectural Intent sections.
Version: v1.0
Date: 2026-03-13
Author: MWMS HeadOffice
Change: Initial creation of MWMS – Task Types Standard defining the standardised task types used within the MWMS ecosystem.
END – MWMS – TASK TYPES STANDARD v1.1