Document Type: Canon
Status: Canon
Authority: MWMS HeadOffice
Applies To: Supabase task system, WordPress MWMS plugins, executors, and AI employee router
Parent: MWMS Canon
Version: v1.1
Last Reviewed: 2026-03-15
Purpose
This document defines the standard Supabase schema required to run MWMS task execution reliably.
It ensures:
• consistent task creation and routing
• consistent task event logging
• consistent output storage and linking
• stable reporting for HeadOffice
• prevention of schema drift across environments
This schema standard is the canonical database foundation for:
• Brain Requests
• Tasks
• Task Events
• Output Artifacts
• Decision Records
• Lessons Learned Records
Scope
This canon applies to:
• the MWMS Supabase task system
• WordPress MWMS plugin integrations that write to or read from the task layer
• executors and routers operating on task records
• canonical table naming and relationship rules for task-based execution
• governance alignment for task traceability and auditability
This document governs the canonical schema shape required for MWMS task-based operation.
It does not govern:
• exact SQL implementation scripts by themselves
• environment-specific migration strategy by itself
• exact RLS policy code by itself
• UI layout for WordPress admin task screens
• executor business logic by itself
• non-task databases unrelated to the MWMS task chain
Those remain governed by build-layer specifications, implementation files, and related technical documents.
Definition / Rules
Core Principle
MWMS must maintain an auditable chain:
Brain Request → Task → Task Events → Output Artifact → Decision Record → Lessons Learned
If the database schema cannot represent this chain, it is not MWMS-compliant.
Naming and Conventions
Tables must use snake_case.
All primary keys must be UUID.
All timestamps must use timestamptz.
All event logs must be append-only.
JSON fields must use jsonb.
Required Tables (Canonical)
• mwms_brain_requests
• mwms_tasks
• mwms_task_events
• mwms_task_artifacts
• mwms_decision_records
• mwms_lessons_learned
These names are canonical for MWMS governance, even if a legacy environment currently uses different names.
Legacy tables may remain, but any new implementation should adopt these canonical names.
Table: mwms_brain_requests
Purpose
The structured intake object that initiates work.
Required Columns
• id (uuid, pk)
• requesting_authority (text)
• requesting_brain (text, nullable)
• target_brain (text)
• operating_layer (text)
• request_summary (text)
• required_output (text)
• priority (text)
• status (text)
• meta_json (jsonb, default {})
• created_at (timestamptz, default now())
• updated_at (timestamptz, default now())
Status Values (recommended)
• new
• routed
• in_progress
• completed
• rejected
• escalated
Table: mwms_tasks
Purpose
Executable unit of work produced from a Brain Request.
Required Columns
• id (uuid, pk)
• request_id (uuid, fk → mwms_brain_requests.id)
• task_type (text)
• assigned_brain (text)
• assigned_employee (text, nullable)
• input_payload (jsonb, default {})
• output_mode (text)
• risk_level (text)
• status (text)
• attempts (int, default 0)
• last_error (text, nullable)
• created_at (timestamptz, default now())
• updated_at (timestamptz, default now())
Status Values (recommended)
• queued
• picked_up
• running
• completed
• failed
• cancelled
• escalated
Risk Values (recommended)
• low
• medium
• high
Table: mwms_task_events
Purpose
Append-only audit timeline for every task.
Required Columns
• id (uuid, pk)
• task_id (uuid, fk → mwms_tasks.id)
• event_type (text)
• event_summary (text)
• event_payload (jsonb, default {})
• created_at (timestamptz, default now())
Event Types (recommended)
• created
• picked_up
• progress
• warning
• error
• completed
• output_saved
• rule_violation
• escalated
Append-only rule
No updates.
No deletes.
Events are immutable.
Table: mwms_task_artifacts
Purpose
Stores and links task outputs.
Required Columns
• id (uuid, pk)
• task_id (uuid, fk → mwms_tasks.id)
• artifact_type (text)
• artifact_summary (text)
• content_location (text)
• content_json (jsonb, default {})
• created_at (timestamptz, default now())
Notes
Large outputs may be stored externally. This table stores links plus metadata.
Table: mwms_decision_records
Purpose
Stores decisions made at governance or capital stakes.
Required Columns
• id (uuid, pk)
• authority (text)
• related_request_id (uuid, nullable)
• related_task_id (uuid, nullable)
• affected_brains (jsonb, default [])
• decision_summary (text)
• reasoning (text)
• evidence_used (text, nullable)
• expected_outcome (text, nullable)
• created_at (timestamptz, default now())
Table: mwms_lessons_learned
Purpose
Stores learning outcomes and improvements.
Required Columns
• id (uuid, pk)
• originating_brain (text)
• related_decision_id (uuid, nullable)
• related_task_id (uuid, nullable)
• event_or_experiment (text)
• result (text)
• insight (text)
• recommended_improvement (text)
• created_at (timestamptz, default now())
Required Relationships
• mwms_tasks.request_id → mwms_brain_requests.id
• mwms_task_events.task_id → mwms_tasks.id
• mwms_task_artifacts.task_id → mwms_tasks.id
• mwms_decision_records.related_request_id → mwms_brain_requests.id (optional)
• mwms_decision_records.related_task_id → mwms_tasks.id (optional)
• mwms_lessons_learned.related_decision_id → mwms_decision_records.id (optional)
• mwms_lessons_learned.related_task_id → mwms_tasks.id (optional)
RLS and Security Notes (Canon Level)
RLS policy design must preserve:
• append-only events
• no cross-tenant leakage (future AIBS)
• restricted write access for high-stakes tables (decisions)
Exact RLS policies are implementation-specific and belong in build layers, not in canon.
Outcome
This schema standard prevents task system drift and ensures MWMS execution remains:
• traceable
• auditable
• scalable
• enforceable under governance
It is the canonical database foundation required for MWMS task-based operation.
Final Rule
If the schema breaks the traceable chain of request, task, event, artifact, decision, and lesson, it breaks MWMS task integrity.
Canonical traceability outranks implementation convenience.
Drift Protection
The system must prevent:
• new environments inventing alternative table names without governance approval
• task execution occurring without append-only event history
• artifacts, decisions, or lessons being disconnected from their task lineage
• schema variation across environments breaking routing or reporting
• high-stakes records being writable without controlled access design
• legacy tables silently replacing canonical structure in new builds
The task schema must remain stable, auditable, and lineage-safe.
Architectural Intent
MWMS – Supabase Task Schema Standard exists to define the canonical database foundation for MWMS task-based execution.
Its role is to ensure that Brain Requests, tasks, events, artifacts, decisions, and lessons all connect through a governed traceability chain so the ecosystem can scale with auditability instead of schema drift and broken lineage.
Change Log
Version: v1.1
Date: 2026-03-15
Author: MWMS HeadOffice
Change: Rebuilt page to align with the locked MWMS document standard for this cleanup pass. Preserved the original purpose, core traceability principle, naming conventions, canonical table list, required columns, status values, event types, relationship rules, RLS notes, and intended governance outcome. Added Document Type, Parent, Scope, Definition / Rules structure, Final Rule, Drift Protection, and Architectural Intent sections.
Version: v1.0
Date: 2026-03-13
Author: MWMS HeadOffice
Change: Initial creation of MWMS – Supabase Task Schema Standard defining the canonical database foundation for MWMS task-based execution.
END – MWMS – SUPABASE TASK SCHEMA STANDARD v1.1