Parent Page: Project Manager Brain
Version: 1.0
Date: 2026-06-23
Author: HeadOffice
Status: Active
Page Type: Brain Workflow Map
Authority Level: MWMS Workflow Map
Purpose
Project Manager Brain Workflow Map defines how approved MWMS work moves through Project Manager Brain from initial direction to completed, tested, accepted and reported execution.
This Workflow Map shows how projects, workstreams, tasks, priorities, dependencies, blockers, changes, meetings, testing, versions, save points, reports and escalations connect.
It also defines how Project Manager Brain coordinates with:
- HeadOffice Brain
- Operations Brain
- Kaizen
- SIT Brain
- specialist Brains
- MCR
- operational Brain websites
- WordPress plugins
- Supabase
- Martyn
- M
- future authorised users
This page does not replace Project Manager Brain Canon, Architecture or Operating Model.
It provides the connected execution flow that operational systems must follow.
Core Workflow Position
Project Manager Brain sits between approved direction and verified completion.
The highest-level workflow is:
Approved Direction
To
Project Intake
To
Project Approval
To
Project Setup
To
Workstream And Task Structure
To
Priority And Readiness Review
To
Execution
To
Testing
To
Acceptance
To
Save Point
To
Reporting
To
Next Valid Action
To
Project Completion Or Continued Execution
Primary System Workflow
The primary Project Manager Brain workflow is:
HeadOffice Direction
To
Project Manager Brain Intake
To
Project Definition
To
Authority Check
To
Project Approval
To
Project Structure
To
Priority Review
To
Dependency Review
To
Owner Confirmation
To
Execution
To
Progress Update
To
Testing
To
Acceptance
To
Version Review
To
Save Point
To
Reporting
To
Next Valid Work
Project Entry Workflow
A project may enter Project Manager Brain from one of the following sources:
- HeadOffice direction
- specialist Brain requirement
- Kaizen finding
- SIT finding
- approved meeting decision
- failed test
- version mismatch
- technical requirement
- system migration
- operational bottleneck
- AIBS product requirement
- future client implementation requirement
- regulatory or compliance need
- approved opportunity
- critical dependency
The project entry workflow is:
Need Identified
To
Source Confirmed
To
Project Proposal Created
To
Objective Defined
To
Reason Defined
To
Proposed Owner Identified
To
Affected Brain Or System Identified
To
Known Dependencies Recorded
To
Known Risks Recorded
To
Approval Authority Identified
To
Project Intake Review
Project Intake Decision Workflow
The project intake review must determine whether the proposal is:
- valid
- authorised
- sufficiently defined
- strategically relevant
- non-duplicative
- ready for planning
- suitable for deferral
- unsuitable for execution
The workflow is:
Project Proposal Reviewed
To
Duplicate Check
To
Authority Check
To
Strategic Relevance Check
To
Scope Clarity Check
To
Owner Readiness Check
To
Dependency Check
To
Risk Check
To
Decision
Possible outcomes are:
- Approved
- Returned For Clarification
- Deferred
- Rejected
- Cancelled
- Escalated To HeadOffice
Project Approval Workflow
When a project is approved, the workflow is:
Project Approved
To
Project Owner Confirmed
To
Contributors Confirmed
To
Project Priority Confirmed
To
Expected Outcome Confirmed
To
Acceptance Criteria Defined
To
Initial Phase Set
To
Initial Save Point Created
To
Workstreams Created
To
Initial Tasks Created
To
Dependencies Linked
To
First Valid Action Identified
To
Project Activated
A project must not become Active if:
- no owner is confirmed
- no valid first action exists
- critical authority is missing
- project scope is undefined
- critical dependencies are unknown
- the project duplicates active work
- acceptance criteria cannot be stated
Project Setup Workflow
The project setup workflow is:
Create Project Record
To
Link Relevant MCR Pages
To
Link Relevant Operational Pages
To
Record Owning Brain
To
Record Project Owner
To
Record Contributors
To
Record Priority
To
Record Current Phase
To
Record Expected Outcome
To
Record Acceptance Criteria
To
Record Risks
To
Record Dependencies
To
Record Blockers
To
Create Workstreams
To
Create Tasks
To
Create Initial Save Point
To
Confirm Next Valid Action
To
Activate Project
Workstream Creation Workflow
A workstream should be created when the project contains a meaningful execution area, phase or functional group.
The workflow is:
Project Reviewed
To
Distinct Execution Area Identified
To
Workstream Objective Defined
To
Owner Confirmed
To
Sequence Position Defined
To
Dependencies Identified
To
Acceptance Criteria Defined
To
Tasks Added
To
Workstream Readiness Checked
To
Workstream Activated
A workstream should not be created when it adds administrative complexity without improving execution visibility.
Task Creation Workflow
Tasks may be created from:
- project planning
- workstream planning
- meeting actions
- approved changes
- failed tests
- SIT findings
- Kaizen findings
- dependency resolution
- project review
- HeadOffice direction
- specialist Brain requests
- version alignment review
The task creation workflow is:
Task Need Identified
To
Task Action Defined
To
Affected Object Defined
To
Required Outcome Defined
To
Parent Project Linked
To
Parent Workstream Linked Where Applicable
To
Owner Confirmed
To
Dependencies Identified
To
Acceptance Criteria Defined
To
Test Requirement Defined
To
Evidence Requirement Defined
To
Authorisation Checked
To
Readiness Assessed
To
Task Created
Task Quality Gate
Before a task can become Ready, Project Manager Brain must confirm:
- title is specific
- description is clear
- action is executable
- outcome is testable
- owner is known
- project is linked
- workstream is linked where required
- dependencies are recorded
- blocker state is known
- evidence requirement is known
- testing requirement is known
- task is authorised
If any critical requirement is missing, the task remains:
- Not Defined
- Missing Owner
- Missing Input
- Waiting For Decision
- Waiting For Dependency
- Blocked
- Not Authorised
Task Readiness Workflow
The task readiness workflow is:
Task Created
To
Authority Check
To
Owner Check
To
Input Check
To
Dependency Check
To
Blocker Check
To
Acceptance Criteria Check
To
Test Requirement Check
To
Readiness Decision
Possible outcomes are:
- Ready
- Waiting For Dependency
- Waiting For Decision
- Missing Owner
- Missing Input
- Blocked
- Not Authorised
- Cancelled
Priority Workflow
Priority is determined after readiness, not before it.
The workflow is:
Ready Work Identified
To
HeadOffice Priority Reviewed
To
Current Main Goal Reviewed
To
Project Priority Reviewed
To
Dependency Impact Reviewed
To
Work Unlocked Reviewed
To
Risk Reduction Reviewed
To
Testing Urgency Reviewed
To
Delay Consequence Reviewed
To
Owner Availability Reviewed
To
Effort Reviewed
To
Version Impact Reviewed
To
SIT Severity Reviewed
To
Kaizen Recurrence Reviewed
To
Recommended Priority Produced
To
Human Review
To
Approved Priority Recorded
Priority Output Workflow
The approved priority output may place work into:
- Must Do Today
- Should Do Today
- Ready If Capacity Allows
- Testing Required
- HeadOffice Decision Required
- Waiting
- Blocked
- Ready Next
- Scheduled Future Work
- High Value But Not Ready
- Retest Required
- Version Alignment Required
- Deferred
- Parking
- Do Not Touch
Every material priority should have an explanation.
Daily Planning Workflow
The daily planning workflow is:
Current Save Points Reviewed
To
Unfinished Critical Work Reviewed
To
Owner Availability Reviewed
To
Blocked Work Reviewed
To
Testing Required Reviewed
To
Failed Tests Reviewed
To
HeadOffice Decisions Reviewed
To
Version Warnings Reviewed
To
Ready Tasks Reviewed
To
Priority Order Confirmed
To
Realistic Capacity Applied
To
Daily Work View Produced
Daily Output
The daily work view should contain:
- current main project
- current main workstream
- Martyn’s Must Do Today tasks
- Martyn’s Should Do Today tasks
- M’s Must Do Today tasks
- M’s Should Do Today tasks
- testing required
- blockers requiring action
- HeadOffice decisions required
- version alignment warnings
- work that must not be touched
- next valid action
- work likely to become ready next
Daily Completion Review Workflow
At the end of the working period:
Daily Tasks Reviewed
To
Completed Work Verified
To
Incomplete Work Updated
To
Blockers Added Or Updated
To
Testing State Updated
To
Evidence Added
To
Priorities Recalculated
To
Project Save Point Updated Where Required
To
Next Valid Actions Confirmed
To
Daily Report Produced
Execution Workflow
The task execution workflow is:
Task Ready
To
Owner Starts Task
To
Task Status Set To In Progress
To
Work Performed
To
Progress Updates Recorded
To
Blocker Check
To
Implementation Completed
To
Evidence Added
To
Task Status Set To Implemented
To
Testing Requirement Applied
A task must not move directly from In Progress to Closed when testing or acceptance is required.
Task Blocker Workflow
The blocker workflow is:
Blocker Identified
To
Blocked Item Linked
To
Blocker Description Recorded
To
Blocker Owner Confirmed
To
Impact Assessed
To
Affected Projects Identified
To
Resolution Action Defined
To
Escalation Need Assessed
To
Task Or Project Status Updated
To
Resolution Attempted
To
Resolution Evidence Recorded
To
Blocker Resolved Or Escalated
When a blocker is resolved:
Resolution Confirmed
To
Evidence Reviewed
To
Dependency State Updated
To
Blocked Task Reassessed
To
Task Returned To Ready Or Active
To
Priority Recalculated
Dependency Workflow
The dependency workflow is:
Dependency Identified
To
Dependent Item Recorded
To
Required Item Recorded
To
Dependency Owner Recorded
To
Dependency Status Recorded
To
Expected Resolution Recorded
To
Delay Impact Recorded
To
Work Unlocked Recorded
To
Dependency Monitored
To
Dependency Satisfied Or Failed
If satisfied:
Dependency Satisfied
To
Dependent Work Reassessed
To
Task Readiness Updated
To
Priority Updated
To
Next Valid Action Updated
If failed:
Dependency Failed
To
Impact Reassessed
To
Alternative Path Reviewed
To
Blocker Created Where Required
To
Escalation Considered
To
Project Save Point Updated
Change Workflow
A change may originate from:
- HeadOffice
- approved meeting decision
- specialist Brain finding
- test result
- Kaizen
- SIT Brain
- operational discovery
- technical limitation
- version change
- project review
The change workflow is:
Change Proposed
To
Change Source Confirmed
To
Authority Checked
To
Change Approved Or Rejected
To
Impact Review Started
To
Projects Affected Identified
To
Workstreams Affected Identified
To
Tasks Affected Identified
To
Priorities Affected Identified
To
Dependencies Affected Identified
To
Pages Affected Identified
To
Plugins Affected Identified
To
Schemas Affected Identified
To
Versions Affected Identified
To
Tests Invalidated Identified
To
Retesting Requirements Identified
To
New Work Created
To
Obsolete Work Cancelled Or Archived
To
Save Point Updated
To
Affected Owners Notified
To
Change Closed
Decision Workflow
The decision workflow is:
Decision Need Identified
To
Decision Authority Identified
To
Evidence Gathered
To
Options Considered
To
Decision Made
To
Decision Recorded
To
Reason Recorded
To
Affected Projects Identified
To
Execution Impact Recorded
To
Testing Impact Recorded
To
Version Impact Recorded
To
Follow-Up Actions Created
To
Project Records Updated
To
Decision Closed Or Scheduled For Review
Suggestions, questions and unapproved proposals must not enter this workflow as approved decisions.
Meeting Workflow
The meeting workflow is:
Meeting Scheduled Or Held
To
Meeting Record Created
To
Notes Added
To
Related Projects Linked
To
Related Brains Linked
To
Proposed Actions Extracted
To
Proposed Decisions Extracted
To
Proposed Changes Extracted
To
Proposed Owners Extracted
To
Proposed Due Dates Extracted
To
Risks And Blockers Extracted
To
Human Review
To
Items Approved, Rejected, Merged Or Deferred
To
Approved Items Applied
To
Affected Project Records Updated
To
Change Impact Reviewed
To
Testing And Version Impact Reviewed
To
Meeting Closed
Meeting Action Review Workflow
Each extracted item must be classified as one of:
- Approved Decision
- Approved Action
- Approved Change
- Approved Blocker
- Approved Risk
- Approved Follow-Up
- Question
- Suggestion
- Duplicate
- Already Recorded
- Rejected
- Deferred
- No Action Required
Only approved items may update live project records.
Meeting Action Application Workflow
Approved meeting item
To
Determine Record Type
To
Create Or Update Decision
Or
Create Or Update Task
Or
Create Or Update Change
Or
Create Or Update Blocker
Or
Create Or Update Dependency
Or
Update Owner
Or
Update Due Date
Or
Update Project Status
To
Impact Review
To
Save Point Review
To
Notification
Testing Workflow
The testing workflow is:
Task Implemented
To
Test Requirement Confirmed
To
Test Record Created
To
Expected Result Defined
To
Test Method Confirmed
To
Test Owner Confirmed
To
Test Executed
To
Actual Result Recorded
To
Evidence Added
To
Pass Or Fail Decision
If passed:
Test Passed
To
Task Status Updated
To
Acceptance Review Started
If failed:
Test Failed
To
Failure Reason Recorded
To
Corrective Action Defined
To
Corrective Task Created Or Reopened
To
Task Status Set To Changes Required
To
Retest Requirement Recorded
To
Project Save Point Updated
Retest Workflow
Corrective Work Completed
To
Evidence Added
To
Task Set To Retest Required
To
New Test Or Retest Record Created
To
Retest Executed
To
Result Recorded
To
Pass Or Fail Decision
Historical failed tests must remain visible.
Acceptance Workflow
The acceptance workflow is:
Test Passed Or Testing Not Required
To
Acceptance Criteria Reviewed
To
Evidence Reviewed
To
Dependencies Confirmed
To
Documentation Requirements Reviewed
To
Version Recording Reviewed
To
MCR Update Requirement Reviewed
To
SIT Findings Reviewed
To
Critical Blockers Reviewed
To
Acceptance Decision
Possible outcomes are:
- Accepted
- Accepted With Conditions
- Changes Required
- Retest Required
- Rejected
- Escalation Required
If accepted:
Acceptance Recorded
To
Task Set To Accepted
To
Task Closed
To
Workstream Progress Updated
To
Project Progress Updated
To
Save Point Updated
Completion Workflow
Task completion is:
Implementation
Plus
Required Testing
Plus
Required Evidence
Plus
Acceptance
Plus
Required Documentation
Plus
Required Version Recording
A project completion workflow is:
All Critical Workstreams Reviewed
To
All Critical Tasks Reviewed
To
All Required Tests Passed
To
All Acceptance Criteria Reviewed
To
All Critical Blockers Resolved
To
All Required Evidence Confirmed
To
All Required MCR Updates Confirmed
To
All Required Version Records Confirmed
To
Final Save Point Created
To
Project Acceptance Decision
To
Project Completed
To
Project Closed
To
Project Archived When Appropriate
Save-Point Workflow
A save point should be created or updated when:
- a major build stage completes
- plugin version changes
- schema changes
- major test completes
- project pauses
- project restarts
- workstream completes
- major change is approved
- major decision changes direction
- project is handed over
- project closes
- a new work session needs a trusted continuation point
The save-point workflow is:
Save Point Triggered
To
Active Version Confirmed
To
Completed Work Confirmed
To
Active Work Confirmed
To
Blocked Work Confirmed
To
Testing State Confirmed
To
Deferred Work Confirmed
To
Risks Confirmed
To
Dependencies Confirmed
To
Recent Decisions Confirmed
To
Recent Changes Confirmed
To
Next Valid Action Confirmed
To
Work Not To Touch Confirmed
To
Evidence Linked
To
Save Point Approved
To
Current Save Point Replaced
Only one save point should be treated as the current trusted save point for an active project.
Version Alignment Workflow
The version alignment workflow is:
Version Change Detected
To
Changed Component Identified
To
New Version Recorded
To
Dependent Systems Identified
To
Compatibility Reviewed
To
Documentation Reviewed
To
Tests Reviewed
To
Retesting Requirement Identified
To
Affected Brains Identified
To
Update Requirement Identified
To
Alignment State Assigned
To
Tasks Created Where Required
To
Escalation Raised Where Required
Version alignment states are:
- Aligned
- Review Required
- Update Required
- Retest Required
- At Risk
- Misaligned
- Blocked By Mismatch
- Unknown
Brain Coordination Workflow
The cross-Brain coordination workflow is:
Project Manager Brain Identifies Need
To
Owning Brain Identified
To
Request Structured
To
Authority Confirmed
To
Request Sent
To
Specialist Brain Performs Work
To
Output Returned
To
Output Reviewed
To
Project Record Updated
To
Testing Applied
To
Acceptance Applied
To
Save Point Updated
Project Manager Brain must not perform specialist work merely because a request remains open.
HeadOffice Coordination Workflow
The HeadOffice workflow is:
Strategic Direction Issued
To
Project Manager Brain Receives Direction
To
Projects And Priorities Updated
To
Execution Begins
To
Project Health Monitored
To
Strategic Conflict Or Major Risk Detected
To
Escalation Prepared
To
HeadOffice Decision Requested
To
Decision Returned
To
Project Records Updated
To
Execution Continues
Project Manager Brain should escalate only the level of detail required for HeadOffice decision-making.
Operations Brain Coordination Workflow
The Operations workflow is:
Execution Issue Identified
To
Sequencing Or Handoff Need Identified
To
Operations Brain Input Requested
To
Operations Guidance Returned
To
Project Manager Brain Applies Approved Guidance
To
Workstreams, Tasks Or Dependencies Updated
To
Execution Continues
Kaizen Coordination Workflow
The Kaizen workflow is:
Repeated Friction Or Waste Identified
To
Kaizen Finding Created
To
Frequency And Impact Assessed
To
Project Manager Brain Reviews Finding
To
Priority And Readiness Assessed
To
Decision
Possible outcomes are:
- Create Improvement Task
- Create Improvement Workstream
- Create Improvement Project
- Add To Near Future
- Defer
- Reject
- Escalate
Approved improvement work then enters the ordinary project and task workflow.
SIT Coordination Workflow
The SIT workflow is:
SIT Review Performed
To
Finding Created
To
Severity Assigned
To
Affected Work Identified
To
Project Manager Brain Records Finding
To
Acceptance Impact Assessed
To
Corrective Action Created
To
Owner Assigned
To
Retest Requirement Defined
To
Escalation Assessed
To
Corrective Work Completed
To
SIT Or Relevant Reviewer Rechecks
To
Finding Resolved Or Escalated
Critical SIT findings must remain visible until formally resolved or accepted by the proper authority.
Specialist Brain Handoff Workflow
The specialist Brain handoff workflow is:
Specialist Work Required
To
Owning Brain Confirmed
To
Input Package Prepared
To
Request Sent
To
Work Accepted By Specialist Brain
To
Specialist Work Completed
To
Evidence Returned
To
Project Manager Brain Reviews Handoff Completeness
To
Testing Or Acceptance Applied
To
Dependent Work Unlocked
To
Project Updated
A handoff is incomplete if required context, evidence or output is missing.
Reporting Workflow
The reporting workflow is:
Current Records Reviewed
To
Current Save Points Reviewed
To
Movement Since Prior Report Identified
To
Outcomes Identified
To
Blockers Identified
To
Failed Tests Identified
To
Decisions Required Identified
To
Version Risks Identified
To
Next Actions Identified
To
Report Produced
To
Report Distributed To Authorised Users
Reports must focus on action and decision value.
Daily Reporting Workflow
Daily Data Reviewed
To
Today’s Work Confirmed
To
Blocked Work Confirmed
To
Testing Work Confirmed
To
Decisions Required Confirmed
To
Next Valid Work Confirmed
To
Daily Report Produced
Weekly Reporting Workflow
Weekly Movement Reviewed
To
Project Outcomes Confirmed
To
Stalled Work Confirmed
To
Tests Reviewed
To
Changes Reviewed
To
Versions Reviewed
To
Kaizen And SIT Findings Reviewed
To
Next Week Readiness Confirmed
To
Weekly Report Produced
Escalation Workflow
The escalation workflow is:
Issue Identified
To
Impact Assessed
To
Urgency Assessed
To
Current Authority Checked
To
Resolution Attempted
To
Escalation Need Confirmed
To
Options Prepared
To
Recommendation Prepared
To
Decision Required Defined
To
Escalation Sent
To
Decision Received
To
Decision Recorded
To
Affected Work Updated
To
Follow-Up Tasks Created
To
Escalation Closed
An escalation must not be a vague statement that a problem exists.
It must provide enough information for a decision.
Project Pause Workflow
A project may be paused when:
- strategic priority changes
- owner is unavailable
- dependency is unresolved
- resources are unavailable
- external access is missing
- critical test fails
- version mismatch blocks work
- HeadOffice pauses execution
- project viability is under review
The pause workflow is:
Pause Need Identified
To
Authority Confirmed
To
Reason Recorded
To
Active Tasks Reviewed
To
Tasks Paused Or Reassigned
To
Dependencies Updated
To
Risks Updated
To
Save Point Created
To
Restart Conditions Defined
To
Project Status Set To Paused
Project Restart Workflow
Restart Conditions Met
To
Project Save Point Reviewed
To
Objective Reconfirmed
To
Priority Reconfirmed
To
Owner Reconfirmed
To
Dependencies Rechecked
To
Versions Rechecked
To
Tasks Revalidated
To
Next Valid Action Confirmed
To
Project Reactivated
Project Cancellation Workflow
Cancellation Proposed
To
Authority Checked
To
Reason Recorded
To
Impact Reviewed
To
Active Tasks Cancelled Or Reassigned
To
Dependencies Updated
To
Affected Projects Updated
To
Evidence Preserved
To
Final Save Point Created
To
Project Set To Cancelled
To
Project Archived When Appropriate
Cancellation must not erase project history.
Archive Workflow
Record No Longer Active
To
Closure State Confirmed
To
Open Dependencies Reviewed
To
Open Tests Reviewed
To
Evidence Confirmed
To
Archive Reason Recorded
To
Record Locked From Ordinary Editing
To
Record Archived
Archived records must remain:
- searchable
- readable
- linked
- auditable
- historically available
First Validation Workflow
The first real validation project is:
Content Brain Operational Build
The workflow is:
Create Content Brain Operational Build Project
To
Record Project Objective
To
Record Current Save Point
To
Record Current Plugin Version
To
Create Workstreams
To
Record Completed Work
To
Record Active Work
To
Record Archived Work
To
Record Testing State
To
Record Dependencies
To
Record Blockers
To
Record Deferred Work
To
Record Decisions And Changes
To
Record Next Valid Action
To
Generate Daily Work View
To
Generate Project Status Report
To
Confirm Version Alignment
To
Compare Project Manager Brain Records Against Operational Reality
To
Correct Any Mismatch
To
Declare Initial Validation Passed Or Failed
Project Manager Brain must not be considered operationally validated if its records do not match the real Content Brain state.
Future AIBS Workflow Position
In future, the same core workflow may support:
- AIBS product development
- client implementation projects
- automation delivery
- project testing
- client approval
- project handover
- maintenance
- recurring optimisation
Future AIBS workflows must preserve:
- project authority
- client permissions
- evidence
- testing
- acceptance
- version control
- auditability
- internal and client visibility boundaries
Initial Workflow Limits
During the first implementation:
- project approval remains human-controlled
- priority approval remains human-controlled
- meeting action approval remains human-controlled
- critical change approval remains human-controlled
- acceptance remains human-controlled
- project closure remains human-controlled
- Canon changes remain outside Project Manager Brain operational authority
- permanent deletion remains restricted
- AI recommendations remain advisory
- no client workflow is active
- no automatic financial commitment is allowed
- no unsupported deadline is created
- no critical project is created automatically from an unreviewed signal
Workflow Success Criteria
The Workflow Map is functioning when:
- approved direction becomes structured work
- projects have clear owners
- workstreams have clear purposes
- tasks are specific
- priorities are explainable
- dependencies are visible
- blockers are visible
- meeting actions are reviewed
- changes propagate correctly
- tests remain linked
- failed tests produce corrective work
- acceptance requires evidence
- version changes trigger review
- save points remain current
- HeadOffice receives useful escalations
- specialist Brain authority remains intact
- Kaizen improvements become controlled work
- SIT findings remain visible
- the next valid action can be identified
Workflow Failure Conditions
The Workflow Map is failing when:
- projects enter execution without approval
- tasks enter priority without readiness
- blocked tasks appear ready
- dependencies remain hidden
- changes do not update affected work
- meeting notes alter projects without review
- failed tests are removed or ignored
- acceptance occurs without evidence
- version changes do not trigger impact review
- save points become stale
- HeadOffice must reconstruct the project state manually
- specialist Brains are bypassed
- AI actions exceed authority
- project history is lost
- reports describe activity without required action
- future work overwhelms the current main goal
MWMS System Change Log
Version: 1.0
Date: 2026-06-23
Author: HeadOffice
Change
Created the initial Project Manager Brain Workflow Map.
Defined the complete workflow from approved direction through project intake, approval, setup, task execution, dependency control, blocker handling, change management, meeting action review, testing, acceptance, save points, version alignment, reporting, escalation, pause, restart, cancellation and archive.
Defined coordination workflows with HeadOffice Brain, Operations Brain, Kaizen, SIT Brain and specialist Brains.
Defined Content Brain Operational Build as the first real workflow validation project.
Change Impact Declaration
This change establishes the approved execution flow for Project Manager Brain.
The change does not authorise autonomous project approval, autonomous priority approval, autonomous meeting action approval, autonomous acceptance or autonomous project closure.
The change requires operational implementations to preserve human review, specialist Brain authority, MCR source truth, testing discipline, evidence-backed completion and version alignment.
Pages Created
Project Manager Brain Workflow Map
Pages Updated
None
Pages Deprecated
None
Standalone Pages Not Created
Project Manager Brain Page Registry
Project Manager Brain Project Intake Workflow
Project Manager Brain Daily Planning Workflow
Project Manager Brain Meeting Action Workflow
Project Manager Brain Testing And Acceptance Workflow
Project Manager Brain Version Alignment Workflow
These separate workflow pages are not created at this stage.
The current Workflow Map is intended to hold the complete initial workflow without unnecessary page expansion.
Registries Requiring Update
MWMS Brain Registry
MWMS Page Parent Map
MWMS Document Registry
MWMS Brain Interaction Map
Project Manager Brain Page Registry once created
Canon Version Update Required
No
Project Manager Brain Canon remains at v1.0.
Change Log Entry Required
Yes
This change must be recorded in MWMS System Change Log 2026 06 16 To 2026 06 30.
Strategic Absorption Result
The Project Manager Brain operating model has been converted into a connected execution workflow.
MWMS now has a defined path for moving approved work from direction to structured execution, testing, acceptance, save-point control, version alignment, reporting and next-action selection without losing decisions, dependencies, ownership or authority boundaries.
END OF FULL FILE OUTPUT