Parent: Governance
Status: Active Canon
Version: v1.0
Last Reviewed: 2026-06-11
Purpose
The MWMS Brain Identity Gate exists to stop any Brain, page, UI screen, Supabase table, plugin layer, workflow, specification, or handoff from drifting into the wrong department shape.
Each MWMS Brain is its own department.
Each department has its own job, default bias, operating surface, and output responsibility.
No Brain should inherit another Brain’s logic unless the workflow explicitly calls for it.
This page is the mandatory preflight gate before any Brain build direction is approved.
Core Rule
Before any Brain-related work is approved, the operator must confirm:
Which Brain owns this?
What is that Brain’s department job?
What is the correct default bias for that Brain?
Is this a core operating surface or only a support layer?
Is another Brain’s logic leaking into this work?
Does this move the Brain toward its real output?
Would M understand the intended department purpose without guessing?
If the answer is unclear, the work does not move forward.
Why This Exists
MWMS is built as a multi-Brain operating system.
The system fails if every Brain starts to look like the same kind of database, research log, dashboard, or generic AI tool.
The danger is not only obvious scope creep.
The deeper danger is quiet Brain-bias drift.
A build can technically stay inside the visible rules while still being shaped by the wrong department logic.
Example:
A Content Brain records layer can be useful.
But if the records layer becomes the main Content Brain product, Content Brain starts to feel like Research Brain.
That is wrong.
Content Brain can use Research Brain evidence, but Content Brain must still be shaped around content outputs.
The Brain Identity Gate prevents that type of hidden drift.
Mandatory Brain Identity Questions
Every new Brain page, build task, plugin screen, Supabase table, workflow, specification, handoff, or operating layer must answer the following questions before approval.
- Which Brain Owns This?
The owning Brain must be named clearly.
Examples:
Content Brain
Research Brain
Ads Brain
Conversion Brain
Compliance Brain
Data Brain
Finance Brain
Operations Brain
Automation Brain
HeadOffice
AIBS Brain
Strategy Brain
UX Brain
Product Brain
Offer Brain
Sales Brain
Customer Brain
Risk Brain
If ownership is unclear, the work must be paused or routed to HeadOffice for clarification.
- What Department Job Does This Brain Own?
The work must match the Brain’s department role.
Examples:
Research Brain owns discovery, evidence, market truth, source quality, and uncertainty.
Content Brain owns transformation of approved intelligence into usable content assets.
Ads Brain owns paid traffic testing, hook testing, audience testing, and campaign decision support.
Conversion Brain owns persuasion, page action, trust, friction reduction, CTA clarity, and conversion improvement.
Compliance Brain owns claims safety, platform policy, evidence standards, and risk control.
Data Brain owns measurement integrity, event quality, attribution, and reporting reliability.
Finance Brain owns budget, capital allocation, downside protection, profitability, and scale readiness.
Operations Brain owns execution stability, handoff clarity, delivery sequencing, and bottleneck control.
Automation Brain owns trigger logic, reliability, monitoring, failure handling, and human override.
HeadOffice owns system control, governance, priority, decision authority, and cross-brain alignment.
The task must be shaped by the owning Brain’s job, not by a neighbouring Brain’s comfort zone.
- What Is The Correct Default Bias?
Each Brain has a default bias.
The default bias is the question that Brain should naturally ask first.
Examples:
Research Brain asks:
What is true and what evidence supports it?
Content Brain asks:
What content asset should this become?
Ads Brain asks:
What test, creative, hook, audience, or campaign decision should this inform?
Conversion Brain asks:
What action, trust, proof, friction, or persuasion improvement is needed?
Compliance Brain asks:
What claim, risk, platform, or evidence issue must be controlled?
Data Brain asks:
Can the measurement and attribution be trusted?
Finance Brain asks:
Is this worth funding, scaling, pausing, or protecting against?
Operations Brain asks:
How does this get executed reliably?
Automation Brain asks:
Can this run safely, predictably, and with human override?
HeadOffice asks:
Does this serve the system direction and maintain control?
If the proposed work is biased toward the wrong Brain, it must be corrected before it moves forward.
- Is This A Core Surface Or Support Layer?
Every build must be classified as either:
Core Surface
or
Support Layer
A Core Surface is the main operating surface of that Brain.
A Support Layer helps the Brain but must not become the main product.
Example:
For Content Brain:
Core Surface:
Output Style Selector
Content Asset Brief Screen
Refresh Plan Output
Publishing Readiness Output
Repurposing Pack Output
Affiliate Funnel Support Output
Support Layer:
Site Intelligence Records
Evidence records
Review history
Archive state
Compliance risk flags
Migration status
The support layer can exist, but it cannot become the main direction of the Brain.
- Is Another Brain’s Logic Leaking In?
The operator must check for wrong-Brain leakage.
Examples:
Research Brain leakage into Content Brain:
Too much focus on evidence records, review logs, source capture, and intelligence storage instead of content outputs.
Data Brain leakage into Ads Brain:
Too much focus on reporting infrastructure instead of campaign testing decisions.
Automation Brain leakage into Operations Brain:
Too much focus on triggers and execution machinery before manual process stability exists.
Compliance Brain leakage into Content Brain:
Too much risk control that prevents content production decisions from being made.
Content Brain leakage into Research Brain:
Creating content briefs before evidence quality is known.
HeadOffice leakage into specialist Brains:
Turning every Brain screen into a command dashboard instead of letting the department do its job.
If leakage is found, the task must be reframed.
- Does This Move The Brain Toward Its Real Output?
The work must move the Brain closer to its true output.
Examples:
Content Brain real outputs:
SEO content briefs
Affiliate pre-sell structures
Refresh plans
Publishing readiness checks
Content packs
Repurposing packs
Internal link plans
Content QA outputs
Research Brain real outputs:
Research verdicts
Evidence summaries
Market signal maps
Customer insight records
Competitor analysis
Source-quality assessments
Ads Brain real outputs:
Test plans
Creative angle decisions
Campaign reviews
Hook performance decisions
Audience testing decisions
Conversion Brain real outputs:
Friction findings
CTA recommendations
Trust improvements
Page conversion recommendations
Offer clarity fixes
If the work only creates more storage, more bloat, or more abstract structure without moving toward the Brain’s real output, it must be challenged.
- Would M Understand The Intended Build Without Guessing?
Every build instruction must be clear enough that M can see:
What this is
What Brain owns it
What it is allowed to do
What it is not allowed to do
Whether it is core or support
What must not be expanded
What status must remain unchanged
If M would need to guess, the instruction is not ready.
Approval Standard
A Brain-related build is approved only when all of the following are true:
Owning Brain is clear.
Department job is clear.
Default bias matches the Brain.
Core surface or support layer is declared.
Wrong-Brain leakage has been checked.
The work moves the Brain toward its real output.
The build does not quietly create automation, routing, workers, generators, dashboards, or cross-brain wiring unless explicitly approved.
M could follow the handoff without interpreting hidden intent.
Failure Conditions
The work must be stopped or rewritten if:
The owning Brain is unclear.
The work sounds useful but does not match the Brain’s department job.
The work is shaped by another Brain’s bias.
A support layer is becoming the core product.
The task creates hidden automation, routing, or cross-brain behaviour.
The task increases bloat without improving the Brain’s real output.
The handoff depends on assumptions M cannot see.
The task creates a generic system instead of a department-specific surface.
Content Brain Example Correction
Incorrect direction:
Build more Site Intelligence record features because records are useful.
Why this is wrong:
Records are useful, but they are not the core Content Brain product.
Correct direction:
Stabilise the Site Intelligence Records layer as a support layer.
Then move the next build direction toward the Content Brain Output Layer.
Correct Content Brain core direction:
Output Style Selector
SEO Content Brief Output
Affiliate Pre-Sell Page Brief
Comparison Page Brief
Product Review Page Brief
Refresh Plan
Thin Content Expansion Plan
Internal Linking Plan
Publishing Readiness Checklist
Repurposing Pack
Content QA Output
Affiliate Funnel Support Pack
Correct rule:
Content Brain turns approved intelligence into usable content assets.
Research Brain Example Correction
Incorrect direction:
Create a content brief generator inside Research Brain.
Why this is wrong:
Research Brain can identify content opportunities, but Content Brain owns content output creation.
Correct direction:
Research Brain produces evidence, insight, verdict, and opportunity records.
Content Brain uses those records to create content briefs and output assets.
Ads Brain Example Correction
Incorrect direction:
Build a raw analytics warehouse inside Ads Brain.
Why this is wrong:
Data Brain owns measurement integrity and data infrastructure.
Correct direction:
Ads Brain receives trusted data and uses it to make campaign, hook, creative, audience, and spend decisions.
Supabase And Plugin Screen Rule
Before creating any Supabase table or plugin screen, confirm:
Is this table or screen serving the owning Brain’s core job?
Is it a core surface or support layer?
Is it storing information only, or helping produce the Brain’s real output?
Could this table or screen accidentally become the main product?
Does this belong in another Brain instead?
If the answer is unclear, do not build.
WordPress Page Rule
Before creating any WordPress page, confirm:
Is this page canon, framework, protocol, template, short log, specification, or operating page?
Does the page belong to the correct Brain?
Is the parent page correct?
Does the page support the Brain’s department job?
Is this page needed, or is it bloat?
Does this page duplicate an existing page?
If the page only exists because something feels useful, do not create it.
Handoff Rule
Before any M handoff, include:
Owning Brain
Department purpose
Approved build surface
Support layers
Forbidden expansion
Manual / automation status
Routing status
Generator status
Worker status
M involvement boundary
Current save point
Expected output
M must never receive a handoff that hides the Brain’s purpose.
Operating Principle
Brain first.
Department purpose second.
Core surface third.
Support layer fourth.
Build last.
Final Rule
No Brain build moves forward unless it passes the MWMS Brain Identity Gate.
The purpose of this page is to stop quiet architecture drift before it becomes code, pages, UI, Supabase structure, or M handoff.
Each Brain must remain itself.
No Brain is allowed to become another Brain by accident.