MWMS MCR

MWMS AI Context Routing 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 Context Routing Framework.

This framework explains how MWMS decides which context, source material, memory, standards, Brain rules, tool information, and task history should be routed into an AI Employee, workflow, tool call, report, validation process, or future client system.

MWMS must not give every AI Employee every piece of context.

Too much context creates confusion.

Too little context creates guessing.

Wrong context creates drift.

Old context creates false confidence.

The purpose of context routing is to deliver the right context to the right AI Employee at the right moment for the right task.

This framework protects MWMS from:

  • context overload
  • context starvation
  • stale memory drift
  • wrong Brain routing
  • irrelevant standards being applied
  • missing source material
  • missing current evidence
  • old save points overriding current screenshots
  • tool actions running without task context
  • AI Employees guessing from incomplete information
  • M receiving developer instructions based on weak context
  • future client systems mixing unrelated context

The goal is not to maximize context.

The goal is to route useful, current, task-specific context.

Scope

This framework applies to all AI task preparation, routing, execution, validation, handoff, tool use, reporting, and future client workflow activity across MWMS.

This includes context routing for:

  • 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
  • M developer handoffs
  • MCR page workflows
  • Supabase workflows
  • Make.com workflows
  • future AIBS client systems

This framework applies before an AI Employee is asked to act, before a workflow is triggered, before a tool call is allowed, before output is validated, before work is handed off, and before recurring reporting runs.

This framework does not authorize development work.

It defines the governance logic for routing context before automation or plugin/UI build.

Core Definition

AI Context Routing is the controlled selection and delivery of relevant context into an AI workflow.

Context may include:

  • current request
  • task type
  • source material
  • source reference
  • source completeness
  • source of truth
  • owning Brain
  • supporting Brains
  • assigned AI Employee
  • relevant MWMS standards
  • current workflow stage
  • current save point
  • previous work completed
  • tool permission boundary
  • developer boundary
  • output format requirement
  • validation requirement
  • risk level
  • human review requirement
  • handoff destination
  • known gaps
  • assumptions allowed
  • current evidence
  • context freshness
  • stop conditions

Context routing decides what should be included, what should be excluded, and what should be escalated before work begins.

Core Principle

The core principle of this framework is:

The right context is better than more context.

MWMS should not load an AI Employee with every memory, every standard, every old page, and every past decision.

MWMS should select the context that is relevant to the current task.

A Course Absorption Agent needs course source, absorption rules, anti-duplication rules, and MCR structure.

A Developer Support Agent needs current file evidence, screenshots, exact site, current save point, and what not to touch.

A Newsletter Signal Extraction Agent needs newsletter body, sender, signal rules, Brain Routing Rule, and dashboard action rules.

A Finance Agent needs numbers, assumptions, payout, costs, exposure, and risk.

A client-facing AIBS Agent needs only approved client-specific context.

Context routing prevents AI work from becoming noisy, stale, or unsafe.

Context Routing Problems

MWMS recognizes four major context routing problems.

1. Context Pollution

Context pollution occurs when an AI Employee receives too much irrelevant, outdated, conflicting, or noisy context.

Examples:

  • giving a course absorption task every old course rule and unrelated Brain page
  • giving developer support old save points that conflict with the current screenshot
  • giving newsletter analysis sponsor/footer clutter
  • giving Affiliate Brain rules to a Content Brain task
  • loading every registry when only one page title matters
  • giving client workflow context from the wrong client
  • including old assumptions that no longer apply
  • including tool documentation not needed for the current step

Context Pollution Risk:

  • weak reasoning
  • wrong emphasis
  • missed important facts
  • bloated output
  • conflicting instructions
  • hallucinated connections
  • slower workflow
  • poor validation

Context Pollution Rule:

Irrelevant context should be excluded even if it is true.

True context can still be harmful if it does not belong in the current task.

2. Context Starvation

Context starvation occurs when an AI Employee lacks required information to complete the task safely.

Examples:

  • preparing M developer instructions without file path
  • updating an MCR page without the exact page title
  • evaluating an offer without payout, network, or traffic platform
  • reviewing a newsletter without full body
  • creating a recurring report without source data
  • validating output without original task instruction
  • routing a Brain Room message without thread context
  • creating a client report without client approval rules

Context Starvation Risk:

  • guessing
  • weak output
  • wrong route
  • unsafe handoff
  • hidden assumptions
  • incomplete validation
  • M having to guess
  • client risk

Context Starvation Rule:

If required context is missing, the workflow must clarify, normalize, draft cautiously, park, or escalate.

Do not pretend missing context exists.

3. Stale Context Drift

Stale context drift occurs when old memory, old save points, old screenshots, old workflow states, or old assumptions are treated as current.

Examples:

  • relying on an old M save point after M has changed the plugin
  • using an old WordPress page list after pages were refreshed
  • using old Google Ads interface instructions after layout changed
  • assuming a course file is still available after upload expiry
  • using old Supabase schema notes after schema changed
  • treating an old registry as current after new pages were added

Stale Context Risk:

  • wrong instructions
  • duplicate pages
  • broken developer handoffs
  • bad troubleshooting
  • incorrect status
  • false confidence

Stale Context Rule:

Current evidence beats old memory.

If current state matters, MWMS must use current screenshots, current files, current page lists, current data, or clearly mark uncertainty.

4. Wrong Context Routing

Wrong context routing occurs when the wrong Brain, AI Employee, standard, skill, or workflow receives the context.

Examples:

  • sending an offer evaluation directly to Ads Brain before Research or Finance
  • sending a development issue into course absorption
  • treating MCR governance as plugin build work
  • routing newsletter noise into ACT NOW
  • sending finance-risk work to a general Writer Agent
  • applying client reporting standards to internal MCR notes
  • sending a validation failure into normal routing instead of failure handling

Wrong Routing Risk:

  • wrong owner
  • wrong output
  • wrong decision
  • ownerless tasks
  • risky automation
  • dashboard noise
  • wasted work

Wrong Context Routing Rule:

Context must be routed to the Brain and AI Employee that can safely act on it.

If ownership is unclear, route to HeadOffice review first.

Context Routing Layers

MWMS context routing has ten layers.

1. Request Identification

The system must first identify what the user, workflow, trigger, message, file, or event is asking for.

Questions:

  • What is the current request?
  • Is it course absorption?
  • Is it newsletter review?
  • Is it developer support?
  • Is it offer evaluation?
  • Is it MCR page work?
  • Is it validation?
  • Is it reporting?
  • Is it a Brain Room task?
  • Is it a tool action?
  • Is it a client workflow?

Request Identification Rule:

Do not route context until the task type is known.

2. Source Identification

The system must identify the active source material.

Source may be:

  • uploaded file
  • transcript
  • pasted text
  • screenshot
  • WordPress page list
  • Supabase row
  • Gmail newsletter
  • Brain Room message
  • offer page
  • report draft
  • developer file
  • client document
  • current user instruction

Source Identification Rule:

The AI Employee must know what source it is working from.

No source means no source-grounded output.

3. Source Completeness Check

The system must check whether the source is complete enough.

Possible statuses:

  • Complete
  • Mostly Complete
  • Partial
  • Incomplete
  • Unknown
  • Source Expired
  • Needs Reupload

Source Completeness Rule:

Do not treat partial source as complete.

If source is incomplete, the output must mark gaps or stop for reupload/evidence.

4. Source Of Truth Selection

The system must identify which source has authority.

Possible sources of truth:

  • current user instruction
  • current screenshot
  • current file content
  • current WordPress page list
  • current Supabase row
  • MCR page
  • approved framework
  • current save point
  • human decision
  • uploaded course source
  • newsletter body
  • client-approved source

Source Of Truth Rule:

Memory can guide, but source of truth decides.

5. Brain Ownership Routing

The system must identify the owning Brain.

Examples:

  • Course absorption → HeadOffice Brain / relevant specialist Brain
  • Newsletter Intelligence → HeadOffice Brain first
  • Offer evaluation → Affiliate Brain with Research, Finance, Experimentation support
  • Developer support → HeadOffice Brain / Operations Brain
  • Finance review → Finance Brain
  • Experiment results → Experimentation Brain
  • Client workflow → AI Business Systems Brain
  • Cross-Brain uncertainty → HeadOffice Brain

Brain Ownership Rule:

Every meaningful task needs an owning Brain.

If no Brain owner is clear, route to HeadOffice review.

6. AI Employee Routing

After Brain ownership is known, the correct AI Employee or role chain must be selected.

Examples:

  • Course Absorption Agent
  • Newsletter Signal Extraction Agent
  • Developer Support Agent
  • Researcher Agent
  • Analyst Agent
  • Writer Agent
  • Reviewer Agent
  • Validator Agent
  • Router Agent
  • Failure Handler Agent
  • Outcome Logger Agent

AI Employee Routing Rule:

Context should be routed to the AI Employee whose role and capability stack match the task.

Do not send everything to a general AI role.

7. Standard And Skill Routing

The system must select which standards and skills apply.

Examples:

Course absorption may need:

  • Course Absorption System v2
  • AI Documentation Automation Pipeline Framework
  • MCR Duplicate Risk Check Skill
  • AI Output Validation Checklist

Developer support may need:

  • Developer Handoff Precision Skill
  • AI Exchange Zone Framework
  • Ambiguity Containment Framework
  • Full File Output Rule

Newsletter review may need:

  • Newsletter Intelligence Operating Protocol
  • Brain Routing Rule
  • Newsletter Signal Filtering Skill
  • Dashboard Readiness Skill

Standard And Skill Routing Rule:

Only route standards and skills that matter to the current task.

Too many standards create context pollution.

8. Tool Context Routing

If tools are involved, the system must route only tool-relevant context.

Tool context may include:

  • tool name
  • permission level
  • input schema
  • output schema
  • approved action
  • forbidden action
  • human approval requirement
  • stop condition
  • logging destination
  • risk level

Tool Context Routing Rule:

A tool call should receive only the context needed to perform the approved tool action safely.

Tool context does not authorize tool use by itself. Permission still governs action.

9. Validation Context Routing

Before output is trusted, validation must receive the correct context.

Validation needs:

  • original task
  • source material
  • output draft
  • expected output format
  • relevant standard
  • risk level
  • destination
  • human review rule
  • known gaps
  • assumptions

Validation Context Rule:

Validation cannot work properly without the original task and source context.

A Validator should not validate polished output in isolation.

10. Handoff Context Routing

When work crosses an Exchange Zone, the receiving role must receive enough context to continue safely.

Handoff context includes:

  • sender
  • receiver
  • source
  • work completed
  • output transferred
  • validation status
  • known gaps
  • dependencies
  • next action
  • owner
  • stop conditions

Handoff Context Rule:

Context must travel with the work.

If context does not travel, the handoff is incomplete.

Context Routing Decisions

MWMS should make one of the following context routing decisions.

1. Route To Processing

Use when context is complete enough and risk is acceptable.

Example:

Course transcript is complete enough and course absorption can begin.

2. Route To Normalization

Use when input is messy but usable.

Example:

Newsletter body includes footer clutter but can be cleaned.

3. Route To Clarification

Use when required context is missing.

Example:

Developer issue lacks file path or current screenshot.

4. Route To Validation

Use when output exists but needs checking.

Example:

MCR page draft needs source grounding and duplicate check.

5. Route To Research

Use when source claims require verification.

Example:

Affiliate offer makes claims that need external evidence.

6. Route To Human Review

Use when risk is medium or high, or current state is uncertain.

Example:

M developer handoff, finance decision, client report, MCR canon save.

7. Route To Parking

Use when context is insufficient but the idea may matter later.

Example:

Course idea is interesting but not enough for a page.

8. Route To Rejection

Use when context is weak, unsafe, duplicated, or not useful.

Example:

Generic course fluff, weak newsletter noise, unsupported offer hype.

9. Route To Failure Handling

Use when a workflow step partially failed.

Example:

Tool output is malformed, body is truncated, validation missed a critical issue.

Context Routing Record Template

Use this template when routing context for important tasks.

Routing Record Title

Field:
Routing Record Title:

Current Request

Field:
Current Request:

Task Type

Field:
Task Type:

Recommended values:

  • Course Absorption
  • Newsletter Intelligence
  • Developer Support
  • Offer Evaluation
  • Research
  • Finance Review
  • Experimentation Review
  • MCR Page Work
  • Validation
  • Reporting
  • Brain Room Task
  • Tool Action
  • Client Workflow
  • Failure Handling

Source Material

Field:
Source Material:

Source Reference

Field:
Source Reference:

Source Completeness

Field:
Source Completeness:

Source Of Truth

Field:
Source Of Truth:

Context Freshness

Field:
Context Freshness:

Recommended values:

  • Fresh
  • Recent
  • Stable
  • Stale
  • Deprecated
  • Unknown

Owning Brain

Field:
Owning Brain:

Supporting Brains

Field:
Supporting Brains:

Assigned AI Employee

Field:
Assigned AI Employee:

Required Standards

Field:
Required Standards:

Required Skills

Field:
Required Skills:

Context To Include

Field:
Context To Include:

Context To Exclude

Field:
Context To Exclude:

Tool Context Required

Field:
Tool Context Required: Yes / No

Permission Boundary

Field:
Permission Boundary:

Validation Context Required

Field:
Validation Context Required: Yes / No

Handoff Context Required

Field:
Handoff Context Required: Yes / No

Known Gaps

Field:
Known Gaps:

Assumptions Allowed

Field:
Assumptions Allowed: Yes / No / Limited

Risk Level

Field:
Risk Level:

Recommended values:

  • Low
  • Medium
  • High
  • Critical

Routing Decision

Field:
Routing Decision:

Recommended values:

  • Route To Processing
  • Route To Normalization
  • Route To Clarification
  • Route To Validation
  • Route To Research
  • Route To Human Review
  • Route To Parking
  • Route To Rejection
  • Route To Failure Handling

Stop Conditions

Field:
Stop Conditions:

Expected Output

Field:
Expected Output:

Handoff Destination

Field:
Handoff Destination:

Logging Required

Field:
Logging Required: Yes / No

Routing Status

Field:
Routing Status:

Recommended values:

  • Draft
  • Ready
  • Routed
  • Waiting For Input
  • Waiting For Validation
  • Waiting For Human Review
  • Parked
  • Rejected
  • Escalated
  • Closed

Quick Use Version

Routing Record Title:
Current Request:
Task Type:
Source Material:
Source Reference:
Source Completeness:
Source Of Truth:
Context Freshness:
Owning Brain:
Supporting Brains:
Assigned AI Employee:
Required Standards:
Required Skills:
Context To Include:
Context To Exclude:
Tool Context Required:
Permission Boundary:
Validation Context Required:
Handoff Context Required:
Known Gaps:
Assumptions Allowed:
Risk Level:
Routing Decision:
Stop Conditions:
Expected Output:
Handoff Destination:
Logging Required:
Routing Status:

Examples

Example 1: Course Absorption Context Routing

Routing Record Title:
Course Lesson To Course Absorption Agent Context Routing

Current Request:
Evaluate uploaded course lesson and extract what is useful for MWMS.

Task Type:
Course Absorption

Source Material:
Uploaded course transcript or pasted lesson block.

Source Reference:
Course name, lesson number, file name.

Source Completeness:
Mostly Complete / Complete

Source Of Truth:
Uploaded course source for lesson content; MCR for MWMS governance.

Context Freshness:
Fresh

Owning Brain:
HeadOffice Brain

Supporting Brains:
AI Business Systems Brain, relevant specialist Brain, Operations Brain

Assigned AI Employee:
Course Absorption Agent

Required Standards:
Course Absorption System v2, MWMS AI Documentation Automation Pipeline Framework, MWMS AI Output Validation Checklist, MCR source-of-truth rules.

Required Skills:
Course Absorption Value Extraction Skill, MCR Duplicate Risk Check Skill, Full Page Output Creation Skill.

Context To Include:
Course source, current block, absorption rules, existing registry awareness, M development boundary.

Context To Exclude:
Unrelated course memories, unrelated Brain rules, generic hype, old duplicate decisions not relevant to this title.

Tool Context Required:
No unless uploaded file processing is needed.

Permission Boundary:
Provided Input Only.

Validation Context Required:
Yes

Handoff Context Required:
Yes if full page output is created.

Known Gaps:
Existing page search may need confirmation before saving.

Assumptions Allowed:
Limited and marked.

Risk Level:
Medium

Routing Decision:
Route To Processing

Stop Conditions:
Weak content, duplicate page risk, source incomplete, M build impact.

Expected Output:
Absorb/park/reject verdict and full page output if justified.

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

Logging Required:
Yes if absorbed.

Routing Status:
Ready

Example 2: Developer Support Context Routing

Routing Record Title:
Developer Issue To Developer Support Agent Context Routing

Current Request:
Prepare exact developer instructions for M.

Task Type:
Developer Support

Source Material:
Screenshot, uploaded file, code snippet, or user instruction.

Source Reference:
Screenshot name, file name, site/domain, task note.

Source Completeness:
Partial unless exact file contents and path are supplied.

Source Of Truth:
Current screenshot and current file content.

Context Freshness:
Fresh if current evidence is supplied.

Owning Brain:
HeadOffice Brain

Supporting Brains:
Operations Brain, Dev Console, relevant technical system.

Assigned AI Employee:
Developer Support Agent

Required Standards:
Full File Output Rule, MWMS AI Exchange Zone And Dependency Control Framework, MWMS AI Ambiguity And Partial Failure Containment Framework, MWMS AI Output Validation Checklist.

Required Skills:
Developer Handoff Precision Skill, Ambiguity Containment Skill, Exchange Zone Control Skill.

Context To Include:
Exact site, current screenshot, current file content, current save point, what not to touch, test requirement.

Context To Exclude:
Old save points unless confirmed current, guessed file paths, unrelated build tracks.

Tool Context Required:
No unless live/read tool access is approved.

Permission Boundary:
Provided Input Only / Draft Creation.

Validation Context Required:
Yes

Handoff Context Required:
Yes

Known Gaps:
File path or current file content may be missing.

Assumptions Allowed:
No for implementation instructions; only marked assumptions for discussion.

Risk Level:
High

Routing Decision:
Route To Clarification or Route To Human Review if evidence is incomplete.

Stop Conditions:
M would need to guess, file path missing, current state unclear, live risk.

Expected Output:
Developer handoff brief or full file output.

Handoff Destination:
M / Dev Console / HeadOffice Review.

Logging Required:
Yes for meaningful development work.

Routing Status:
Waiting For Input if evidence is incomplete.

Example 3: Newsletter Intelligence Context Routing

Routing Record Title:
Newsletter Email To Signal Extraction Context Routing

Current Request:
Extract business-relevant intelligence from a newsletter.

Task Type:
Newsletter Intelligence

Source Material:
Newsletter email body.

Source Reference:
Sender, subject, date, Gmail label.

Source Completeness:
Complete / Mostly Complete / Partial

Source Of Truth:
Newsletter source for content; HeadOffice Newsletter Intelligence rules for routing.

Context Freshness:
Fresh

Owning Brain:
HeadOffice Brain

Supporting Brains:
Ads Brain, Affiliate Brain, Content Brain, Research Brain, Finance Brain, AI Business Systems Brain.

Assigned AI Employee:
Newsletter Signal Extraction Agent

Required Standards:
HeadOffice Newsletter Intelligence Operating Protocol, MWMS Brain Routing Rule, MWMS AI Command And Trigger Framework, MWMS AI Output Validation Checklist.

Required Skills:
Newsletter Signal Filtering Skill, Brain Routing Skill, Dashboard Readiness Skill.

Context To Include:
Sender, subject, body, date, business relevance filter, action categories, Brain routing rules.

Context To Exclude:
Sponsor clutter, generic AI news, footer content, old unrelated newsletter opinions.

Tool Context Required:
Yes if Gmail/Supabase workflow is used.

Permission Boundary:
Gmail Read Only / Supabase Controlled Write only if approved.

Validation Context Required:
Yes

Handoff Context Required:
Yes if routed.

Known Gaps:
Body may be incomplete or truncated.

Assumptions Allowed:
Limited and marked.

Risk Level:
Medium

Routing Decision:
Route To Normalization before Processing.

Stop Conditions:
Body incomplete, signal generic, urgent claim unverified, compliance risk.

Expected Output:
Newsletter intelligence record or review report.

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

Logging Required:
Yes

Routing Status:
Ready if body is complete.

Example 4: Offer Evaluation Context Routing

Routing Record Title:
Affiliate Offer To Offer Evaluation Context Routing

Current Request:
Evaluate whether an offer is suitable for MWMS testing.

Task Type:
Offer Evaluation

Source Material:
Offer page, affiliate network data, user-provided offer details.

Source Reference:
Offer name, network, URL, payout if known.

Source Completeness:
Partial unless payout, network, traffic platform, and goal are known.

Source Of Truth:
Current offer source and verified external data where required.

Context Freshness:
Unknown until current research is completed.

Owning Brain:
Affiliate Brain

Supporting Brains:
Research Brain, Ads Brain, Finance Brain, Experimentation Brain, HeadOffice Brain.

Assigned AI Employee:
Offer Evaluation Agent / Researcher Agent / Analyst Agent.

Required Standards:
Affiliate Product Intelligence Protocol, Brain Routing Rule, Finance review rules, Experimentation review rules, Ads compliance rules.

Required Skills:
Offer Evidence Separation Skill, Research Evidence Extraction Skill, Finance Risk Review Skill, Offer Test Suitability Skill.

Context To Include:
Offer name, network, payout, claims, proof, mechanism, traffic platform, test goal, compliance risk.

Context To Exclude:
Vendor hype, unsupported claims, unrelated product assumptions.

Tool Context Required:
Possibly, if current research is required.

Permission Boundary:
Read Only Research / Draft Report only.

Validation Context Required:
Yes

Handoff Context Required:
Yes

Known Gaps:
Payout, EPC, refund risk, traffic costs, and proof may be missing.

Assumptions Allowed:
Limited and marked.

Risk Level:
High

Routing Decision:
Route To Research before Finance or Experimentation.

Stop Conditions:
Missing payout, weak proof, compliance risk, finance assumptions unclear.

Expected Output:
Offer evaluation report with Green/Yellow/Red verdict.

Handoff Destination:
Research Brain, Finance Brain, Experimentation Brain, Parking System, or Rejected Archive.

Logging Required:
Yes if evaluated.

Routing Status:
Waiting For Research if current data is missing.

Example 5: Client Report Context Routing

Routing Record Title:
Client Source To AIBS Report Context Routing

Current Request:
Prepare a future client report from approved source material.

Task Type:
Client Workflow / Reporting

Source Material:
Approved client data source.

Source Reference:
Client name or ID, report period, approved data source.

Source Completeness:
Must be confirmed before report drafting.

Source Of Truth:
Approved client source only.

Context Freshness:
Fresh / Recent depending on report period.

Owning Brain:
AI Business Systems Brain

Supporting Brains:
HeadOffice Brain, Operations Brain, client-specific workflow Brain.

Assigned AI Employee:
AIBS Client Reporting Agent.

Required Standards:
AI Documentation Automation Pipeline Framework, Recurring Intelligence And Reporting Pipeline Framework, Tool Permission Record Template, Output Validation Checklist.

Required Skills:
Client Report Drafting Skill, Client Context Isolation Skill, Source Grounding Skill.

Context To Include:
Only approved client-specific context, report purpose, client approval rules, privacy boundary, source data.

Context To Exclude:
Other client data, internal MWMS assumptions not relevant to client, unsupported claims.

Tool Context Required:
Yes if client system access is used.

Permission Boundary:
Read Only / Draft Creation until approved.

Validation Context Required:
Yes

Handoff Context Required:
Yes

Known Gaps:
Client approval rules may not be finalized.

Assumptions Allowed:
Limited and clearly marked.

Risk Level:
High

Routing Decision:
Route To Human Review before delivery.

Stop Conditions:
Client data outside scope, privacy risk, unsupported claims, missing approval gate.

Expected Output:
Client report draft.

Handoff Destination:
AIBS Client Review / HeadOffice approval.

Logging Required:
Yes

Routing Status:
Future Draft Only

Context Routing Readiness Checklist

Before context is routed into an AI task, check:

  1. Is the current request clear?
  2. Is the task type identified?
  3. Is source material known?
  4. Is source reference recorded?
  5. Is source completeness checked?
  6. Is source of truth identified?
  7. Is context freshness known?
  8. Is owning Brain clear?
  9. Are supporting Brains listed where relevant?
  10. Is assigned AI Employee clear?
  11. Are required standards selected?
  12. Are required skills selected?
  13. Is irrelevant context excluded?
  14. Is tool context required?
  15. Is permission boundary defined?
  16. Is validation context required?
  17. Is handoff context required?
  18. Are known gaps stated?
  19. Are assumptions controlled?
  20. Is risk level assigned?
  21. Is routing decision clear?
  22. Are stop conditions listed?
  23. Is expected output defined?
  24. Is handoff destination clear?
  25. Is logging required?

If several answers are unclear, the context routing is not ready.

Common Context Routing Failure Modes

Context routing has failed if:

  1. Too much irrelevant context is included.
  2. Required context is missing.
  3. Old memory is treated as current evidence.
  4. Source of truth is unclear.
  5. Wrong Brain receives the task.
  6. Wrong AI Employee receives the task.
  7. Wrong standards are applied.
  8. Tool permission context is missing.
  9. Validation lacks original task context.
  10. Handoff loses source and risk context.
  11. Client context is mixed.
  12. Developer support relies on old save points.
  13. Newsletter analysis includes sponsor clutter.
  14. Offer evaluation uses vendor hype as evidence.
  15. The AI guesses because context was starved.

Manual Use Rule

Context routing should be manually proven before it becomes technical infrastructure.

Manual use helps MWMS learn:

  • which context is essential
  • which context creates pollution
  • which source types need routing rules
  • which AI Employees need stronger context packs
  • where old memory causes errors
  • which workflows need context freshness checks
  • where human review should be triggered
  • which context fields may later become Supabase task fields
  • which context routing rules may later power AI Manager or Task Executor

Manual context routing discipline comes before automation.

Future Plugin Or UI Relevance

This framework may later support:

  • Context Routing Registry
  • AI Manager context selector
  • AI Employee Router context matching
  • Brain Room task context builder
  • Task Executor context injection
  • Developer Support context panel
  • Newsletter Intelligence context router
  • Course Absorption context router
  • Offer Evaluation context router
  • AIBS client context isolation layer

Possible future fields:

  • context_routing_id
  • routing_record_title
  • current_request
  • task_type
  • source_material
  • source_reference
  • source_completeness
  • source_of_truth
  • context_freshness
  • owning_brain
  • supporting_brains
  • assigned_ai_employee
  • required_standards
  • required_skills
  • context_to_include
  • context_to_exclude
  • tool_context_required
  • permission_boundary
  • validation_context_required
  • handoff_context_required
  • known_gaps
  • assumptions_allowed
  • risk_level
  • routing_decision
  • stop_conditions
  • expected_output
  • handoff_destination
  • logging_required
  • routing_status
  • created_at
  • updated_at

No technical build is authorized by this framework alone.

Governance Role

HeadOffice owns the MWMS AI Context Routing Framework.

HeadOffice is responsible for:

  • defining context routing governance
  • preventing context pollution
  • preventing context starvation
  • preventing stale memory drift
  • ensuring source of truth is clear
  • ensuring current evidence is prioritized
  • ensuring correct Brain ownership
  • ensuring correct AI Employee assignment
  • ensuring standards and skills are routed selectively
  • ensuring tool context does not bypass permission rules
  • ensuring validation receives original task context
  • ensuring handoff context travels with the work
  • protecting M’s active build areas
  • protecting MCR source of truth
  • protecting future AIBS client context isolation

Individual Brains may define local context needs, but HeadOffice governs cross-Brain, high-risk, developer, MCR, tool-enabled, automation-related, and client-facing context routing.

Relationship To Other MWMS Standards

This framework supports and must align with:

  • MWMS AI Agent Operations Core
  • MWMS AI Command And Trigger Framework
  • 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 Recurring Intelligence And Reporting Pipeline Framework
  • MWMS AI Agent Memory And Context Framework
  • MWMS AI Agent Context Pack Template
  • 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 Output Validation Standard
  • MWMS AI Output Validation Checklist
  • 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 selective context delivery layer to the MWMS AI Agent Operations Core.

Drift Protection

This framework protects MWMS from:

  1. Dumping all memory into every task
  2. Starving AI Employees of critical context
  3. Letting old memory override current evidence
  4. Applying the wrong Brain rules
  5. Applying irrelevant standards
  6. Sending tasks to the wrong AI Employee
  7. Treating stale screenshots, page lists, or save points as current
  8. Letting tool calls run without task context
  9. Validating outputs without original source context
  10. Losing context across Exchange Zones
  11. Mixing client contexts
  12. Creating developer handoffs from incomplete context
  13. Creating MCR pages from polluted context
  14. Routing newsletter noise into dashboards
  15. Allowing context errors to become downstream system truth

Any important AI task without proper context routing should remain draft, parked, clarified, or under review.

Architectural Intent

The architectural intent of the MWMS AI Context Routing Framework is to make AI work context-precise.

MWMS is building a large AI ecosystem.

As the ecosystem grows, the challenge is not only having enough knowledge.

The challenge is delivering the correct knowledge into the correct workflow at the correct time.

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

  • What is the current request?
  • What source material is active?
  • What is the source of truth?
  • Is the context fresh?
  • Which Brain owns the task?
  • Which AI Employee should receive it?
  • Which standards and skills apply?
  • What context should be included?
  • What context should be excluded?
  • What tool context is required?
  • What validation context is required?
  • What handoff context must travel?
  • What gaps or assumptions exist?
  • What routing decision should be made?

When MWMS controls context routing, AI Employees become more accurate, safer, less noisy, and easier to scale into future automation.

Change Log

v1.0 — Initial Draft

Created the MWMS AI Context Routing Framework to define how MWMS routes the right context, source material, memory, standards, skills, tool context, validation context, and handoff context into AI Employees and workflows.

This framework establishes context routing problems, context pollution, context starvation, stale context drift, wrong context routing, routing layers, routing decisions, routing records, examples, readiness checks, failure modes, future plugin/UI relevance, governance role, drift protection, and architectural intent.

It establishes that the right context is better than more context.