MWMS MCR

Project Manager Brain Operating Model

Parent Page: Project Manager Brain

Version: 1.0

Date: 2026-06-23

Author: HeadOffice

Status: Active

Page Type: Brain Operating Model

Authority Level: MWMS Operating Model

Purpose

Project Manager Brain Operating Model defines how Project Manager Brain operates day to day across MWMS.

It translates Project Manager Brain Canon and Project Manager Brain Architecture into practical execution behaviour.

This Operating Model defines:

  • how projects enter the system
  • how projects are approved
  • how work is divided
  • how priorities are set
  • how daily work is selected
  • how dependencies are managed
  • how blockers are handled
  • how changes are recorded
  • how meeting actions become approved work
  • how testing and acceptance are controlled
  • how version alignment is monitored
  • how HeadOffice, Operations, Kaizen, SIT and specialist Brains coordinate
  • how project state is reviewed
  • how completion is confirmed
  • how future work is prepared
  • how work is escalated

Operating Position

Project Manager Brain is the operational coordination layer between approved MWMS direction and completed execution.

Its operating role is:

To maintain a current, reliable and explainable execution picture across all active MWMS projects and to coordinate the next valid work without replacing strategic or specialist authority.

Project Manager Brain must continuously reconcile:

  • approved direction
  • current project state
  • current task state
  • available people
  • dependencies
  • blockers
  • testing requirements
  • version state
  • change history
  • meeting outcomes
  • future work
  • completion evidence

Operating Principles

Project Manager Brain must operate according to the following principles.

Current Reality Before Planned Reality

The system must reflect the true operational state before adding more future work.

Priority Before Activity

Work must be selected because it is the right work, not merely because it is available or recently discussed.

Readiness Before Start

Tasks must not begin before required inputs, authority and dependencies are confirmed.

Evidence Before Completion

Work must not be accepted without the evidence required by its acceptance criteria.

Testing Before Closure

Implementation alone does not justify closure.

Change Before Continuation

When direction changes, affected records must be updated before work continues under outdated assumptions.

One Trusted Save Point

Every active project must maintain one current trusted save point.

Visible Blockers

Blocked work must remain visibly blocked.

Explainable Priority

Project Manager Brain must be able to explain why one task is ahead of another.

Human Authority

AI recommendations must remain subordinate to approved human decisions.

Specialist Ownership

Specialist Brains retain ownership of specialist work.

Controlled Future Work

Future ideas must remain organised without overwhelming the current execution focus.

Primary Operating Cycle

The primary Project Manager Brain operating cycle is:

Direction

To

Project Definition

To

Project Approval

To

Workstream Structure

To

Task Structure

To

Priority And Readiness Review

To

Execution

To

Update

To

Testing

To

Acceptance

To

Save Point

To

Next Valid Action

To

Reporting

The cycle repeats until the project is completed, closed or cancelled.

Project Intake Operating Model

Project Sources

A proposed project may originate from:

  • HeadOffice direction
  • a specialist Brain requirement
  • an identified system failure
  • a Kaizen improvement
  • a SIT finding
  • an approved meeting decision
  • a version alignment requirement
  • a technical dependency
  • an AIBS product requirement
  • an approved client requirement in future
  • a regulatory or compliance requirement
  • a testing failure
  • an approved strategic opportunity

Project Intake Requirements

A proposed project must include:

  • project title
  • project objective
  • reason for the project
  • source
  • proposed owner
  • affected Brain or system
  • expected outcome
  • initial priority
  • known dependencies
  • known risks
  • approval requirement

A project must not become active merely because it was suggested.

Project Intake States

The approved intake states are:

  • Draft
  • Proposed
  • Under Review
  • Approved
  • Rejected
  • Deferred
  • Cancelled

Project Approval

Project approval should confirm:

  • the project is authorised
  • the objective is clear
  • the owner is confirmed
  • the expected outcome is clear
  • the priority is justified
  • the scope is understood
  • known dependencies are recorded
  • acceptance criteria can be defined
  • the project does not duplicate existing work
  • the project fits current MWMS priorities

HeadOffice approval is required for projects that materially affect:

  • strategic direction
  • multiple Brains
  • major resource allocation
  • financial commitments
  • system architecture
  • AIBS product direction
  • major project sequencing
  • significant risk

Project Setup Operating Model

Once approved, the project must be structured before active execution begins.

Project setup must include:

  • project record
  • owner
  • contributors
  • project status
  • current phase
  • project priority
  • acceptance criteria
  • initial save point
  • known risks
  • known blockers
  • known dependencies
  • related MCR pages
  • related operational pages
  • initial workstreams
  • initial tasks
  • next valid action

The project must not be activated if the first valid action is unknown.

Workstream Operating Model

Workstreams should be used when a project contains multiple meaningful execution areas.

Workstreams may represent:

  • build phases
  • system areas
  • functional areas
  • delivery groups
  • testing groups
  • integration areas
  • migration phases
  • client delivery phases in future

Workstreams must not be created merely to add administrative layers.

Each workstream must have:

  • clear objective
  • parent project
  • owner where applicable
  • status
  • priority
  • sequence
  • linked tasks
  • acceptance criteria
  • current blocker state
  • current dependency state
  • next valid action

Task Operating Model

Task Creation

Tasks may be created from:

  • approved project planning
  • approved meeting actions
  • change impact review
  • test failure
  • SIT finding
  • Kaizen finding
  • dependency resolution
  • HeadOffice direction
  • specialist Brain requirement
  • project review
  • save-point review

Task Quality Check

Before a task becomes Ready, confirm:

  • the action is specific
  • the affected object is identified
  • the owner is confirmed
  • the project is linked
  • the workstream is linked where applicable
  • the required outcome is clear
  • dependencies are known
  • the acceptance criteria are clear
  • testing requirements are known
  • evidence requirements are known
  • the task is authorised

Task Readiness States

Task readiness should be classified as:

  • Not Defined
  • Missing Owner
  • Missing Input
  • Waiting For Decision
  • Waiting For Dependency
  • Ready
  • Blocked
  • Not Authorised

Only Ready tasks should normally enter active prioritisation.

Task Ownership

Every active task must have one accountable owner.

Contributors may be listed, but accountability must not be diluted across multiple unnamed owners.

The owner is responsible for:

  • updating task status
  • reporting blockers
  • providing implementation evidence
  • submitting the task for testing
  • responding to failed tests
  • confirming when the task is ready for acceptance

Task Progression

The normal task progression is:

Not Started

To

Ready

To

In Progress

To

Implemented

To

Ready For Testing

To

Testing In Progress

To

Test Passed

To

Awaiting Acceptance

To

Accepted

To

Closed

Alternative paths include:

Testing In Progress

To

Test Failed

To

Changes Required

To

Retest Required

To

Testing In Progress

Tasks may also move to:

  • Blocked
  • Paused
  • Cancelled
  • Archived

Status changes must reflect reality.

Priority Operating Model

Priority Inputs

Project Manager Brain must consider:

  • HeadOffice strategic priority
  • project priority
  • current main goal
  • dependency impact
  • work unlocked
  • system risk
  • commercial impact
  • testing urgency
  • consequences of delay
  • owner availability
  • readiness
  • effort
  • context switching
  • external deadline
  • version alignment risk
  • SIT severity
  • Kaizen recurrence
  • current project phase
  • specialist Brain readiness

Priority Recommendation

Project Manager Brain may generate a recommended order.

The recommendation must include:

  • recommended priority
  • reason
  • key dependency
  • key risk
  • expected result
  • consequence of delay
  • work unlocked
  • owner readiness

Human Priority Approval

Martyn, HeadOffice or another authorised role may approve or override the recommendation.

Any material override should record:

  • previous recommendation
  • approved priority
  • override reason
  • approving authority
  • date

Priority Categories

Approved operational categories are:

  • 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

Daily Work Operating Model

Daily Review Purpose

The daily review determines what valid work should happen today.

It must not become a broad planning meeting that repeatedly reopens settled strategy.

Daily Inputs

The daily review should consider:

  • current save points
  • unfinished work from the prior day
  • Must Do Today tasks
  • active blockers
  • tests awaiting action
  • failed tests
  • HeadOffice decisions required
  • version warnings
  • newly approved changes
  • owner availability
  • available working time
  • near-future work that may become ready

Daily Output

The daily output should show:

  • current main project
  • current main workstream
  • Martyn’s priority tasks
  • M’s priority tasks
  • tests requiring action
  • blockers requiring removal
  • decisions requiring approval
  • work that should not be touched
  • next valid task
  • tasks likely to become ready next
  • material changes since the last review
  • version or dependency warnings

Daily Task Limits

The system should avoid unrealistic daily plans.

Daily selection should account for:

  • task size
  • available time
  • interruption risk
  • context switching
  • dependency uncertainty
  • testing time
  • review time
  • corrective work
  • existing unfinished tasks

A smaller realistic task list is preferred over a large aspirational list.

Weekly Review Operating Model

Weekly Review Purpose

The weekly review confirms overall project movement and future readiness.

Weekly Inputs

The weekly review should consider:

  • projects advanced
  • projects stalled
  • workstreams completed
  • tasks completed
  • tasks reopened
  • blockers added
  • blockers resolved
  • tests passed
  • tests failed
  • changes approved
  • decisions made
  • version changes
  • SIT findings
  • Kaizen findings
  • next week readiness
  • capacity concerns

Weekly Output

The weekly report should include:

  • key outcomes
  • meaningful movement
  • projects at risk
  • unresolved blockers
  • failed tests
  • decisions required
  • version concerns
  • next week priorities
  • work that should remain deferred
  • major lessons
  • required escalations

Project Review Operating Model

Every active project should be reviewed at a frequency appropriate to its importance and pace.

The project review must confirm:

  • objective remains valid
  • owner remains correct
  • project status remains accurate
  • priority remains justified
  • workstreams remain relevant
  • tasks remain current
  • dependencies remain accurate
  • blockers remain visible
  • decisions are recorded
  • changes are reflected
  • testing state is correct
  • version state is current
  • save point is current
  • next valid action is known

A project must not remain Active when there is no active or ready work.

Dependency Operating Model

Dependency Identification

Dependencies should be identified during:

  • project setup
  • workstream setup
  • task setup
  • change review
  • meeting review
  • testing
  • version review
  • SIT review
  • Kaizen review
  • project review

Dependency Classification

Dependencies may be classified as:

  • task dependency
  • project dependency
  • Brain dependency
  • owner dependency
  • decision dependency
  • test dependency
  • page dependency
  • plugin dependency
  • schema dependency
  • Canon dependency
  • external dependency
  • access dependency
  • evidence dependency

Dependency Review

Each dependency should confirm:

  • dependent item
  • required item
  • owner
  • status
  • expected resolution
  • delay impact
  • work unlocked
  • escalation need

A dependency should be marked Satisfied only when the required condition is genuinely met.

Blocker Operating Model

Blocker Identification

A blocker exists when work cannot validly proceed.

Common blocker sources include:

  • missing decision
  • unavailable owner
  • failed test
  • missing access
  • missing data
  • missing specification
  • unresolved dependency
  • version mismatch
  • broken plugin
  • broken schema
  • unclear acceptance criteria
  • conflicting direction
  • missing evidence
  • unresolved SIT finding

Blocker Response

The blocker process is:

Blocker Identified

To

Impact Assessed

To

Owner Assigned

To

Resolution Action Defined

To

Escalation Need Checked

To

Resolution Attempted

To

Evidence Recorded

To

Blocker Resolved Or Accepted

Blocked tasks must not be shown as ready.

Change And Decision Operating Model

Decision Capture

Material decisions must be recorded when they affect:

  • project scope
  • project priority
  • ownership
  • build order
  • acceptance criteria
  • system architecture
  • Brain authority
  • plugin behaviour
  • schema structure
  • testing
  • version alignment
  • project continuation
  • project cancellation

Change Review

Every approved change must trigger an impact review.

The review should ask:

  • which projects are affected
  • which workstreams are affected
  • which tasks are invalid
  • which tasks must be added
  • which priorities change
  • which dependencies change
  • which pages change
  • which plugins change
  • which schemas change
  • which versions change
  • which tests become invalid
  • which retests are required
  • whether a new save point is required
  • whether HeadOffice must review

Work should not continue under an outdated plan after a material approved change.

Meeting Operating Model

Meeting Intake

A meeting record should capture:

  • title
  • date
  • attendees
  • notes
  • recording where applicable
  • related projects
  • related Brains
  • source owner

Action Extraction

Project Manager Brain may extract proposed:

  • decisions
  • actions
  • owners
  • due dates
  • blockers
  • risks
  • changes
  • cancellations
  • follow-up items
  • unresolved questions

Human Review

Extracted items must be reviewed before approval.

The reviewer should classify each item as:

  • Approved Decision
  • Approved Action
  • Approved Change
  • Approved Risk
  • Approved Blocker
  • Question
  • Suggestion
  • Rejected
  • Duplicate
  • Already Recorded
  • No Action Required

Approved Application

Approved meeting items may then:

  • create a task
  • update a task
  • change an owner
  • create a decision
  • create a change
  • create a blocker
  • create a dependency
  • update project status
  • trigger testing
  • trigger version review
  • trigger escalation

Testing Operating Model

Test Planning

Testing should be defined before final acceptance.

A test must state:

  • what is being tested
  • why it is being tested
  • expected result
  • test method
  • test owner
  • required evidence
  • acceptance effect

Test Execution

The test owner records:

  • actual result
  • evidence
  • pass or fail
  • failure details
  • corrective action required
  • retest requirement

Failed Tests

A failed test must:

  • remain visible
  • prevent acceptance where relevant
  • create or link corrective work
  • define retest requirements
  • update project or task state
  • update the save point

A failed test must not be removed merely because the implementation was changed later.

The retest should provide the new result.

Acceptance Operating Model

Acceptance Review

Acceptance should confirm:

  • defined criteria were met
  • required tests passed
  • required evidence exists
  • dependencies are satisfied
  • required documentation is updated
  • required versions are recorded
  • required MCR updates are complete
  • no unresolved critical SIT finding remains
  • no unresolved critical blocker remains

Acceptance Outcomes

The approved outcomes are:

  • Accepted
  • Accepted With Conditions
  • Rejected
  • Changes Required
  • Retest Required
  • Escalation Required

Project closure should require all critical acceptance conditions to be resolved.

Save-Point Operating Model

Save-Point Timing

A save point should be created or updated when:

  • a meaningful build stage is completed
  • a plugin version changes
  • a schema changes
  • a major test completes
  • a major change is approved
  • a workstream completes
  • a project pauses
  • a project is handed over
  • a project is closed
  • a new session needs a trusted continuation point

Save-Point Content

The save point should include:

  • project name
  • date
  • active version
  • completed work
  • current active work
  • testing state
  • blockers
  • dependencies
  • deferred work
  • risks
  • recent decisions
  • recent changes
  • next valid action
  • work that must not be touched
  • required evidence links

The save point must be concise enough to use but complete enough to restore the project state.

Version Alignment Operating Model

Version Review Events

Version alignment should be reviewed when:

  • a plugin version changes
  • a schema version changes
  • Canon changes
  • an operational workflow changes
  • a handoff changes
  • a dependent Brain changes
  • testing exposes incompatibility
  • SIT identifies drift
  • a project reaches acceptance
  • a project is handed over

Version Review Questions

The review should ask:

  • what changed
  • which version is now active
  • which systems depend on it
  • whether dependencies remain compatible
  • whether documentation is current
  • whether tests remain valid
  • whether retesting is required
  • whether another Brain must update
  • whether the save point remains valid

Version Alignment States

Approved states are:

  • Aligned
  • Review Required
  • Update Required
  • Retest Required
  • At Risk
  • Misaligned
  • Blocked By Mismatch
  • Unknown

Kaizen Operating Model

Kaizen Intake

Kaizen may submit:

  • repeated friction
  • repeated delay
  • duplicated effort
  • recurring test failure
  • workflow inefficiency
  • handoff failure
  • avoidable manual work
  • process improvement opportunity

Kaizen Review

Project Manager Brain should assess:

  • frequency
  • impact
  • effort
  • urgency
  • risk reduction
  • work unlocked
  • current priority conflict
  • readiness
  • ownership

Approved Kaizen work may become:

  • task
  • workstream
  • improvement project
  • process change
  • test requirement
  • future work item

SIT Operating Model

SIT Intake

SIT may submit findings concerning:

  • false completion
  • missing evidence
  • unreliable implementation
  • broken workflow
  • drift
  • inconsistent versions
  • weak testing
  • unresolved risk
  • rescue need

SIT Finding Handling

A valid SIT finding must:

  • be recorded
  • be linked to affected work
  • receive severity
  • receive owner
  • receive corrective action
  • receive retest requirement where applicable
  • affect acceptance where relevant
  • remain visible until resolved or formally accepted

Critical SIT findings must be escalated.

HeadOffice Operating Model

HeadOffice Inputs

HeadOffice may provide:

  • strategic direction
  • portfolio priority
  • project approval
  • project cancellation
  • major scope changes
  • risk acceptance
  • resource decisions
  • cross-Brain authority decisions
  • escalation outcomes

Project Manager Brain Outputs To HeadOffice

Project Manager Brain should provide:

  • project health
  • priority conflicts
  • major blockers
  • failed critical tests
  • version misalignment
  • strategic decisions required
  • resource conflicts
  • project viability concerns
  • consequences of delay
  • recommended action

HeadOffice should receive only the level of detail needed for decision and control.

Operations Brain Operating Model

Project Manager Brain should use Operations Brain for:

  • execution sequencing
  • handoff design
  • process continuity
  • dependency coordination
  • bottleneck analysis
  • workflow stability
  • operational timing

Operations Brain outputs should influence execution design but should not create unapproved strategic priorities.

Specialist Brain Operating Model

Specialist Brains are responsible for:

  • specialist analysis
  • specialist execution
  • specialist deliverables
  • specialist testing requirements
  • specialist evidence
  • specialist blockers
  • specialist handoffs
  • specialist version changes

Project Manager Brain is responsible for:

  • recording the work
  • coordinating timing
  • tracking dependencies
  • tracking status
  • coordinating testing
  • coordinating acceptance
  • reporting outcomes
  • preserving save points

Escalation Operating Model

Escalation Triggers

Escalation should occur when:

  • authority is unclear
  • priorities conflict
  • critical work is blocked
  • critical testing fails
  • SIT identifies serious failure
  • version mismatch threatens operations
  • resources are insufficient
  • project scope changes materially
  • evidence is disputed
  • project viability is uncertain
  • work proceeds without authority
  • specialist Brains disagree materially
  • delay consequences are significant

Escalation Format

Each escalation should state:

  • issue
  • project
  • impact
  • urgency
  • evidence
  • options
  • recommendation
  • decision required
  • consequence of no decision

Escalations must not be vague complaints.

Reporting Operating Model

Daily Report

The daily report should focus on:

  • current main focus
  • today’s valid tasks
  • blockers
  • tests
  • decisions
  • next actions
  • work unlocked
  • warnings

Weekly Report

The weekly report should focus on:

  • outcomes
  • movement
  • failed work
  • delayed work
  • resolved blockers
  • new blockers
  • test outcomes
  • changes
  • versions
  • next week
  • escalations

Project Status Report

The project report should focus on:

  • objective
  • current phase
  • current save point
  • progress
  • blockers
  • dependencies
  • tests
  • version
  • risks
  • decisions
  • next action

Reporting must remain action-driven.

Archive Operating Model

Projects, workstreams and tasks may be archived when:

  • completed and no longer active
  • cancelled
  • replaced
  • no longer operationally relevant
  • retained for historical reference

Archived records must remain readable and linked.

Archived records should not receive ordinary edits.

Reactivation should require explicit action and reason.

Initial Human Roles

Martyn

Primary responsibilities:

  • approve projects
  • confirm priorities
  • approve major changes
  • approve decisions
  • review daily work
  • accept critical work
  • resolve escalations
  • control settings
  • confirm HeadOffice direction

M

Primary responsibilities:

  • execute assigned work
  • update tasks
  • raise blockers
  • provide evidence
  • submit work for testing
  • respond to failed tests
  • contribute to project updates
  • confirm implementation state

Project Manager Brain

Primary responsibilities:

  • organise records
  • coordinate execution
  • recommend priorities
  • identify dependencies
  • track blockers
  • prepare reports
  • identify missing information
  • maintain save points
  • recommend next actions
  • flag risks and misalignment

AI must not be treated as the accountable human owner of critical work.

First Operational Validation

The first operational validation project is:

Content Brain Operational Build

The operating model must prove that it can:

  • create the project
  • record the objective
  • record the current plugin version
  • record the current save point
  • create workstreams
  • create tasks
  • assign owners
  • record completed work
  • record active work
  • record archived work
  • record testing state
  • record blockers
  • record dependencies
  • record deferred work
  • record decisions
  • identify next valid action
  • generate a daily view
  • generate a project report
  • confirm version alignment

The Project Manager Brain operating model should not be considered validated until the Content Brain project accurately matches operational reality.

Initial Operating Limits

During the first build:

  • all critical changes require human review
  • all project approvals require human approval
  • all meeting actions require human approval
  • all acceptance decisions require human approval
  • all priority overrides must be recorded
  • all version changes must be confirmed
  • all permanent deletions remain prohibited unless explicitly authorised
  • all AI recommendations remain advisory
  • no autonomous project closure is allowed
  • no client-facing operations are enabled
  • no unsupported deadlines are generated

Operating Model Success Criteria

The Operating Model is functioning when:

  • daily work is clear
  • tasks are specific
  • owners are clear
  • priorities are explainable
  • dependencies are visible
  • blockers are visible
  • meetings create controlled actions
  • changes update affected work
  • tests remain linked
  • acceptance requires evidence
  • save points remain current
  • version alignment is visible
  • HeadOffice receives useful escalations
  • future work remains controlled
  • specialist authority remains intact
  • the next valid action is known

Operating Model Failure Conditions

The Operating Model is failing when:

  • task lists become vague
  • records fall behind reality
  • owners are unclear
  • priorities become arbitrary
  • blocked work is shown as active
  • meetings create unreviewed changes
  • failed tests are hidden
  • acceptance lacks evidence
  • save points are outdated
  • version changes are ignored
  • future work overwhelms today’s priorities
  • HeadOffice must manually reconstruct project state
  • Project Manager Brain begins making strategy
  • specialist Brains lose authority
  • AI actions bypass human approval

MWMS System Change Log

Version: 1.0

Date: 2026-06-23

Author: HeadOffice

Change

Created the initial Project Manager Brain Operating Model.

Defined how projects enter the system, how work is structured, how priorities are approved, how daily and weekly reviews operate, how dependencies and blockers are managed, how meeting actions are reviewed, how testing and acceptance are controlled, how save points are maintained and how version alignment is monitored.

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

Established Content Brain Operational Build as the first live validation project.

Change Impact Declaration

This change establishes the practical operating behaviour required to run Project Manager Brain.

The change does not authorise autonomous strategy, autonomous project approval, autonomous meeting action approval or autonomous completion acceptance.

The change requires human review for critical project, priority, change, testing, acceptance and version decisions.

Pages Created

Project Manager Brain Operating Model

Pages Updated

None

Pages Deprecated

None

Standalone Pages Not Created

Project Manager Brain Workflow Map

Project Manager Brain Page Registry

Project Manager Brain Daily Review Protocol

Project Manager Brain Weekly Review Protocol

Project Manager Brain Project Intake Standard

Project Manager Brain Save Point Standard

The Workflow Map and Page Registry remain scheduled as separate foundation pages.

The remaining pages are not created at this stage and should only be introduced if the operational build demonstrates a clear need.

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 architecture has been converted into a practical operating model.

MWMS now has a defined method for moving approved projects from intake through prioritisation, execution, testing, acceptance, save-point control, version alignment and reporting while preserving human authority and specialist Brain ownership.

END OF FULL FILE OUTPUT