Document Type: Reference
Status: Reference Architecture
Authority: MWMS HeadOffice
Applies To: Entire MWMS ecosystem
Parent: MWMS Canon
Version: v1.0
Last Reviewed: 2026-03-15
Purpose
This document defines how data moves across the MWMS ecosystem.
It explains:
• where data originates
• where data is processed
• where data is stored
• which Brain or system layer owns each flow
This page exists to make MWMS data movement visible at the system level.
It is the data-flow companion to the broader MWMS system architecture.
Scope
This reference applies to:
• data movement across WordPress, Supabase, executors, and Brain-level systems
• operational and governance data flows inside MWMS
• ownership visibility for major data pathways
• traceability of request, task, output, decision, and learning data
• future system expansion where new flows must be mapped deliberately
This document governs the high-level map of how data travels through MWMS.
It does not govern:
• exact database schema by itself
• exact API contract definitions by themselves
• UI layout by itself
• executor logic by itself
• Brain authority by itself
• security policy implementation by itself
Those remain governed by the MWMS – Supabase Task Schema Standard, MWMS – System Architecture, relevant Brain documents, and build-layer technical specifications.
Definition / Rules
Core Principle
Data in MWMS must move through defined, visible paths.
If a data flow cannot be explained in terms of origin, processing, storage, ownership, and output, it is structurally unclear.
Unclear data flow creates governance risk.
Primary Data Layers
MWMS operates through five major data layers.
- Input Layer
This is where data enters the system.
Typical inputs include:
• human requests
• WordPress admin submissions
• Brain intake forms
• task creation triggers
• campaign results
• external research inputs
• executor-generated outputs
Primary ownership at intake depends on the originating context:
• Humans / HeadOffice
• relevant Brain intake surface
• WordPress control layer
- Processing Layer
This is where input data is transformed into structured work or intelligence.
Typical processing includes:
• request classification
• Brain routing
• task creation
• executor analysis
• validation logic
• report generation
• review logic
Primary ownership typically sits with:
• HeadOffice for routing and high-level control
• relevant Brain for scoped analysis
• executor / worker layer for structured task processing
- Storage Layer
This is where MWMS stores system-of-record data.
Primary storage domains:
WordPress stores:
• admin pages
• page content
• dashboards
• visual control surfaces
• some UI-linked fields
Supabase stores:
• brain requests
• tasks
• task events
• artifacts
• decision records
• lessons learned
• structured operational history
Canon pages store:
• governance rules
• standards
• protocols
• frameworks
• reference architecture
- Output Layer
This is where processed data becomes usable output.
Typical outputs include:
• reports
• structured analysis
• campaign recommendations
• artifacts
• governance alerts
• decision records
• lessons learned entries
• dashboard visibility signals
Outputs may appear in:
• WordPress admin views
• Supabase records
• generated files or artifacts
• Brain-level reporting pages
- Governance Layer
This is the rule and review layer that determines how data is allowed to move.
Governance oversight includes:
• Brain scope validation
• task lineage
• append-only events where required
• visibility for HeadOffice
• SIT integrity checks
• Finance visibility for capital-relevant flows
• canon-defined boundaries
Major Data Flow Chains
Flow 1 – Human Request to Output
Human / HeadOffice Request
↓
WordPress intake or direct instruction
↓
Brain Request created
↓
Supabase task created
↓
Executor processes task
↓
Task events logged
↓
Artifact or output produced
↓
WordPress / Supabase visibility updated
Primary owners:
• HeadOffice
• target Brain
• executor layer
Flow 2 – Brain Request to Task Lineage
Brain Request
↓
mwms_brain_requests
↓
mwms_tasks
↓
mwms_task_events
↓
mwms_task_artifacts
This is the canonical operational data chain.
Primary owners:
• HeadOffice for routing governance
• assigned Brain for scoped ownership
• Supabase as system of record
Flow 3 – Decision and Learning Loop
Output or major event
↓
review / governance consideration
↓
decision record created (if required)
↓
lesson captured (if meaningful)
↓
future system improvement
Primary owners:
• HeadOffice
• relevant Brain
• Finance Brain / SIT Brain when applicable
Flow 4 – Dashboard Visibility Flow
Stored operational data
↓
query / aggregation logic
↓
WordPress dashboard panels or reference pages
↓
human visibility and review
↓
next action or escalation
Primary owners:
• WordPress UI layer
• reporting logic
• HeadOffice visibility surfaces
Flow 5 – Governance Violation Flow
task or system action
↓
rule breach detected
↓
task event logged as violation
↓
SIT visibility or enforcement logic
↓
HeadOffice escalation
↓
corrective action or suppression
Primary owners:
• executor logic
• SIT Brain
• HeadOffice
Data Ownership Principles
Every major data flow must have an owner.
Ownership categories include:
Origin Owner
The Brain, human, or system that created the data.
Processing Owner
The Brain or executor responsible for transforming the data.
Storage Owner
The platform responsible for preserving the record.
Review Owner
The Brain or authority responsible for interpreting, approving, or escalating the result.
No important data flow should exist without ownership clarity.
System Map Summary
At the highest level, MWMS data moves like this:
Input
↓
classification
↓
routing
↓
task creation
↓
processing
↓
event logging
↓
output generation
↓
review / decision / learning
↓
visibility across the system
Relationship to Other MWMS Pages
This page works alongside:
• MWMS – System Architecture
• MWMS – Brain Interaction Map
• MWMS – Request Routing Map
• MWMS – Supabase Task Schema Standard
• MWMS – Decision Record System
• MWMS – Lessons Learned System
System Architecture explains how MWMS is wired.
System Data Flow Map explains how data moves through that wiring.
Final Rule
If data moves through MWMS without visible origin, ownership, storage, and review path, that flow is structurally unsafe.
Data clarity is governance clarity.
Drift Protection
The system must prevent:
• data moving between layers without traceable lineage
• WordPress and Supabase responsibilities becoming blurred
• outputs existing without their task or request history
• decisions being made from data with unclear provenance
• dashboards showing signals that cannot be traced back to source records
• new systems being added without mapping their data movement
Data flow must remain explicit, reviewable, and structurally legible.
Architectural Intent
MWMS – System Data Flow Map exists to make data movement across MWMS understandable as a governed system.
Its role is to show how requests, tasks, events, outputs, decisions, and lessons move between humans, Brains, WordPress, Supabase, executors, and governance layers so the ecosystem can scale without hidden data chaos.
Change Log
Version: v1.0
Date: 2026-03-15
Author: MWMS HeadOffice
Change: Rebuilt the placeholder page into a structured MWMS reference architecture document. Defined the purpose of the data-flow map, major data layers, canonical data chains, ownership principles, system summary, related-page relationships, drift protection, and architectural intent.
END – MWMS – SYSTEM DATA FLOW MAP v1.0MWMS System Data Flow Map