MWMS Business Brain Copilot Architecture Framework

System: MWMS
Document Type: Operating Framework
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Version: v1.0
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, AIBS Brain, Data Brain, Automation Brain, Research Brain, Experimentation Brain, Finance Brain, Content Brain, Sales Brain, Risk Brain, Compliance Brain, Operations Brain
Parent Page: HeadOffice
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR
Last Reviewed: 2026-06-03
Source / Origin: AI Automations by Jack — Business Systems / AI Copilot / Business Brain / Memory / Instructions / Universal Remote / Numbers Block
MWMS Classification: AIOS Architecture Framework / Business Copilot Framework / Context-Memory-Tool-Data Operating Standard / HeadOffice Decision Support Architecture
Primary Brain: HeadOffice Brain
Supporting Brains: AIBS Brain, Data Brain, Automation Brain, Research Brain, Experimentation Brain, Finance Brain, Content Brain, Sales Brain, Risk Brain, Compliance Brain, Operations Brain, Product Brain, Customer Brain

Related Pages: AIBS Brain Canon, MWMS AI Operating System Architecture Framework, MWMS Context Engineering Framework, MWMS AI Agent Memory And Context Framework, MWMS AI Tool Permission And Access Framework, MWMS AI Automation Security And Risk Checklist, MWMS Dashboard-First Client AIOS Offer Framework, MWMS AI Audit Diagnostic And Paid Roadmap Framework, MWMS Commercial Constraint And Client Acquisition Operating Framework, MWMS Offer And Niche Selection Framework, MWMS Avatar Hypothesis And Market Definition Framework, MWMS Source Visibility And Evidence Display Standard, MWMS Brain To Brain Request Protocol, MWMS Brain Routing Rule, MWMS Supabase RAG And Vector Memory Framework, MWMS AI Dashboard Capability Framework, HeadOffice Kaizen Continuous Improvement Loop

Source Evidence: This framework is derived from the AI Automations by Jack business systems block, which frames the major business AI advantage as context, speed, and focus, and introduces a business copilot architecture built from a business brain file, working files, long-term memory, system instructions, external tool access, and structured business numbers.

Purpose

The purpose of the MWMS Business Brain Copilot Architecture Framework is to define how MWMS structures a full business AI copilot using context, memory, operating instructions, tools, structured data, dashboards, and decision-support outputs.

This framework exists because MWMS must not think of AI as a chatbot.

A business copilot is not just a conversation window.

A serious business copilot needs:

a canonical business profile
source-of-truth hierarchy
business identity
operating doctrine
active working files
long-term memory
structured business numbers
tool access
dashboards
action outputs
task routing
governance
decision-support logic

The source block positions AI advantage around three factors:

Context — the AI must understand the business deeply
Speed — the AI must help the business act faster
Focus — the AI must help identify the most important bottleneck and avoid distraction

This is strongly aligned with MWMS.

MWMS already has Brains, MCR pages, Brain Room, HeadOffice, Supabase, AI Employees, task logs, dashboards, memory frameworks, and AIOS architecture.

This framework ties those pieces together into a clear architecture:

Business Brain Profile + Memory Layers + Operating Doctrine + Tool Routing + Numbers Layer + Dashboards + Governance = Business Brain Copilot.

Core Doctrine

The MWMS doctrine is:

AI without business context is weak.
AI with business context, memory, tools, numbers, and governance becomes a business copilot.

A business copilot must know:

who the business is
who it serves
how it makes money
what it believes
what it will and will not do
what its current bottleneck is
what the numbers say
what systems already exist
what tools it may use
what memory it should retrieve
what actions it may recommend
what actions require human approval
what source of truth must be followed

The copilot must not behave like a generic assistant.

It must act within the business’s identity, rules, priorities, evidence, and governance boundaries.

Strategic Importance

This framework is strategically important because it strengthens several MWMS directions at once.

It supports:

HeadOffice decision-making
AIBS client AIOS architecture
Business Brain setup
AI Employee context packs
Memory and retrieval design
structured data / Supabase design
tool permission boundaries
dashboard-first client systems
AI audit outputs
client onboarding
business diagnostics
task creation and routing
decision-support reporting

The block’s strongest lesson is:

The AI copilot becomes powerful when it stops being generic and starts operating inside the real business context.

The course’s brain.md concept describes a business DNA document containing the business identity, customers, problems solved, customer journey, metrics, team, current state, links, founder story, credibility, edge, and audience sophistication.

For MWMS, this becomes bigger than a file.

It becomes a Business Brain Profile Standard.

Every serious MWMS Brain, AI Employee, client AIOS, or AIBS client package needs a canonical profile that defines what the system must know before it acts.

Definition

A business brain copilot is an AI-supported operating system that understands the business, retrieves relevant memory, reads structured data, uses approved tools, creates structured outputs, and helps the owner or team make better decisions.

A Business Brain Profile is the canonical identity and context document that defines the business, customer, offer, journey, numbers, team, constraints, current focus, dream outcome, founder story, links, and operating boundaries.

A numbers layer is the structured database layer that stores metrics and business performance data so the AI can reason from actual numbers rather than memory alone.

A tool-routing layer defines what tools the copilot may use, when to use them, and what approval boundaries apply.

MWMS Definition

The MWMS Business Brain Copilot Architecture is:

A governed AIOS pattern that combines business identity, context hierarchy, memory layers, operating doctrine, approved tool access, structured business numbers, visible outputs, and decision-support logic so MWMS or a client business can make faster, better, more focused decisions.

Scope

This framework applies to:

HeadOffice Brain decision support
MWMS Brain Room evolution
AI Manager architecture
AI Employee context packs
AIBS client AIOS foundations
client business brain profiles
AI audit intake and roadmap systems
Data Brain schemas
Supabase metrics systems
vector memory / RAG systems
MCR retrieval systems
dashboard systems
business operating dashboards
tool routing policies
MCP / API / automation bridge architecture
system instruction files
AIOS governance
business bottleneck analysis
executive decision support
future client copilot offers

This framework does not authorise immediate development work.

Any implementation must be converted into a separate developer-safe brief with exact site, page, table, file path, test steps, and rollback notes.

Core Principle

The core principle is:

A business copilot must combine context, memory, tools, numbers, and governance.

Context alone is not enough.

Memory alone is not enough.

Tools alone are dangerous.

Numbers alone lack interpretation.

Dashboards alone do not decide.

Instructions alone do not create business value.

A serious copilot needs all layers working together.

The MWMS Business Brain Copilot Stack

The standard MWMS Business Brain Copilot stack contains ten layers:

Business Brain Profile Layer
System vs Session Layer
Context Hierarchy Layer
Memory Layer
Operating Doctrine Layer
Tool Routing Layer
Numbers / Structured Data Layer
Output Workspace Layer
Dashboard And Decision Layer
Governance And Safety Layer

1. Business Brain Profile Layer

The Business Brain Profile is the canonical identity of the business.

It answers:

who the business is
who it serves
what it sells
how it makes money
what it believes
how it decides
what it will not do
what its current bottleneck is
what its dream outcome is

The source block describes brain.md as the business DNA, single source of truth, and backbone for who the business is, who it serves, how it makes money, what it believes, how it decides, and what it will and will not do.

Business Brain Profile Fields

Every Business Brain Profile should include:

Business Name:
Business Owner / Maker:
Business Summary:
Primary Business Model:
Revenue Streams:
Primary Offers:
Target Customers:
Ideal Customer Profile:
Customer Problems Solved:
Big Problem Umbrellas:
Customer Journey:
Click-To-Close Path:
Lead Sources:
Sales Process:
Delivery Process:
Retention Process:
Current Metrics:
Revenue:
Profit:
Leads:
Appointments:
Presentations:
Sales:
Retention / Churn:
Team Members:
Contractors:
Roles:
Costs:
Current Bottleneck:
Current Focus:
Dream Outcome:
Core Links:
Website:
Social Profiles:
Content Channels:
Founder Origin Story:
Credibility:
Unique Edge:
Audience Sophistication:
Decision Rules:
Constraints:
What The Business Will Not Do:
Source Of Truth:
Last Updated:

Rule

A business copilot without a Business Brain Profile is operating with incomplete identity.

2. System vs Session Layer

The source block separates systems from sessions.

Systems are more static, repeatable operating assets such as websites, dashboards, operating systems, scraping systems, content systems, and workflow systems. Sessions are flexible working conversations with the AI where the user may explore ideas, decisions, plans, or documents.

MWMS must preserve this distinction.

Systems

Systems are structured assets.

Examples:

HeadOffice dashboard
Brain Room
task queue
client AIOS
lead qualification system
content repurposing system
competitor intelligence system
MCR page structure
Supabase database
AI audit roadmap dashboard
client reporting system
workflow automation

Systems should be:

documented
repeatable
governed
measurable
supportable
tied to outcomes

Sessions

Sessions are working conversations.

Examples:

strategy discussion
idea exploration
page drafting
client call preparation
bottleneck analysis
audit analysis
campaign review
content planning
decision support
task planning

Sessions should produce:

decisions
notes
tasks
documents
updates
memory entries
action plans
page drafts
system improvement recommendations

Rule

Systems run the business.
Sessions improve, use, or create systems.

3. Context Hierarchy Layer

The business copilot needs a hierarchy of truth.

The source block’s system instructions lesson defines a hierarchy including system doctrine, brain.md, project files, live resources, long-term memory, current thread, and inference.

MWMS should use its own hierarchy.

MWMS Context Hierarchy

The standard hierarchy is:

System / Developer Instructions
MWMS Constitution / Canons / MCR Source Of Truth
Brain Canon
Business Brain Profile
Relevant MCR Pages
Active Project Files / Current Working Context
Structured Data / Supabase / Metrics
Approved Tool Outputs
Long-Term Memory / Vector Retrieval
Current Conversation
Clearly Labelled Inference

Rule

The copilot must know which source has authority when sources conflict.

MCR and Brain Canons outrank casual conversation.

4. Memory Layer

The source block separates memory into:

short-term memory
mid-term memory
long-term memory

Short-term memory is the current conversation/context window. Mid-term memory is active project files used regularly. Long-term memory is a vector/RAG database for material that should be retrievable later but not always loaded.

MWMS should adopt this as an architectural standard.

Short-Term Memory

Short-term memory includes:

current conversation
current task
current files
current page being drafted
current decision
current user instruction

Use for:

immediate work
active drafting
live decision-making
current block absorption

Risk:

can drift if conversation is long
can lose important details
should not be the only source of truth

Mid-Term Memory

Mid-term memory includes frequently used project files and active context.

Examples:

current Brain Canon
current MCR page being updated
active project brief
current campaign rules
recent uploaded course files
active client audit notes
active implementation checklist
current metrics export

Use for:

work happening this week/month
active projects
often-used reference material

Long-Term Memory

Long-term memory includes searchable archives.

Examples:

old course transcripts
newsletters
old audits
client documents
meeting notes
historic campaign results
content archives
research libraries
MCR history
case study archive

Use for:

retrieval when needed
evidence support
long-range continuity
pattern detection

Memory Placement Rule

If it is used often, keep it close.

If it is needed later but not constantly, store it in long-term retrieval.

If it is source-of-truth, it must live in MCR or the approved canonical system.

Rule

Memory must be placed according to frequency, authority, and risk.

5. Operating Doctrine Layer

The operating doctrine layer tells the AI how to behave.

The source block uses a master instruction file that defines the AI as a business brain copilot, not a general chatbot, and instructs it to load business context, follow a hierarchy of truth, route tools, output recommendations, and operate around clarity, leverage, alignment, and execution.

MWMS should implement this through Brain Canons, Employee Role Cards, system prompts, tool policies, and client AIOS instruction files.

Operating Doctrine Fields

Each serious copilot should define:

Identity:
Purpose:
Owner:
Primary User:
Authority Level:
Source Of Truth:
Truth Hierarchy:
Required Context:
Allowed Tools:
Prohibited Tools:
When To Retrieve Memory:
When To Use Structured Data:
When To Ask Clarifying Questions:
When To Escalate:
When To Create Tasks:
Output Format:
Tone / Style:
Accuracy Rules:
Evidence Rules:
Memory Write Rules:
Governance Rules:
Risk Boundaries:
Human Approval Requirements:

Rule

A copilot without operating doctrine behaves like a generic chatbot.

6. Tool Routing Layer

The tool routing layer defines what the copilot may access and when.

The source block shows direct MCP integrations and n8n as a “universal remote” that can bridge to tools such as Gmail, Calendar, Drive, and other workflows.

For MWMS, this is useful but must be governed.

Tool Types

Possible tools include:

Gmail
Google Calendar
Google Drive
Supabase
WordPress / MCR
Make
n8n
Firecrawl
scraping tools
CRM
task systems
dashboards
analytics
ad platforms
reporting tools
document tools
vector stores
finance systems
content tools

Tool Routing Questions

Ask:

What tool is needed?
Why is it needed?
Is the tool approved for this Brain or AIOS?
What data will be accessed?
Is the action read-only or write-capable?
Does the user need to approve?
Is there a risk?
Is the action logged?
Does this touch client data?
Does this touch external communication?
Does this affect money, ads, publishing, or customer contact?

Universal Remote Rule

n8n or Make may act as controlled execution bridges.

But they must not become unrestricted access layers.

Rule

Tool access is authority.

Authority must be governed.

7. Numbers / Structured Data Layer

The source block’s numbers lesson is critical.

It explains that text memory is not enough for business decision-making. Business numbers need structured storage, such as a database, so the AI can query metrics, calculate averages, identify trends, compare sources, and support executive decisions.

For MWMS, this is a major standard:

Text memory explains context. Structured data explains performance.

A business copilot needs both.

Numbers Categories

The source block groups numbers into areas such as revenue/finance, leads/sales, customers, and content/platform metrics.

MWMS should structure numbers across:

Finance

revenue
profit
expenses
cashflow
subscriptions
tool costs
ad spend
CAC
LTV
margin
churn

Leads And Sales

leads
source
appointments
presentations
sales
close rate
show-up rate
follow-up rate
pipeline stage
offer conversion

Affiliate

impressions
views
clicks
LPCTR
VSL clicks
sales
refunds
EPC
CPA
ROAS
profit/loss

PPL

visitors
form starts
submitted leads
accepted leads
rejected leads
payout
CPL
rejection reason
buyer value

Content

platform
title
format
views
likes
comments
watch time
CTR
engagement
subscribers
leads generated
conversions

AIBS

audit leads
audits sold
implementation proposals
projects sold
MRR
churn
client value metrics
support load
reports delivered
time saved
opportunities found

Operations

tasks
task status
blockers
owner
due dates
events
completion rate
failed task rate
handoff time

Rule

Business numbers belong in structured data, not scattered conversation notes.

8. Output Workspace Layer

The copilot should create useful operating assets.

The source Notion lesson shows the AI creating documents, job descriptions, plans, to-do lists, and structured pages using a workspace integration.

For MWMS, the destination is not automatically Notion.

The destination depends on authority and purpose.

MWMS Output Destinations

Possible output destinations:

MCR page
HeadOffice dashboard
Brain Room
Supabase task
WordPress admin panel
client AIOS dashboard
audit roadmap
proposal draft
report
PDF
Google Doc
Google Sheet
operating brief
implementation checklist
SOP
content calendar
task list
email draft
sales script
experiment plan

Output Questions

Ask:

Is this source-of-truth?
Is this operational?
Is this a draft?
Is this client-facing?
Is this internal?
Does it need approval?
Where should it live?
Who needs to see it?
Does it create a task?
Does it update memory?

Rule

The copilot should create structured assets, not just answers.

9. Dashboard And Decision Layer

A business copilot should help make better decisions.

Dashboards and reports make this visible.

The numbers lesson shows the AI querying structured data and answering questions like average views, growth trends, and future projections.

MWMS should use dashboards and decision reports to connect:

context
memory
metrics
tasks
recommendations
next actions

Decision Outputs

The copilot may produce:

bottleneck diagnosis
constraint report
priority list
next three actions
opportunity scorecard
campaign review
content performance review
lead pipeline review
client audit roadmap
finance snapshot
task health report
weekly Kaizen digest
risk alert
trend report
experiment recommendation

Decision Questions

Ask:

What matters most now?
What is the bottleneck?
What do the numbers show?
What does the memory/context show?
What is the highest-leverage action?
What can be ignored?
What needs escalation?
What should be tested?
What should be built?
What should be parked?

Rule

A business copilot should convert data and context into decision support.

10. Governance And Safety Layer

The more powerful the copilot becomes, the more governance matters.

If the copilot can access tools, write files, query databases, create tasks, draft emails, update dashboards, or trigger workflows, it must be bounded.

Governance Requirements

A business copilot must define:

source-of-truth authority
user permissions
tool permissions
read/write boundaries
approval gates
audit logs
memory write rules
client data boundaries
external communication rules
publishing rules
financial action restrictions
deletion restrictions
escalation conditions
risk categories
fallback procedures
human ownership

Rule

A powerful copilot without governance becomes a business risk.

The Context + Speed + Focus Advantage

The source block defines the three differentiators as:

context
speed
focus

MWMS should treat this as a core business copilot doctrine.

Context

Context means the AI understands:

the business
the owner
the customer
the offer
the numbers
the history
the current bottleneck
the constraints
the rules
the source of truth

Without context, AI gives generic advice.

Speed

Speed means the AI helps:

create faster
decide faster
analyse faster
retrieve faster
draft faster
route faster
build faster
respond faster
test faster

Without speed, the copilot does not create leverage.

Focus

Focus means the AI helps identify:

the bottleneck
the 10X constraint
what matters now
what should be ignored
what should be parked
what should be tested
what should not be built

Without focus, AI creates more distraction.

Rule

A Business Brain Copilot must improve context, speed, and focus.

Business Brain Profile Standard

Every serious MWMS business copilot or client AIOS should begin with a Business Brain Profile.

Profile Sections

1. Business Identity

business name
owner
mission
current stage
business model
primary revenue streams
source of truth

2. Customer / Avatar

ideal customer
customer segments
geography
sophistication level
pains
desires
objections
buying triggers

3. Offer And Monetisation

offers
pricing
fulfilment
recurring revenue
upsells
value proposition
transformation promised

4. Customer Journey

discovery
lead capture
follow-up
sales process
payment
onboarding
delivery
retention
referral

5. Numbers

revenue
profit
leads
conversion
retention
churn
content metrics
campaign metrics
operating metrics

6. Team

internal team
contractors
roles
costs
performance notes
responsibilities

7. Current State

current bottleneck
current focus
active projects
current risks
constraints
dream outcome

8. Owner / Maker

founder story
credibility
beliefs
edge
preferred work style
public brand
content angle

9. Rules And Boundaries

what the business will not do
compliance rules
decision rules
cost rules
tool rules
approval rules

Rule

The Business Brain Profile must be updated when the business materially changes.

Business Brain Update Triggers

Update the Business Brain Profile when:

offer changes
avatar changes
business model changes
pricing changes
team changes
new Brain is created
new AIOS is created
current focus changes
major bottleneck changes
key metrics change
new compliance boundary appears
new tool stack is adopted
new source-of-truth page is created
client onboarding is completed
audit produces a roadmap

Rule

The Business Brain Profile is a living canonical document, not a one-time worksheet.

Memory Routing Standard

MWMS should route information to the correct memory layer.

Active Context

Use for:

current task
current page
current file
current session
immediate decision

Project / Mid-Term Memory

Use for:

frequently referenced pages
current course block
active client audit
active campaign
current project brief
working SOPs
current metrics files

Long-Term Retrieval

Use for:

course archives
old newsletters
historical decisions
old transcripts
research archives
case study library
client history
past campaign data

Structured Database

Use for:

metrics
task records
event logs
content performance
leads
customers
financial data
audit records
campaign records
experiment results

MCR / Canon

Use for:

final source-of-truth pages
Brain Canons
operating frameworks
governance rules
approved protocols
architectural standards

Rule

Do not store structured metrics in vector memory when they belong in a database.

Do not store source-of-truth rules only in chat memory.

Tool Routing Policy Standard

Every business copilot should define tool routing.

Example Routing

Use MCR when:

canonical rule is needed
framework must be referenced
source-of-truth page exists
Brain Canon governs decision

Use Supabase when:

metrics are needed
tasks are needed
records are needed
structured data is needed
trend analysis is needed

Use vector memory when:

long-term documents must be retrieved
historic course/newsletter data is needed
semantic search is useful

Use Google Drive / Docs when:

user documents or files are stored there
a working document is needed
collaboration is needed

Use Gmail / Calendar only when:

user explicitly requests email/calendar action
permission is granted
tool access is appropriate

Use n8n / Make when:

workflow execution is needed
external tool bridge is required
controlled automation is approved

Use web/browser tools when:

current external information is needed
competitor/current market data is required
sources must be checked

Rule

The copilot should use the right source or tool for the job, not the most convenient one.

Numbers Layer Standard

The numbers layer should help the copilot answer business questions.

Questions The Numbers Layer Should Support

Where are we making money?
Where are we losing money?
What offer is working?
What content is resonating?
What campaign is profitable?
What lead source converts best?
What is the bottleneck?
What is trending up?
What is trending down?
What should we do more of?
What should we improve?
What should we stop?
What is the projected result if the trend continues?

Rule

Numbers must be queryable, structured, and attached to decisions.

Business Bottleneck Decision Standard

The copilot should help identify the bottleneck.

Common bottlenecks:

leads
conversion
delivery
profit
focus
proof
retention
traffic
content
sales
onboarding
support
cashflow
data quality
tool complexity
M build capacity
compliance risk

Bottleneck Questions

Ask:

What is the current constraint?
What evidence supports this?
What do the numbers show?
What does the business owner feel?
What does the customer journey show?
What stage is leaking?
Is this a knowledge problem, system problem, sales problem, or focus problem?
What is the highest-leverage action?

Rule

The copilot should not recommend new work before diagnosing the bottleneck.

Application To HeadOffice Brain

HeadOffice Brain is the primary owner of this framework.

HeadOffice should use the Business Brain Copilot model to:

preserve Martyn’s vision
improve decisions
prevent drift
diagnose constraints
route tasks
assess priorities
protect M’s build capacity
manage Brain-to-Brain coordination
review metrics
produce operating summaries
maintain source-of-truth discipline

HeadOffice Rule

HeadOffice Copilot must always prioritise context, speed, focus, governance, and source-of-truth alignment.

Application To AIBS Brain

AIBS Brain uses this framework for client AIOS design.

Every serious AIBS client copilot should define:

client Business Brain Profile
operating doctrine
data sources
tool permissions
memory layers
dashboard outputs
client value reports
governance boundaries
numbers layer
decision support use cases

AIBS Rule

AIBS should sell business copilots as governed operating systems, not generic AI assistants.

Application To Data Brain

Data Brain owns the structured numbers layer.

Data Brain should define:

schemas
tables
fields
metrics
data quality rules
source of truth
update frequency
query patterns
dashboard logic
reporting standards
retention rules
client data isolation

Data Rule

If the copilot needs to calculate, compare, trend, or report numbers, the data belongs in a structured database.

Application To Automation Brain

Automation Brain owns execution bridges.

Automation Brain should define:

approved workflow triggers
n8n / Make routing
webhook security
workflow logs
action boundaries
approval gates
failure handling
retries
alerting
tool bridge ownership

Automation Rule

Automation bridges must be controlled, logged, and scoped.

Application To Research Brain

Research Brain supports context quality.

Research Brain should provide:

market context
avatar context
competitor research
source evidence
historical references
case study patterns
trend analysis
evidence packs

Research Rule

The copilot’s strategic advice is only as good as its context and evidence.

Application To Experimentation Brain

Experimentation Brain tests copilot recommendations.

Experimentation Brain should help define:

hypotheses
success criteria
test design
stop conditions
learning capture
experiment records
validation logic

Experimentation Rule

The copilot may recommend tests, but Experimentation Brain governs validation.

Application To Finance Brain

Finance Brain supports business numbers and financial decisions.

Finance Brain should define:

revenue tracking
cost tracking
margin logic
CAC/LTV
forecast rules
budget rules
tool-cost control
runway
profitability analysis

Finance Rule

The copilot must not make financial assumptions without structured data or clearly labelled uncertainty.

Application To Content Brain

Content Brain uses Business Brain Profile context for content creation.

Content Brain should use:

customer pains
founder story
edge
audience sophistication
content metrics
platform performance
market signals
offer rules
brand voice

Content Rule

Content created without Business Brain context will drift generic.

Application To Sales Brain

Sales Brain uses the Business Brain Profile and numbers layer to improve:

positioning
discovery
offer framing
objection handling
proposal drafting
cost of inaction
follow-up
close logic

Sales Rule

Sales advice must be based on the business model, customer journey, and numbers.

Application To Risk And Compliance Brain

Risk and Compliance Brain govern the copilot’s access and outputs.

They should check:

sensitive data
client data
regulated claims
external communication
tool access
memory writes
deletion actions
financial decisions
advertising claims
public publishing
privacy obligations
approval gates

Risk Rule

The more tools a copilot can use, the more governance it needs.

Application To Operations Brain

Operations Brain ensures the copilot’s outputs become action.

Operations should define:

task creation rules
owner assignment
handoff
due dates
follow-up cadence
dashboard review rhythm
escalation rules
weekly review process

Operations Rule

Decision support is incomplete unless it creates operating action.

Business Copilot Output Standards

When asked for business guidance, the copilot should usually provide:

What matters most
Current constraint
Evidence / context used
Recommended action
Next three steps
What not to do
Where this should be recorded or routed

Rule

The copilot should reduce confusion, not create more options.

Business Copilot Setup Checklist

Before creating a business copilot, check:

Identity

Business Brain Profile created?
Owner defined?
Source of truth defined?
Business model clear?
Customer/avatar clear?

Memory

short-term context defined?
mid-term files defined?
long-term memory defined?
memory placement rules defined?
memory update triggers defined?

Doctrine

operating instructions created?
truth hierarchy defined?
output standards defined?
escalation rules defined?
guardrails defined?

Tools

approved tools listed?
read/write boundaries defined?
approval gates defined?
logs defined?
risky tools restricted?

Data

numbers layer defined?
key tables identified?
metrics defined?
update cadence defined?
dashboard/report needs defined?

Outputs

where does the copilot write?
where does it create tasks?
where does it create pages?
where does it create reports?
what needs approval?

Governance

risk review complete?
compliance review complete?
human owner defined?
source-of-truth boundary clear?

Client Business Copilot Template

Use this template for future AIBS clients.

Client Business Name:
Owner / Decision Maker:
Primary User:
Industry:
Business Model:
Primary Offer:
Target Customer:
Core Problem Solved:
Customer Journey:
Current Bottleneck:
Current Metrics:
Team / Roles:
Tools Used:
Data Sources:
Memory Sources:
Operating Doctrine:
Allowed Tools:
Restricted Tools:
Dashboard Outputs:
Reports:
Decision Support Use Cases:
Human Approval Rules:
Risk Notes:
Compliance Notes:
MRR / Retention Logic:
Last Updated:

MWMS Internal Business Copilot Template

Use this template for internal MWMS Brain or HeadOffice copilot design.

Copilot Name:
Owning Brain:
Supporting Brains:
Purpose:
Authority Level:
Source Of Truth:
Brain Canon References:
Required MCR Pages:
Business Brain Profile:
Active Project Context:
Memory Sources:
Structured Data Sources:
Tool Access:
Output Destinations:
Task Routing Rules:
Decision Types Supported:
Escalation Rules:
Human Approval Requirements:
Drift Risks:
Review Cadence:

Drift Protection

This framework protects MWMS from:

treating AI as generic chat
rebuilding context every session
losing business identity
confusing memory with source of truth
storing metrics in unstructured notes
giving tools too much access
creating dashboards without decision value
creating copilot outputs with no action
bypassing MCR authority
bypassing Brain Canons
overloading vector memory
overloading the context window
using Notion-style tools as source of truth when MCR is canonical
relying on AntiGravity or any one tool as the architecture
creating client copilots without data boundaries
creating automation bridges without governance
letting a copilot recommend new work before diagnosing the bottleneck

Copilot Drift Signals

Watch for:

AI gives generic advice
AI ignores MCR rules
AI forgets current focus
AI suggests work outside scope
AI uses wrong source of truth
AI invents facts
AI cannot identify the bottleneck
AI cannot access relevant numbers
AI relies on old context
AI recommends tools without governance
AI creates tasks without owner
AI creates pages without need
AI confuses systems and sessions
AI stores everything in the wrong layer
AI cannot explain evidence
AI creates too many options instead of next steps

Rule

Copilot drift must be corrected by updating context, doctrine, memory placement, tool routing, or source-of-truth references.

Implementation Boundary

This page is an architecture framework, not a build task.

It does not instruct M to change:

mwmsbrain.site
mwmsheadofficebrain.site
Brain Room
Dev Console
AI Manager
Supabase tables
WordPress plugin files
MCR structure
AI Employee router
automation workflows

Before any implementation, HeadOffice must create a specific developer brief with:

exact site
exact module
exact purpose
exact file paths if code is involved
exact tables if database is involved
exact UI change
exact tool permissions
exact test steps
exact rollback notes
what not to touch

Rule

Architecture becomes development only after scoped approval.

Strategic Summary

This framework absorbs the strongest business systems lesson from the course block:

A serious business copilot is built from context, memory, instructions, tools, numbers, dashboards, and governance.

The course used AntiGravity, Notion, Pinecone, n8n, and Supabase as examples.

MWMS should extract the architecture, not become dependent on the exact tool choices.

For MWMS, the correct interpretation is:

MCR remains source of truth
Supabase remains the structured data layer where appropriate
vector/RAG memory supports retrieval
Brain Canons define authority
AI Employees need operating doctrine
n8n/Make can be controlled execution bridges
dashboards show performance and value
Business Brain Profiles define identity
HeadOffice governs priority and focus

The value is not in the tool stack.

The value is in the complete copilot architecture.

Final Standard

The MWMS final standard is:

A Business Brain Copilot must know the business, follow the source of truth, retrieve the right memory, query the right numbers, use only approved tools, create structured outputs, and support focused decisions.

A valid copilot must include:

Business Brain Profile
system vs session distinction
context hierarchy
memory routing
operating doctrine
tool routing policy
structured numbers layer
output workspace
dashboard / decision layer
governance and safety layer

That is the MWMS Business Brain Copilot Architecture standard.

Change Log

Version: v1.0

Date: 2026-06-03
Author: MWMS HeadOffice

Change:

Created the MWMS Business Brain Copilot Architecture Framework from the AI Automations by Jack — Business Systems block.

Captured the useful architecture from:

Your HUGE Opportunity
ABC’s
Introduction
AntiGravity
Brain.md
Notion
Memory
Instructions
Universal Remote
Numbers

Extracted the core MWMS-relevant operating model:

Business brain + context + memory + instructions + tools + numbers = AI business copilot.

Defined the MWMS Business Brain Copilot Stack with ten layers:

Business Brain Profile Layer
System vs Session Layer
Context Hierarchy Layer
Memory Layer
Operating Doctrine Layer
Tool Routing Layer
Numbers / Structured Data Layer
Output Workspace Layer
Dashboard And Decision Layer
Governance And Safety Layer

Added major sections:

Context + Speed + Focus Advantage
Business Brain Profile Standard
Business Brain Update Triggers
Memory Routing Standard
Tool Routing Policy Standard
Numbers Layer Standard
Business Bottleneck Decision Standard
Business Copilot Output Standards
Business Copilot Setup Checklist
Client Business Copilot Template
MWMS Internal Business Copilot Template
Copilot Drift Protection
Copilot Drift Signals
Implementation Boundary

Mapped the framework across:

HeadOffice Brain
AIBS Brain
Data Brain
Automation Brain
Research Brain
Experimentation Brain
Finance Brain
Content Brain
Sales Brain
Risk Brain
Compliance Brain
Operations Brain

Clarified that MWMS should absorb the architecture, not blindly copy the exact AntiGravity / Notion / Pinecone / n8n / Supabase implementation.

Purpose of creation:

To establish the MWMS standard for designing business copilots and client AIOS foundations that combine business identity, context hierarchy, memory layers, operating doctrine, approved tool access, structured business numbers, output workspaces, dashboards, governance, and decision-support logic.

END — MWMS BUSINESS BRAIN COPILOT ARCHITECTURE FRAMEWORK v1.0