Document Type: Standard
Status: Governance Standard
Authority: MWMS HeadOffice
Applies To: All MWMS development sessions involving WordPress, Supabase, APIs, executors, or production infrastructure
Version: v1.1
Last Reviewed: 2026-03-15
Parent: MWMS Canon
Purpose
The MWMS Development Safety Ladder defines the required safety levels for all technical changes within the MWMS ecosystem.
It ensures that structural changes to the system occur in a controlled, auditable, and reversible manner.
The ladder prevents the most common catastrophic failures in modern AI-assisted systems, including:
• accidental database damage
• plugin corruption
• executor failures
• production outages
• API misconfiguration
• loss of system state
This framework applies to development sessions involving:
• WordPress plugin development
• Supabase schema changes
• executor logic
• API integrations
• VPS infrastructure
• production configuration
Scope
This standard applies to:
• all AI-assisted MWMS development sessions
• structural technical changes across WordPress, Supabase, APIs, executors, and infrastructure
• safety sequencing before, during, and after technical changes
• verification and savepoint discipline for development work
• production-safe change behaviour across the ecosystem
This document governs the safety sequence that must be followed when making technical changes inside MWMS.
It does not govern:
• business strategy decisions
• canon authority by itself
• non-technical chat sessions
• marketing execution
• financial approvals
• detailed tool-specific implementation instructions by themselves
Those remain governed by HeadOffice, the MWMS Developer Command Set, session protocols, and the relevant technical or governance documents.
Definition / Rules
Core Principle
Every structural change must climb the Safety Ladder.
No change may jump directly to production.
Each level confirms system stability before moving upward.
The Safety Ladder
• Level 0 — Observation
• Level 1 — Planning
• Level 2 — Controlled Change
• Level 3 — Verification
• Level 4 — Savepoint
• Level 5 — Production Confirmation
Level 0 — Observation
At this stage, the system is only being inspected.
No structural change occurs.
Examples:
• reviewing a WordPress plugin file
• inspecting Supabase schema
• reading executor logs
• checking API configuration
• reviewing system reports
Rules:
• no file changes
• no schema changes
• no policy changes
• no executor modifications
Level 1 — Planning
At this stage, the change is defined but not executed.
Required actions:
• identify the target system
• identify the exact file or table
• identify the purpose of the change
• confirm whether the system is development, staging, or production
Examples:
• deciding to add a new column to a Supabase table
• preparing to update a WordPress plugin file
• planning a new API route
• defining executor behaviour
No system change occurs yet.
Level 2 — Controlled Change
At this stage the change is implemented.
Rules:
• only one change path may be executed
• no multi-path experimentation in production
• file outputs must follow the Full Output Rule
• SQL changes must use safe syntax
• destructive operations must be explicitly requested
Examples:
• replacing a plugin file
• adding a database column
• updating an executor handler
• modifying a WordPress admin page
Level 3 — Verification
Immediately after a change is applied the system must be verified.
Verification may include:
• confirming WordPress admin page loads
• confirming Supabase query success
• confirming executor response
• confirming API response
• confirming logs show no errors
No further change may occur until verification is complete.
Level 4 — Savepoint
Once the system has been verified, a Savepoint must be declared.
The savepoint records:
• Identifier
• Date
• Location
• System State
• What Changed
• Rollback Target
Savepoints provide a recovery anchor if future changes cause failure.
Level 5 — Production Confirmation
This level confirms that the system is operating correctly after the change.
Confirmation includes:
• no runtime errors
• no plugin crashes
• no API failures
• expected functionality working
If problems occur, the system may revert to the previous savepoint.
Enforcement
AI must not execute structural instructions unless the session has reached Level 2 — Controlled Change.
AI must not perform multiple structural changes before Level 3 — Verification is complete.
AI must declare a Savepoint before continuing further development.
If a change bypasses the ladder:
The session must stop and return to Level 1 — Planning.
Relationship to Other MWMS Governance Rules
The Safety Ladder operates alongside:
• MWMS Session Boot Protocol
• MWMS Developer Command Set
• Full Output Rule
• Savepoint Discipline Rule
• Build Guardrails
Together these systems ensure safe operation of the MWMS ecosystem.
Practical Example
Typical development sequence:
Level 0
Inspect Supabase schema.
Level 1
Plan new column for affiliate_offers table.
Level 2
Execute SQL snippet to add column.
Level 3
Verify table update in Supabase.
Level 4
Declare Savepoint.
Level 5
Confirm system functionality.
Outcome
The Development Safety Ladder ensures that MWMS development remains:
• stable
• reversible
• auditable
• safe for production systems
It is mandatory for all AI-assisted MWMS development.
Final Rule
No technical change is complete simply because it was applied.
A change is only complete when it has been verified, anchored by savepoint, and confirmed stable.
Drift Protection
The system must prevent:
• direct jumps from idea to production change
• multiple structural changes being bundled before verification
• savepoints being skipped after successful modification
• AI-assisted development running ahead of system confirmation
• production changes being treated casually because they appear small
• technical sessions continuing after an unverified change
The Safety Ladder must remain sequential, explicit, and enforced.
Architectural Intent
MWMS – Development Safety Ladder exists to give MWMS a controlled progression model for technical change.
Its role is to make AI-assisted development safer by forcing observation, planning, controlled execution, verification, savepoint declaration, and final confirmation so the system can evolve without reckless structural risk.
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 principle, six safety levels, enforcement rules, related governance links, practical example, and intended safety 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 – Development Safety Ladder defining the required safety levels for technical changes across the MWMS ecosystem.
END – MWMS – DEVELOPMENT SAFETY LADDER v1.1