Document Type: Canon
Status: Canon
Version: v1.22
Authority: HeadOffice
Applies To: All MWMS work involving AI tools (Plus, Pro, future systems)
Parent: Governance
Last Reviewed: 2026-04-22
Purpose
This guide exists to ensure consistency, discipline, ecosystem alignment, and canon compliance when starting any working session involving MWMS.
It removes ambiguity about:
what mode the session is in
what rules apply
how authority is enforced
how drift is prevented
how build-state is controlled
how system improvements are captured
how file changes are delivered
what long-term ecosystem vision governs decisions
how system architecture operates
how revenue flows through the ecosystem
where structural pages belong
where implementation work belongs
This is not optional process.
It is system hygiene.
This page also exists to prevent session drift caused by incomplete startup context.
Where a task depends on specific standards, those standards must be provided at session start.
Consistency comes from structure, not memory.
Scope
This canon applies to:
all MWMS AI-assisted working sessions
Plus sessions
Pro sessions
canon editing sessions
standards and page-standardisation sessions
brain-scoped work
free sessions
build sessions
governance sessions
This document governs how MWMS sessions must be started and what must be confirmed before valid work proceeds.
It does not replace:
individual brain canon
technical build specifications
page-level standards
registry update rules
savepoint requirements
change logs
Those remain governed by their own authoritative documents.
Core Principle (Non-Negotiable)
AI tools do not enforce canon.
Canon is enforced at the session boundary.
If the session is not framed correctly at the start, drift is expected.
Consistency comes from structure, not memory.
Mandatory Session Awareness Confirmation
Before beginning work the AI must confirm awareness of:
HeadOffice governance authority
Brain Registry structure
cross-brain authority boundaries
Finance capital governance
SIT enforcement authority
Experimentation statistical governance
Ads Brain experimentation role
Affiliate Brain opportunity validation role
If awareness cannot be confirmed the session must pause.
Mandatory Page Ownership Declaration Rule
Before drafting any new page or structural update, the AI must explicitly declare:
Site
Owning Brain
Document Type
Exact Page Title
Parent Page
Output Type
This declaration must appear BEFORE the draft document content.
Purpose:
prevent incorrect site placement
prevent incorrect page placement into MCR or incorrect Brain
ensure correct authority alignment on first creation
ensure parent-child structure is declared before drafting
reduce structural rework
If page destination is unclear, the output is invalid.
Environment Source-of-Truth Rule
MWMS uses two distinct environments.
MCR
MCR is the canonical structural knowledge layer of MWMS.
MCR stores:
canon
architecture
frameworks
models
protocols
standards
registries
employee registries
structural definitions
system logic descriptions
MCR defines how MWMS should work.
MWMSBrain.site
MWMSBrain.site is the operational interface layer of MWMS.
MWMSBrain.site contains:
dashboards
panels
UI rendering
PHP wiring
Supabase connections
admin interfaces
live system visibility
operational control surfaces
MWMSBrain.site makes MWMS usable in live operational form.
Core Environment Rule
Structure lives in MCR.
Implementation lives in MWMSBrain.site.
If a page defines:
doctrine
governance
canon
architecture
framework logic
protocol logic
standards
registries
employee registries
structural Brain behaviour
it belongs in MCR.
If work defines:
plugin build work
PHP / WordPress implementation
dashboard rendering
panel wiring
Supabase integration
admin-page build logic
interface behaviour
live operational UI
it belongs in MWMSBrain.site.
Instruction Location Precision Rule
When requesting page creation, modification, or review, the AI must explicitly state the system location where the work must occur.
The AI must never assume that conceptual architecture layers and physical implementation layers are interchangeable.
The following distinction must always be made explicit:
CREATE PAGE IN: MCR
or
IMPLEMENT / BUILD IN: MWMSBrain.site
MCR refers to the canonical architecture structure layer of MWMS.
MWMSBrain.site refers to the live operational interface layer where structure is implemented as usable system surfaces.
If the location is unclear, the AI must ask for clarification before giving page instructions.
Instruction clarity is required to prevent:
duplicate pages
incorrect hierarchy placement
wiring errors
structural drift
operator confusion
If system location is missing, the instruction is invalid.
Mandatory Full File Output Rule
All structural outputs must be delivered as:
FULL FILE OUTPUT
complete document
full replacement content
copy-paste ready
Partial outputs are invalid.
Fragment outputs are invalid.
Patch-style outputs are invalid.
Insertion-only outputs are invalid.
Section-only outputs are invalid.
The operator must never be required to reconstruct a document manually.
FULL FILE OUTPUT is the default behaviour in MWMS structured sessions.
If the operator must request FULL FILE OUTPUT, the session has failed format discipline.
Wait For Finished Rule (Course Absorption Sessions)
When the operator specifies:
read only
wait
do not extract yet
wait until finished
the AI must:
acknowledge receipt
read silently
not extract capability
not propose changes
not create pages
not propose frameworks
Extraction begins only after the operator confirms:
FINISHED
Violation of this rule introduces structural noise and workflow disruption.
Course absorption sessions must respect block boundaries.
MCR First Comparison Rule
Before recommending:
new pages
framework updates
canon updates
protocol updates
structural changes
the AI must:
compare new material against existing MCR structure.
Purpose:
prevent duplication
prevent parallel frameworks
prevent taxonomy drift
prevent structural fragmentation
prevent unnecessary page creation
Updates should prioritise:
merge into existing frameworks
strengthen existing pages
reduce structural proliferation
New pages should only be created when capability does not already exist structurally.
Output Structure Rule
All structural outputs must clearly state:
PAGE OWNERSHIP DECLARATION
FULL FILE OUTPUT
Change Impact Declaration (when applicable)
Monthly Change Log instruction (only when required)
If any of these elements are missing, the output is non-compliant.
Monthly Change Log Handling Rule
Monthly change log entries must only be produced when a session creates a meaningful:
system-level change
governance-level change
architectural change
behavioural rule change
structural milestone change
Routine actions must not automatically generate monthly logs.
If a monthly change log entry is required, the AI must clearly state:
Please add this to Change Log Month
If no meaningful system change occurred, the AI must say nothing about monthly logging.
Page-Level Change Logs
Where pages contain a Change Log section at the bottom, that log may remain minimal.
Approved minimum format:
Version: v1.0
Date: YYYY-MM-DD
Author: HeadOffice
Change: Initial creation.
Page-level logs exist only for document history continuity.
They do not automatically require monthly change log entries.
Employee Impact Check Rule
After any structural addition or structural update to MWMS, the session must include an Employee Impact Check.
Structural updates include:
new frameworks
framework updates
new systems
architecture changes
new decision models
new protocols
new standards
new registries
new behavioural logic
new structural capability layers
Purpose:
Ensure the employee layer evolves alongside the capability layer of MWMS.
Without this check, the system risks accumulating large capability depth without a clear operational workforce structure.
Employee Impact Check Procedure
For each Brain affected by the session, determine whether the new material:
creates a new employee requirement
strengthens an existing employee
suggests a future employee but not yet required
has no employee impact
The check must be performed even when no employee change is identified.
Structural Layer Relationship
MWMS is built across two interconnected layers:
Capability Layer
Employee Layer
Capability Layer defines:
what the system can do
Employee Layer defines:
who performs those functions
Both layers must evolve together to maintain implementation readiness.
Drift Protection
The system must prevent:
unclear destination pages
missing ownership declarations
fragment-only outputs
partial replacement outputs
missing FULL FILE OUTPUT
unnecessary change log work
incorrect Brain placement
incorrect Parent page placement
mixing MCR and MWMSBrain.site locations
missing governance context
session drift caused by incomplete startup structure
confusion between structural knowledge layer and operational interface layer
If the operator must ask where content belongs, the output failed structural requirements.
MWMS Ecosystem Vision Directive
MWMS operates as:
a governance-first AI corporation
a capital-efficient experimentation engine
a continuously improving system
Brains operate within defined authority boundaries.
HeadOffice maintains oversight authority.
Humans retain final authority.
All system decisions must align with:
survivability
capital discipline
structured experimentation
long-term system stability
Architectural Intent
Session structure exists to:
prevent drift
reduce errors
improve build speed
maintain governance discipline
enable reliable scaling
Structure enables repeatability.
Repeatability enables scale.
Scale enables system survivability.
Change Log
Version: v1.22
Date: 2026-04-22
Author: HeadOffice
Change:
Strengthened Full File Output rule as default behaviour.
Added Wait For Finished rule for course absorption sessions.
Added MCR First Comparison rule to prevent duplicate framework creation.
Improved drift protection language covering partial outputs.
Clarified separation between insertion outputs and full replacement outputs.
Improved structural reliability across multi-page sessions.