MWMS AI Work Session Closure And Knowledge Commitment Protocol

Document Type: Protocol
Status: Active
Version: v1.0
Authority: HeadOffice
Owning Brain: HeadOffice Brain
Parent: HeadOffice Brain
Applies To: All MWMS Brains, AI Employees, Brain Rooms, Course Absorption Sessions, Development Sessions, Research Sessions, Operational Work Sessions, Client Workflows And Human-AI Collaboration Sessions
Last Reviewed: 2026-06-17

Purpose

The MWMS AI Work Session Closure And Knowledge Commitment Protocol defines how every meaningful MWMS work session must be formally closed, summarised, committed to durable knowledge and prepared for clean continuation.

The protocol ensures that completed work, decisions, lessons, corrections, unresolved issues, current save points and next actions are not lost when a conversation, task, agent run or work session ends.

It establishes a mandatory closure process that converts temporary session activity into durable operational memory.

The protocol exists to prevent:

session amnesia
repeated work
lost decisions
missing save points
forgotten corrections
unclear next steps
inconsistent project history
poor handoffs
duplicated pages
drift between sessions
reliance on temporary chat context
unfinished work being mistaken for completed work

Core Principle

A work session is not complete merely because activity has stopped.

A work session is complete only when its durable outcomes have been:

identified
classified
verified
committed
routed
recorded
made recoverable for the next session

Temporary conversation is not durable organisational knowledge.

Every meaningful MWMS session must end with a formal knowledge-commitment event.

Scope

This protocol applies to:

Canon sessions
Brain sessions
course absorption sessions
content review sessions
research sessions
campaign review sessions
development sessions
Supabase sessions
WordPress sessions
plugin sessions
Content Brain sessions
Affiliate Brain sessions
AIBS Brain sessions
PPL Brain sessions
HeadOffice sessions
SIT sessions
AI Employee work sessions
Brain Room workflows
client work
M handoffs
multi-agent workflows
long-running tasks
interrupted work sessions
sessions ending because of time, fatigue, limits or blockers

This protocol applies whether the session is:

completed successfully
partially completed
paused
blocked
abandoned
escalated
transferred
interrupted unexpectedly

Definitions

Work Session

A bounded period of activity involving one or more humans, AI models, AI Employees, tools, Brains or systems working toward a defined outcome.

Session Closure

The formal process of ending the session and recording its durable state.

Knowledge Commitment

The controlled act of saving verified session outcomes into the appropriate durable MWMS destination.

Session Summary

A concise, structured record of what occurred during the session.

Save Point

The exact current state from which the next session must resume.

Open Thread

A task, decision, issue or dependency that remains unresolved.

Durable Outcome

Information that will still matter in future sessions.

Transient Activity

Conversation, exploration, speculation or temporary detail that does not need to become permanent MWMS knowledge.

Commitment Destination

The approved Brain page, registry, decision record, session log, task record, system log, external knowledge engine or other durable location where information is saved.

Closure Trigger

An event that requires the closure protocol to begin.

Mandatory Closure Triggers

The protocol must begin when:

the user says the session is finished
the user says they are stopping for the day
a course block is completed
a task reaches completion
a session is paused
work is blocked
the user requests tomorrow’s tasks
the user asks what was completed
the user asks for the current save point
a Brain Room task ends
work is handed to M
an AI Employee finishes a run
a high-risk action is completed
a system change is made
the session reaches a natural stopping point
the tool or model context is nearing practical limits
the task must move to another project or session
unresolved work must be resumed later

Closure must not depend only on the user remembering to ask.

Where the workflow permits, the responsible AI Employee should detect the need for closure.

Session Closure States

Every session must be assigned one final state.

Completed

The session goal was achieved and all required outputs were verified.

Partially Completed

Some planned work was completed, but additional work remains.

Paused

Work was intentionally stopped at a known recoverable point.

Blocked

Work cannot continue because of a missing dependency, error, authority issue, unavailable tool, missing evidence or external constraint.

Escalated

The session ended because the task requires a higher authority, specialist reviewer or human decision.

Abandoned

The planned work was intentionally discontinued and should not be resumed unless reauthorised.

Interrupted

The session ended unexpectedly before normal closure could occur.

The closure state must not falsely describe partial work as completed.

Closure Sequence

Every formal closure must follow this sequence:

Confirm the session objective.
Review work performed.
Separate completed work from attempted work.
Record decisions.
Record corrections and user instructions.
Record lessons learned.
Identify unresolved issues.
Define the exact save point.
Define the next valid action.
Determine commitment destinations.
Save or prepare durable records.
Verify commitment.
issue a concise closure confirmation.

Step One — Confirm The Session Objective

The closure record must state what the session was intended to achieve.

The objective must be taken from:

the user’s stated task
the session start protocol
the approved task record
the Brain Room assignment
the current course block
the current development goal
the applicable save point

The objective must not be rewritten after the fact to make the session appear more successful.

Step Two — Review Work Performed

The closure process must review the full session and identify:

files reviewed
pages inspected
pages created
pages updated
pages rejected
frameworks absorbed
tools used
systems touched
tests performed
errors encountered
decisions proposed
decisions approved
outputs delivered
actions executed
actions not executed

The closure review must consider the entire session, not merely the last few messages.

Step Three — Separate Completed Work From Attempted Work

The closure record must distinguish:

completed and verified
completed but not verified
drafted
discussed
proposed
attempted
failed
deferred
rejected
not started

Discussion must not be recorded as completion.

A proposed page is not a created page.

A drafted output is not a published page.

A command suggested is not a command executed.

A tool call attempted is not a successful system change.

Step Four — Record Decisions

Every material decision made during the session must record:

decision
reason
authority
status
affected Brain or system
implementation consequence
whether a formal decision record is required

Examples include:

create a new framework
update an existing page
reject duplicate material
defer an item
stop work
change priority
alter scope
assign ownership
preserve a naming rule
approve a workflow
reject a tool or architecture

Decisions must not be inferred where the user did not approve them.

Step Five — Record Corrections And User Instructions

Any user correction that affects future work must be captured.

This includes:

naming corrections
canonical Brain names
formatting rules
output rules
source-of-truth rules
project boundaries
ownership rules
workflow rules
prohibited actions
parent page rules
versioning rules
task priority corrections
user preference corrections
corrections to claims about what exists

Corrections must be treated as high-value session outcomes because they prevent repeated drift.

Where appropriate, corrections must update:

memory
Canon
enforcement pages
operating guides
task instructions
decision records
page registries

Step Six — Record Lessons Learned

Lessons learned must capture non-obvious insights from the session.

A valid lesson should explain:

what happened
why it mattered
what was learned
how future work should change

Lessons may include:

a workflow that failed
a tool limitation
a source-of-truth error
an ineffective page structure
a successful shortcut
a repeated drift pattern
a hidden dependency
a useful architecture
a quality-control insight
a better routing decision

Routine activity should not be inflated into a lesson.

Step Seven — Identify Unresolved Issues

Every open issue must record:

issue
current status
blocker
owner
dependency
risk
next action
resume condition

Open issues must not be buried inside general narrative.

They must be visible enough for the next session to resume without rediscovery.

Step Eight — Define The Exact Save Point

The save point must state the exact current position.

A valid save point should answer:

what was last completed
what remains incomplete
which page, block, lesson, screen, record or file is next
which system state must remain unchanged
which work must not be repeated
which rules must be applied
what the first action of the next session is

Examples include:

paused after lesson 088
next lesson is 089
page draft completed but not published
plugin installed but screen validation incomplete
record created but Supabase sync not confirmed
course block reviewed and three pages remain to output
framework created and registry updates remain outstanding

A vague save point such as “continue tomorrow” is not compliant.

Step Nine — Define The Next Valid Action

The closure record must identify the single best next action.

The next action must:

start from the save point
avoid repeating completed work
respect current project scope
follow Canon
preserve system safety
be specific enough to execute immediately
not create unnecessary options
not introduce unrelated work

Where multiple tasks remain, they may be sequenced, but one first action must be clear.

Step Ten — Determine Commitment Destinations

Session outcomes must be routed to the correct durable destination.

Possible destinations include:

HeadOffice Brain
applicable Brain Canon
Brain Page Registry
MWMS Canon Index
decision record
system change log
course absorption decision registry
session history
project save point
task record
AI Employee record
SIT log
lessons learned page
improvement log
external knowledge engine
client record
M handoff file

Not every session outcome belongs in every destination.

The closure process must avoid unnecessary duplication.

Step Eleven — Save Or Prepare Durable Records

The responsible AI process must either:

save the record directly where authorised
prepare the exact full page output
create a draft
create a task
update a registry
create a session summary
provide the user with the exact content to save
record that commitment is pending

Where direct system access is unavailable, the closure record must say that the output was prepared but not committed.

Prepared content must not be described as saved.

Step Twelve — Verify Commitment

Knowledge commitment is complete only when the destination is verified.

Verification may include:

page exists
page update is visible
registry contains the page
file exists
task exists
record exists
source was added
system log was written
database row exists
draft exists
user confirms publication
output was delivered in full file format

Where commitment cannot be verified, status must remain:

Pending Commitment
Prepared But Not Saved
Save Not Verified
Publication Not Confirmed
Registry Update Outstanding

Step Thirteen — Issue Closure Confirmation

The final closure confirmation must state:

session state
what was completed
what remains
save point
next action
commitment status

The confirmation should be concise.

It must not replace the durable closure record.

Required Session Summary Structure

Every formal session summary should use the following structure.

Session Summary

Date:

Project:

Brain:

Session Type:

Session Objective:

Session State:

Work Completed:

Decisions Made:

Pages Created:

Pages Updated:

Pages Rejected Or Deferred:

Systems Or Tools Touched:

Corrections And Rules Confirmed:

Key Lessons:

Open Threads:

Current Save Point:

First Action Next Session:

Commitment Destinations:

Commitment Status:

Risks Or Warnings:

This structure may be expanded where a Brain has stricter requirements.

Course Absorption Closure Requirements

For course absorption sessions, closure must additionally record:

course name
block or lesson range
files reviewed
duplicates ignored
material absorbed
material rejected
pages created
pages to update later
items parked
next course block
whether the course or block is complete
Course Absorption Decision Registry impact

A course block must not be marked complete until:

all files in the block were reviewed
duplicate files were identified
create/update/hold/reject decisions were made
page outputs were completed or explicitly queued
the next action is recorded

Development Session Closure Requirements

For development sessions, closure must additionally record:

environment
site
system
visible screen or file last used
code or configuration changed
test result
deployment status
rollback state
known error
exact next screen or command
M involvement
prohibited areas
whether production was affected

Development closure must not occur inside the course absorption project except to record that the work belongs elsewhere.

Brain Session Closure Requirements

For Brain sessions, closure must additionally record:

owning Brain
parent page
pages reviewed
pages created
pages updated
registry impact
Canon impact
Brain authority impact
cross-Brain routing
system change log requirement

AI Employee Session Closure Requirements

For AI Employee work, closure must additionally record:

AI Employee name
assigned role
task ID
authority level
tools used
data accessed
actions performed
review status
escalation status
output location
performance issues
next assignment

An AI Employee must not close its own high-risk task as approved where independent review is required.

Memory Classification Rules

Session outcomes must be classified before commitment.

Governance Memory

Includes:

Canon rules
authority
ownership
mandatory protocols
naming rules
system-wide restrictions

Project Memory

Includes:

current workstream
save point
goals
dependencies
blockers
sequencing
project-specific decisions

Operational Memory

Includes:

active status
current task
system state
page publication status
recent implementation detail

User Preference Memory

Includes:

confirmed workflow preferences
formatting preferences
communication rules
output requirements

Reference Memory

Includes:

external tools
source files
useful resources
system references

Temporary Detail

Includes:

short-lived discussion
speculative ideas
abandoned branches
irrelevant conversational detail

Temporary detail must not be committed merely because it appeared in the session.

Durability Test

Before saving information, the AI must ask:

Will this matter in a future session?
Will forgetting this cause repeated work or drift?
Is this verified?
Does it have an owner?
Does it have a proper destination?
Does it replace or update existing knowledge?
Is it sensitive?
Does it require approval?
Is it already stored elsewhere?

If the answer does not support durable value, the information should not be committed.

Duplicate Prevention

Before creating a new session record, memory or page, the system must check whether:

the information already exists
an existing record should be updated
the same save point was already recorded
the same decision was already logged
the same lesson already exists
a page with the same purpose already exists
the same course block was already absorbed

Where an existing record exists, update it rather than create unnecessary duplication.

Knowledge Commitment Authority

The authority to commit knowledge depends on the destination.

AI Employees may automatically commit low-risk operational records where authorised.

Brain-level frameworks, Canon, ownership, authority, system standards and sensitive records require the appropriate approval.

HeadOffice governs:

global commitments
cross-Brain commitments
Canon promotion
ownership changes
authority changes
system-wide closure rules

SIT may block invalid commitment.

Data Brain governs storage and retrieval integrity.

The applicable owning Brain governs subject-matter correctness.

Unverified Knowledge Rules

Unverified information must be labelled.

Approved labels include:

Unverified
Draft
Proposed
Pending Review
Pending User Confirmation
Historical
Superseded
Rejected
Assumption
External Claim

Unverified material must not be silently committed as authoritative MWMS truth.

Interrupted Session Recovery

Where normal closure was not completed, the next session must begin with recovery.

Recovery must:

inspect available conversation history
inspect task records
inspect created files or pages
identify the last verified action
distinguish intended work from executed work
reconstruct the save point
identify missing commitment
create a recovery summary
resume only after the state is clear

The AI must not guess what was completed.

Long-Running Task Closure

Long-running tasks may produce interim closure records.

An interim closure must record:

current stage
completed sub-tasks
pending sub-tasks
current artifacts
errors
last successful checkpoint
restart procedure
monitoring status
owner
expected next event

Interim closure does not mark the full task complete.

Daily Work Closure

At the end of a workday, the closure record should clearly state:

tasks planned
tasks completed
additional work completed
unfinished work
what slowed progress
current save point
tomorrow’s first task
do-not-touch areas
status that must remain unchanged

Daily task review must not imply that doing more than planned is a failure.

The closure record should reflect actual progress honestly.

Handoff Requirements

Where work transfers to another human, AI Employee, Brain or project, the handoff must include:

objective
current state
completed work
open work
files or pages
applicable rules
decisions
known risks
prohibited actions
exact next action
authority required
acceptance criteria

The receiving party should not need to rediscover basic context.

M Handoff Rules

Where work is handed to M:

only approved development work may be transferred
the task must be complete enough to execute
scope must be bounded
current system state must be stated
do-not-touch areas must be explicit
success criteria must be clear
files and pages must be identified
authority must be stated
the task must belong to the correct project
course absorption work must not be transferred as development work

Failure And Error Recording

The closure record must include material failures.

A failure record should state:

what failed
exact stage
impact
whether data changed
whether rollback occurred
whether the issue persists
next recovery step
owner
escalation requirement

Failures must not be omitted to make the session appear cleaner.

User Correction Priority

User corrections take priority over model assumptions.

Where the user corrects the AI during a session, closure must preserve:

what the AI got wrong
the correct rule or fact
future application
whether memory or Canon requires update
whether prior outputs may be affected

Repeated corrections should trigger an enforcement review.

Closure Quality Standard

A compliant closure must allow a new authorised person or AI Employee to resume the work without needing the user to explain the session again.

The closure is insufficient if the next session still requires asking:

what were we doing
what was completed
where did we stop
what page is next
what rule applies
what should not be repeated
what system state exists
what the user already approved

Relationship To External Knowledge Systems

Session summaries may be committed to an external knowledge engine.

The knowledge engine may support:

semantic retrieval
cross-session history
project recall
decision search
lesson retrieval
multi-agent continuity

The external knowledge engine must not become the sole authority.

Session summaries must remain subordinate to:

active Canon
current decision records
current registries
verified system state
current user instructions

Relationship To AI Work Session Persistence

This protocol governs formal session closure.

The MWMS AI Work Session Persistence Standard governs continuity and persistence during and across active work.

The distinction is:

persistence keeps work available
closure determines what becomes durable organisational knowledge

Relationship To HeadOffice Brain

HeadOffice Brain owns:

closure governance
cross-Brain commitment
system-wide session standards
handoff requirements
decision preservation
unresolved authority questions
project boundary enforcement

Relationship To Data Brain

Data Brain governs:

storage structure
metadata
source identity
indexing
retrieval
duplicate detection
commitment integrity
history preservation

Relationship To SIT Brain

SIT Brain may:

detect missing closure
detect false completion claims
detect missing save points
detect unverified commitments
block invalid Canon commitment
detect repeated user corrections
verify registry updates
inspect handoff completeness
log closure failures
require recovery

Relationship To Other MWMS Pages

This protocol operates with:

MWMS AI Work Session Persistence Standard
MWMS External Knowledge Engine And Reasoning Agent Separation Framework
MWMS AI Agent Memory And Context Framework
MWMS AI Employee Handoff Protocol
MWMS AI Documentation Automation Pipeline Framework
MWMS AI Brain Audit And Decay Prevention Framework
MWMS Decision Record System
MWMS Canon Session Protocol
How To Start A Session — MWMS Operating Guide
MWMS Brain Interaction Protocol
MWMS Brain Authority Matrix
MWMS Lessons Learned
MWMS Improvement Log
MWMS System Change Log
MWMS Course Absorption Decision Registry
MWMS Canon Index

Where another page requires a stricter closure, audit or commitment process, the stricter rule applies.

Prohibited Patterns

MWMS prohibits:

ending a meaningful session without a save point
claiming work was saved when it was only drafted
recording discussion as completed work
forgetting user corrections
creating vague “continue tomorrow” notes
repeating completed work because closure was incomplete
committing model speculation as fact
omitting unresolved issues
hiding failures
creating duplicate session memories
creating a new page where an existing page should be updated
using temporary chat history as the only project record
handing off work without current state
marking a course complete before absorption decisions are finished
marking a system change complete without verification
allowing an AI Employee to approve its own high-risk closure
mixing projects during closure
transferring development work into the course absorption environment

Failure Modes Prevented

This protocol is designed to prevent:

lost work
repeated work
session drift
false completion
missing task continuity
broken handoffs
lost user corrections
forgotten blockers
unclear next steps
duplicated pages
abandoned decisions
inconsistent memories
stale project status
unverified system claims
cross-project contamination
incomplete course absorption
missing registry updates
reliance on temporary model context

Minimum Compliance Standard

A session is compliant only when:

its objective is identified
its final state is assigned
completed work is distinguished from attempted work
material decisions are recorded
user corrections are recorded
open threads are identified
an exact save point exists
the first next action is defined
durable outcomes have destinations
commitment status is honest
verification status is visible
the next session can resume without rediscovery

Drift Protection

No Brain, AI Employee or workflow may weaken this protocol by:

treating conversation history as sufficient closure
omitting save points
using vague next steps
hiding failed work
claiming unverified commitment
removing user corrections
recording drafts as published
skipping closure for speed
creating duplicate knowledge
allowing unresolved work to disappear
changing project scope during closure
marking work complete because the session ended

Any exception must be:

explicitly authorised
recorded
time-bounded
recoverable
reviewable by HeadOffice and SIT Brain

Architectural Intent

MWMS is intended to compound intelligence across every work session.

Compounding requires more than doing work.

It requires that each session leaves behind:

verified outputs
durable decisions
recoverable state
clear next actions
preserved corrections
reusable lessons
accountable ownership
traceable commitments

Without formal closure, MWMS loses part of the value created during every session.

With formal closure, each session strengthens the system that follows it.

Final Rule

No meaningful MWMS work session is complete until the system can answer:

What did we intend to do?
What did we actually complete?
What did we decide?
What did we learn?
What remains open?
Where exactly did we stop?
What happens next?
What was committed?
What still requires saving or approval?

If those questions cannot be answered, the session remains operationally incomplete.

Source Absorption Basis

This protocol was created from the AI Automations by Jack course block covering the WrapUp Skill, NotebookLM session-history workflows, automatic session summaries, durable memory updates and cross-session knowledge continuity.

The source material defined a closure sequence that reviews decisions, completed work, learnings, open threads and user preferences before generating a dated session summary and pushing it into long-term knowledge storage.

The wider block also established the use of a persistent knowledge repository that can be consulted by multiple AI work surfaces, allowing session history to become retrievable context rather than remaining trapped inside one conversation.

Change Log

Version: v1.0
Date: 2026-06-17
Author: HeadOffice
Change: Initial protocol created from AI Automations by Jack course absorption.
Change Impact Declaration: Establishes mandatory work-session closure, save-point capture, durable knowledge commitment and clean continuation requirements across MWMS.

Pages Created

MWMS AI Work Session Closure And Knowledge Commitment Protocol

Pages Updated

None in this output

Pages Deprecated

None

Standalone Pages Not Created

MWMS NotebookLM WrapUp Skill
MWMS Session Summary Skill
MWMS AI Brain Notebook Workflow
MWMS Daily Chat Wrap-Up Page
MWMS Claude Session Memory Protocol

Registries Requiring Update

HeadOffice Brain Page Registry
MWMS Canon Index
MWMS Course Absorption Decision Registry

Canon Version Update Required

No immediate HeadOffice Brain Canon version change required unless this protocol is promoted into mandatory system-wide session enforcement.

Change Log Entry Required

Strategic Absorption Result

MWMS gains a formal closure discipline that converts temporary session activity into durable organisational intelligence, preserves exact save points, prevents repeated work and enables clean continuation across humans, Brains, AI Employees, tools and projects.

END OF FULL FILE OUTPUT