Document Type: Standard
Status: Governance Standard
Authority: MWMS HeadOffice
Applies To: All MWMS task-based systems (WordPress plugins, Supabase schemas, executors, and AI employees)
Parent: MWMS Canon
Version: v1.1
Last Reviewed: 2026-03-15
Purpose
The MWMS Task Architecture Standard defines the canonical structure for how work moves through MWMS execution systems.
It ensures that:
• all work is traceable
• all outputs are attributable
• governance decisions remain auditable
• system memory is preserved
• execution can scale safely across Brains and AI Employees
This standard aligns MWMS governance with implementation across:
• Supabase task tables
• WordPress admin tooling
• executors and worker logic
• AI employee routing
• reporting and audit layers
Scope
This standard applies to:
• all MWMS task-based execution systems
• WordPress, Supabase, executor, and AI employee task handling
• canonical execution objects and their relationship to one another
• auditability and lineage requirements for work moving through MWMS
• bridge rules between governance intent and actual execution infrastructure
This document governs the meaning, structure, and required relationship of MWMS execution objects.
It does not govern:
• exact table names by themselves
• exact SQL implementation by itself
• UI layout by itself
• Brain authority by itself
• canon editing rules by themselves
• platform-specific deployment instructions by themselves
Those remain governed by the MWMS – Supabase Task Schema Standard, MWMS – Brain Request System, MWMS – System Architecture, and related technical and governance documents.
Definition / Rules
Core Principle
MWMS is a governed execution system.
Work is not chat.
Work is a structured chain:
Request → Task → Events → Output → Decision → Lesson
This chain forms the traceable memory and operational backbone of the MWMS organisation.
Canonical Object Model
MWMS execution must support these canonical object types:
• Brain Request
• Task
• Task Event
• Output Artifact
• Decision Record
• Lessons Learned Record
If a system cannot map work into these objects, it is not MWMS-compliant.
Canonical Flow
All work must follow the same flow:
Brain Request
↓
Task
↓
Task Events (timeline)
↓
Output Artifact(s)
↓
Decision Record (if required)
↓
Lessons Learned Record (if required)
- Brain Request (Entry Gate)
Definition
A Brain Request is the structured intake object that initiates work inside MWMS.
It exists to ensure that work is:
• correctly routed
• properly scoped
• traceable to an authority
Required Fields
• request_id
• requesting_authority (Human Exec / HeadOffice / Brain)
• target_brain
• operating_layer (Canon / Schema / Runtime / Execution)
• request_summary
• required_output
• priority (Low / Normal / High / Critical)
• status (New / Routed / In Progress / Completed / Rejected)
Rules
• all work begins as a Brain Request
• requests must target exactly one Brain
• if collaboration is required, follow-up requests must be created
• unscoped requests must be returned for clarification
- Task (Execution Unit)
Definition
A Task is an executable unit of work generated from a Brain Request.
A request may create:
• one task
or
• multiple tasks (only if explicitly segmented and logged)
Required Fields
• task_id
• request_id (link to Brain Request)
• assigned_brain
• assigned_employee (optional, but recommended)
• task_type (analysis / build / review / research / report / other)
• input_payload (structured JSON)
• output_mode (text / file / DB update / mixed)
• status (Queued / Picked Up / Running / Completed / Failed / Cancelled)
• risk_level (Low / Medium / High)
• created_at
• updated_at
Rules
• every task must be linked to a Brain Request
• tasks must not exist without an originating request
• task payloads must be structured, not freeform
• risk level must be declared when system interaction is involved
- Task Event (Audit Timeline)
Definition
A Task Event is a timeline entry that records what happened during task execution.
Task Events provide the system’s audit history.
Required Fields
• event_id
• task_id
• event_type (created / picked_up / progress / warning / error / completed / output_saved)
• event_summary
• event_payload (structured JSON)
• created_at
Rules
• events must be append-only
• no event may silently overwrite another event
• errors must be recorded as events
• outputs must be referenced by event entries
- Output Artifact (Deliverable)
Definition
An Output Artifact is any deliverable produced by a task.
Examples:
• full file replacement content
• SQL snippet
• structured report
• creative assets
• campaign plans
Required Fields
• artifact_id
• task_id
• artifact_type (file / report / script / schema / creative / other)
• artifact_summary
• artifact_content_location (inline / stored / external link)
• created_at
Rules
• every output must be attributable to a task
• any final output must be stored or referenced
• code outputs must follow the Full Output Rule where applicable
- Decision Record (Governance Memory)
Definition
A Decision Record captures why an important decision was made.
Required Fields
• decision_id
• related_request_id (optional)
• related_task_id (optional)
• authority (Human Exec / HeadOffice / Brain)
• affected_brains
• decision_summary
• reasoning
• evidence_used
• expected_outcome
• date_recorded
Rules
• decisions must be created for structural, strategic, or financial commitments
• routine work does not require a Decision Record
• Decision Records must be factual and auditable
- Lessons Learned Record (Kaizen Memory)
Definition
A Lessons Learned Record captures what was learned from an outcome.
Required Fields
• lesson_id
• related_decision_id (optional)
• related_task_id (optional)
• originating_brain
• event_or_experiment
• result
• insight
• recommended_improvement
• date_recorded
Rules
• lessons must be objective, not emotional
• lessons must propose an improvement when possible
• repeated lessons may justify governance updates
Enforcement Rules
The following enforcement rules apply across all MWMS task systems.
• No Request → No Task
• No Task → No Events
• No Events → No Auditable Execution
• No Output → No Completion Claim
• Decisions must be recorded when stakes are high
• Lessons must be recorded when insights are meaningful
Violations invalidate the execution output for MWMS purposes.
Integration Notes
This standard is designed to map directly onto:
• Supabase task / event tables
• WordPress admin pages
• AI employee router logic
• HeadOffice reporting and audit views
This standard does not mandate exact table names.
It mandates object meaning and required fields.
Outcome
The MWMS Task Architecture Standard ensures MWMS execution remains:
• governed
• traceable
• auditable
• scalable
• resistant to drift
It is the canonical bridge between MWMS governance documents and the actual execution infrastructure.
Final Rule
If work cannot be traced from request through task, events, output, decision, and lesson where applicable, it is not complete from an MWMS governance perspective.
Execution without lineage is non-compliant execution.
Drift Protection
The system must prevent:
• task systems inventing local object meanings that break MWMS lineage
• work being completed without a request origin
• outputs existing without task attribution
• high-stakes decisions being detached from execution history
• lessons being recorded without link to actual events or work
• implementation convenience eroding the canonical request-to-lesson chain
The task architecture must remain consistent across all MWMS execution environments.
Architectural Intent
MWMS – Task Architecture Standard exists to define the canonical object model for governed work inside MWMS.
Its role is to ensure that requests, tasks, events, outputs, decisions, and lessons form one coherent execution chain so governance documents can map cleanly into real infrastructure without losing traceability, auditability, or organisational memory.
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 execution principle, canonical object model, canonical flow, all six execution objects, enforcement rules, integration 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 – Task Architecture Standard defining the canonical structure for how work moves through MWMS execution systems.
END – MWMS – TASK ARCHITECTURE STANDARD v1.1