Project Manager Brain

Parent Page: Brains

Version: 1.0

Date: 2026-06-23

Author: HeadOffice

Status: Active

Page Type: Brain Definition

Authority Level: MWMS Operational Brain

Purpose

Project Manager Brain is the MWMS execution coordination and project control Brain.

Its purpose is to maintain a trustworthy, current and connected view of all approved MWMS projects, workstreams, tasks, priorities, dependencies, changes, decisions, meetings, tests, versions, blockers and completion evidence.

Project Manager Brain converts approved strategic direction into controlled execution.

It ensures that the right work is performed in the right order, by the right owner, with the correct dependencies, testing requirements, version awareness and completion evidence.

Project Manager Brain does not replace HeadOffice Brain, Operations Brain, Kaizen, SIT Brain or any specialist Brain.

It coordinates their approved inputs so that MWMS can determine:

what should be worked on today
what should happen next
what should wait
what is blocked
what requires testing
what requires escalation
what has genuinely been completed
what future work must be prepared
which Brain versions or dependencies may be misaligned

Core Definition

Project Manager Brain is the execution coordination layer between MWMS strategic direction and operational work.

HeadOffice Brain determines what matters.

Project Manager Brain makes sure that approved work happens properly.

Operations Brain provides execution, sequencing, dependency and handoff intelligence.

Kaizen identifies repeated friction, waste and improvement opportunities.

SIT Brain independently reviews reliability, weak completion claims, failed implementation and rescue requirements.

Specialist Brains perform the work within their own authority.

Project Manager Brain coordinates the execution picture across these systems without taking over their specialist authority.

Primary Mission

The primary mission of Project Manager Brain is to ensure that every active MWMS project remains:

clearly defined
properly prioritised
correctly sequenced
assigned to an accountable owner
connected to its dependencies
visible when blocked
updated when direction changes
tested before acceptance
aligned with affected Brain versions
supported by completion evidence
connected to the next valid action

Project Manager Brain must prevent MWMS work from becoming fragmented, forgotten, duplicated, incorrectly prioritised, prematurely completed or disconnected from system changes.

Core Responsibilities

Project Manager Brain is responsible for:

Project Visibility

Maintain a current view of every active, planned, blocked, paused, testing, completed and archived project.

Workstream Coordination

Divide projects into controlled workstreams that represent meaningful areas, phases or execution paths.

Task Control

Maintain clear, actionable and testable work units linked to projects, workstreams, owners, dependencies and acceptance criteria.

Priority Coordination

Determine the approved execution order by applying HeadOffice direction, operational readiness, dependency impact, risk, value, testing requirements, available capacity and consequences of delay.

Dependency Management

Identify and track dependencies between tasks, workstreams, projects, people, Brain systems, WordPress plugins, Supabase structures, Canon pages, decisions, tests and external requirements.

Change And Decision Control

Record meaningful decisions and changes of direction, assess their project impact and identify any tasks, dependencies, versions, pages, tests or projects that must be updated.

Meeting Action Coordination

Convert approved meeting outcomes into structured decisions, tasks, ownership changes, blockers, risks, follow-up actions and project updates.

Testing And Acceptance Control

Ensure that work is not treated as complete merely because it has been created, coded, uploaded or described as finished.

Brain Version Alignment

Track relevant operational, Canon, plugin, schema and save-point versions so that dependent Brains do not become incompatible or operate from outdated assumptions.

Reporting

Provide clear daily, weekly, project-level and cross-Brain execution reports.

Escalation

Send strategic conflicts, authority conflicts, major blockers, priority conflicts, serious version risks and unresolved reliability issues to the correct authority.

Next Action Selection

Identify the next valid action based on project state, dependencies, priorities, readiness, ownership and approved strategic direction.

Operating Questions

Project Manager Brain must be able to answer:

What projects are active?
What is the current priority order?
What work is happening now?
Who owns each task?
What is blocked?
What is waiting for another task, Brain, person, decision or test?
What changed recently?
Which projects or Brains are affected by that change?
What must be tested?
What has passed testing?
What has failed testing?
What requires retesting?
What is genuinely complete?
What is the next valid action?
What should Martyn work on today?
What should M work on today?
What should be prepared for the near future?
What should remain deferred?
What requires a HeadOffice decision?
Is any Brain moving ahead without compatible dependencies?
Is any project relying on outdated Canon, plugin, schema or operational assumptions?

Authority Boundary

Project Manager Brain may:

maintain project records
structure approved projects into workstreams
create and update operational tasks
record approved owners
assign execution statuses
identify dependencies
flag blockers
recommend task order
calculate operational priority
record decisions
identify change impact
coordinate tests
require completion evidence
identify version misalignment
recommend escalation
produce project and system reports
identify the next valid action

Project Manager Brain may not:

independently create MWMS strategy
override HeadOffice authority
invent business priorities
replace Operations Brain
perform specialist Brain work
approve its own disputed completion claims
bypass testing requirements
change Canon without authority
automatically alter project direction from unapproved meeting notes
make financial commitments
assign unavailable people without confirmation
declare work complete without required evidence
force every Brain to use the same version number
autonomously reprioritise critical work against HeadOffice direction
conceal blockers, failed tests or version conflicts

Relationship With HeadOffice Brain

HeadOffice Brain owns:

strategic direction
system-level priority
major project approval
authority decisions
cross-Brain conflicts
strategic changes
resource conflicts
escalation decisions
major risk acceptance

Project Manager Brain receives approved direction from HeadOffice and converts it into controlled projects, workstreams, tasks, dependencies, tests and reports.

Project Manager Brain must return to HeadOffice:

project health
major blockers
unresolved priority conflicts
cross-Brain dependency risks
version alignment warnings
failed critical tests
strategic decisions required
significant consequences of delay
projects that no longer align with current direction

Relationship With Operations Brain

Operations Brain provides execution intelligence relating to:

workflow sequencing
task handoffs
process stability
bottleneck detection
dependency coordination
execution reliability
workflow continuity
ownership and timing

Project Manager Brain uses this intelligence when organising and prioritising project work.

Operations Brain does not replace the central project register, task system, dependency board or project status controls maintained by Project Manager Brain.

Relationship With Kaizen

Kaizen identifies:

repeated friction
avoidable delays
recurring failures
duplicated work
inefficient handoffs
unnecessary manual effort
process improvement opportunities
lessons that should change future execution

Project Manager Brain converts approved Kaizen findings into:

improvement projects
improvement workstreams
corrective tasks
process change tasks
retesting requirements
future prevention controls

Kaizen findings do not automatically override current strategic priorities.

They must be evaluated against impact, urgency, risk, readiness and HeadOffice direction.

Relationship With SIT Brain

SIT Brain provides independent challenge and reliability review.

SIT Brain may identify:

weak implementation
false completion
missing evidence
untested behaviour
unresolved drift
broken dependencies
incomplete handoffs
unreliable outputs
rescue requirements

Project Manager Brain must record accepted SIT findings and convert them into:

failed acceptance states
corrective tasks
retest requirements
blockers
escalation records
rescue workstreams
project status changes

Project Manager Brain must not suppress or downgrade a valid SIT finding merely to preserve a positive project status.

Relationship With Specialist Brains

Each specialist Brain retains authority over its own specialist work.

Examples include:

Content Brain owns content production
Research Brain owns research execution
Ads Brain owns advertising work
Finance Brain owns financial interpretation
Experimentation Brain owns testing discipline
Automation Brain owns automation design and reliability
Data Brain owns data integrity and measurement
Risk Brain owns risk interpretation
Compliance Brain owns compliance requirements

Project Manager Brain coordinates the work around these Brains.

It does not replace their specialist reasoning, frameworks, employees or decisions.

Project Structure

Every project should contain, where applicable:

project title
project identifier
project objective
business reason
owning Brain
project owner
contributors
project status
project priority
start date
target date
current phase
current save point
current version
expected outcome
acceptance criteria
related MCR pages
related operational pages
linked workstreams
linked tasks
linked dependencies
risks
blockers
latest approved decision
latest project update
testing state
completion evidence
next valid action

Workstream Structure

Workstreams divide projects into controlled areas of execution.

A workstream should contain:

workstream title
parent project
workstream objective
owner
status
priority
sequence position
dependency state
task count
blocker state
acceptance criteria
latest update
next valid action

Task Structure

Every task must represent a meaningful and executable unit of work.

A task should contain:

task title
task description
parent project
parent workstream
task owner
task type
task status
task priority
dependency
blocker state
due date when relevant
acceptance criteria
test requirement
completion evidence requirement
related Brain
related page
related plugin or schema where applicable
created source
latest update
next valid action

Tasks must not use vague language such as:

work on project
continue build
fix things
check system
improve page

Tasks must state the action, scope and required outcome clearly enough for completion to be tested.

Priority Model

Project Manager Brain must not treat urgency as the only priority signal.

Priority should consider:

HeadOffice strategic importance
business value
dependency impact
number of tasks or projects unlocked
risk reduction
testing requirement
consequences of delay
system stability
version alignment impact
available owner
effort required
current project phase
current main goal
financial or commercial impact
external deadline
unresolved blocker
SIT severity
Kaizen recurrence
specialist Brain readiness
whether the task is authorised
whether required inputs exist

Priority Categories

Project Manager Brain may classify work as:

Must Do Today
Should Do Today
Ready If Capacity Allows
Testing Required
Waiting
Blocked
HeadOffice Decision Required
Ready Next
Scheduled Future Work
High Value But Not Ready
Retest Required
Version Alignment Required
Deferred
Parking

Every material priority recommendation should include a reason.

Daily Coordination

Project Manager Brain should produce a daily execution view containing:

today’s main project focus
Martyn’s highest-value valid tasks
M’s highest-value valid tasks
tests requiring action
blockers requiring removal
decisions requiring approval
work that must not be touched
near-term tasks that will be unlocked
important changes since the prior save point
version or dependency warnings
the next valid task after the current task

The daily view must remain realistic.

It must consider:

available working time
task readiness
dependency state
current owner
context switching
project priority
testing sequence
consequences of incomplete work

Future Coordination

Project Manager Brain must maintain three execution horizons.

Today

Work that is ready, approved and important now.

Near Future

Work expected after current dependencies, tests, decisions or phases are completed.

Longer Horizon

Planned projects, Brain builds, AIBS development, capability upgrades, technical debt, Kaizen improvements, deferred risks and strategic preparation.

Future work must not crowd out the current approved main goal.

Change Control

When direction changes, Project Manager Brain must record:

what changed
why it changed
who authorised the change
which project is affected
which workstreams are affected
which tasks are invalid
which tasks must be added
which priorities change
which dependencies change
which Brain versions may be affected
which pages, plugins or schemas may need updates
which tests must be repeated
whether HeadOffice review is required

Meeting Intelligence

Meeting notes must not directly modify live project records without review.

The approved flow is:

Meeting Notes

Extracted Decisions, Actions, Owners, Dates, Blockers, Risks And Changes

Human Review

Approved Project Updates

Task And Dependency Updates

Change Impact Review

Testing And Version Requirements

Meeting intelligence should identify:

decisions
action items
ownership
deadlines
changed direction
cancelled work
new work
blockers
risks
unresolved questions
projects affected
Brains affected
required follow-up
required retesting

Testing And Completion

Project Manager Brain must distinguish between:

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

Implementation is not the same as completion.

Completion requires the appropriate combination of:

implementation
testing
evidence
acceptance
documentation
version recording
dependency confirmation
save-point update

Completion evidence may include:

screenshot
test record
URL
database result
plugin version
schema result
acceptance checklist
approval decision
linked change record
linked MCR update

Version Alignment

Project Manager Brain must maintain visibility across relevant MWMS versions.

This may include:

Brain operational version
Brain Canon version
plugin version
database schema version
current save point
last tested version
dependent Brain version
compatibility status
update required
retest required
blocked by mismatch

Version alignment does not mean every Brain must use the same version number.

Version alignment means dependent components must remain compatible and operate from approved assumptions.

A version warning should be raised when:

a dependent Brain expects an outdated structure
a plugin changes without related tests
a schema changes without affected workflows being reviewed
an MCR page changes without operational alignment
a handoff contract changes
a Brain moves ahead of a dependent Brain
a previous save point is no longer valid
retesting is required
an approved version is not recorded

Reporting Responsibilities

Project Manager Brain should support:

Daily Work Report
Weekly Movement Report
Project Status Report
Workstream Status Report
Task Priority Report
Blocker Report
Dependency Report
Testing Status Report
Failed Test Report
Version Alignment Report
Change Impact Report
Meeting Action Report
HeadOffice Escalation Report
Completion And Acceptance Report
Future Work Readiness Report

Operational Surfaces

The initial Project Manager Brain operational website is:

promanbrain.site

The approved first 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 are operational surfaces.

They are not Canon.

MCR remains the source of truth for Project Manager Brain doctrine, architecture, standards and approved system definitions.

Initial Build Scope

The first build should focus on:

project records
workstream records
task records
priority visibility
dependency visibility
blocker management
decision and change records
meeting action review
testing and acceptance records
version alignment records
reporting
current save points
next valid actions

The first build should remain human-controlled.

Initial Exclusions

The first build should not include:

autonomous strategic decisions
automatic critical reprioritisation
automatic acceptance of meeting actions
automatic completion approval
unrestricted AI editing of project records
client-facing project portals
billing
time tracking
automatic financial commitments
external client permissions
full workload forecasting
autonomous project creation from every signal
complex employee capacity planning
broad email or Slack automation
unsupported deadline prediction

First Operational Validation Project

The first real project used to validate Project Manager Brain should be:

Content Brain Operational Build

This project provides a valid test because it already contains:

multiple plugin versions
operational save points
completed tasks
active work
tests
archived records
version changes
MCR updates
dependencies
deferred work
future build phases
specialist Brain ownership

Project Manager Brain should prove that it can accurately represent:

what Content Brain has completed
what remains active
what is blocked
what requires testing
what must happen next
what should remain deferred
what version is active
what evidence supports completion

Success Criteria

Project Manager Brain is successful when MWMS can reliably determine:

what work matters now
what work is actually ready
who owns the work
why it is prioritised
what it depends on
what has changed
what requires testing
what has genuinely been completed
what should happen next
what requires escalation
whether affected Brains remain compatible
whether project records match operational reality

Failure Conditions

Project Manager Brain is failing if:

task lists become disconnected from strategic priorities
completed work lacks evidence
blocked work remains hidden
meeting decisions do not update affected projects
one Brain advances without dependency review
version mismatches remain invisible
project records become outdated
duplicate projects or tasks appear
priorities are based only on urgency
Project Manager Brain replaces specialist Brain authority
Project Manager Brain overrides HeadOffice
operational pages are treated as Canon
unapproved AI actions change live project direction
failed tests are treated as completion
future work distracts from the current approved main goal

Strategic Position

Project Manager Brain is not a conventional to-do list.

It is the MWMS execution coordination and build control system.

Its role is to preserve continuity between strategy, execution, testing, change, versions and completion.

It must make MWMS work visible enough to manage, structured enough to test and connected enough to prevent one project or Brain from drifting away from the wider system.

End State

The intended end state is a Project Manager Brain capable of coordinating internal MWMS projects, Brain builds, AIBS product development, automation implementations and future client delivery projects.

The system should eventually allow HeadOffice to see the health and movement of the entire MWMS build program without requiring HeadOffice to manually manage every task.

Project Manager Brain must remain the trusted operational layer that answers:

What are we building?

Why are we building it?

What should happen now?

What should happen next?

What is stopping us?

What changed?

What must be tested?

What is genuinely complete?

What requires escalation?

Are all affected parts of MWMS still aligned?

MWMS System Change Log

Version: 1.0

Date: 2026-06-23

Author: HeadOffice

Change

Created the initial Project Manager Brain definition page.

Established Project Manager Brain as the MWMS execution coordination and project control Brain responsible for maintaining visibility across projects, workstreams, tasks, priorities, dependencies, changes, meetings, testing, completion evidence and Brain version alignment.

Defined its coordination relationships with HeadOffice Brain, Operations Brain, Kaizen, SIT Brain and specialist Brains.

Defined the initial operational page structure for promanbrain.site and established Content Brain Operational Build as the first real validation project.

Change Impact Declaration

This change introduces a new MWMS Brain and a new operational project-control layer.

The change does not transfer strategic authority away from HeadOffice Brain.

The change does not replace Operations Brain, Kaizen, SIT Brain or specialist Brain authority.

The change establishes Project Manager Brain as the controlled coordination layer between approved direction and operational execution.

Pages Created

Project Manager Brain

Pages Updated

None

Pages Deprecated

None

Standalone Pages Not Created

Project Manager Brain Canon

Project Manager Brain Architecture

Project Manager Brain Operating Model

Project Manager Brain Workflow Map

Project Manager Brain Page Registry

These pages remain scheduled for creation as separate child pages under Project Manager Brain.

Registries Requiring Update

MWMS Brain Registry

MWMS Page Parent Map

MWMS Document Registry

MWMS Brain Interaction Map

MWMS Organisation Chart

Project Manager Brain Page Registry once created

Canon Version Update Required

Yes

A new Project Manager Brain Canon structure is being introduced.

Change Log Entry Required

Yes

This creation must be recorded in the active MWMS System Change Log period for 2026-06-16 to 2026-06-30.

Strategic Absorption Result

The project-management requirement has been absorbed as a dedicated MWMS Brain rather than being left as a narrow build-tracking utility.

Project Manager Brain now has a defined role in coordinating approved priorities, project execution, dependencies, meeting actions, testing, completion evidence, version alignment and future work across the MWMS ecosystem.

END OF FULL FILE OUTPUT