Parent Page: Project Manager Brain
Version: 1.0
Date: 2026-06-23
Author: HeadOffice
Status: Active
Page Type: Brain Architecture
Authority Level: MWMS Architecture
Purpose
Project Manager Brain Architecture defines the structural design, system layers, records, operational surfaces, integrations, data flows, control points and future expansion path required for Project Manager Brain.
This architecture translates the Project Manager Brain Canon into an implementable operational system.
It defines how Project Manager Brain will coordinate projects, workstreams, tasks, priorities, dependencies, blockers, changes, meetings, tests, versions, reporting and escalations across MWMS.
The architecture must preserve:
- HeadOffice authority
- specialist Brain authority
- MCR source truth
- human review
- testing discipline
- evidence-backed completion
- version alignment
- change traceability
- recoverable operational records
Architectural Position
Project Manager Brain sits between strategic direction and operational execution.
The architectural flow is:
HeadOffice Direction
To
Project Manager Brain Project Control
To
Operations Sequencing And Coordination
To
Specialist Brain Execution
To
Testing And Acceptance
To
Project Completion And Reporting
Project Manager Brain also receives structured inputs from:
- Kaizen
- SIT Brain
- meetings
- specialist Brains
- operational websites
- plugins
- Supabase
- MCR
- human users
- future AIBS project systems
Project Manager Brain must not become the execution engine for every specialist Brain.
Its architecture coordinates and records work while preserving specialist ownership.
Architecture Goals
Project Manager Brain architecture must support:
- clear project structure
- reliable task control
- visible priorities
- visible dependencies
- visible blockers
- controlled change management
- reviewed meeting actions
- structured testing
- acceptance control
- version alignment
- current save points
- action-driven reporting
- HeadOffice escalation
- future automation
- future AIBS project management
Core Architecture Layers
Project Manager Brain is structured across seven primary layers.
Layer One: Canon And Governance Layer
This layer exists in MCR.
It contains:
- Project Manager Brain
- Project Manager Brain Canon
- Project Manager Brain Architecture
- Project Manager Brain Operating Model
- Project Manager Brain Workflow Map
- Project Manager Brain Page Registry
- future approved standards
- future approved templates
- future approved implementation specifications
This layer defines authority, rules and approved structure.
It must not be replaced by operational website content.
Layer Two: Operational Interface Layer
This layer exists on:
promanbrain.site
The approved initial operational pages are:
- Project Manager Brain
- Project Manager Brain Dashboard
- Project Manager Brain Projects
- Project Manager Brain Workstreams
- Project Manager Brain Tasks
- Project Manager Brain Priorities
- Project Manager Brain Dependencies
- Project Manager Brain Changes And Decisions
- Project Manager Brain Meetings And Actions
- Project Manager Brain Testing And Acceptance
- Project Manager Brain Version Alignment
- Project Manager Brain Reports
- Project Manager Brain Settings
These pages provide human-facing control and visibility.
They are operational surfaces only.
Layer Three: Application Logic Layer
This layer is expected to be delivered through a controlled WordPress plugin.
The Project Manager Brain plugin should eventually control:
- project record creation
- project editing
- workstream creation
- task creation
- task status changes
- priority calculation support
- dependency linking
- blocker handling
- decision records
- change records
- meeting action review
- testing records
- acceptance decisions
- version alignment records
- reporting
- permissions
- validation
- archival behaviour
- save-point generation
The plugin must not store critical logic only inside WordPress page content.
Operational logic should remain modular, versioned and recoverable.
Layer Four: Data Layer
The primary structured data layer should be Supabase.
Supabase should eventually store:
- projects
- workstreams
- tasks
- task relationships
- priorities
- dependencies
- blockers
- project updates
- decisions
- changes
- meeting records
- proposed meeting actions
- approved meeting actions
- test records
- acceptance records
- completion evidence
- Brain version records
- project save points
- escalations
- reports
- audit history
The data layer must support:
- stable identifiers
- relational links
- timestamps
- ownership
- status history
- archive states
- auditability
- recoverability
- controlled permissions
- future automation
Layer Five: Coordination Layer
The coordination layer manages relationships with other MWMS systems.
Primary coordination targets include:
- HeadOffice Brain
- Operations Brain
- Kaizen
- SIT Brain
- specialist Brains
- MCR
- operational Brain websites
- Supabase
- WordPress plugins
- future AIBS systems
This layer must ensure that inputs from other systems are classified before changing project records.
Layer Six: Intelligence Layer
The intelligence layer may provide controlled AI support.
Approved future AI capabilities may include:
- task clarification
- dependency detection
- blocker detection
- priority recommendation
- next action recommendation
- meeting action extraction
- change impact analysis
- version mismatch detection
- missing evidence detection
- report preparation
- escalation preparation
- stale save-point warnings
- future work readiness analysis
The intelligence layer must remain subordinate to Canon, permissions and human review.
Layer Seven: Reporting And Escalation Layer
This layer provides action-driven outputs to:
- Martyn
- M
- HeadOffice
- Operations
- specialist Brain owners
- future authorised users
It should support:
- daily task views
- weekly movement views
- project health views
- blocker views
- dependency views
- test status views
- version alignment views
- change impact views
- escalation views
- future work readiness views
Core Record Architecture
Project Record
The project record is the highest operational work container.
Required project fields should include:
- project identifier
- project title
- project description
- objective
- business reason
- owning Brain
- project owner
- contributors
- project status
- project priority
- project phase
- start date
- target date
- current version
- current save point
- expected outcome
- acceptance criteria
- risk state
- blocker state
- testing state
- latest decision
- latest update
- next valid action
- related MCR pages
- related operational pages
- archive state
- created date
- updated date
Workstream Record
The workstream record divides a project into meaningful execution areas.
Required workstream fields should include:
- workstream identifier
- parent project identifier
- workstream title
- workstream description
- objective
- owner
- priority
- status
- sequence position
- dependency state
- blocker state
- acceptance criteria
- latest update
- next valid action
- archive state
- created date
- updated date
Task Record
The task record is the core executable work unit.
Required task fields should include:
- task identifier
- parent project identifier
- parent workstream identifier
- task title
- task description
- task type
- owner
- status
- priority
- readiness state
- dependency state
- blocker state
- due date where relevant
- acceptance criteria
- test requirement
- evidence requirement
- related Brain
- related MCR page
- related operational page
- related plugin
- related schema
- source
- next valid action
- archive state
- created date
- updated date
Dependency Record
The dependency record links work that cannot proceed independently.
Required dependency fields should include:
- dependency identifier
- dependent item type
- dependent item identifier
- required item type
- required item identifier
- dependency description
- dependency owner
- dependency status
- date identified
- expected resolution
- impact
- projects affected
- escalation state
- created date
- updated date
Blocker Record
The blocker record identifies active execution obstruction.
Required blocker fields should include:
- blocker identifier
- blocked item type
- blocked item identifier
- blocker description
- blocker owner
- date identified
- impact
- urgency
- required resolution
- projects affected
- tasks affected
- escalation state
- next review date
- resolution evidence
- resolved date
Decision Record
The decision record captures approved direction.
Required decision fields should include:
- decision identifier
- decision title
- decision statement
- decision owner
- decision date
- reason
- evidence considered
- alternatives rejected where relevant
- projects affected
- tasks affected
- priority impact
- dependency impact
- test impact
- version impact
- follow-up action
- review requirement
- status
Change Record
The change record captures meaningful changes to approved project direction or system state.
Required change fields should include:
- change identifier
- change title
- change description
- reason
- authorised by
- date authorised
- project impact
- workstream impact
- task impact
- priority impact
- dependency impact
- page impact
- plugin impact
- schema impact
- version impact
- testing impact
- retesting requirement
- escalation requirement
- completion state
Meeting Record
The meeting record stores the source meeting and its controlled outputs.
Required meeting fields should include:
- meeting identifier
- meeting title
- meeting date
- attendees
- source notes
- recording link where applicable
- related projects
- related Brains
- extraction status
- review status
- approval status
- created date
- updated date
Meeting Action Record
The meeting action record stores proposed and approved actions.
Required meeting action fields should include:
- meeting action identifier
- parent meeting identifier
- action type
- action statement
- proposed owner
- proposed due date
- related project
- related task
- related Brain
- approval state
- approved owner
- approved date
- project update state
- task creation state
- change review state
Test Record
The test record captures validation activity.
Required test fields should include:
- test identifier
- related project
- related workstream
- related task
- test title
- test objective
- test method
- expected result
- actual result
- test status
- tested by
- test date
- evidence
- failure reason
- corrective action
- retest required
- acceptance impact
Acceptance Record
The acceptance record captures final approval of work.
Required acceptance fields should include:
- acceptance identifier
- item type
- item identifier
- acceptance criteria
- criteria result
- evidence reviewed
- accepted by
- acceptance date
- acceptance status
- conditions
- rejected reason
- follow-up requirement
Version Alignment Record
The version alignment record tracks compatibility across systems.
Required version fields should include:
- version record identifier
- Brain name
- operational site
- Canon version
- operational version
- plugin version
- schema version
- current save point
- last tested date
- dependency list
- compatibility state
- update required
- retest required
- mismatch description
- escalation state
- updated date
Save-Point Record
The save-point record captures the current trusted state of a project.
Required save-point fields should include:
- save-point identifier
- project identifier
- save-point date
- active version
- completed work
- active work
- blocked work
- testing state
- deferred work
- current risks
- current dependencies
- current decisions
- next valid action
- evidence references
- created by
- approval state
Escalation Record
The escalation record captures issues requiring higher authority.
Required escalation fields should include:
- escalation identifier
- issue
- source
- severity
- impact
- urgency
- options
- recommendation
- decision required
- authority required
- date raised
- current state
- decision outcome
- resolution date
Priority Architecture
Priority must be represented as more than one static number.
The architecture should support:
- strategic priority
- operational priority
- urgency
- readiness
- dependency impact
- risk impact
- testing impact
- value impact
- effort
- owner availability
- delay consequence
- version alignment impact
- final recommended order
- human override
- override reason
The final priority displayed to users should be explainable.
The system should preserve both:
- calculated recommendation
- approved human priority
Human authority must be able to override a recommendation while preserving the reason.
Status Architecture
Project Statuses
Approved initial project statuses should include:
- Draft
- Proposed
- Approved
- Planned
- Active
- At Risk
- Blocked
- Paused
- Ready For Testing
- Testing
- Changes Required
- Awaiting Acceptance
- Completed
- Closed
- Archived
- Cancelled
Workstream Statuses
Approved initial workstream statuses should include:
- Not Started
- Ready
- Active
- Blocked
- Paused
- Ready For Testing
- Testing
- Changes Required
- Completed
- Archived
- Cancelled
Task Statuses
Approved initial task statuses should include:
- Not Started
- Ready
- In Progress
- Implemented
- Ready For Testing
- Testing In Progress
- Test Failed
- Changes Required
- Retest Required
- Test Passed
- Awaiting Acceptance
- Accepted
- Closed
- Archived
- Cancelled
Dependency Statuses
Approved initial dependency statuses should include:
- Unknown
- Identified
- Waiting
- In Progress
- Ready
- Satisfied
- Failed
- Escalated
- Cancelled
Blocker Statuses
Approved initial blocker statuses should include:
- Open
- Under Review
- Resolution In Progress
- Escalated
- Resolved
- Accepted Risk
- Closed
Architecture Flow
Project Creation Flow
Approved Need Identified
To
Project Record Created
To
Objective And Owner Confirmed
To
Priority Set
To
Acceptance Criteria Defined
To
Workstreams Created
To
Tasks Created
To
Dependencies Linked
To
Project Approved
To
Execution Begins
Task Execution Flow
Task Created
To
Readiness Checked
To
Dependencies Checked
To
Owner Confirmed
To
Priority Confirmed
To
Task Started
To
Implementation Completed
To
Testing Required Decision
To
Test Or Acceptance
To
Evidence Recorded
To
Task Accepted
To
Task Closed
Change Flow
Change Proposed
To
Authority Checked
To
Change Approved
To
Impact Analysed
To
Affected Projects Updated
To
Affected Tasks Updated
To
Dependencies Updated
To
Version Review
To
Testing Review
To
New Save Point Created
Meeting Flow
Meeting Notes Captured
To
Actions And Decisions Extracted
To
Human Review
To
Approved Items Confirmed
To
Project Records Updated
To
Tasks Created Or Updated
To
Changes Recorded
To
Dependencies Reviewed
To
Testing And Version Impact Reviewed
To
Meeting Closed
Testing Flow
Implementation Completed
To
Test Requirement Confirmed
To
Test Record Created
To
Test Executed
To
Evidence Captured
To
Pass Or Fail Decision
To
Corrective Work Or Acceptance
To
Retest Where Required
To
Acceptance Recorded
To
Save Point Updated
Escalation Flow
Issue Identified
To
Impact Assessed
To
Existing Authority Checked
To
Resolution Attempted
To
Escalation Required Decision
To
Escalation Record Created
To
HeadOffice Or Relevant Authority Reviews
To
Decision Recorded
To
Project Updated
To
Follow-Up Work Created
Operational Page Architecture
Project Manager Brain
Purpose:
Provide the top-level entry point and identity for the operational Brain.
Project Manager Brain Dashboard
Purpose:
Provide a current system overview.
Expected dashboard panels include:
- active projects
- current main focus
- today’s priorities
- blocked work
- testing required
- decisions required
- recent changes
- version warnings
- near-future work
- HeadOffice escalations
Project Manager Brain Projects
Purpose:
Create, view, edit, archive and review projects.
Project Manager Brain Workstreams
Purpose:
Create, organise and monitor project workstreams.
Project Manager Brain Tasks
Purpose:
Create, assign, update, test, accept and archive tasks.
Project Manager Brain Priorities
Purpose:
Show approved execution order and priority reasoning.
Project Manager Brain Dependencies
Purpose:
Show work that is waiting, what it is waiting for and what becomes available when dependencies are resolved.
Project Manager Brain Changes And Decisions
Purpose:
Record approved decisions, changes of direction and their system impact.
Project Manager Brain Meetings And Actions
Purpose:
Capture meeting notes, review extracted actions and apply approved updates.
Project Manager Brain Testing And Acceptance
Purpose:
Manage tests, failures, corrective actions, retests, evidence and acceptance.
Project Manager Brain Version Alignment
Purpose:
Track Canon, operational, plugin, schema and dependency compatibility.
Project Manager Brain Reports
Purpose:
Generate action-driven project and system reports.
Project Manager Brain Settings
Purpose:
Control approved statuses, permissions, connections, configuration values and future integration settings.
Dashboard Architecture
The initial dashboard should be restrained.
It should not attempt to display every possible metric.
The first dashboard should focus on:
- Current Main Project
- Must Do Today
- Should Do Today
- Blocked Tasks
- Testing Required
- HeadOffice Decisions Required
- Recent Changes
- Version Alignment Warnings
- Next Valid Actions
- Near Future Work
Future dashboard expansion may include:
- project health scoring
- owner workload
- risk trends
- testing failure trends
- dependency concentration
- delayed work
- Kaizen recurrence
- SIT findings
- AIBS client projects
Permissions Architecture
Initial User Roles
Martyn
Expected authority:
- full project visibility
- project creation
- project approval
- priority approval
- task creation
- task editing
- decision approval
- change approval
- test review
- acceptance
- escalation
- settings control
M
Expected authority:
- view assigned and relevant projects
- view relevant dependencies
- update assigned tasks
- add implementation evidence
- submit work for testing
- raise blockers
- add project updates
- participate in meeting actions
- view accepted priorities
M must not automatically receive strategic approval authority.
Future Roles
Future roles may include:
- HeadOffice Reviewer
- Project Manager
- Task Owner
- Tester
- SIT Reviewer
- Specialist Brain Reviewer
- AIBS Client Viewer
- AIBS Client Approver
- Read Only User
Permissions must be capability-based rather than relying only on page access.
Human Review Gates
Human review must be required for:
- project approval
- strategic priority override
- material scope change
- meeting action approval
- critical task assignment
- test acceptance
- disputed completion
- critical version mismatch resolution
- project closure
- major escalation resolution
- Canon-affecting change
Automation must not bypass these gates.
Integration Architecture
HeadOffice Integration
Project Manager Brain should send HeadOffice:
- project health
- major blockers
- priority conflicts
- strategic decisions required
- critical failed tests
- version alignment risks
- material scope changes
- resource conflicts
- consequences of delay
HeadOffice should return:
- approved direction
- approved priority
- approved escalation decision
- approved project status
- strategic change decisions
Operations Brain Integration
Project Manager Brain should request or use:
- sequencing guidance
- handoff requirements
- bottleneck analysis
- workflow continuity requirements
- dependency coordination
- execution reliability guidance
Kaizen Integration
Project Manager Brain should receive:
- repeated friction findings
- improvement recommendations
- waste patterns
- process failures
- preventive improvement opportunities
Approved findings should become controlled project work.
SIT Brain Integration
Project Manager Brain should receive:
- independent review findings
- reliability concerns
- failed implementation findings
- missing evidence
- rescue requirements
- retest requirements
Specialist Brain Integration
Specialist Brains should provide:
- specialist work output
- specialist status
- specialist blockers
- specialist test requirements
- specialist acceptance evidence
- version changes
- handoff outputs
MCR Integration
Project Manager Brain should link to relevant MCR pages.
MCR content must not be duplicated unnecessarily into operational records.
Operational records should reference:
- relevant Canon
- relevant framework
- relevant standard
- relevant checklist
- relevant protocol
WordPress Integration
WordPress should provide:
- operational interface
- user access
- plugin execution
- visible navigation
- forms
- tables
- filters
- dashboards
- record views
WordPress should not become the sole data source for structured project records.
Supabase Integration
Supabase should provide:
- structured storage
- relational data
- auditability
- archive support
- reporting support
- future automation support
- future cross-site integration
Version Architecture
The Project Manager Brain plugin must use controlled versioning.
Every plugin release should record:
- version number
- release date
- changes
- affected screens
- affected tables
- migration requirements
- tests completed
- known limitations
- rollback position
Database changes should also be versioned.
The system must preserve awareness of:
- plugin version
- schema version
- operational save point
- Canon version
Archive Architecture
Records should generally be archived rather than permanently deleted.
Archive support should apply to:
- projects
- workstreams
- tasks
- dependencies
- blockers
- meeting records
- test records
- version records
Archived records must remain:
- searchable
- attributable
- linked
- historically visible
- protected from ordinary editing
Deletion Architecture
Permanent deletion should be restricted.
Permanent deletion should require explicit authority where the record affects:
- decisions
- changes
- tests
- acceptance
- completion evidence
- version history
- escalations
- project history
Audit Architecture
The system should record meaningful operational changes.
Audit history should capture:
- record created
- record updated
- status changed
- owner changed
- priority changed
- dependency changed
- blocker added
- test result added
- acceptance changed
- meeting action approved
- version changed
- record archived
Audit entries should identify:
- user
- timestamp
- record
- previous state
- new state
- reason where required
Initial Build Architecture
Phase One
MCR Foundation
- Project Manager Brain
- Project Manager Brain Canon
- Project Manager Brain Architecture
- Project Manager Brain Operating Model
- Project Manager Brain Workflow Map
- Project Manager Brain Page Registry
Phase Two
Operational Shell
- approved WordPress pages
- plugin foundation
- admin menu
- page routing
- access controls
Phase Three
Core Records
- projects
- workstreams
- tasks
- project updates
- save points
Phase Four
Execution Controls
- priorities
- dependencies
- blockers
- next valid actions
Phase Five
Governance Records
- decisions
- changes
- meeting records
- meeting actions
Phase Six
Quality Controls
- testing
- failures
- corrective actions
- retesting
- acceptance
- completion evidence
Phase Seven
Version Control
- Brain version records
- plugin version records
- schema version records
- compatibility warnings
Phase Eight
Reporting
- daily view
- weekly view
- project status
- blockers
- testing
- versions
- escalations
Phase Nine
Real Validation
- Content Brain Operational Build entered
- current save point represented
- tasks represented
- dependencies represented
- tests represented
- versions represented
- next valid work confirmed
Phase Ten
Controlled Intelligence
- meeting extraction
- priority recommendations
- dependency suggestions
- missing evidence detection
- version mismatch detection
- report preparation
Initial Architecture Exclusions
The initial architecture must not include:
- unrestricted autonomous project creation
- autonomous strategy
- automatic critical reprioritisation
- automatic meeting action approval
- autonomous project closure
- automatic completion acceptance
- client billing
- time tracking
- broad client portals
- full workforce planning
- advanced financial forecasting
- automatic contractual deadlines
- uncontrolled external integrations
- unsupported workload promises
- AI modification of Canon
Scalability Architecture
The architecture must support later expansion into:
- multiple MWMS projects
- multiple project owners
- multiple specialist Brains
- multiple companies
- AIBS internal development
- AIBS client delivery
- automation implementation projects
- recurring optimisation projects
- client approvals
- project handover
- project maintenance
- project reporting
Future multi-company support must not be added before the single-system operational model is stable.
Architecture Success Criteria
The architecture is successful when:
- records link correctly
- project state is current
- priorities remain explainable
- dependencies are visible
- blockers are visible
- changes propagate correctly
- meeting actions require approval
- tests remain linked to work
- acceptance requires evidence
- save points remain reliable
- version mismatches are visible
- HeadOffice receives proper escalations
- specialist authority remains intact
- archived history remains available
- the system can identify the next valid action
Architecture Failure Conditions
The architecture is failing when:
- page content becomes the main database
- operational records redefine Canon
- data relationships are lost
- records cannot be audited
- projects operate without save points
- tasks become disconnected from projects
- dependencies remain hidden
- failed tests disappear
- completion evidence is missing
- AI bypasses human review
- version changes are not recorded
- duplicate records become common
- the system cannot explain priority
- HeadOffice must reconstruct project state manually
- specialist Brains lose authority
- the architecture becomes too complex to operate
MWMS System Change Log
Version: 1.0
Date: 2026-06-23
Author: HeadOffice
Change
Created the initial Project Manager Brain Architecture.
Defined the seven-layer architecture covering Canon and governance, operational interfaces, application logic, Supabase data, cross-Brain coordination, controlled intelligence, reporting and escalation.
Defined the initial project, workstream, task, dependency, blocker, decision, change, meeting, test, acceptance, version, save-point and escalation record structures.
Defined the operational page purposes, permissions model, human review gates, integration flows, archive controls, audit requirements and phased implementation sequence.
Change Impact Declaration
This change provides the initial technical and operational architecture required to implement Project Manager Brain.
The change does not authorise autonomous strategic decisions or unrestricted automation.
The change confirms WordPress as the operational interface, a controlled WordPress plugin as the application layer, Supabase as the intended structured data layer and MCR as the source of truth.
Pages Created
Project Manager Brain Architecture
Pages Updated
None
Pages Deprecated
None
Standalone Pages Not Created
Project Manager Brain Operating Model
Project Manager Brain Workflow Map
Project Manager Brain Page Registry
Project Manager Brain Database Schema Specification
Project Manager Brain Plugin Build Specification
Project Manager Brain Dashboard Specification
The first three remain scheduled MCR foundation pages.
The final three are not created at this stage and must only be introduced when the operational build requires them.
Registries Requiring Update
MWMS Architecture Registry
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 concept has been converted into an implementable MWMS architecture.
The architecture now defines how approved direction will move through project records, operational coordination, specialist execution, testing, acceptance, version alignment, reporting and escalation without weakening HeadOffice authority or specialist Brain boundaries.
END OF FULL FILE OUTPUT