MWMS AI Command And Trigger Framework

System: MWMS
Document Type: Framework
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, Course Absorption System, Newsletter Intelligence, Opportunity System, Dev Console, 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 Command And Trigger Framework.

This framework explains how MWMS uses commands, workflow triggers, event triggers, and scheduled triggers to start AI workflows safely.

As MWMS grows, workflows should not always require long manual explanations.

MWMS needs clean ways to activate repeatable workflows such as:

course absorption
newsletter review
Agentic Work Unit creation
AI output validation
M developer handoff preparation
offer routing
research requests
finance review
failure logging
outcome logging
weekly HeadOffice reporting
Kaizen reporting
future AIBS client reporting

Commands and triggers become controlled entry points into the MWMS AI workforce.

They are not shortcuts around governance.

A command or trigger should never bypass:

Brain ownership
context requirements
skill requirements
tool permission rules
validation gates
human review
failure handling
outcome logging
M’s active build boundaries

This framework ensures commands and triggers activate governed workflows, not uncontrolled automation.

Scope

This framework applies to all command-triggered, event-triggered, manual-triggered, and scheduled AI workflow activation across MWMS.

This includes triggers used by:

HeadOffice Brain
Brain Room
AI Manager
AI Employee Router
Task Executor systems
Dev Console
Newsletter Intelligence
Course Absorption
Opportunity System
Affiliate Brain
Research Brain
Experimentation Brain
Finance Brain
Content Brain
Ads Brain
Sales Brain
Conversion Brain
Operations Brain
AI Business Systems Brain
future AIBS client systems

This framework applies before any command, slash command, button, automation trigger, webhook, scheduled run, recurring task, queue event, dashboard action, or future client workflow trigger is treated as operational.

This framework does not authorize immediate development work.

It defines the governance logic for commands and triggers before any plugin, UI, automation, or Task Executor build.

Core Definition

An AI Command is a deliberate instruction that starts a predefined workflow.

An AI Trigger is an event, schedule, action, message, file, system state, or condition that starts a predefined workflow.

A command is usually human-initiated.

A trigger may be human-initiated, system-initiated, event-based, or time-based.

Examples:

/absorb-course
/review-newsletter
/create-work-unit
/validate-output
/prepare-m-handoff
/route-offer
/log-failure
/log-outcome
/weekly-headoffice-report

A command or trigger should define:

what workflow starts
who or what may start it
required input
assigned AI Employee
required skill
required context
tool permission boundary
validation level
human review requirement
output expected
handoff destination
stop conditions
logging requirement
expected outcome

A command is not just text.

A command is a controlled doorway into a workflow.

Core Principle

The core principle of this framework is:

Commands and triggers must activate governed workflows, not bypass governance.

A command should not mean:

“AI, do whatever seems right.”

A command should mean:

“Start this approved workflow, with this required context, under this role, with this validation and handoff path.”

The stronger MWMS becomes, the more important this rule becomes.

Uncontrolled commands create chaos.

Governed commands create leverage.

Command And Trigger Types

MWMS recognizes five command and trigger types.

1. Manual Command Trigger

A manual command trigger is started deliberately by a human.

Examples:

Martyn types /absorb-course
Martyn types /validate-output
M uses a Dev Console command
HeadOffice requests a weekly report
a future client operator runs a report command

Best used for:

controlled workflows
high-context work
work requiring human judgment
work not ready for automation
early-stage workflow proof

Rule:

Manual commands are the safest starting point for new AI workflows.

Manual proof should happen before event triggers or scheduled triggers are introduced.

2. Slash Command Trigger

A slash command is a short command phrase used to start a predefined workflow.

Examples:

/absorb-course
/review-newsletter
/create-agentic-work-unit
/prepare-handoff
/validate-page
/log-failure
/log-outcome
/route-signal
/prepare-weekly-report

Slash commands are useful because they:

reduce repeated explanation
standardize workflow entry
make operator behaviour consistent
help future UI/plugin design
make workflow routing easier

Rule:

A slash command must map to one approved workflow.

If a slash command can mean five different things, it is not ready.

3. Event Based Trigger

An event-based trigger starts when something happens.

Examples:

new Gmail newsletter arrives with the MWMS-News label
new Brain Room message is posted
new offer enters Opportunity Intake
new Supabase row appears
new file is uploaded
new task status changes
validation fails
M completes a task
a dashboard item becomes urgent

Best used for:

repeatable workflows
queue-based systems
review pipelines
controlled automation
workflow status movement

Rule:

Event-based triggers require stronger validation than manual commands because they may run without human explanation.

4. Time Based Trigger

A time-based trigger runs on a schedule.

Examples:

daily newsletter digest
weekly HeadOffice report
weekly Kaizen Digest
weekly AI Employee outcome report
monthly offer pipeline review
monthly content refresh report
future client weekly report

Best used for:

recurring reporting
operational summaries
monitoring
digest creation
performance review
governance review

Rule:

Scheduled workflows require monitoring, failure handling, and clear output expectations.

A scheduled report that produces weak output every week becomes automated clutter.

5. Conditional Trigger

A conditional trigger runs only when a condition is met.

Examples:

notify HeadOffice if a high-priority signal appears
trigger validation if a page draft is marked ready
create failure log if automation output is missing required fields
send offer to Finance Brain only if payout data exists
escalate if M would need to guess
park newsletter signal if confidence is low
trigger human review if risk is high

Best used for:

safety gates
escalation logic
failure handling
risk controls
review workflows
future Task Executor rules

Rule:

Conditional triggers must be conservative.

When uncertainty exists, the trigger should route to review, not action.

Command Governance Layers

Every command or trigger must be governed through the following layers.

1. Command Identity

Each command must have a clear identity.

Command identity includes:

command name
command type
workflow triggered
owning Brain
assigned AI Employee
status
version
last reviewed

Good command names:

/absorb-course
/review-newsletter
/create-work-unit
/validate-output
/prepare-m-handoff
/route-offer
/log-failure
/weekly-headoffice-report

Bad command names:

/do-it
/fix
/run-ai
/next
/auto
/smart-task

Command Identity Rule:

A command name should make the workflow obvious.

2. Workflow Mapping

Every command must map to a defined workflow.

Examples:

/absorb-course maps to Course Absorption Workflow.
/review-newsletter maps to Newsletter Intelligence Review Workflow.
/prepare-m-handoff maps to Developer Support Workflow.
/validate-output maps to AI Output Validation Workflow.
/log-failure maps to AI Agent Failure Handling Workflow.
/log-outcome maps to AI Agent Outcome Logging Workflow.

Workflow Mapping Rule:

No command should exist without a workflow behind it.

If the workflow does not exist, the command remains proposed or parked.

3. Input Requirement

Every command must define required input.

Examples:

/absorb-course requires:

course file, transcript, or pasted block
course name or lesson reference where available
current absorption context

/prepare-m-handoff requires:

exact issue
screenshot or file evidence where needed
site/domain
current save point
what not to touch

/review-newsletter requires:

newsletter source
subject
sender
body or cleaned body
date if available

Input Requirement Rule:

If required input is missing, the command should not proceed as final output.

It may proceed only to clarification, normalization, draft, park, or escalation.

4. Context Requirement

Every command must define required context.

Context may include:

source of truth
owning Brain
relevant standards
current workflow stage
previous decisions
current save point
developer boundary
tool permission boundary
validation level
risk level
output destination

Context Requirement Rule:

A command without context produces guesswork.

Commands should load or request the right context before processing.

5. AI Employee Assignment

Every command should assign the correct AI Employee or role chain.

Examples:

/absorb-course may assign:

Course Absorption Agent
HeadOffice Validation Agent
Router Agent

/prepare-m-handoff may assign:

Developer Support Agent
Reviewer Agent
Validator Agent

/weekly-headoffice-report may assign:

Recurring Report Generator Agent
Analyst Agent
Reviewer Agent
Outcome Logger Agent

AI Employee Assignment Rule:

Commands must route to roles, not generic AI.

6. Skill Requirement

Every command should activate a known skill or skill chain.

Examples:

/absorb-course may use:

Course Absorption Value Extraction Skill
MCR Duplicate Risk Check Skill
Full Page Output Creation Skill

/review-newsletter may use:

Newsletter Signal Filtering Skill
Brain Routing Skill
Dashboard Readiness Skill

/prepare-m-handoff may use:

Developer Handoff Precision Skill
Exchange Zone Control Skill
Ambiguity Containment Skill

Skill Requirement Rule:

A command should activate a skill, not force the AI Employee to invent the procedure.

7. Permission Boundary

Commands and triggers must define permission boundaries.

Permission boundary examples:

Provided Input Only
Read Only
Draft Creation Only
Controlled Write
Human Review Before Action
No External Action
No Delete
No Live System Change

Permission Boundary Rule:

A command cannot grant tool access by itself.

Tool access must follow the MWMS AI Tool Permission Record Template.

8. Output Requirement

Every command must define expected output.

Output examples:

full page output
course absorption report
newsletter intelligence record
Agentic Work Unit
validation report
developer handoff brief
failure log
outcome log
routing recommendation
weekly report
dashboard item
client report draft

Output Requirement Rule:

If the output format is undefined, the command is not ready.

9. Validation Requirement

Every meaningful command must define validation level.

Validation levels:

Light Validation
Structured Validation
Operational Validation
High Risk Validation
Critical Validation

Examples:

/validate-output obviously requires validation.
/prepare-m-handoff requires High Risk Validation.
/absorb-course requires Operational Validation before MCR save.
/weekly-headoffice-report requires report usefulness review.
/route-offer requires evidence and Brain routing validation.

Validation Requirement Rule:

Commands may start workflows, but validation decides whether outputs move forward.

10. Human Review Requirement

Commands must define when human review is required.

Human review is required before:

MCR canon changes
developer handoff to M
live system changes
Supabase writes outside approved workflows
paid traffic decisions
finance decisions
public content
client-facing output
high-risk automation

Human Review Rule:

Command convenience must never remove required human review.

11. Stop Conditions

Every command must define stop conditions.

Stop conditions may include:

required input missing
source incomplete
source of truth unclear
Brain ownership unclear
risk level high
tool permission unclear
validation fails
M would need to guess
duplicate page risk
compliance risk
finance risk
client data risk
output confidence low
workflow not approved

Stop Condition Rule:

A good command knows when not to continue.

12. Logging And Outcome Requirement

Commands should define what must be logged.

Logging may include:

command run
source processed
output created
validation status
handoff created
failure found
outcome created
human approval recorded
workflow parked or rejected

Logging Rule:

Important command-triggered work must leave a trace.

Outcome Rule:

A command is useful only if it produces or supports a useful outcome.

Command Record Template

Use this template when defining a new MWMS command.

Command Name

Field:
Command Name:

Command Type

Field:
Command Type:

Recommended values:

Manual Command
Slash Command
Event Based Trigger
Time Based Trigger
Conditional Trigger

Command Purpose

Field:
Command Purpose:

Workflow Triggered

Field:
Workflow Triggered:

Owning Brain

Field:
Owning Brain:

Assigned AI Employee

Field:
Assigned AI Employee:

Supporting AI Employees

Field:
Supporting AI Employees:

Required Input

Field:
Required Input:

Required Context

Field:
Required Context:

Required Skill

Field:
Required Skill:

Tool Permission Boundary

Field:
Tool Permission Boundary:

Approved Actions

Field:
Approved Actions:

Forbidden Actions

Field:
Forbidden Actions:

Expected Output

Field:
Expected Output:

Validation Requirement

Field:
Validation Requirement:

Human Review Requirement

Field:
Human Review Requirement:

Handoff Destination

Field:
Handoff Destination:

Stop Conditions

Field:
Stop Conditions:

Logging Requirement

Field:
Logging Requirement:

Expected Outcome

Field:
Expected Outcome:

Command Status

Field:
Command Status:

Recommended values:

Proposed
Draft
Manual Use
Proven Manual Use
Assisted Use
Controlled Automation Candidate
Controlled Automation
Parked
Deprecated
Retired

Command Version

Field:
Command Version:

Last Reviewed

Field:
Last Reviewed:

Quick Use Version

Command Name:
Command Type:
Command Purpose:
Workflow Triggered:
Owning Brain:
Assigned AI Employee:
Supporting AI Employees:
Required Input:
Required Context:
Required Skill:
Tool Permission Boundary:
Approved Actions:
Forbidden Actions:
Expected Output:
Validation Requirement:
Human Review Requirement:
Handoff Destination:
Stop Conditions:
Logging Requirement:
Expected Outcome:
Command Status:
Command Version:
Last Reviewed:

Trigger Record Template

Use this template when defining a non-manual workflow trigger.

Trigger Name

Field:
Trigger Name:

Trigger Type

Field:
Trigger Type:

Recommended values:

Event Based Trigger
Time Based Trigger
Conditional Trigger

Trigger Event Or Condition

Field:
Trigger Event Or Condition:

Workflow Started

Field:
Workflow Started:

Owning Brain

Field:
Owning Brain:

Source System

Field:
Source System:

Examples:

Gmail
Brain Room
Supabase
WordPress
Make.com
n8n
Google Sheets
Dashboard
AI Manager
Task Executor
Client System

Required Input Payload

Field:
Required Input Payload:

Required Pre Checks

Field:
Required Pre Checks:

AI Employee Assigned

Field:
AI Employee Assigned:

Permission Boundary

Field:
Permission Boundary:

Output Created

Field:
Output Created:

Validation Gate

Field:
Validation Gate:

Human Review Gate

Field:
Human Review Gate:

Failure Handling

Field:
Failure Handling:

Logging Destination

Field:
Logging Destination:

Trigger Status

Field:
Trigger Status:

Recommended values:

Proposed
Draft
Manual Proof
Assisted Use
Controlled Automation Candidate
Controlled Automation
Suspended
Parked
Deprecated
Retired

Quick Trigger Version

Trigger Name:
Trigger Type:
Trigger Event Or Condition:
Workflow Started:
Owning Brain:
Source System:
Required Input Payload:
Required Pre Checks:
AI Employee Assigned:
Permission Boundary:
Output Created:
Validation Gate:
Human Review Gate:
Failure Handling:
Logging Destination:
Trigger Status:

Example Commands

Example 1: Course Absorption Command

Command Name:
/absorb-course

Command Type:
Slash Command / Manual Command

Command Purpose:
Start the course absorption workflow for uploaded or pasted course material.

Workflow Triggered:
Course Absorption Workflow

Owning Brain:
HeadOffice Brain

Assigned AI Employee:
Course Absorption Agent

Supporting AI Employees:
Input Normalizer, Reviewer Agent, Validator Agent, Router Agent

Required Input:
Course file, transcript, pasted block, lesson title, or course description.

Required Context:
Course Absorption System v2, MCR source-of-truth rule, anti-duplication rule, current course context, M development boundary.

Required Skill:
Course Absorption Value Extraction Skill

Tool Permission Boundary:
Provided Input Only unless approved file analysis is required.

Approved Actions:

review source material
extract MWMS system value
recommend absorb, update, park, ignore, or reject
create full page output if justified

Forbidden Actions:

do not save directly to MCR
do not create duplicate pages
do not absorb weak material
do not create developer work unless requested

Expected Output:
Course absorption verdict and full page output if justified.

Validation Requirement:
Operational Validation.

Human Review Requirement:
Required before MCR save.

Handoff Destination:
MCR, Parking System, relevant Brain, or Archive.

Stop Conditions:

source incomplete
duplicate page risk
weak content
unclear Brain mapping
M active build affected

Logging Requirement:
Required if absorbed.

Expected Outcome:
MWMS Brain improves or weak material is rejected.

Command Status:
Manual Use

Command Version:
v1.0

Last Reviewed:
YYYY-MM-DD

Example 2: Newsletter Review Command

Command Name:
/review-newsletter

Command Type:
Slash Command / Manual Command / Event Based Trigger Candidate

Command Purpose:
Review newsletter content for business-relevant MWMS signals.

Workflow Triggered:
Newsletter Intelligence Workflow

Owning Brain:
HeadOffice Brain

Assigned AI Employee:
Newsletter Signal Extraction Agent

Supporting AI Employees:
Input Cleaner, Analyst Agent, Reviewer Agent, Router Agent

Required Input:
Newsletter subject, sender, date, body, snippet, source.

Required Context:
HeadOffice Newsletter Intelligence Operating Protocol, Brain Routing Rule, business relevance filter, action categories, dashboard readiness rules.

Required Skill:
Newsletter Signal Filtering Skill

Tool Permission Boundary:
Read Only or Controlled Write only inside approved workflow.

Approved Actions:

clean newsletter noise
extract business signal
assign primary Brain
recommend action type
recommend ACT NOW, TEST, MONITOR, PARK, or REJECT

Forbidden Actions:

do not create downstream tasks without review
do not mark generic news urgent
do not treat sponsor content as business signal
do not route weak signals to dashboard

Expected Output:
Newsletter intelligence report or queue-ready record.

Validation Requirement:
Operational Validation.

Human Review Requirement:
Required before downstream action.

Handoff Destination:
Newsletter Queue Review, HeadOffice Dashboard candidate, Routed Actions, Parking System, or Rejected Archive.

Stop Conditions:

body incomplete
source unclear
signal generic
compliance or paid traffic risk
current verification required

Logging Requirement:
Required.

Expected Outcome:
Useful intelligence routed; noise parked or rejected.

Command Status:
Assisted Use

Command Version:
v1.0

Last Reviewed:
YYYY-MM-DD

Example 3: M Handoff Command

Command Name:
/prepare-m-handoff

Command Type:
Slash Command / Manual Command

Command Purpose:
Prepare exact developer handoff instructions for M.

Workflow Triggered:
Developer Support Workflow

Owning Brain:
HeadOffice Brain

Assigned AI Employee:
Developer Support Agent

Supporting AI Employees:
Evidence Extractor, Analyst Agent, Writer Agent, Reviewer Agent, Validator Agent

Required Input:
Exact issue, screenshot or file evidence, site/domain, current save point, what not to touch.

Required Context:
Full File Output Rule, developer boundary, current evidence, M’s active build state, test requirement.

Required Skill:
Developer Handoff Precision Skill

Tool Permission Boundary:
Provided Input Only unless file/system read access is approved.

Approved Actions:

review provided evidence
identify known gaps
draft exact developer instruction
include file path where available
include test steps and expected result

Forbidden Actions:

do not guess file paths
do not alter live code
do not touch unrelated systems
do not send vague instructions to M
do not ignore visible evidence

Expected Output:
Developer handoff brief or full file output.

Validation Requirement:
High Risk Validation.

Human Review Requirement:
Always required.

Handoff Destination:
M, Dev Console, Brain Room, or HeadOffice Review.

Stop Conditions:

file path missing
file contents missing
current state unclear
live risk detected
M would need to guess

Logging Requirement:
Required for meaningful development work.

Expected Outcome:
M can act safely without ambiguity.

Command Status:
Manual Use

Command Version:
v1.0

Last Reviewed:
YYYY-MM-DD

Example 4: Output Validation Command

Command Name:
/validate-output

Command Type:
Slash Command / Manual Command

Command Purpose:
Validate AI output before it is saved, routed, displayed, sent, built, or acted upon.

Workflow Triggered:
AI Output Validation Workflow

Owning Brain:
HeadOffice Brain

Assigned AI Employee:
HeadOffice Validation Agent

Supporting AI Employees:
Reviewer Agent, Failure Handler Agent, Router Agent

Required Input:
AI output, original task, source material, destination, risk level, relevant standard.

Required Context:
AI Output Validation Standard, AI Output Validation Checklist, Brain ownership, source of truth, human review rules.

Required Skill:
Output Validation Skill

Tool Permission Boundary:
Provided Input Only unless source read access is approved.

Approved Actions:

check task alignment
check source grounding
check output format
check Brain routing
check risk and human review requirements
produce pass, revise, reject, park, or escalate verdict

Forbidden Actions:

do not approve high-risk final action alone
do not ignore missing source
do not validate unsupported assumptions as facts
do not bypass human review

Expected Output:
Validation report with decision state.

Validation Requirement:
Structured, Operational, High Risk, or Critical depending on output.

Human Review Requirement:
Required for high-risk work.

Handoff Destination:
HeadOffice Review, Revision, Parking System, Failure Log, or Approved Next Step.

Stop Conditions:

source missing
output unsupported
risk unclear
destination unclear
human approval required

Logging Requirement:
Required for important validation.

Expected Outcome:
Weak outputs are stopped before becoming operational truth.

Command Status:
Manual Use

Command Version:
v1.0

Last Reviewed:
YYYY-MM-DD

Example 5: Weekly HeadOffice Report Command

Command Name:
/weekly-headoffice-report

Command Type:
Slash Command / Time Based Trigger Candidate

Command Purpose:
Generate a weekly HeadOffice operational intelligence report.

Workflow Triggered:
Recurring Intelligence And Reporting Workflow

Owning Brain:
HeadOffice Brain

Assigned AI Employee:
Recurring Report Generator Agent

Supporting AI Employees:
Analyst Agent, Reviewer Agent, Outcome Logger Agent, Failure Handler Agent

Required Input:

newsletter intelligence summary
routed actions
open priorities
system failures
AI Employee outcomes
Kaizen notes
MCR changes
active risks

Required Context:
HeadOffice operating priorities, current system status, reporting format, dashboard status, validation rules.

Required Skill:
Recurring Report Generation Skill

Tool Permission Boundary:
Read Only or Provided Input Only until controlled reporting workflow is approved.

Approved Actions:

summarize validated weekly signals
identify priorities
identify risks
identify decisions needed
prepare report draft

Forbidden Actions:

do not invent missing data
do not include unvalidated dashboard noise
do not create tasks without review
do not send final report externally without approval

Expected Output:
Weekly HeadOffice report draft.

Validation Requirement:
Operational Validation.

Human Review Requirement:
Required before action or external delivery.

Handoff Destination:
HeadOffice Review, Dashboard, Brain Room, or Archive.

Stop Conditions:

required source data missing
report includes unvalidated claims
urgent issue requires escalation
scheduled workflow failed

Logging Requirement:
Required.

Expected Outcome:
HeadOffice gains a clear weekly view of priorities, risks, signals, and next actions.

Command Status:
Proposed / Draft

Command Version:
v1.0

Last Reviewed:
YYYY-MM-DD

Example Event Triggers

Example 1: Gmail Newsletter Trigger

Trigger Name:
New Gmail Newsletter Label Trigger

Trigger Type:
Event Based Trigger

Trigger Event Or Condition:
New email receives approved MWMS newsletter label.

Workflow Started:
Newsletter Intelligence Workflow

Owning Brain:
HeadOffice Brain

Source System:
Gmail / Make.com

Required Input Payload:
Sender, subject, date, body, snippet, label.

Required Pre Checks:

body exists
source label is approved
email is relevant
duplicate not already processed

AI Employee Assigned:
Newsletter Signal Extraction Agent

Permission Boundary:
Gmail Read Only, controlled Supabase write if approved.

Output Created:
Newsletter intelligence record or review queue item.

Validation Gate:
Operational Validation before downstream action.

Human Review Gate:
Required before routing into action.

Failure Handling:
If body missing, JSON parse fails, or fields are vague, stop and log failure.

Logging Destination:
Make execution history, Supabase record, HeadOffice review queue.

Trigger Status:
Assisted Use

Example 2: Brain Room Task Trigger

Trigger Name:
Brain Room Task Candidate Trigger

Trigger Type:
Event Based Trigger / Conditional Trigger

Trigger Event Or Condition:
Brain Room message appears to contain a task, decision, issue, or workflow request.

Workflow Started:
Brain Room Task Conversion Workflow

Owning Brain:
HeadOffice Brain

Source System:
Brain Room

Required Input Payload:
Message text, sender, thread context, timestamp, related Brain if known.

Required Pre Checks:

message is actionable
task type can be classified
risk level can be estimated
not casual chat only

AI Employee Assigned:
Brain Room Task Builder Agent

Permission Boundary:
Draft Creation Only until task creation workflow is approved.

Output Created:
Agentic Work Unit draft.

Validation Gate:
Structured Validation before task creation.

Human Review Gate:
Required for medium/high-risk tasks.

Failure Handling:
If task is unclear, request clarification or park.

Logging Destination:
Brain Room thread, task log if created.

Trigger Status:
Draft / Future Use

Example 3: Validation Failure Trigger

Trigger Name:
AI Output Validation Failure Trigger

Trigger Type:
Conditional Trigger

Trigger Event Or Condition:
An AI output fails validation or requires significant revision.

Workflow Started:
Failure Handling Workflow

Owning Brain:
HeadOffice Brain

Source System:
Validation workflow

Required Input Payload:
Failed output, validation notes, source, task, risk level.

Required Pre Checks:

failure category identified
severity estimated
containment needed

AI Employee Assigned:
Failure Handler Agent

Permission Boundary:
Draft failure log and escalation recommendation only.

Output Created:
Failure Log Record or revision request.

Validation Gate:
Failure classification review.

Human Review Gate:
Required for serious or critical failures.

Failure Handling:
Contain, escalate, correct, revalidate, log, learn.

Logging Destination:
AI Agent Failure Log Record, HeadOffice review.

Trigger Status:
Manual Use / Future Candidate

Command And Trigger Readiness Checklist

Before approving a command or trigger, check:

Is the command or trigger name clear?
Is the type defined?
Is the workflow triggered known?
Is the owning Brain clear?
Is the assigned AI Employee clear?
Is the required skill defined?
Is required input clear?
Is required context clear?
Is the tool permission boundary defined?
Are approved actions explicit?
Are forbidden actions explicit?
Is expected output defined?
Is validation requirement defined?
Is human review requirement clear?
Is handoff destination defined?
Are stop conditions listed?
Is logging required?
Is expected outcome clear?
Has manual proof happened?
Is automation premature?
Could this affect M’s active build?
Could this affect MCR, money, compliance, public content, or clients?
Does this command duplicate another command?
Is the command too broad?
Should this remain manual?

If several answers are unclear, the command or trigger is not ready.

Common Command And Trigger Failure Modes

Command and trigger governance has failed if:

A command starts a vague workflow.
A command does not define required input.
A command relies on old memory instead of current context.
A slash command maps to multiple unrelated workflows.
A trigger runs before manual proof.
An event trigger creates downstream tasks without review.
A scheduled trigger produces recurring low-quality output.
Tool permissions are assumed.
Human review is bypassed.
Stop conditions are missing.
Failures are not logged.
Output has no destination.
Commands create MCR clutter.
Commands create vague work for M.
Commands produce activity but no outcome.

Manual Use Rule

Commands and triggers should be manually proven before automation.

Manual use helps MWMS learn:

whether the command is clear
whether required input is realistic
whether the workflow actually produces value
whether the output format works
where validation fails
where context is missing
whether stop conditions are correct
whether the command is too broad
whether automation is justified later

Manual command discipline comes before UI buttons, slash command systems, event triggers, or scheduled automation.

Future Plugin Or UI Relevance

This framework may later support:

Brain Room slash commands
AI Manager command registry
AI Employee Router command mapping
Task Executor trigger rules
HeadOffice command panel
Dev Console command shortcuts
Newsletter Intelligence triggers
Course Absorption command workflows
Opportunity System workflow buttons
Recurring report scheduler
AIBS client command library

Possible future fields:

command_id
command_name
command_type
command_purpose
workflow_triggered
owning_brain
assigned_ai_employee
supporting_ai_employees
required_input
required_context
required_skill
tool_permission_boundary
approved_actions
forbidden_actions
expected_output
validation_requirement
human_review_requirement
handoff_destination
stop_conditions
logging_requirement
expected_outcome
command_status
command_version
last_reviewed
trigger_id
trigger_name
trigger_type
trigger_event_or_condition
source_system
required_input_payload
required_pre_checks
output_created
validation_gate
human_review_gate
failure_handling
logging_destination
created_at
updated_at

No technical build is authorized by this framework alone.

Governance Role

HeadOffice owns the MWMS AI Command And Trigger Framework.

HeadOffice is responsible for:

approving command and trigger governance
preventing command sprawl
preventing unsafe automation triggers
ensuring commands map to workflows
ensuring commands use the right AI Employees and skills
ensuring tool permissions are respected
ensuring validation gates remain in place
ensuring human review is not bypassed
ensuring scheduled workflows are monitored
protecting M’s active build areas
protecting MCR source of truth
protecting future AIBS client systems

Individual Brains may propose commands and triggers, but HeadOffice governs cross-Brain, high-risk, tool-enabled, scheduled, automation-related, and client-facing triggers.

Relationship To Other MWMS Standards

This framework supports and must align with:

MWMS AI Agent Operations Core
MWMS AI Multi Agent Role Design Framework
MWMS AI Exchange Zone And Dependency Control Framework
MWMS AI Ambiguity And Partial Failure Containment Framework
MWMS AI Agent Skill Library Framework
MWMS AI Plugin Orchestration Framework
MWMS AI Documentation Automation Pipeline Framework
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 AI Agent Deployment Readiness Checklist
MWMS AI Agent Deployment Readiness Review Template
MWMS Brain Routing Rule
MWMS Brain To Brain Request Protocol
MWMS Supabase Event Schema
AI Business Systems Brain Blueprint

This framework adds the controlled command and trigger activation layer to the MWMS AI Agent Operations Core.

Drift Protection

This framework protects MWMS from:

Creating random slash commands
Triggering workflows without context
Running automations before manual proof
Letting commands bypass validation
Letting triggers bypass human review
Treating command convenience as operational safety
Creating scheduled reports that produce recurring noise
Creating event triggers with no stop conditions
Allowing command sprawl across Brains
Giving commands tool access without permission records
Triggering M developer work from vague commands
Creating downstream tasks from weak inputs
Automating MCR page creation too early
Letting future client triggers run without approval gates
Measuring command activity instead of command outcomes

Any command or trigger without a governed workflow should remain proposed, draft, manual, parked, or rejected.

Architectural Intent

The architectural intent of the MWMS AI Command And Trigger Framework is to give MWMS safe control points for activating AI workflows.

MWMS will eventually need fast ways to start repeatable work.

But speed without control creates drift.

Commands and triggers should become the clean operating buttons of the MWMS AI workforce.

The long-term goal is that every command or trigger can answer:

What workflow does this start?
Who or what may start it?
What input is required?
What context is required?
Which AI Employee is assigned?
Which skill is used?
What tools are allowed?
What output is expected?
What validation is required?
Where does the output go?
When must the workflow stop?
What must be logged?
What outcome should be created?

When MWMS can answer those questions, commands and triggers become safe workflow activation systems instead of risky shortcuts.

Change Log

v1.0 — Initial Draft

Created the MWMS AI Command And Trigger Framework to define how MWMS governs slash commands, manual triggers, event-based triggers, time-based triggers, conditional triggers, workflow activation, required input, context, AI Employee assignment, skill use, permission boundaries, validation gates, human review, stop conditions, logging, and outcome requirements.

This framework establishes commands and triggers as controlled entry points into governed MWMS AI workflows, not shortcuts around governance.