MWMS Context Engineering Framework

Page Type: Framework
Parent Page: HeadOffice
Status: Active
Source / Origin: AI Automations by Jack — AI Foundations Section 1
Created / Absorbed Date: 2026-05-31
MWMS Classification: AI Context Standard / Cross-Brain Architecture Framework / AI Employee Design Standard
Primary Brain: HeadOffice Brain
Supporting Brains: Automation Brain, AIBS Brain, Data Brain, Research Brain, Content Brain, Affiliate Brain, Sales Brain, Customer Brain, Compliance Brain, Risk Brain
Related Pages: MWMS AI Context Activation And Usage Protocol, MWMS AI Agent Memory And Context Framework, MWMS AI Agent Operations Core, MWMS AI Employee Role Card Standard, MWMS AI Employee Capability Stack Framework, MWMS Source Visibility And Evidence Display Standard, MWMS Missing Context And Evidence Gap Handling Rule, MWMS Research Planning And Query Rewriting Standard, MWMS AI Schema And Decision Ready Output Framework
Source Evidence: AI Automations by Jack identifies context engineering as a major AI system design principle and frames useful AI output around trigger identification, required information, data sources, and wiring those sources into AI workflows.

Purpose

The MWMS Context Engineering Framework defines how MWMS designs, manages, retrieves, protects, and applies context inside AI Employees, Brain systems, automations, client systems, and decision workflows.

This framework exists because AI output quality is not determined only by the model being used.

AI output quality is heavily determined by the quality, relevance, freshness, structure, and safety of the context supplied to the system.

A weak AI system asks the model to guess.

A strong AI system gives the model the right context before asking it to act.

MWMS must therefore treat context as a designed system layer, not as a casual prompt add-on.

The purpose of this framework is to make context engineering a formal MWMS discipline across all Brains, Employees, automations, dashboards, and future client AI operating systems.

Strategic Importance

Context engineering is strategically important because MWMS is becoming a multi-Brain, multi-Employee, multi-system intelligence architecture.

As MWMS grows, the biggest problem will not simply be creating more AI outputs.

The bigger problem will be making sure each AI Employee knows:

what task it is performing
what Brain it belongs to
what sources matter
what prior decisions exist
what business rules apply
what constraints must be respected
what evidence is available
what context is current
what context is outdated
what context is missing
what context is sensitive
what information should not be used
what should be escalated to HeadOffice

Context engineering becomes the difference between a useful AI Employee and a generic chatbot.

For MWMS, context is not just background information.

Context is operational infrastructure.

Core Doctrine

The MWMS doctrine is:

Better context creates better AI decisions.

The AI model is only one part of the system.

The real advantage comes from supplying the AI with the correct combination of:

system instructions
role definition
business context
user context
source material
current task data
past decisions
relevant evidence
constraints
permissions
output rules
escalation rules
feedback history

MWMS must therefore build systems that do not merely ask AI to respond.

MWMS must build systems that first prepare the AI to respond correctly.

Definition

Context Engineering is the structured design of the information environment around an AI system so that the system can produce accurate, relevant, safe, useful, and decision-ready outputs.

It includes:

identifying what the AI needs to know
identifying where that information comes from
deciding what context should be permanent
deciding what context should be retrieved only when needed
deciding what context should be excluded
validating the quality of context
protecting sensitive context
preventing stale or incorrect context from contaminating outputs
displaying source evidence when required
updating context as the business changes

MWMS Definition

Context engineering is:

The discipline of designing, selecting, retrieving, validating, and controlling the information an AI Employee or AI system uses before it acts.

Context Engineering Is Not Prompt Engineering

Prompt engineering and context engineering are related, but they are not the same.

Prompt Engineering

Prompt engineering focuses on how the instruction is written.

It asks:

What should the AI do?
What role should it assume?
What output format should it use?
What examples should it follow?
What constraints should it obey?

Context Engineering

Context engineering focuses on what the AI knows before it performs the task.

It asks:

What background does the AI need?
What source material should be used?
What previous decisions matter?
What current system state matters?
What data should be retrieved?
What information should be excluded?
What context must be shown as evidence?
What context is missing?

MWMS Rule

Prompt engineering tells the AI what to do.

Context engineering gives the AI what it needs to know.

Both are required.

The MWMS Context Stack

Every AI Employee or AI system should be assessed across the following context layers.

Layer 1: Identity Context

Identity context defines who the AI is inside the MWMS system.

This prevents generic output.

Identity context includes:

Employee name
Brain ownership
role description
responsibility boundaries
authority level
escalation path
output style
decision rights
prohibited actions
relationship to other Brains

Example

An Affiliate Brain Offer Evaluator should know that it is responsible for evaluating affiliate offers, not writing final ad copy, approving spend, or changing tracking infrastructure.

Design Questions

Which Brain owns this Employee?
What is the Employee’s job?
What decisions can it make?
What decisions must it escalate?
What output does it produce?
What should it refuse to do?
Which pages define its role?

MWMS Rule

Every AI Employee must have identity context before task context.

Layer 2: Task Context

Task context defines the specific job being performed now.

This is the immediate operational context.

Task context includes:

task type
task objective
user request
input data
expected output
deadline or urgency
target Brain
success criteria
required format
known constraints

Example

A Content Brain Employee asked to create a content brief needs to know the target topic, audience, search intent, content type, offer relationship, publishing goal, and output format.

Design Questions

What is the specific task?
What is the expected output?
What does success look like?
What input has been provided?
What is missing?
What format is required?
What Brain receives the result?

MWMS Rule

AI should not begin production work until the task context is clear enough to produce a useful result.

Layer 3: Business Context

Business context defines the commercial and operational environment behind the task.

Business context includes:

business model
current business stage
monetization model
target audience
offer structure
current priorities
strategic constraints
existing systems
current bottlenecks
available resources
risk tolerance
implementation capacity

Example

A sales automation for a startup with no traffic is different from a sales automation for an established coaching business with 500 leads per month.

Design Questions

What business is this system serving?
What is the revenue model?
What is the current constraint?
What is the commercial goal?
What existing assets are available?
What resources are limited?
What risk level is acceptable?

MWMS Rule

Business context must shape AI recommendations. Generic best practice is not enough.

Layer 4: Source Context

Source context defines the documents, pages, transcripts, files, lessons, screenshots, research, or evidence that support the AI output.

Source context includes:

uploaded course files
PDFs
transcripts
MCR pages
Brain pages
newsletters
research reports
screenshots
SOPs
prior summaries
performance reports
official documentation
client-provided materials

Design Questions

What source material supports this output?
Is the source current?
Is the source reliable?
Is the source complete?
Is the source directly relevant?
Does the output need citations or evidence?
Are there conflicting sources?
Should the source be promoted to MCR, Brain Canon, or a temporary holding area?

MWMS Rule

When source material exists, the AI should use it. When source material is missing, the AI should say so.

Layer 5: Historical Context

Historical context defines what has already happened.

This prevents repeated mistakes and duplicated work.

Historical context includes:

previous decisions
rejected options
approved frameworks
created pages
previous course absorptions
save points
change logs
implementation history
known issues
user corrections
system failures
prior conclusions

Example

If MWMS already rejected a tool as unnecessary, a future AI output should not recommend it again without new evidence.

Design Questions

Has MWMS made a decision about this before?
Has a related page already been created?
Was this idea rejected, deferred, or approved?
Is there a save point?
Is there an unresolved correction?
Has the user given a preference that applies here?

MWMS Rule

Historical context prevents MWMS from going in circles.

Layer 6: System State Context

System state context defines what is currently active, paused, broken, working, or pending.

This is especially important for HeadOffice, development handoffs, automation monitoring, and build sequencing.

System state context includes:

active systems
paused systems
stable save points
known bugs
pending tasks
blocked work
current implementation stage
active Brain build phase
automation status
dashboard status
tool access status
current priorities

Example

If M is working on development, course absorption should not interfere with the development path. If HeadOffice Newsletter Intelligence is stable but one Gmail label issue remains, future work should resume from that exact point.

Design Questions

What is currently active?
What is paused?
What must not be touched?
What is the latest stable save point?
What is currently broken?
What is waiting for M?
What task should happen next?

MWMS Rule

AI recommendations must match the current system state, not an imagined ideal state.

Layer 7: Constraint Context

Constraint context defines limits that must be respected.

Constraint context includes:

budget limits
tool limits
upload limits
time limits
user preferences
compliance limits
platform rules
technical constraints
team capacity
current project boundaries
M’s development availability
no-code vs code boundaries
“do not touch” areas

Example

A recommendation to buy another tool is weak if MWMS already has a low-cost rule and an existing tool can do the job.

Design Questions

What constraints apply?
What must not be changed?
What tools are already approved?
What costs should be avoided?
What project boundary applies?
What compliance rules apply?
What development work must not be interrupted?

MWMS Rule

Constraints are part of the context, not an afterthought.

Layer 8: Governance Context

Governance context defines the rules that control what the AI can and cannot do.

Governance context includes:

approval rules
escalation rules
evidence requirements
source visibility rules
output validation rules
permissions
data handling rules
sensitive data rules
API key rules
human review gates
change declaration rules
MCR promotion rules
Brain ownership rules

Design Questions

What governance rules apply?
Does this require human approval?
Does this require evidence?
Does this require a change log?
Does this affect another Brain?
Does this create risk?
Does this need escalation to HeadOffice?
Does this require a compliance review?

MWMS Rule

AI systems must be governed before they are scaled.

Layer 9: Performance Context

Performance context defines what results, metrics, and feedback should influence the AI’s next action.

Performance context includes:

conversion rates
CTR
CPA
cost
revenue
response time
task completion rate
error rate
usage rate
quality scores
confidence scores
human correction patterns
test results
engagement metrics
feedback loops

Example

Ads Brain should not make creative recommendations without knowing whether the current problem is hook failure, audience mismatch, landing page weakness, tracking failure, or offer weakness.

Design Questions

What performance data matters?
What metric indicates success?
What metric indicates risk?
Is the data reliable?
Is the sample size meaningful?
What should be ignored as noise?
What trend matters most?
What is the current bottleneck?

MWMS Rule

Performance context should guide optimization. Without it, AI can only guess.

Layer 10: Evidence And Source Visibility Context

Evidence context defines what the AI must show to support its output.

This is essential for MWMS trust.

Evidence context includes:

cited source files
source pages
source dates
source reliability
evidence strength
assumptions
uncertainty
known gaps
reasoning summary
confidence level

Design Questions

What evidence supports this?
What is assumed?
What is uncertain?
What source was used?
What source was ignored?
What evidence is missing?
Does the user need a source-visible answer?
Does this output affect a decision?

MWMS Rule

Important decisions require visible evidence.

Context Types

MWMS uses five major context types.

1. Static Context

Static context changes slowly.

Examples:

MWMS mission
Brain purpose
Employee role
brand rules
page format rules
naming standards
compliance principles
offer positioning
business model
permanent user preferences

Use Static Context For

role cards
system prompts
Brain canon pages
client profiles
brand voice
governance rules
reusable context packs

2. Dynamic Context

Dynamic context changes frequently.

Examples:

active tasks
current campaigns
recent emails
current lead records
active bugs
current course block
latest newsletter
new performance data
recent user decisions
implementation status

Use Dynamic Context For

HeadOffice dashboards
active workflows
campaign reviews
task routing
daily reports
current build work
live decision support

3. Retrieved Context

Retrieved context is pulled only when needed.

Examples:

relevant MCR pages
source documents
previous course summaries
past decisions
related Brain pages
prior transcripts
research snippets
client records
SOP sections

Use Retrieved Context For

file-based Q&A
course absorption
research synthesis
offer evaluation
employee task support
evidence-backed recommendations

4. Human-Supplied Context

Human-supplied context is information provided directly by Martyn, M, a client, or another human operator.

Examples:

clarifications
screenshots
instructions
corrections
preferences
approval decisions
project status notes
implementation feedback
business priorities

Use Human-Supplied Context For

resolving ambiguity
correcting system assumptions
updating save points
setting priority
approving page creation
defining constraints

5. System-Generated Context

System-generated context is created by MWMS systems.

Examples:

task logs
event logs
AI output logs
Kaizen logs
status updates
error records
test results
dashboard metrics
automated summaries
routing records

Use System-Generated Context For

monitoring
reporting
trend detection
failure analysis
system improvement
HeadOffice oversight

The MWMS Context Engineering Flow

Every AI system should follow this flow.

Step 1: Define The Trigger

The trigger is the event that starts the system.

Examples:

new email received
form submitted
file uploaded
newsletter labeled
task created
call transcript added
campaign data updated
user sends request
scheduled report time reached

Trigger Questions

What starts the process?
Is the trigger manual, automatic, scheduled, or event-based?
Is the trigger reliable?
Does the trigger include enough starting data?
What should happen if the trigger fires incorrectly?

Step 2: Define The Required Context

Before designing the AI action, define what the system needs to know.

Required Context Questions

What does the AI need to know to do this well?
What does the AI need to avoid doing this badly?
What rules apply?
What source material matters?
What current system state matters?
What previous decision matters?
What output format is required?

Step 3: Identify Context Sources

Identify where the required context comes from.

Possible sources:

user input
Supabase
WordPress pages
MCR pages
Gmail
Google Drive
transcripts
uploaded files
dashboards
analytics
task tables
event logs
previous chat summaries
client intake forms
CRM records
source documents

Source Questions

Where does the information live?
Is it structured or unstructured?
Is it reliable?
Is it current?
Can the AI access it?
Should the AI access it?
Does it require permission?
Does it need retrieval?

Step 4: Classify The Context

Classify context before using it.

Context Classification

static
dynamic
retrieved
human-supplied
system-generated
sensitive
public
internal
client-confidential
temporary
permanent
uncertain
stale

Classification Questions

What type of context is this?
How often does it change?
Who owns it?
Who can access it?
Should it be stored?
Should it be retrieved only when needed?
Should it be excluded?

Step 5: Filter The Context

Not all context should be used.

AI can be harmed by too much context, stale context, irrelevant context, or sensitive context.

Filter Questions

Is this context relevant to the task?
Is it current?
Is it reliable?
Is it duplicated?
Is it too broad?
Is it too sensitive?
Is it allowed?
Does it create confusion?
Does it conflict with higher authority context?

MWMS Rule

More context is not always better.

The right context is better.

Step 6: Structure The Context

Context should be organized before it reaches the AI.

Possible structure:

role
objective
known facts
relevant sources
current task
constraints
examples
output format
decision rules
escalation rules

Structure Questions

Is the context readable?
Is the hierarchy clear?
Are instructions separated from user input?
Are sources separated from assumptions?
Are constraints clearly marked?
Are examples clearly marked?
Is the expected output clear?

Step 7: Apply The Context

The context is then applied to the AI task.

This may happen through:

system prompt
developer instruction
user prompt
retrieval snippet
context pack
database lookup
attached source file
memory object
prior decision log
task payload

Apply Questions

Where is the context inserted?
Is it part of the system instruction?
Is it part of task input?
Is it retrieved dynamically?
Is it attached as evidence?
Is it stored in memory?
Is it visible to the user?

Step 8: Produce The Output

The AI produces the requested output using the selected context.

The output should reflect:

the task
the Brain owner
the relevant evidence
the user’s requested format
the known constraints
the decision rules
the uncertainty level

Output Questions

Does the output answer the task?
Does it use the right context?
Does it ignore irrelevant context?
Does it reveal sensitive context?
Does it cite or reference evidence when required?
Does it make unsupported claims?
Does it need human review?

Step 9: Record The Context Used

For important outputs, MWMS should record what context was used.

This supports:

trust
auditing
debugging
repeatability
source visibility
quality improvement
dispute resolution

Record Questions

What source was used?
What context pack was used?
What file was used?
What Brain pages were used?
What assumptions were made?
What evidence was missing?
What version of the prompt was used?

Step 10: Update Or Improve Context

Context must improve over time.

Updates may come from:

human correction
new source material
changed business rules
improved page structure
updated Brain canon
failed output review
Kaizen log
system error
new source evidence
performance feedback

Update Questions

Did this output reveal a missing context gap?
Was the context stale?
Did the AI use the wrong source?
Should a new context page be created?
Should an existing page be updated?
Should a memory be saved?
Should old context be retired?

Context Authority Hierarchy

When context conflicts, MWMS should follow the authority hierarchy.

Highest Authority

Direct current user instruction
MWMS Canon / Constitution / Governance rules
Active project save points
Current Brain Canon
Current page-specific instructions
Source material uploaded for the task
Prior absorbed course summaries
General memory
General AI knowledge

MWMS Rule

Current user instruction and MWMS governance override generic AI assumptions.

Context Freshness Standard

Context must be checked for freshness where freshness matters.

Freshness Categories

Permanent Context

Examples:

MWMS mission
Brain purpose
core governance rules
standard page structure

Review frequency:

only when system architecture changes

Stable Context

Examples:

Brain Canon pages
employee role cards
client onboarding structure
page templates

Review frequency:

periodically or after major upgrades

Active Context

Examples:

current build status
active course block
campaign performance
task status
newsletter queue status

Review frequency:

every time used

Volatile Context

Examples:

prices
tool features
platform UI
laws
compliance rules
API details
current market conditions

Review frequency:

verify before use

MWMS Rule

Do not treat old context as current unless the system confirms it is still valid.

Context Safety Rules

Context can create risk if handled badly.

MWMS must apply safety rules to context engineering.

Rule 1: Do Not Expose Sensitive Context Unnecessarily

Sensitive information should not be passed to AI unless required.

Examples:

API keys
passwords
private client data
personal identifiers
financial details
confidential strategy
legal documents
private emails

Rule 2: Use Least Context Required

Provide enough context to do the job, not everything available.

Rule 3: Separate Instructions From User Input

System instructions and user-supplied content should be clearly separated to reduce prompt injection risk.

Rule 4: Treat External Input As Untrusted

External input may contain:

incorrect information
malicious instructions
prompt injection
irrelevant data
outdated information
hidden instructions

Rule 5: Use Source Visibility For Important Decisions

If the output affects a decision, the source should be visible or traceable.

Rule 6: Do Not Let Retrieved Context Override Governance

Retrieved source material should not override MWMS governance, safety, or current user instruction.

Rule 7: Record Context Gaps

If needed context is missing, the system should record the gap instead of guessing.

MWMS Context Pack Standard

A context pack is a prepared bundle of information used by an AI Employee or system.

Context Pack Components

A strong context pack should include:

purpose
Brain owner
AI Employee role
task objective
business context
relevant source pages
current constraints
required output format
approval rules
escalation rules
known exclusions
version/date
change log

Example Context Packs

Affiliate Offer Evaluation Context Pack
Content Brief Generation Context Pack
Newsletter Intelligence Context Pack
Client Onboarding Context Pack
Google Ads Campaign Review Context Pack
AIBS Client Discovery Context Pack
Experiment Review Context Pack
HeadOffice Weekly Report Context Pack

MWMS Rule

Repeated AI workflows should use context packs rather than rebuilding context manually every time.

Application To MWMS Brains

HeadOffice Brain

HeadOffice uses context engineering to maintain cross-Brain coordination.

HeadOffice must know:

current system state
active priorities
paused work
save points
dependencies
unresolved risks
routed actions
strategic constraints

HeadOffice is the highest-level owner of context coherence.

Automation Brain

Automation Brain uses context engineering to design workflows that receive the right information before acting.

Automation Brain must define:

trigger context
task payload
data source lookups
automation state
error context
retry context
escalation context

AIBS Brain

AIBS Brain uses context engineering to package client AI systems correctly.

AIBS must define:

client profile context
business model context
offer context
process context
client goal context
delivery context
approval context
reporting context

Data Brain

Data Brain uses context engineering to determine what information is reliable enough to support decisions.

Data Brain must define:

source of truth
data quality
data freshness
event meaning
measurement reliability
metric context
uncertainty level

Research Brain

Research Brain uses context engineering to decide what evidence matters.

Research Brain must define:

source credibility
source relevance
source age
conflicting evidence
research question
synthesis context
evidence strength

Content Brain

Content Brain uses context engineering to produce content that matches audience, intent, offer, voice, and publishing purpose.

Content Brain must define:

audience context
search intent
topic cluster
offer connection
brand voice
source material
content format
publishing goal

Affiliate Brain

Affiliate Brain uses context engineering to evaluate offers correctly.

Affiliate Brain must define:

offer data
affiliate metrics
vendor context
market context
traffic source context
compliance context
testing history
financial threshold

Sales Brain

Sales Brain uses context engineering to personalize sales conversations and follow-up.

Sales Brain must define:

lead source
lead quality
pain points
objections
call history
buying stage
offer fit
follow-up rules

Compliance Brain

Compliance Brain uses context engineering to apply the right rules to the right situation.

Compliance Brain must define:

jurisdiction
platform policy
claim type
sensitive category
data handling rule
risk level
approval requirement

Risk Brain

Risk Brain uses context engineering to understand what could fail.

Risk Brain must define:

dependency context
tool risk
access risk
failure scenario
data exposure
financial exposure
recovery path

Add source visibility and evidence display.

Context Engineering Checklist

Use this checklist before deploying or trusting an AI system.

Task Clarity

Is the task clear?
Is the desired output clear?
Is the Brain owner clear?
Is the decision authority clear?
Is the success standard clear?

Context Selection

Is the required context identified?
Are the right sources available?
Is the context relevant?
Is the context current?
Is the context structured?

Context Safety

Is sensitive information excluded unless required?
Is user input separated from system instruction?
Is prompt injection risk considered?
Is least-context principle applied?
Is governance context included?

Context Reliability

Is the source reliable?
Is the source complete?
Is the source current?
Are assumptions marked?
Are evidence gaps recorded?

Context Output

Does the AI show source evidence when required?
Does the output reflect the right Brain rules?
Does the output match the requested format?
Does the output avoid unsupported claims?
Does the output escalate uncertainty?

Context Improvement

Are corrections captured?
Are context gaps logged?
Are stale pages updated?
Are context packs versioned?
Are repeated workflows standardized?

Implementation Rules

Rule 1: No Important AI Output Without Context Review

Any AI output affecting strategy, compliance, spend, client delivery, or system architecture must have context review.

Rule 2: Context Must Match The Brain

Each Brain needs different context.

Do not give every Brain the same generic context pack.

Rule 3: Source Context Must Be Traceable

If a decision is based on source material, the source should be traceable.

Rule 4: Dynamic Context Must Be Checked Before Action

Active campaigns, tasks, builds, and system states must be checked before recommendations are made.

Rule 5: Sensitive Context Must Be Minimized

Do not pass private or sensitive data into AI systems unless required for the task.

Rule 6: Context Gaps Must Be Declared

If key context is missing, the AI should say what is missing and why it matters.

Rule 7: Context Packs Should Be Versioned

Reusable context packs must have version dates and change logs.

Rule 8: Context Should Improve Through Kaizen

Every recurring context failure should create a context improvement action.

Related Employee Capabilities

Context Engineer

Responsible for designing, maintaining, and improving context packs for AI Employees and AI Operating Systems.

Source Librarian

Responsible for organizing source material and ensuring relevant documents can be retrieved.

Evidence Reviewer

Responsible for checking whether AI outputs are supported by proper evidence.

Memory Curator

Responsible for deciding what should become persistent memory, Brain content, MCR content, or temporary context.

AI Employee Architect

Responsible for ensuring each AI Employee has the correct identity, task, context, output, and governance layers.

Governance Reviewer

Responsible for checking whether context usage creates privacy, security, compliance, or operational risk.

Future Expansion

This framework should later connect to:

AI Employee context pack templates
Brain-specific context templates
client onboarding context packs
Supabase context table design
MCR retrieval workflows
source visibility dashboards
RAG implementation standards
prompt injection protection standards
HeadOffice context audit dashboard
AI Employee memory scoring
context freshness review cycle

Potential future pages:

MWMS Context Pack Template Standard
MWMS Brain Context Map Standard
MWMS Context Freshness Review Protocol
MWMS Dynamic Context Retrieval Standard
MWMS Context Gap Logging Standard

Strategic Summary

The MWMS Context Engineering Framework makes context a formal system layer.

It ensures that AI Employees and AI Operating Systems do not act from vague, generic, outdated, or unsafe information.

MWMS must engineer context deliberately because context determines:

output quality
decision accuracy
trust
safety
personalization
system usefulness
operational reliability
business value

The long-term MWMS advantage will not come only from better prompts or better models.

It will come from better context architecture.

Final Standard

The MWMS standard is:

The right AI model matters.
The right prompt matters.
But the right context matters more.
Every serious MWMS AI system must define, retrieve, filter, structure, protect, apply, and improve context before it acts.

This framework establishes context engineering as a core MWMS operating discipline.

Change Log

2026-05-31 — Created

Created from AI Automations by Jack — AI Foundations Section 1.
Added context engineering as a formal MWMS architecture discipline.
Defined context engineering as the structured design, selection, retrieval, validation, and control of information used by AI systems.
Established the MWMS Context Stack: identity, task, business, source, historical, system state, constraint, governance, performance, and evidence context.
Added static, dynamic, retrieved, human-supplied, and system-generated context categories.
Added the MWMS Context Engineering Flow: trigger, required context, context sources, classification, filtering, structuring, application, output, recording, and improvement.
Added context authority hierarchy for resolving conflicting information.
Added context freshness standard for permanent, stable, active, and volatile context.
Added context safety rules covering sensitive information, least-context usage, prompt injection risk, source visibility, and governance priority.
Added MWMS Context Pack Standard for repeatable AI Employee and AI Operating System workflows.
Mapped context engineering responsibilities across HeadOffice, Automation Brain, AIBS Brain, Data Brain, Research Brain, Content Brain, Affiliate Brain, Sales Brain, Compliance Brain, and Risk Brain.
Added context engineering failure modes and implementation checklist.
Added related future employee capabilities: Context Engineer, Source Librarian, Evidence Reviewer, Memory Curator, AI Employee Architect, and Governance Reviewer.