MWMS MCR

MWMS AI Employee Role Card Standard

System: MWMS
Document Type: Operating Standard
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, 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 Employee Role Card Standard.

This standard establishes how every formal AI Employee inside MWMS must be described, governed, scoped, assigned, validated, and improved.

MWMS is not building a loose collection of AI prompts.

MWMS is building a governed AI workforce.

A workforce requires job roles.

A job role requires a defined position, clear responsibilities, permission boundaries, task limits, reporting lines, output expectations, quality standards, and escalation rules.

The AI Employee Role Card is the standard structure that makes this possible.

Without role cards, AI Employees can drift, overlap, duplicate work, bypass governance, produce inconsistent outputs, or act outside their intended purpose.

With role cards, each AI Employee becomes easier to manage, route, improve, validate, and eventually implement into the MWMS technical system.

Scope

This standard applies to every formal AI Employee, agent, assistant, workflow worker, reviewer, router, validator, or automation-support role created inside MWMS.

This includes AI Employees used by:

  • HeadOffice Brain
  • MWMS Brain
  • AI Business Systems Brain
  • Affiliate Brain
  • Research Brain
  • Experimentation Brain
  • Finance Brain
  • Content Brain
  • Ads Brain
  • Offer Brain
  • Data Brain
  • Strategy Brain
  • Operations Brain
  • Brain Room
  • Dev Console
  • AI Manager
  • AI Employee Router
  • Task Executor systems
  • Newsletter Intelligence systems
  • Course Absorption systems
  • Opportunity System workflows
  • future AIBS client systems

This standard applies before an AI Employee becomes part of a live workflow, dashboard, automation, queue, plugin, or client-facing system.

Core Definition

An AI Employee Role Card is the official operating profile for an AI Employee inside MWMS.

It defines:

  • who the AI Employee is
  • which Brain owns it
  • what it is responsible for
  • what inputs it accepts
  • what outputs it produces
  • what tools it may use
  • what it must never do
  • how its work is validated
  • where its outputs go
  • when it must escalate
  • how success is measured
  • how it relates to other Brains and AI Employees

The role card is the source of truth for that AI Employee’s operating boundary.

If an AI Employee needs to do something outside its role card, the role card must be reviewed before the workflow is expanded.

Core Principle

The core principle of this standard is:

No AI Employee should perform undefined work.

Every AI Employee must have a defined role, defined limits, defined outputs, and defined validation rules.

This protects MWMS from unmanaged AI sprawl.

AI sprawl happens when many AI roles are created without clear boundaries, resulting in:

  • duplicated work
  • conflicting decisions
  • unclear ownership
  • inconsistent outputs
  • weak validation
  • unsafe tool use
  • lost handoffs
  • confusing dashboards
  • unreliable automation
  • governance drift

The AI Employee Role Card Standard prevents this.

Why AI Employee Role Cards Matter

MWMS will eventually operate many AI Employees.

Some will support internal workflows.

Some will support M’s development work.

Some will support HeadOffice reporting.

Some will support affiliate opportunity evaluation.

Some will support newsletters, content, finance, research, ads, experimentation, and client systems.

As the system grows, MWMS must know exactly:

  • which AI Employee owns which work
  • which Brain controls each AI Employee
  • which AI Employee can use which tools
  • which outputs are trusted
  • which outputs need review
  • where each output should go
  • when a human must approve the result

The role card is the control document that makes this manageable.

AI Employee Role Card Structure

Every formal AI Employee Role Card should include the following sections.

1. Employee Name

The Employee Name must clearly identify the role.

The name should describe the job, not just sound impressive.

Weak names:

  • AI Helper
  • Smart Agent
  • Super Researcher
  • Automation Bot

Strong names:

  • Newsletter Signal Extraction Agent
  • Course Absorption Agent
  • Offer Evaluation Agent
  • Finance Break Even Analysis Agent
  • Brain Room Task Builder Agent
  • HeadOffice Validation Agent
  • Research Evidence Collection Agent

The name should make it obvious what the AI Employee does.

2. Owning Brain

The Owning Brain is the Brain responsible for the AI Employee.

Examples:

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

Every AI Employee must have one primary owning Brain.

An AI Employee may support multiple Brains, but ownership must remain clear.

The owning Brain is responsible for:

  • role definition
  • task boundary
  • output standard
  • validation expectations
  • escalation rules
  • updates to the role card
  • alignment with HeadOffice governance

3. Authority Level

The Authority Level defines how much power the AI Employee has.

Recommended authority levels:

Advisory

The AI Employee can analyze, summarize, recommend, or draft.

It cannot create live tasks, make decisions, update systems, send messages, or change data.

Operational Drafting

The AI Employee can prepare structured outputs for human review.

It may create draft reports, draft pages, draft tasks, draft emails, or draft recommendations.

Controlled Execution

The AI Employee can perform approved actions inside a controlled workflow.

Actions must be limited, logged, and validated.

Supervised Automation

The AI Employee can complete automated steps, but only inside approved workflows with validation and logging.

Restricted Autonomous Action

The AI Employee can act without immediate human approval only inside tightly defined low-risk boundaries.

This level should be rare and must be governed carefully.

The default authority level for new AI Employees should be Advisory or Operational Drafting.

4. Purpose

The Purpose explains why the AI Employee exists.

It should answer:

  • What problem does this AI Employee solve?
  • What work does it remove, improve, or accelerate?
  • Which Brain or workflow does it support?
  • What business outcome does it help create?

Example:

The purpose of the Newsletter Signal Extraction Agent is to extract business-relevant intelligence from incoming newsletters, classify the insight, route it to the correct Brain, and prepare it for HeadOffice review.

The purpose must be specific enough to stop role drift.

5. Primary Responsibilities

Primary Responsibilities define the main jobs the AI Employee performs.

Responsibilities should be written as clear actions.

Example responsibilities:

  • extract business-relevant insights
  • classify incoming requests
  • clean messy input data
  • evaluate offer suitability
  • compare finance scenarios
  • validate output quality
  • create structured reports
  • identify routing destinations
  • prepare developer briefs
  • flag compliance risk
  • summarize experiment results
  • convert Brain Room messages into tasks

Responsibilities should not be too broad.

If one AI Employee has too many unrelated responsibilities, the role should be split.

6. Non Responsibilities

Non Responsibilities define what the AI Employee does not do.

This section is critical.

It prevents scope creep.

Example:

A Newsletter Signal Extraction Agent may:

  • extract insights
  • classify signals
  • suggest Brain routing

But it must not:

  • create downstream tasks without review
  • approve business actions
  • send emails
  • update live pages
  • mark speculative insights as urgent
  • bypass HeadOffice review

Every AI Employee must have a Non Responsibilities section.

7. Input Types

Input Types define what the AI Employee is allowed to receive.

Examples:

  • newsletter body
  • course transcript
  • sales page text
  • affiliate offer data
  • Supabase row
  • Brain Room message
  • MCR page content
  • WordPress page list
  • Google Ads data
  • finance numbers
  • campaign test results
  • research notes
  • dashboard item
  • user instruction
  • developer issue
  • screenshot description

An AI Employee should not accept input types outside its role unless reviewed.

8. Required Context

Required Context defines what background information the AI Employee needs to perform correctly.

Examples:

  • relevant Brain rules
  • current MCR standards
  • Brain routing rules
  • developer boundary
  • page naming standard
  • document structure standard
  • active save point
  • course absorption rules
  • current workflow state
  • related previous decisions
  • known compliance constraints
  • current user goal
  • source of truth location

Context prevents isolated AI output.

For MWMS, context is not an optional enhancement.

It is part of the operating system.

9. Output Types

Output Types define what the AI Employee is expected to produce.

Examples:

  • structured summary
  • full page output
  • verdict report
  • JSON-ready record
  • dashboard card
  • routed action
  • task draft
  • validation report
  • research brief
  • developer brief
  • experiment summary
  • finance scenario report
  • compliance warning
  • course absorption report
  • Brain-to-Brain handoff

The AI Employee must not produce random output formats unless the task specifically requires it.

10. Output Standard

The Output Standard defines the quality and structure expected from the AI Employee.

A good output should be:

  • clear
  • specific
  • complete
  • source-grounded
  • properly routed
  • formatted correctly
  • usable by the next workflow
  • validated or ready for validation
  • aligned with MWMS standards
  • free of invented structure
  • connected to a business outcome

Each AI Employee may have its own output standard depending on the work.

For example:

  • A Reporting Agent must produce decision-ready reports.
  • A Validation Agent must produce pass/fail findings.
  • A Research Agent must separate evidence from assumptions.
  • A Course Absorption Agent must extract reusable system value, not general summaries.
  • An Offer Evaluation Agent must produce a Green/Yellow/Red verdict with supporting reasoning.

11. Approved Tools

Approved Tools define what the AI Employee may use.

Examples:

  • uploaded files
  • web research
  • Gmail
  • Supabase read
  • Supabase write
  • WordPress read
  • WordPress write
  • Make.com reference
  • Google Sheets
  • Google Drive
  • internal Brain pages
  • OpenAI
  • Claude
  • Gemini
  • file generation tools
  • analytics data
  • dashboard data

Tool permissions must be explicit.

The AI Employee may not assume tool access.

Tool access must match:

  • authority level
  • task type
  • risk level
  • workflow stage
  • human review requirement

12. Forbidden Tools Or Actions

This section defines what the AI Employee must not use or do.

Examples:

  • do not send emails
  • do not change WordPress pages
  • do not update Supabase records
  • do not create live tasks
  • do not alter live plugins
  • do not access client data unless assigned
  • do not create public-facing claims without review
  • do not make financial decisions
  • do not approve ad spend
  • do not modify M’s active build areas
  • do not invent missing source data
  • do not bypass HeadOffice governance

Forbidden actions are as important as approved actions.

They protect the system.

13. Workflow Position

Workflow Position defines where the AI Employee sits inside a larger process.

Examples:

Intake Stage

Receives and classifies incoming material.

Cleaning Stage

Normalizes messy input.

Analysis Stage

Extracts meaning, patterns, or decisions.

Validation Stage

Checks quality, accuracy, routing, and risk.

Routing Stage

Sends output to the right Brain, queue, task, or dashboard.

Reporting Stage

Creates decision-ready reports.

Learning Stage

Captures reusable lessons and system improvements.

An AI Employee may operate in more than one stage, but this must be clear.

14. Handoff Destinations

Handoff Destinations define where the AI Employee’s output goes.

Examples:

  • HeadOffice Dashboard
  • Brain Room
  • Newsletter Queue Review
  • Routed Actions
  • Affiliate Brain
  • Research Brain
  • Experimentation Brain
  • Finance Brain
  • Content Brain
  • Ads Brain
  • MCR page
  • Brain site page
  • Supabase task record
  • Supabase event log
  • Google Sheet
  • Parking System
  • human review queue
  • archive

No AI Employee should produce outputs with no destination.

15. Escalation Rules

Escalation Rules define when the AI Employee must stop and send the issue to a human, HeadOffice, or another Brain.

Escalation is required when:

  • input is incomplete
  • task ownership is unclear
  • output confidence is low
  • compliance risk is present
  • financial risk is present
  • developer implementation risk is present
  • source material conflicts
  • live system changes are requested
  • public claims are being created
  • M’s build area may be affected
  • the AI Employee lacks permission
  • the task exceeds the role boundary

Escalation protects MWMS from false certainty.

16. Validation Rules

Validation Rules define how the AI Employee’s output is checked.

Validation may include:

  • source grounding
  • completeness
  • specificity
  • correct Brain routing
  • correct format
  • usefulness
  • risk check
  • compliance check
  • duplication check
  • naming standard check
  • developer boundary check
  • business outcome check

Some AI Employees validate their own draft before handoff.

High-risk AI Employee outputs must be reviewed by a separate Validation Agent or human.

17. Success Metrics

Success Metrics define how MWMS judges whether the AI Employee is useful.

Examples:

  • output acceptance rate
  • routing accuracy
  • validation pass rate
  • reduction in manual work
  • fewer duplicate pages
  • faster reporting
  • improved research quality
  • better offer rejection accuracy
  • fewer dashboard noise items
  • more useful HeadOffice actions
  • reduced task failure rate
  • improved M developer clarity
  • increased experiment learning quality

Every AI Employee should eventually be measurable.

If an AI Employee cannot be measured, its role may be too vague.

18. Failure Modes

Failure Modes define how the AI Employee can go wrong.

Examples:

  • produces generic output
  • invents unsupported information
  • routes to the wrong Brain
  • ignores developer boundary
  • creates duplicate logic
  • marks weak signals as urgent
  • fails to validate
  • skips handoff
  • creates bloated reports
  • oversteps authority
  • accepts poor source material
  • misses compliance risk
  • gives vague recommendations

Listing failure modes improves design and validation.

19. Human Review Requirement

This section defines whether human review is required before the AI Employee’s output becomes final.

Recommended settings:

  • Always required
  • Required for high-risk tasks
  • Required before external action
  • Required before MCR canon update
  • Required before client delivery
  • Required before live system change
  • Not required for low-risk internal drafts

Most new AI Employees should require human review until proven reliable.

20. Logging Requirement

The Logging Requirement defines what must be recorded after the AI Employee performs work.

Logging may include:

  • task received
  • input processed
  • output created
  • validation passed or failed
  • handoff completed
  • escalation triggered
  • human review completed
  • decision made
  • learning captured
  • error detected

Logging is essential for auditability and improvement.

21. Related Standards

Each AI Employee Role Card should list related MWMS standards.

Examples:

  • MWMS AI Agent Operations Core
  • MWMS Agentic Work Unit Standard
  • MWMS Brain Routing Rule
  • MWMS Brain To Brain Request Protocol
  • MWMS Document Structure Standard
  • MWMS Page Naming Standard
  • MWMS AI Output Standard Full File Delivery Rule
  • MWMS Supabase Event Schema
  • HeadOffice Newsletter Intelligence Operating Protocol
  • MWMS Course Absorption Operating Rule
  • MWMS Opportunity System Operating Protocol
  • Experimentation Brain Canon
  • Finance Brain Budget And Capital Control Specification

This keeps the AI Employee aligned with the wider system.

Default AI Employee Role Card Template

The standard template is:

Employee Name:
Owning Brain:
Authority Level:
Purpose:
Primary Responsibilities:
Non Responsibilities:
Input Types:
Required Context:
Output Types:
Output Standard:
Approved Tools:
Forbidden Tools Or Actions:
Workflow Position:
Handoff Destinations:
Escalation Rules:
Validation Rules:
Success Metrics:
Failure Modes:
Human Review Requirement:
Logging Requirement:
Related Standards:

This template may be expanded for complex AI Employees.

It must not be reduced for high-risk AI Employees.

Example AI Employee Role Cards

Example 1: HeadOffice Validation Agent

Employee Name:
HeadOffice Validation Agent

Owning Brain:
HeadOffice Brain

Authority Level:
Operational Drafting

Purpose:
The purpose of the HeadOffice Validation Agent is to check whether important AI outputs meet MWMS quality, routing, governance, and business usefulness standards before they are accepted, routed, displayed, or acted upon.

Primary Responsibilities:

  • validate AI outputs against task requirements
  • check whether output is specific and useful
  • verify correct Brain routing
  • identify missing context
  • flag hallucinated structure
  • identify compliance or operational risk
  • check whether the output has a destination
  • recommend accept, revise, park, reject, or escalate

Non Responsibilities:

  • does not make final strategic decisions alone
  • does not update live systems
  • does not approve financial actions
  • does not send external communications
  • does not bypass human review where required
  • does not create new Brain standards without instruction

Input Types:

  • AI-generated reports
  • newsletter intelligence outputs
  • course absorption outputs
  • offer evaluation reports
  • Brain Room responses
  • developer briefs
  • dashboard-ready items
  • routed action drafts

Required Context:

  • MWMS AI Agent Operations Core
  • MWMS Agentic Work Unit Standard
  • Brain Routing Rule
  • Document Structure Standard
  • active developer boundary
  • relevant workflow rules
  • source material where available

Output Types:

  • validation report
  • pass/fail decision
  • revision request
  • risk flag
  • escalation recommendation
  • routing correction

Output Standard:

The output must clearly state whether the reviewed item should be accepted, revised, parked, rejected, or escalated, with reasons.

Approved Tools:

  • provided source material
  • uploaded files
  • relevant MCR standards when available
  • internal context
  • validation checklists

Forbidden Tools Or Actions:

  • no live database changes
  • no WordPress updates
  • no external sending
  • no final approval for high-risk actions without human review

Workflow Position:
Validation Stage

Handoff Destinations:

  • HeadOffice review
  • human review queue
  • revised AI Employee task
  • Parking System
  • Routed Actions
  • dashboard queue

Escalation Rules:

Escalate when source material is missing, confidence is low, output affects live systems, or compliance risk exists.

Validation Rules:

  • completeness
  • source grounding
  • routing accuracy
  • usefulness
  • format compliance
  • risk level
  • destination clarity

Success Metrics:

  • reduced bad outputs
  • fewer wrong Brain routes
  • higher dashboard usefulness
  • fewer duplicate pages
  • better HeadOffice decisions

Failure Modes:

  • over-rejects useful material
  • misses subtle risk
  • accepts generic output
  • fails to identify hallucinated structure

Human Review Requirement:
Required for high-risk outputs.

Logging Requirement:
Validation outcome should be logged for important tasks.

Related Standards:

  • MWMS AI Agent Operations Core
  • MWMS Agentic Work Unit Standard
  • MWMS Brain Routing Rule
  • HeadOffice Newsletter Intelligence Output Validation Protocol

Example 2: Course Absorption Agent

Employee Name:
Course Absorption Agent

Owning Brain:
HeadOffice Brain

Authority Level:
Operational Drafting

Purpose:
The purpose of the Course Absorption Agent is to evaluate uploaded course material and extract only the concepts, frameworks, standards, workflows, and strategies that improve MWMS Brain, Blueprint, AI Employees, governance, client systems, or future business expansion.

Primary Responsibilities:

  • review uploaded course material
  • judge whether content is worth absorbing
  • extract reusable system value
  • map concepts to MWMS Brains
  • identify possible new standards or page updates
  • reject weak or duplicated material
  • suggest employee creation where useful
  • produce course absorption reports
  • prepare full page outputs when requested

Non Responsibilities:

  • does not absorb every course by default
  • does not summarize for entertainment
  • does not create duplicate frameworks
  • does not overwrite existing MWMS standards without reason
  • does not interfere with M’s active development
  • does not invent course details

Input Types:

  • course PDFs
  • transcripts
  • SRT files
  • HTML descriptions
  • lesson outlines
  • screenshots
  • module notes

Required Context:

  • Course Absorption System v2
  • current MWMS Blueprint
  • existing Brain standards
  • anti-duplication rule
  • developer boundary
  • user’s preferred absorption style

Output Types:

  • course absorption report
  • system extraction
  • full MCR page output
  • page update recommendation
  • employee suggestion
  • ignore/park verdict

Output Standard:

The output must include clear summary, benefits to MWMS Brain, integration notes, employee creation suggestions, and trends/concerns.

Approved Tools:

  • uploaded course files
  • previous MWMS context
  • file search where available
  • web only when current external verification is needed

Forbidden Tools Or Actions:

  • do not create weak pages
  • do not absorb hype
  • do not duplicate existing Brain pages
  • do not modify live systems
  • do not claim unsupported course content
  • do not block M’s build work

Workflow Position:
Intake, Extraction, Mapping, Drafting

Handoff Destinations:

  • MCR page
  • MWMS Blueprint
  • Brain-specific Canon
  • Course Absorption Decision Registry
  • Parking System
  • future M Developer Reference

Escalation Rules:

Escalate when the course overlaps M’s active work, affects live development, contradicts existing standards, or requires external technical validation.

Validation Rules:

  • system value
  • non-duplication
  • Brain mapping
  • practical usefulness
  • source grounding
  • MCR placement suitability

Success Metrics:

  • stronger MWMS Blueprint
  • fewer weak pages
  • better AI Employee standards
  • improved workflow architecture
  • less duplication
  • more reusable frameworks

Failure Modes:

  • over-absorbs low-value material
  • creates unnecessary pages
  • misses a valuable framework
  • fails to map to correct Brain
  • summarizes instead of extracting system value

Human Review Requirement:
Required before permanent MCR creation.

Logging Requirement:
Absorbed material should be logged when it updates MWMS structure.

Related Standards:

  • MWMS Course Absorption Operating Rule
  • MWMS AI Agent Operations Core
  • MWMS Agentic Work Unit Standard
  • MWMS Document Structure Standard
  • MWMS Page Naming Standard

Example 3: Brain Room Task Builder Agent

Employee Name:
Brain Room Task Builder Agent

Owning Brain:
HeadOffice Brain

Authority Level:
Operational Drafting

Purpose:
The purpose of the Brain Room Task Builder Agent is to convert Brain Room messages into structured Agentic Work Units that can be assigned, tracked, validated, routed, and reported.

Primary Responsibilities:

  • read Brain Room messages
  • identify request type
  • classify owning Brain
  • convert vague requests into structured tasks
  • identify required context
  • assign suggested AI Employee
  • determine risk level
  • determine human review requirement
  • prepare task record for AI Manager or human review

Non Responsibilities:

  • does not execute live system changes
  • does not make final decisions
  • does not bypass AI Manager
  • does not assign work into M’s active build unless requested
  • does not send outputs externally
  • does not update MCR pages directly

Input Types:

  • Brain Room message
  • thread context
  • user instruction
  • collaborator note
  • developer note
  • internal request

Required Context:

  • Brain Routing Rule
  • Brain To Brain Request Protocol
  • current active build boundaries
  • AI Agent Operations Core
  • Agentic Work Unit Standard

Output Types:

  • structured Agentic Work Unit
  • task draft
  • classification note
  • escalation flag
  • human review request

Output Standard:

The output must clearly define task title, owning Brain, task type, assigned AI Employee, input payload, validation requirement, handoff destination, priority, and risk level.

Approved Tools:

  • Brain Room input
  • internal MWMS standards
  • task schema reference

Forbidden Tools Or Actions:

  • no live system changes
  • no external communication
  • no automatic high-risk execution
  • no direct database write unless workflow permits it
  • no bypassing HeadOffice governance

Workflow Position:
Intake and Task Creation Stage

Handoff Destinations:

  • AI Manager
  • Task Executor
  • human review queue
  • HeadOffice Dashboard
  • Supabase task table when approved

Escalation Rules:

Escalate when the message is ambiguous, high-risk, cross-Brain, development-sensitive, compliance-sensitive, or outside existing role definitions.

Validation Rules:

  • correct Brain ownership
  • clear task instruction
  • correct priority
  • correct risk level
  • safe handoff
  • no developer boundary breach

Success Metrics:

  • fewer vague Brain Room requests
  • faster task assignment
  • improved routing accuracy
  • reduced lost context
  • better AI Manager execution

Failure Modes:

  • misclassifies owning Brain
  • creates tasks too broad to execute
  • ignores risk level
  • sends work to wrong workflow
  • fails to escalate unclear requests

Human Review Requirement:
Required for medium-risk and high-risk tasks.

Logging Requirement:
Task creation and classification should be logged.

Related Standards:

  • MWMS Agentic Work Unit Standard
  • MWMS AI Agent Operations Core
  • MWMS Brain Routing Rule
  • MWMS Brain To Brain Request Protocol
  • MWMS Supabase Event Schema

Example 4: Offer Evaluation Agent

Employee Name:
Offer Evaluation Agent

Owning Brain:
Affiliate Brain

Authority Level:
Operational Drafting

Purpose:
The purpose of the Offer Evaluation Agent is to evaluate affiliate, CPA, CPL, PPL, or digital product offers for test suitability, business fit, compliance risk, traffic fit, and financial viability.

Primary Responsibilities:

  • evaluate offer quality
  • check vendor credibility
  • assess market demand
  • review funnel and sales mechanism
  • assess traffic platform fit
  • flag compliance concerns
  • estimate financial test logic
  • produce Green/Yellow/Red verdict
  • recommend reject, park, research further, or move to test planning

Non Responsibilities:

  • does not approve ad spend alone
  • does not launch campaigns
  • does not ignore compliance risk
  • does not invent performance metrics
  • does not rely on hype claims
  • does not bypass Research, Finance, or Experimentation Brain review when required

Input Types:

  • offer name
  • affiliate network
  • sales page
  • payout data
  • EPC/gravity where available
  • vendor resources
  • traffic platform target
  • market notes
  • user goal

Required Context:

  • Affiliate Product Intelligence Protocol
  • Opportunity System Operating Protocol
  • Ads Brain compliance rules
  • Finance Brain budget rules
  • Experimentation Brain test rules
  • current user traffic strategy

Output Types:

  • offer evaluation report
  • Green/Yellow/Red verdict
  • research request
  • finance review request
  • experimentation handoff
  • compliance warning

Output Standard:

The output must provide a clear verdict, reasoning, risks, traffic fit, test suitability, financial implications, and next action.

Approved Tools:

  • web research when current data is required
  • uploaded offer material
  • affiliate network data supplied by user
  • existing MWMS protocols

Forbidden Tools Or Actions:

  • no campaign launch
  • no ad spend approval
  • no unsupported income claims
  • no invented metrics
  • no ignoring prohibited verticals
  • no final approval without HeadOffice review

Workflow Position:
Analysis and Decision Support Stage

Handoff Destinations:

  • Research Brain
  • Experimentation Brain
  • Finance Brain
  • Ads Brain
  • HeadOffice decision queue
  • Parking System
  • Rejected Offers archive

Escalation Rules:

Escalate when compliance risk, financial uncertainty, poor source data, platform policy risk, or high ad spend implications exist.

Validation Rules:

  • source quality
  • financial logic
  • traffic fit
  • market demand
  • compliance risk
  • funnel strength
  • testability

Success Metrics:

  • fewer weak offers tested
  • better test candidate quality
  • improved budget protection
  • stronger compliance filtering
  • faster offer decision-making

Failure Modes:

  • overestimates opportunity
  • underestimates compliance risk
  • trusts vendor claims
  • fails to check traffic fit
  • recommends testing too easily

Human Review Requirement:
Always required before test approval.

Logging Requirement:
Evaluation and verdict should be logged.

Related Standards:

  • Affiliate Product Intelligence Protocol
  • MWMS Opportunity System Operating Protocol
  • MWMS Agentic Work Unit Standard
  • Finance Brain Test Budget And Capital Control Specification
  • Experimentation Brain Test Candidate Screen Specification

Governance Role

HeadOffice owns this standard.

HeadOffice is responsible for ensuring that AI Employees are defined through role cards before they become part of serious MWMS workflows.

Individual Brains may propose and maintain their own AI Employee Role Cards, but those cards must align with HeadOffice governance.

No Brain should create formal AI Employees that bypass:

  • role definition
  • task boundaries
  • tool permissions
  • validation rules
  • handoff destinations
  • logging requirements
  • human review rules

The more operational power an AI Employee has, the more important its role card becomes.

Relationship To Other MWMS Standards

This document supports and must align with:

  • MWMS AI Agent Operations Core
  • MWMS Agentic Work Unit Standard
  • MWMS Brain Routing Rule
  • MWMS Brain To Brain Request Protocol
  • MWMS AI Output Standard Full File Delivery Rule
  • MWMS Brain Header Schema Standard
  • MWMS Page Naming Standard
  • MWMS Document Structure Standard
  • MWMS Architecture Registry
  • MWMS System Data Flow Map
  • MWMS Supabase Event Schema
  • HeadOffice Newsletter Intelligence Operating Protocol
  • MWMS Course Absorption Operating Rule
  • MWMS Opportunity System Operating Protocol
  • AI Business Systems Brain Blueprint

This standard defines the role structure required before Agentic Work Units can be reliably assigned to AI Employees.

Drift Protection

This standard protects MWMS from the following forms of drift:

  1. Creating AI Employees without clear ownership
  2. Allowing AI Employees to perform undefined work
  3. Duplicating responsibilities across Brains
  4. Giving AI Employees unclear authority
  5. Allowing tool use without permission boundaries
  6. Accepting outputs without validation rules
  7. Producing outputs with no handoff destination
  8. Expanding AI Employee scope without governance
  9. Confusing advisory roles with execution roles
  10. Allowing AI Employees to bypass human review
  11. Creating too many overlapping agents
  12. Turning AI Employees into generic chatbots
  13. Losing accountability for AI-generated work
  14. Failing to measure AI Employee usefulness
  15. Allowing live systems to be affected by undefined AI behavior

Any AI Employee that does not have a clear role card should be treated as experimental, temporary, or advisory only.

Architectural Intent

The architectural intent of the MWMS AI Employee Role Card Standard is to prepare MWMS for scalable AI workforce management.

As MWMS grows, the system will need many AI Employees.

Those Employees must be understandable to:

  • Martyn
  • M
  • future developers
  • future operators
  • future consultants
  • future clients
  • HeadOffice governance systems
  • Brain-specific workflows
  • AI Manager
  • AI Employee Router
  • task execution systems

The role card is the bridge between concept and implementation.

It turns “we need an AI agent for this” into:

  • who owns it
  • what it does
  • what it must not do
  • what it can access
  • what it produces
  • where the output goes
  • how quality is checked
  • when a human steps in
  • how success is measured

This makes AI Employees real operating assets instead of loose ideas.

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

  • Who am I?
  • Which Brain owns me?
  • What work do I perform?
  • What work do I refuse?
  • What inputs do I accept?
  • What context do I require?
  • What tools can I use?
  • What output must I produce?
  • Where does my output go?
  • How is my work validated?
  • When do I escalate?
  • How is my performance measured?

When MWMS can answer those questions for every AI Employee, it will have the foundation of a true governed AI workforce.

Change Log

v1.0 — Initial Draft

Created the MWMS AI Employee Role Card Standard as the required operating profile for defining, governing, assigning, validating, and improving AI Employees across MWMS.

This standard supports the MWMS AI Agent Operations Core and the MWMS Agentic Work Unit Standard by ensuring that every AI Employee has clear ownership, responsibilities, boundaries, tool permissions, output standards, validation rules, handoff destinations, escalation rules, logging requirements, and success metrics.