Parent: Governance
Status: Active Canon
Version: v1.0
Last Reviewed: 2026-06-11
Purpose
The MWMS Core Surface Versus Support Layer Rule exists to stop useful supporting systems from becoming the main product of a Brain.
Every MWMS Brain has a core operating surface.
Every MWMS Brain may also have support layers.
The core surface is what the Brain is really for.
The support layer helps the Brain operate, but it must not become the Brain’s main direction.
This rule prevents database bloat, research drift, dashboard drift, records drift, and useful-side-feature drift from quietly reshaping a Brain.
Core Rule
Before any Brain page, UI screen, Supabase table, plugin feature, workflow, specification, or M handoff is approved, it must be classified as either:
Core Surface
or
Support Layer
If it is a Core Surface, it must directly serve the Brain’s main department job.
If it is a Support Layer, it must remain clearly secondary.
A Support Layer is not allowed to become the main product unless Martyn explicitly approves that shift.
Why This Exists
A support layer can be useful and still be dangerous.
The danger is that useful support layers feel productive.
They create records.
They store information.
They organise signals.
They make the system look more complete.
But if they are not controlled, they can pull a Brain away from its real department purpose.
Example:
Content Brain can have Site Intelligence Records.
That records layer is useful.
But if the Records layer becomes the main Content Brain UI, Content Brain starts drifting toward Research Brain.
That is wrong.
Content Brain’s core surface should be content output selection and content asset production pathways.
The Records layer should stay behind that as a support layer.
Definitions
Core Surface
A Core Surface is the main working surface of a Brain.
It is where the Brain performs its real department job.
It should answer the Brain’s default department question.
It should move the operator toward the Brain’s real output.
A Core Surface should be visible, central, and protected.
Support Layer
A Support Layer helps the Brain perform its job.
It may store records, evidence, status, history, logs, signals, templates, or metadata.
It may be necessary.
It may be valuable.
But it is not the main Brain product.
A Support Layer should stay secondary unless it is explicitly promoted.
Core Surface Test
A proposed build layer is a Core Surface only if it passes all of these checks:
It directly serves the owning Brain’s department purpose.
It helps produce the Brain’s real output.
It answers the Brain’s default operating question.
It is not mainly storage.
It is not mainly logging.
It is not mainly administration.
It is not mainly evidence capture.
It is not mainly status tracking.
It is not secretly doing another Brain’s job.
It would still make sense if all support layers were hidden behind it.
If the layer does not pass these checks, it is not a Core Surface.
Support Layer Test
A proposed build layer is a Support Layer if it mainly does one or more of the following:
Stores records.
Stores evidence.
Tracks status.
Tracks history.
Stores logs.
Holds review outcomes.
Stores metadata.
Holds archive state.
Tracks migration state.
Tracks compliance flags.
Tracks build readiness signals.
Supports a later output decision.
Helps the operator verify what happened.
A Support Layer is allowed, but it must be named as support and controlled as support.
Mandatory Classification
Every new Brain build item must include one of these labels:
Core Surface
Support Layer
Do not use vague labels like:
Useful layer
Important screen
Future feature
Operating layer
Admin area
Signal system
Record system
Workflow helper
Those labels are not enough.
The classification must be explicit.
Content Brain Example
Content Brain department job:
Turn approved intelligence into usable content assets.
Content Brain default question:
What content asset should this become?
Content Brain Core Surfaces:
Output Style Selector
SEO Content Brief Output
Affiliate Pre-Sell Page Brief
Product Review Page Brief
Comparison Page Brief
Listicle Brief
Authority Article Brief
Refresh Plan Output
Thin Content Expansion Plan
Internal Linking Plan
Publishing Readiness Checklist
Repurposing Pack
Content QA Output
Affiliate Funnel Support Pack
Content Brain Support Layers:
Site Intelligence Records
Evidence records
Review history
Compliance risk flags
Friction signals
Build readiness signals
Archive state
Migration status
Test record storage
Correct rule:
Records may support Content Brain, but records must not become Content Brain.
Research Brain Example
Research Brain department job:
Discover, validate, and structure evidence, market truth, customer signals, source quality, and uncertainty.
Research Brain default question:
What is true, what evidence supports it, and what does the market or user behaviour show?
Research Brain Core Surfaces:
Research Evidence Layer
Research Verdict Layer
Market Signal Interpretation
Customer Insight Records
Competitor Analysis
Source Quality Review
Opportunity Evidence Review
Research Brain Support Layers:
Source archive
Intake logs
Search query records
Evidence metadata
Research backlog
Review timestamps
Correct rule:
Evidence and verdicts are core to Research Brain.
Content brief generation is not core to Research Brain.
Ads Brain Example
Ads Brain department job:
Make paid traffic, creative, hook, audience, campaign, and spend testing decisions.
Ads Brain default question:
What test, creative, hook, audience, campaign, or spend decision should this inform?
Ads Brain Core Surfaces:
Campaign Testing Decision Layer
Creative Testing Layer
Hook Testing Layer
Audience Testing Layer
Campaign Review Screen
Ad Iteration Decision Surface
Scaling Signal Review
Ads Brain Support Layers:
Creative archive
Performance history
Campaign notes
Platform notes
Test logs
Spend snapshots
Correct rule:
Ads Brain can use data, but Ads Brain must not become Data Brain.
Data Brain owns measurement integrity.
Ads Brain owns test and campaign decisions.
Conversion Brain Example
Conversion Brain department job:
Improve action, persuasion, trust, proof, clarity, and conversion performance.
Conversion Brain default question:
What action, trust, proof, friction, or persuasion improvement is needed?
Conversion Brain Core Surfaces:
Conversion Friction Review
CTA Improvement Layer
Trust Signal Review
Proof Structure Review
Offer Clarity Review
Landing Page Improvement Brief
Message Match Review
Conversion Brain Support Layers:
Screenshot notes
Test history
Page review records
Conversion issue logs
Proof asset references
Correct rule:
Conversion Brain should not become a general content production system.
It should focus on improving action and conversion.
Compliance Brain Example
Compliance Brain department job:
Control claims, evidence requirements, platform policy, legal risk, and safety wording.
Compliance Brain default question:
What claim, risk, platform, legal, safety, or evidence issue must be controlled?
Compliance Brain Core Surfaces:
Claims Risk Review
Evidence Requirement Gate
Platform Policy Review
Safe Wording Recommendation
Compliance Approval Gate
Risk Classification Layer
Compliance Brain Support Layers:
Policy references
Claims archive
Review history
Risk status records
Evidence notes
Correct rule:
Compliance Brain can approve, block, or warn.
It should not become the content creation owner.
Data Brain Example
Data Brain department job:
Protect measurement integrity, event quality, attribution, analytics reliability, and reporting trust.
Data Brain default question:
Can the measurement, event, attribution, and reporting be trusted?
Data Brain Core Surfaces:
Measurement Integrity Review
Event Tracking Plan
Attribution Reliability Review
Data Quality Signal Review
Reporting Confidence Summary
Data Brain Support Layers:
Raw data references
Event logs
Debug logs
Analytics notes
Historical snapshots
Correct rule:
Data Brain can inform other Brains, but it must not make their specialist decisions for them.
Finance Brain Example
Finance Brain department job:
Control capital allocation, budget, downside risk, profitability, scale readiness, and financial exposure.
Finance Brain default question:
Is this worth funding, scaling, pausing, protecting, or reducing exposure to?
Finance Brain Core Surfaces:
Budget Decision Layer
Capital Allocation Review
Scaling Readiness Review
Downside Risk Review
Profitability Review
CAC / LTV Signal Review
Finance Brain Support Layers:
Spend records
Revenue snapshots
Cost logs
Forecast notes
Budget history
Correct rule:
Finance Brain can set limits and approve scale, but it does not own ad creative, content output, or research verdicts.
Operations Brain Example
Operations Brain department job:
Protect execution order, ownership, handoff clarity, delivery stability, and bottleneck control.
Operations Brain default question:
How does this get executed reliably, in the right order, with clear ownership and minimal bottlenecks?
Operations Brain Core Surfaces:
Execution Plan
Operating Checklist
Task Handoff
Bottleneck Review
Workflow Stability Review
Delivery Sequence
Operations Brain Support Layers:
Task logs
Status notes
Ownership records
Timing notes
Meeting notes
Correct rule:
Operations Brain should organise execution, not redefine specialist Brain outputs.
Automation Brain Example
Automation Brain department job:
Design safe, reliable, repeatable automation with monitoring, failure handling, and human override.
Automation Brain default question:
Can this run safely, predictably, repeatedly, and with human override?
Automation Brain Core Surfaces:
Automation Readiness Review
Trigger Logic Specification
Failure Handling Plan
Human Override Rule
Monitoring Requirement
Maintainability Review
Automation Brain Support Layers:
Execution logs
Error logs
Run history
Connection notes
Tool references
Correct rule:
Automation Brain must not start automating a process before the manual workflow is stable and approved.
HeadOffice Example
HeadOffice department job:
Govern the MWMS system, maintain alignment, protect priorities, control change, and manage cross-brain authority.
HeadOffice default question:
Does this serve the system direction, maintain control, and keep the Brains aligned?
HeadOffice Core Surfaces:
System Governance
Priority Control
Brain Alignment
Change Control
Decision Authority
M Handoff Protection
System Direction
HeadOffice Support Layers:
Status boards
Change logs
Operating notes
Registry records
Review history
Correct rule:
HeadOffice governs the system, but it must not flatten every specialist Brain into the same generic dashboard.
Support Layer Promotion Rule
A Support Layer can only become a Core Surface if Martyn explicitly approves the promotion.
Before promotion, the following must be documented:
Original Brain
Original classification
Reason it was a Support Layer
Reason it should become Core Surface
Risk of wrong-Brain drift
Impact on current Brain purpose
Impact on other Brains
Approval status
If this is not documented, the layer remains Support Layer.
Support Layer Containment Rule
Every Support Layer must have a containment note.
The containment note must answer:
What does this layer support?
What is it not allowed to become?
What Brain owns the core output?
What future expansion is forbidden without approval?
Example:
Content Brain Site Intelligence Records containment note:
This layer stores Site Intelligence test records, review outcomes, compliance risk flags, friction signals, build readiness signals, archive state, and migration status.
It supports Content Brain output decisions.
It is not the main Content Brain product.
It must not expand into Research Brain, full dashboard build, automation, content generation, worker execution, or Brain Room routing without approval.
The core Content Brain direction remains Output Style Selector and Content Asset Production Pathways.
UI Rule
Every plugin or admin UI screen must be classified as:
Core Surface UI
or
Support Layer UI
Core Surface UI should be prominent.
Support Layer UI should be accessible but not presented as the main Brain product.
A Support Layer UI must not be expanded just because it is useful.
Supabase Rule
Every Supabase table must be classified as supporting one of these:
Core Surface
Support Layer
If a Supabase table only stores records, logs, evidence, state, archive status, or metadata, it is usually a Support Layer.
If it directly powers the Brain’s main output pathway, it may support a Core Surface.
Supabase structure must not define the Brain’s purpose by accident.
WordPress Page Rule
Every WordPress page must support one of these:
Core operating page
Framework
Protocol
Template
Short summary log
Future specification
Support record explanation
No WordPress page should be created just because a support layer exists.
The existence of a test, record, or log does not automatically justify a WordPress page.
M Handoff Rule
Every M handoff must state:
Core Surface
Support Layer
or
Both
The handoff must also state:
Do not promote support layer to core.
Do not expand support layer beyond approved scope.
Do not infer future UI direction from support layer unless approved.
Do not build around records unless records are explicitly the core surface.
Failure Conditions
A build must stop if:
A Support Layer is being treated as the main product.
A Core Surface is not clearly defined.
The UI is growing around support records instead of real Brain outputs.
Supabase structure is shaping the Brain more than the department purpose.
The work is useful but does not move toward the Brain’s real output.
The layer belongs to another Brain.
M would likely build the wrong centre of gravity.
The task creates more bloat instead of better output.
Operating Principle
A useful layer is not automatically a core layer.
A record system is not automatically the product.
A dashboard is not automatically the command surface.
A database is not automatically the operating model.
The Brain’s department purpose decides the core surface.
Final Rule
Every MWMS Brain must clearly separate Core Surface from Support Layer.
Support Layers are allowed.
Support Layers can be valuable.
Support Layers can be necessary.
But Support Layers must never quietly become the Brain’s main product.
Each Brain must be built around its real department output.
Change Update
Created / added:
MWMS Core Surface Versus Support Layer Rule
Parent:
Governance
Status:
Active Canon
Version:
v1.0
Last Reviewed:
2026-06-11
Purpose:
Added a system-level rule to stop useful support layers from becoming the main product of a Brain.
Reason:
Content Brain drift exposed that a useful Records layer could accidentally become the centre of the Brain, even though the real Content Brain core should be output style selection and content asset production pathways.
Related control pages:
MWMS Brain Identity Gate v1.0
MWMS Department Bias Map v1.0
Operating impact:
All future Brain pages, UI screens, Supabase tables, plugin features, workflows, specifications, and M handoffs must classify the work as Core Surface or Support Layer before approval.
Support layers must remain secondary unless Martyn explicitly approves promotion to core surface.