System: MWMS
Document Type: Framework
Authority Level: MCR Source Of Truth
Status: Active
Version: v1.1
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, MWMS Brain, Brain Room, AI Manager, AI Employee Router, Task Executor Systems, Newsletter Intelligence, Recurring Reports, Routed Actions, HeadOffice Dashboard, Dev Console, AIBS Brain
Parent Page: HeadOffice
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR
Last Reviewed: 2026-06-21
Source / Origin: MWMS Research Synthesis Documentation And Distribution Framework v1.0 and AI Automations by Jack research, client intelligence, fact-checking, multi-model review, source verification, automated reporting, meeting preparation, and evidence distribution material
MWMS Classification: Research Synthesis Framework / Evidence Documentation Framework / Decision Ready Intelligence Framework / Governed Distribution Framework / Research Reporting Standard / Intelligence Delivery Standard
Primary Brain: HeadOffice Brain
Supporting Brains: Research Brain, Data Brain, AIBS Brain, Content Brain, Affiliate Brain, Ads Brain, Finance Brain, Experimentation Brain, Operations Brain, Product Brain, Compliance Brain, Risk Brain
Related Pages: MWMS Deep Search Quality And Observability Framework, MWMS Source Visibility And Evidence Display Standard, MWMS Independent Model Review And Rescue Routing Framework, MWMS AI Documentation Automation Pipeline Framework, MWMS Recurring Intelligence And Reporting Pipeline Framework, MWMS AI Schema And Decision Ready Output Framework, MWMS Structured Analysis And Insight Workflow Framework, MWMS Operational Decision Intelligence Framework, MWMS KPI Dashboard And Insight Summary Framework, MWMS AI Output Validation Standard, MWMS Agentic Reporting Standard, MWMS Brain Routing Rule, MWMS Brain To Brain Request Protocol
Purpose
The purpose of this document is to define the MWMS Research Synthesis Documentation And Distribution Framework.
This framework explains how MWMS moves intelligence from raw source material into a finished, validated, documented, decision-ready, and safely distributed output.
MWMS does not only need to collect information.
MWMS needs to turn information into:
usable research
checked findings
clear synthesis
structured documentation
decision-ready reports
routed actions
safe internal distribution
future client-ready deliverables
proof of system value
traceable recommendations
reusable organisational intelligence
The full delivery chain is:
Request → Research → Evidence → Verification → Synthesis → Documentation → Validation → Distribution → Review → Logging → Learning
This framework ensures MWMS does not stop at:
“AI created something.”
An output is not complete until it is:
requested for a clear purpose
sourced
checked
synthesised
structured
validated
routed
approved where required
distributed safely
logged
reviewed for usefulness
The goal is to make MWMS intelligence useful, trusted, explainable, actionable, and distributable without creating uncontrolled automation or weak reporting.
Scope
This framework applies to all MWMS workflows where research, analysis, documentation, reporting, evidence, or intelligence must move toward distribution.
This includes:
Newsletter Intelligence reports
Weekly HeadOffice reports
Weekly Kaizen Digests
Course Absorption outputs
MCR page drafts
M developer handoff summaries
Routed Actions summaries
AI Employee outcome reports
AI Employee failure reviews
Structured Analysis reports
Forecasting and Scenario Planning reports
Operational Decision records
KPI dashboard insight summaries
AIBS client report drafts
client intelligence reports
meeting preparation reports
fact-checking reports
competitive research reports
source-backed recommendation reports
multi-model review summaries
future client dashboards
future system proof packages
future automated email or report distribution
This framework applies across:
HeadOffice Brain
Brain Room
Newsletter Intelligence
Course Absorption
Opportunity System
Affiliate Brain
Research Brain
Experimentation Brain
Finance Brain
Ads Brain
Content Brain
Operations Brain
Data Brain
Product Brain
Dev Console
AIBS Brain
future client systems
This framework does not authorise automatic external distribution, automated email sending, client delivery, developer build work, or dashboard publication by itself.
It defines the governed pipeline that must exist before distribution becomes operational.
Core Definition
Research is the collection, inspection, and grounding of source material.
Evidence is the specific material that supports, challenges, or contextualises a claim.
Verification is the process of checking whether the evidence is reliable, current, relevant, and sufficient.
Synthesis is the process of turning checked findings into coherent meaning.
Documentation is the process of structuring that meaning into a usable output.
Distribution is the process of sending, routing, publishing, displaying, or handing off that output to the correct destination.
A MWMS output is not truly complete when the first draft is created.
It is complete only when the output has passed the correct review gates and reached the correct destination safely.
Core Principle
The core principle of this framework is:
Intelligence is not finished until it is researched, checked, synthesised, documented, validated, routed, and safely distributed.
MWMS must avoid weak delivery patterns such as:
raw research without interpretation
source lists without findings
summaries without decisions
recommendations without evidence
reports without owners
documentation without validation
dashboard items without action
email or report distribution without approval
client output without review
M handoffs without evidence
recurring reports without usefulness checks
polished reports that hide uncertainty
synthesis that removes credible disagreement
Good intelligence delivery requires the whole pipeline.
Research Synthesis Documentation And Distribution Pipeline
The MWMS delivery pipeline has sixteen stages:
Define The Request And Delivery Purpose
Define The Decision Or Output Need
Identify Source Material
Conduct Research Or Source Review
Clean And Normalise Input
Extract Evidence
Verify Findings
Separate Findings From Interpretation
Synthesise Meaning
Create Documentation
Apply Schema And Format Rules
Validate Output
Approve Distribution
Distribute Or Route
Log Outcome
Capture Learning And Feedback
- Define The Request And Delivery Purpose
Every delivery pipeline must begin with a clear request and purpose.
Examples:
create a HeadOffice weekly report
summarise newsletter intelligence
prepare a course absorption output
prepare an M developer handoff
create a client report draft
prepare a routed action summary
document a new framework
summarise AI Employee outcomes
prepare a proof or demonstration package
verify a business claim
prepare meeting intelligence
Request And Purpose Questions
Ask:
who requested the work
what question must be answered
what decision must be supported
what output is required
who will receive it
how it will be used
what level of evidence is required
what deadline or urgency applies
Delivery Purpose Rule
Do not begin research or distribution until the purpose is clear.
If the purpose is unclear, the output will become generic.
- Define The Decision Or Output Need
The system must define what the final recipient needs to understand or decide.
Possible needs include:
approve
reject
compare
prioritise
fund
build
test
monitor
escalate
communicate
update a framework
assign an action
pause work
request more evidence
Decision Questions
Ask:
what must the recipient know
what must the recipient decide
what action may follow
what evidence threshold applies
what uncertainty is acceptable
what authority is required
what happens if the recommendation is wrong
Rule
Research should be designed backward from the decision or output need.
- Identify Source Material
The source material must be clearly identified.
Sources may include:
course transcript
uploaded PDF
newsletter body
Gmail email
research source
official documentation
offer page
experiment result
finance note
Supabase record
Brain Room message
M update
screenshot
WordPress page list
AI output
failure log
outcome log
client document
dashboard record
meeting transcript
CRM record
support record
website page
regulatory source
public dataset
research paper
Source Identification Rule
Source material must travel through the pipeline.
If the source is lost, the output cannot be properly validated.
Source Record Requirements
Where material decisions depend on a source, preserve:
source title
source type
source location or URL
source owner
publication or event date
retrieval date
source confidence
permission status
relevant claim or finding
- Conduct Research Or Source Review
Research or source review determines what is known, what is useful, what is disputed, and what is missing.
This stage may include:
reading the source
verifying facts
checking source completeness
separating claims from evidence
identifying missing fields
identifying business relevance
identifying related MWMS standards
identifying Brain ownership
identifying risk
identifying whether current verification is needed
finding independent evidence
finding contradictory evidence
checking original sources
Research Rule
Research must support a decision, report, or documented outcome.
Research that creates no usable decision or output should be parked.
- Clean And Normalise Input
Raw input often contains clutter.
Cleaning may include:
removing transcript filler
removing newsletter footer clutter
removing duplicated points
removing irrelevant examples
fixing broken structure
grouping related ideas
marking missing information
marking uncertainty
separating facts from assumptions
identifying source gaps
preserving meaningful dates
preserving speaker or source identity
Normalisation Rule
Dirty input should not move directly into documentation or distribution.
Clean input first.
Cleaning must not alter the substantive meaning of the source.
- Extract Evidence
Evidence extraction identifies the useful information inside the source.
Evidence may include:
facts
examples
patterns
metrics
dates
risks
claims
proof
limitations
assumptions
decision signals
workflow steps
system rules
business implications
supporting evidence
challenging evidence
contextual evidence
Evidence Rule
Evidence must be separated from interpretation.
This protects MWMS from turning weak claims into system truth.
Evidence Record Standard
Important evidence should record:
Evidence ID:
Source ID:
Claim Or Question:
Evidence Summary:
Evidence Location:
Evidence Role:
Evidence Strength:
Source Confidence:
Date Relevance:
Used In Final Output: Yes / No
- Verify Findings
Findings should be checked before synthesis where the output may create material action.
Verification may include:
checking the original source
checking source freshness
checking whether multiple sources are independent
checking calculations
checking claim scope
checking whether evidence supports the exact conclusion
checking for corrections or later updates
checking contradictory sources
checking client or record identity
checking whether the source is authorised for use
Verification Status Values
Use:
Verified
Partially Verified
Unverified
Contradicted
Outdated
Source Unavailable
Review Required
Rule
Unverified material must not silently become a verified finding.
- Separate Findings From Interpretation
The system must distinguish:
Raw Research
Material collected from sources.
Checked Finding
A conclusion directly supported by reviewed evidence.
Interpretation
What the finding may mean for MWMS.
Recommendation
What MWMS may choose to do.
Decision
What an authorised person or Brain has approved.
Action
The work created by the decision.
Rule
Research, findings, interpretation, recommendation, decision, and action must not be collapsed into one section.
A recommendation is not a decision.
An interpretation is not a verified fact.
- Synthesise Meaning
Synthesis turns checked findings into meaning.
Synthesis should answer:
What does this source actually mean?
What is supported?
What is disputed?
What remains unknown?
Why does it matter to MWMS?
Which Brain is affected?
What pattern is emerging?
What decision does this support?
What risk exists?
What opportunity exists?
What should happen next?
What should be ignored?
What should be parked?
What should be escalated?
Synthesis Rule
Synthesis is not summarisation.
A summary says what was said.
Synthesis explains what the checked findings mean, where uncertainty remains, and what should happen next.
Synthesis must not remove credible disagreement merely to create a cleaner narrative.
- Create Documentation
Documentation turns synthesis into a usable format.
Possible documentation outputs include:
MCR page
full page output
HeadOffice report
weekly digest
routed action summary
developer handoff
structured analysis report
scenario plan
decision record
validation report
failure log
outcome log
KPI insight summary
client intelligence report
meeting preparation report
fact-check report
research brief
future client report draft
Documentation Rule
Documentation must match the destination.
A page, dashboard item, developer brief, internal research report, and client report require different formats.
- Apply Schema And Format Rules
Before validation, output should be structured using the correct schema or format.
Examples:
MCR page header format
decision record schema
dashboard card schema
recurring report format
developer handoff format
failure log format
client report format
fact-check report format
research brief format
JSON payload structure
Supabase row fields
Schema And Format Rule
Output must be structured before it can be trusted, routed, or distributed.
Unstructured output should remain draft.
- Validate Output
Validation checks whether the output is safe, supported, complete, and useful.
Validation should check:
request alignment
source grounding
source completeness
claim accuracy
source freshness
source independence where required
missing assumptions
contradictory evidence
schema completeness
field validity
decision readiness
owner clarity
action clarity
risk visibility
confidence calibration
human review requirement
destination match
distribution readiness
Validation Rule
No important output should be distributed before validation.
A polished report can still be wrong, incomplete, misleading, or unsafe.
- Approve Distribution
Distribution must be approved according to risk.
Distribution may require:
Martyn approval
HeadOffice approval
human review
M review
Finance review
Compliance or Risk review
client review
permission gatekeeper approval
validation sign-off
Approval Rule
Distribution is a permissioned action.
Even internal distribution can create confusion if the output is weak, stale, unsupported, or misrouted.
- Distribute Or Route
Distribution means the output moves to its intended destination.
Possible destinations include:
MCR
HeadOffice Dashboard
Brain Room
Newsletter Queue Review
Routed Actions
relevant Brain
M
Dev Console
report archive
Parking System
Rejected Archive
client review queue
client-facing delivery after approval
email distribution after approval
Distribution Rule
Distribution must have:
a destination
an owner
a purpose
a next action
a distribution status
Do not distribute outputs into nowhere.
- Log Outcome
After distribution, MWMS should record what occurred.
Log:
what was distributed
where it went
who received it
who approved it
when it was distributed
what action was created
what decision followed
whether the output was accepted
whether revisions were required
whether distribution failed
Rule
A distributed output should remain traceable after delivery.
- Capture Learning And Feedback
MWMS should record whether the output created value.
Outcome questions:
Was the output used?
Did it create a decision?
Did it create an action?
Did it reduce risk?
Did it help M?
Did it improve HeadOffice visibility?
Did it support a client workflow?
Did it reveal a failure?
Was the recommendation accepted?
Were the sources useful?
Was the report too long or too weak?
Should the pipeline be improved?
Learning Rule
Distribution without outcome review creates hidden waste.
MWMS should learn from what was actually useful.
Research Output Architecture
A strong MWMS research output should separate six sections.
Section One: Request And Decision Context
Include:
original request
request owner
intended recipient
decision required
deadline
risk level
Section Two: Source And Evidence Record
Include:
sources used
source types
source dates
source confidence
supporting evidence
challenging evidence
missing evidence
Section Three: Checked Findings
Include only findings that are directly supported by the reviewed evidence.
Section Four: Interpretation
Explain what the findings may mean for MWMS.
Section Five: Recommendation
State the recommended action, conditions, alternatives, and risks.
Section Six: Decision And Routing
Record:
decision status
decision owner
next action
destination
deadline
review requirement
Rule
The report structure must preserve the boundary between evidence, interpretation, recommendation, and authorised decision.
Executive Summary And Detail Standard
Research outputs for decision-makers should usually contain two levels.
Executive Summary
Provide:
the question
the strongest finding
the recommended action
the main risk
the required decision
Detailed Evidence
Provide:
source record
supporting and challenging evidence
reasoning
assumptions
limitations
alternatives
unresolved issues
Rule
Executive brevity must not remove access to detailed evidence.
Decision Focused Question Standard
Research should answer decision-focused questions.
Weak question:
“What is happening in AI?”
Stronger question:
“Which current AI capability creates the strongest near-term value for the MWMS Content Brain without duplicating Research Brain?”
Weak question:
“Is this tool good?”
Stronger question:
“Does this tool meet the current MWMS use case, authority, security, integration, cost, and maintenance requirements?”
Rule
The quality of synthesis depends heavily on the quality of the research question.
Contradiction And Missing Information Standard
Every material report should identify:
credible conflicting findings
missing sources
unverified assumptions
outdated information
blocked source access
uncertain calculations
unresolved definitions
unknown business impact
The report should not hide these issues.
Possible statuses include:
Resolved
Partially Resolved
Unresolved
Not Material
Requires Specialist Review
Requires Human Decision
Rule
Unknowns must be documented, not filled with plausible AI language.
Original Source Preservation Rule
MWMS should preserve the original source alongside the processed output where practical.
The final documentation should not become the only surviving record.
Original source preservation supports:
verification
future review
correction
reprocessing
dispute resolution
course absorption
auditability
source comparison
Rule
A cleaned summary must not silently replace the original evidence.
Source Link Placement Standard
Where direct source references are useful, place them close to the finding they support.
Do not provide a long source list with no connection to individual claims.
Source references may include:
source name
URL
document title
page or section
timestamp
record ID
retrieval date
Rule
Source visibility should help the reader verify the output.
It should not create citation theatre.
Raw Research And Final Output Separation
Raw research should remain separate from the final distributed output.
Raw research may contain:
unused sources
weak sources
notes
search paths
uncertain claims
duplicates
tool output
exploratory reasoning
The final output should contain:
relevant checked findings
material evidence
important limitations
decision-focused interpretation
approved recommendations
Rule
Final documentation should not expose unnecessary research clutter, but the research trail must remain accessible where required.
Distribution Types
MWMS recognises the following distribution types.
- Internal Review Distribution
Used when output is sent for human review before action.
Examples:
course absorption page draft to Martyn
report draft to HeadOffice
developer handoff draft to Martyn
client report draft to HeadOffice
dashboard item candidate to review queue
Rule
Internal review distribution should clearly say what decision is needed.
- MCR Distribution
Used when validated documentation is saved into MCR.
Examples:
framework page
registry update
operating standard
protocol
checklist
template
copy map
implementation map
Rule
MCR distribution requires:
source-of-truth discipline
duplicate checks
parent checks
authority checks
registry updates where needed
- Brain Distribution
Used when output is routed to a Brain for action or operational copy.
Examples:
Affiliate Brain receives offer evaluation
Research Brain receives research request
Finance Brain receives budget review request
Experimentation Brain receives test candidate
Ads Brain receives campaign signal
Content Brain receives production signal
Rule
Brain distribution must include:
ownership
purpose
source
expected output
authority
deadline where applicable
- Dashboard Distribution
Used when output becomes visible on a dashboard.
Examples:
HeadOffice ACT NOW card
Routed Actions item
risk alert
KPI summary
outcome scorecard
failure trend panel
Rule
Dashboard distribution requires dashboard-readiness validation.
Weak records should not become visible operational truth.
- Developer Distribution
Used when output is sent to M or a future developer.
Examples:
exact developer handoff
file replacement instruction
test steps
bug report
Dev Console support brief
save point summary
Rule
If M would need to guess, developer distribution must stop.
- Email Distribution
Used when output is sent by email or an email-like workflow.
Examples:
internal HeadOffice report email
weekly digest
M task summary
future client report delivery
stakeholder report
Rule
Email distribution requires permission, validation, and approval.
Automated email distribution is not allowed until manual proof and approval gates are proven.
- Client Review Distribution
Used for future AIBS workflows when output goes to a review step before client delivery.
Examples:
client report draft
client KPI summary
client workflow recommendation
client risk summary
client action plan
Rule
Client review distribution must preserve:
privacy
scope
source approval
client isolation
human review
- Client Delivery Distribution
Used when output is delivered to the client.
Examples:
weekly client report
dashboard insight
operational recommendation
workflow summary
Rule
Client delivery is never the default.
Client delivery requires:
validated sources
approved content
permission
human review
clear scope
appropriate evidence visibility
- Decision Record Distribution
Used when research or synthesis results in a formal decision.
The decision record should preserve:
decision question
evidence
recommendation
authority
decision
conditions
owner
date
review point
Rule
A recommendation must not be distributed as if it is an approved decision.
- Research Archive Distribution
Used when the output should be preserved for future reference without immediate action.
Examples:
market research
competitor research
source library
historical report
parked opportunity research
Rule
Archived research must retain:
date
topic
source status
freshness limitations
future review condition
Research To Distribution Record Template
Use this template when MWMS prepares an output for distribution.
Delivery Record Title
Field:
Delivery Record Title:
Original Request
Field:
Original Request:
Request Owner
Field:
Request Owner:
Delivery Purpose
Field:
Delivery Purpose:
Decision Required
Field:
Decision Required:
Output Type
Field:
Output Type:
Recommended values:
MCR Page
HeadOffice Report
Newsletter Digest
Kaizen Digest
Developer Handoff
Routed Action Summary
AI Employee Outcome Report
Failure Review
Structured Analysis Report
Scenario Plan
Decision Record
Dashboard Item
Client Report Draft
Client Dashboard Summary
Email Report
Research Brief
Fact Check Report
Meeting Intelligence Report
Source Material
Field:
Source Material:
Original Source Preserved
Field:
Original Source Preserved: Yes / No
Source Quality
Field:
Source Quality:
Recommended values:
Strong
Usable
Partial
Weak
Conflicting
Unverified
Stale
Unknown
Research Completed
Field:
Research Completed: Yes / No
Verification Status
Field:
Verification Status:
Recommended values:
Verified
Partially Verified
Unverified
Contradicted
Outdated
Source Unavailable
Review Required
Evidence Extracted
Field:
Evidence Extracted:
Supporting Evidence
Field:
Supporting Evidence:
Challenging Evidence
Field:
Challenging Evidence:
Missing Information
Field:
Missing Information:
Checked Findings
Field:
Checked Findings:
Interpretation
Field:
Interpretation:
Recommendation
Field:
Recommendation:
Synthesis Summary
Field:
Synthesis Summary:
Documentation Format
Field:
Documentation Format:
Schema Or Format Applied
Field:
Schema Or Format Applied:
Validation Status
Field:
Validation Status:
Recommended values:
Not Validated
Light Validation Complete
Structured Validation Complete
Operational Validation Complete
High Risk Validation Complete
Failed Validation
Needs Revision
Distribution Type
Field:
Distribution Type:
Recommended values:
Internal Review Distribution
MCR Distribution
Brain Distribution
Dashboard Distribution
Developer Distribution
Email Distribution
Client Review Distribution
Client Delivery Distribution
Decision Record Distribution
Research Archive Distribution
Distribution Destination
Field:
Distribution Destination:
Permission Check Required
Field:
Permission Check Required: Yes / No
Human Approval Required
Field:
Human Approval Required: Yes / No
Human Approval Status
Field:
Human Approval Status:
Recommended values:
Not Required
Required Not Granted
Granted
Denied
Pending
Owner Of Next Action
Field:
Owner Of Next Action:
Next Action
Field:
Next Action:
Stop Conditions
Field:
Stop Conditions:
Logging Required
Field:
Logging Required: Yes / No
Outcome Review Required
Field:
Outcome Review Required: Yes / No
Delivery Status
Field:
Delivery Status:
Recommended values:
Draft
Ready For Review
Waiting For Validation
Waiting For Approval
Approved For Distribution
Distributed
Parked
Rejected
Escalated
Closed
Quick Use Version
Delivery Record Title:
Original Request:
Request Owner:
Delivery Purpose:
Decision Required:
Output Type:
Source Material:
Original Source Preserved:
Source Quality:
Research Completed:
Verification Status:
Evidence Extracted:
Supporting Evidence:
Challenging Evidence:
Missing Information:
Checked Findings:
Interpretation:
Recommendation:
Synthesis Summary:
Documentation Format:
Schema Or Format Applied:
Validation Status:
Distribution Type:
Distribution Destination:
Permission Check Required:
Human Approval Required:
Human Approval Status:
Owner Of Next Action:
Next Action:
Stop Conditions:
Logging Required:
Outcome Review Required:
Delivery Status:
Examples
Example 1: Newsletter Intelligence Digest Distribution
Delivery Record Title:
Weekly Newsletter Intelligence Digest Distribution
Original Request:
Prepare the current newsletter intelligence for HeadOffice review.
Request Owner:
HeadOffice.
Delivery Purpose:
Summarise business-relevant external signals for HeadOffice review.
Decision Required:
Determine which items should be acted upon, tested, monitored, parked, or rejected.
Output Type:
Newsletter Digest
Source Material:
newsletter_intelligence records, Newsletter Queue Review, Routed Actions.
Original Source Preserved:
Yes.
Source Quality:
Usable if newsletter body capture and field quality are valid.
Research Completed:
Yes, if high-priority claims were verified or marked for verification.
Verification Status:
Partially Verified unless all material claims have been checked.
Evidence Extracted:
ACT NOW, TEST, MONITOR, PARK, and REJECT signal groups.
Supporting Evidence:
Source newsletter content and verified external evidence where required.
Challenging Evidence:
Contradictions, promotional bias, or missing proof.
Missing Information:
Any unavailable details required for action.
Checked Findings:
Verified or clearly qualified business signals.
Interpretation:
What the signals mean for MWMS.
Recommendation:
Route, test, monitor, park, reject, or request more research.
Synthesis Summary:
External signals are grouped by business relevance, Brain ownership, action type, urgency, evidence strength, and required decision.
Documentation Format:
Newsletter Intelligence Digest format.
Schema Or Format Applied:
Recurring Intelligence And Reporting Pipeline format.
Validation Status:
Operational Validation Complete before action.
Distribution Type:
Internal Review Distribution or Dashboard Distribution if approved.
Distribution Destination:
HeadOffice Review, HeadOffice Dashboard, or Newsletter Digest Archive.
Permission Check Required:
Yes if dashboard or email distribution is involved.
Human Approval Required:
Yes before downstream action.
Human Approval Status:
Pending.
Owner Of Next Action:
HeadOffice.
Next Action:
Review, route, park, reject, or assign owner.
Stop Conditions:
Body incomplete, generic signals, missing source, inflated urgency, unverified high-risk claims.
Logging Required:
Yes.
Outcome Review Required:
Yes.
Delivery Status:
Ready For Review.
Example 2: Course Absorption MCR Distribution
Delivery Record Title:
Course Absorption Framework Page MCR Distribution
Original Request:
Absorb the supplied course block into the MWMS Blueprint.
Request Owner:
Martyn.
Delivery Purpose:
Save valuable course-derived intelligence into MCR.
Decision Required:
Create, update, merge, park, or reject.
Output Type:
MCR Page
Source Material:
Course transcript or lesson block.
Original Source Preserved:
Yes.
Source Quality:
Mostly Complete.
Research Completed:
Yes, source reviewed and MWMS value extracted.
Verification Status:
Verified against the supplied material.
Evidence Extracted:
Reusable framework, governance rule, workflow, template, or system upgrade.
Supporting Evidence:
Relevant course material and existing MCR structure.
Challenging Evidence:
Tool hype, duplication, unsupported claims, or conflicting Canon.
Missing Information:
Any absent source content required for safe absorption.
Checked Findings:
Durable course intelligence suitable for MWMS.
Interpretation:
How the material strengthens existing MWMS systems.
Recommendation:
Create, update, merge, park, or reject.
Synthesis Summary:
Course material adds defined value to MWMS and should be absorbed without creating unnecessary duplication.
Documentation Format:
Full MCR page output.
Schema Or Format Applied:
MWMS Document Structure Standard and Brain Header Schema Standard.
Validation Status:
Operational Validation Required.
Distribution Type:
MCR Distribution.
Distribution Destination:
MCR under the correct parent.
Permission Check Required:
Yes.
Human Approval Required:
Yes.
Human Approval Status:
Required Not Granted until Martyn reviews.
Owner Of Next Action:
Martyn.
Next Action:
Check duplicate, check parent, save page, and update registry.
Stop Conditions:
Duplicate page exists, weak material, wrong parent, source incomplete, registry unclear.
Logging Required:
Yes.
Outcome Review Required:
Yes if absorbed.
Delivery Status:
Waiting For Approval.
Example 3: Developer Handoff Distribution
Delivery Record Title:
Developer Handoff To M Distribution
Original Request:
Prepare safe implementation instructions for M.
Request Owner:
Martyn or HeadOffice.
Delivery Purpose:
Send safe, exact development instructions to M.
Decision Required:
Approve the handoff for development or return it for clarification.
Output Type:
Developer Handoff
Source Material:
Screenshot, file content, current save point, user instruction.
Original Source Preserved:
Yes.
Source Quality:
Strong only if current file path and evidence are confirmed.
Research Completed:
Yes, current evidence reviewed.
Verification Status:
Verified against the current state.
Evidence Extracted:
Issue, affected site, affected file, required change, and test requirement.
Supporting Evidence:
Current screenshots, files, logs, and save point.
Challenging Evidence:
Conflicting state or evidence that the requested change may already exist.
Missing Information:
Anything M would otherwise need to guess.
Checked Findings:
The confirmed current state and required change.
Interpretation:
Why the change is required and what it must not affect.
Recommendation:
Proceed, revise, or stop.
Synthesis Summary:
M can complete the task if instructions are exact and the current state is confirmed.
Documentation Format:
Developer handoff brief.
Schema Or Format Applied:
Exchange Zone and Developer Support format.
Validation Status:
High Risk Validation Required.
Distribution Type:
Developer Distribution.
Distribution Destination:
M, Dev Console, or Brain Room.
Permission Check Required:
Yes.
Human Approval Required:
Yes.
Human Approval Status:
Pending.
Owner Of Next Action:
Martyn or M.
Next Action:
Approve and send to M, or request missing evidence.
Stop Conditions:
M would need to guess, file path missing, test steps missing, live risk unclear.
Logging Required:
Yes.
Outcome Review Required:
Yes.
Delivery Status:
Waiting For Validation.
Example 4: Weekly HeadOffice Report Distribution
Delivery Record Title:
Weekly HeadOffice Report Distribution
Original Request:
Prepare the current weekly operational intelligence report.
Request Owner:
HeadOffice.
Delivery Purpose:
Provide HeadOffice with a weekly operational intelligence view.
Decision Required:
Determine current priorities, owners, risks, and next actions.
Output Type:
HeadOffice Report
Source Material:
Routed Actions, Newsletter Intelligence, Brain Room notes, AI outcomes, failures, M updates, and MCR changes.
Original Source Preserved:
Yes.
Source Quality:
Usable if source records are current and structured.
Research Completed:
Yes.
Verification Status:
Partially Verified or Verified depending on source coverage.
Evidence Extracted:
ACT NOW items, TEST items, MONITOR items, risks, blockers, outcomes, and decisions needed.
Supporting Evidence:
Current operational records.
Challenging Evidence:
Conflicting status, missing completion evidence, or stale records.
Missing Information:
Unconfirmed ownership, status, dates, or outcomes.
Checked Findings:
The supported current operational state.
Interpretation:
What requires HeadOffice attention.
Recommendation:
Prioritise, assign, escalate, park, or close.
Synthesis Summary:
Report explains the current operational state, evidence, risks, and decisions required.
Documentation Format:
Weekly HeadOffice Report format.
Schema Or Format Applied:
Recurring Intelligence And Reporting Pipeline Framework.
Validation Status:
Operational Validation Required.
Distribution Type:
Internal Review Distribution or Email Distribution if approved.
Distribution Destination:
HeadOffice Review, Brain Room, or Report Archive.
Permission Check Required:
Yes if email distribution or dashboard publication occurs.
Human Approval Required:
Yes.
Human Approval Status:
Pending.
Owner Of Next Action:
HeadOffice.
Next Action:
Review priorities, assign owners, route actions, and park noise.
Stop Conditions:
Missing source data, generic report, stale records, no owners, no decisions.
Logging Required:
Yes.
Outcome Review Required:
Yes.
Delivery Status:
Ready For Review.
Example 5: Future AIBS Client Report Distribution
Delivery Record Title:
AIBS Client Weekly Report Distribution
Original Request:
Prepare a reviewed client-facing operational report.
Request Owner:
AIBS Brain or authorised client service owner.
Delivery Purpose:
Deliver a reviewed client-facing operational report.
Decision Required:
Approve, revise, hold, or deliver.
Output Type:
Client Report Draft or Client Report
Source Material:
Approved client workflow records and client-approved source data.
Original Source Preserved:
Yes.
Source Quality:
Must be Strong or Usable.
Research Completed:
Yes.
Verification Status:
Verified or clearly qualified.
Evidence Extracted:
Client workflow status, completed work, risks, decisions needed, and recommended actions.
Supporting Evidence:
Approved client records, logs, metrics, and deliverables.
Challenging Evidence:
Conflicting metrics, incomplete attribution, missing client input, or unresolved failure.
Missing Information:
Any information required to support the client-facing conclusion.
Checked Findings:
Verified client-specific operational findings.
Interpretation:
Why the findings matter to the client.
Recommendation:
The actions the client or MWMS should consider.
Synthesis Summary:
Report explains what changed, why it matters, what evidence supports it, and what the client should do next.
Documentation Format:
Client weekly report format.
Schema Or Format Applied:
AIBS Client Report format.
Validation Status:
High Risk Validation Required.
Distribution Type:
Client Review Distribution first and Client Delivery Distribution only after approval.
Distribution Destination:
Client Review Queue or client delivery channel after approval.
Permission Check Required:
Yes.
Human Approval Required:
Always.
Human Approval Status:
Required Not Granted until approved.
Owner Of Next Action:
HeadOffice or Client Review Owner.
Next Action:
Validate, review, approve, revise, or hold.
Stop Conditions:
Unapproved data, privacy risk, unsupported claim, unclear recommendation, missing approval.
Logging Required:
Yes.
Outcome Review Required:
Yes.
Delivery Status:
Draft or Waiting For Approval.
Example 6: Fact Check Research Distribution
Delivery Record Title:
Business Claim Fact Check Distribution
Original Request:
Verify whether a material business claim is supported.
Request Owner:
Research Brain, HeadOffice, or requesting Brain.
Delivery Purpose:
Provide a source-backed verdict and decision guidance.
Decision Required:
Accept, reject, qualify, escalate, or investigate the claim further.
Output Type:
Fact Check Report
Source Material:
Original claim, original source, independent sources, primary evidence, and contradictory evidence.
Original Source Preserved:
Yes.
Source Quality:
Varies by evidence chain.
Research Completed:
Yes.
Verification Status:
Verified, Partially Verified, Contradicted, or Unverified.
Evidence Extracted:
Supporting, challenging, and contextual evidence.
Supporting Evidence:
Sources that materially support the exact claim.
Challenging Evidence:
Sources that contradict or qualify the claim.
Missing Information:
Evidence required for a stronger verdict.
Checked Findings:
The parts of the claim that are supported, unsupported, outdated, or misleading.
Interpretation:
What the verdict means for MWMS.
Recommendation:
Use, qualify, reject, monitor, or escalate.
Synthesis Summary:
The claim has been evaluated against inspectable evidence and assigned a controlled verdict.
Documentation Format:
Fact Check Report format.
Schema Or Format Applied:
Deep Search claim and evidence structure.
Validation Status:
Structured Validation Complete or High Risk Validation Complete.
Distribution Type:
Internal Review Distribution, Brain Distribution, or Decision Record Distribution.
Distribution Destination:
Requesting Brain, HeadOffice, or Research Archive.
Permission Check Required:
Depends on destination.
Human Approval Required:
Required for material public, legal, financial, medical, compliance, or client-facing use.
Owner Of Next Action:
Requesting Brain or authorised reviewer.
Next Action:
Apply verdict, request further research, or escalate.
Stop Conditions:
Primary evidence unavailable, material contradiction unresolved, wrong claim evaluated, weak source independence.
Logging Required:
Yes.
Outcome Review Required:
Yes.
Delivery Status:
Ready For Review.
Distribution Readiness Checklist
Before any output is distributed, check:
Is the original request clear?
Is the request owner known?
Is the delivery purpose clear?
Is the required decision known?
Is the output type known?
Is source material identified?
Is the original source preserved?
Is source quality assessed?
Was research or source review completed?
Was verification performed where required?
Was evidence extracted?
Were supporting and challenging findings separated?
Were missing information and contradictions recorded?
Were checked findings separated from interpretation?
Was synthesis performed?
Is the recommendation supported?
Is the documentation format correct?
Was the correct schema or format applied?
Is validation complete?
Is distribution type known?
Is destination clear?
Is permission checking required?
Has permission been checked where needed?
Is human approval required?
Has human approval been granted where needed?
Is owner of next action assigned?
Is next action clear?
Are stop conditions listed?
Is logging required?
Is outcome review required?
Could this confuse M?
Could this pollute MCR?
Could this create dashboard noise?
Could this create client risk?
Could this present interpretation as fact?
Could this hide unresolved disagreement?
If several answers are unclear, distribution is not ready.
Common Distribution Failure Modes
Research, synthesis, documentation, and distribution have failed if:
Raw research is distributed without synthesis.
A source list is distributed without checked findings.
A summary is distributed without decision meaning.
Documentation is created without source grounding.
Interpretation is presented as fact.
A recommendation is presented as an approved decision.
Output is distributed without validation.
Report has no owner or next action.
Dashboard item is published without readiness review.
Developer handoff is sent while M would need to guess.
MCR page is saved without duplicate or parent check.
Newsletter digest includes generic noise.
Email distribution happens before approval.
Client report is delivered without human review.
Source quality is hidden.
Contradictory evidence is removed.
Missing evidence is filled with plausible AI language.
Weak output becomes recurring report content.
Distribution destination is unclear.
Outcome is never reviewed.
Manual Use Rule
Research, synthesis, documentation, and distribution workflows should be manually proven before automation or scheduled distribution.
Manual use helps MWMS learn:
which outputs are useful
which reports are worth distributing
which documentation formats work
which synthesis steps are missing
which approval gates are needed
which outputs create decisions
which outputs create noise
which evidence standards are appropriate
which distribution types require stricter review
which workflows may later become scheduled
which client outputs are safe and useful
Manual distribution discipline comes before automated email, dashboard publication, client delivery, or Task Executor distribution.
Future Plugin Or UI Relevance
This framework may later support:
distribution readiness checklist
report distribution registry
HeadOffice report distribution workflow
Newsletter Digest distribution workflow
M developer handoff distribution panel
client report review queue
email distribution approval gate
dashboard publication approval gate
AI Manager delivery routing
Task Executor distribution state machine
AIBS client report delivery system
research evidence viewer
claim-to-source display
report approval workflow
Possible future fields:
delivery_record_id
delivery_record_title
original_request
request_owner
delivery_purpose
decision_required
output_type
source_material
original_source_preserved
source_quality
research_completed
verification_status
evidence_extracted
supporting_evidence
challenging_evidence
missing_information
checked_findings
interpretation
recommendation
synthesis_summary
documentation_format
schema_or_format_applied
validation_status
distribution_type
distribution_destination
permission_check_required
human_approval_required
human_approval_status
owner_next_action
next_action
stop_conditions
logging_required
outcome_review_required
delivery_status
created_at
updated_at
No technical build is authorised by this framework alone.
Governance Role
HeadOffice owns the MWMS Research Synthesis Documentation And Distribution Framework.
HeadOffice is responsible for:
defining delivery pipeline governance
ensuring requests and decision needs are clear
ensuring outputs move from research to verification and synthesis before documentation
ensuring checked findings remain separate from interpretation
ensuring documentation is validated before distribution
ensuring distribution has permission and approval where needed
ensuring client delivery never bypasses review
ensuring M developer handoffs are evidence-based
ensuring dashboards do not receive weak outputs
ensuring recurring reports do not distribute noise
ensuring source evidence remains accessible
ensuring credible disagreement is not hidden
ensuring output usefulness is reviewed after distribution
protecting M’s active build areas
protecting MCR source of truth
protecting future AIBS client delivery quality
Individual Brains may create local reports and summaries, but HeadOffice governs cross-Brain, MCR-related, dashboard-related, developer-related, email-related, automation-related, and client-facing distribution.
Relationship To Other MWMS Standards
This framework supports and must align with:
MWMS AI Documentation Automation Pipeline Framework
MWMS Recurring Intelligence And Reporting Pipeline Framework
MWMS AI Schema And Decision Ready Output Framework
MWMS Structured Analysis And Insight Workflow Framework
MWMS Operational Decision Intelligence Framework
MWMS KPI Dashboard And Insight Summary Framework
MWMS Analytics And Visualization Workflow Framework
MWMS AI Permission Gatekeeper Framework
MWMS AI Context Routing Framework
MWMS AI Exchange Zone And Dependency Control Framework
MWMS AI Ambiguity And Partial Failure Containment Framework
MWMS AI Agent Operations Core
MWMS AI Output Validation Standard
MWMS AI Output Validation Checklist
MWMS Agentic Reporting Standard
MWMS Agentic Reporting Template
MWMS AI Agent Outcome Measurement Framework
MWMS AI Agent Outcome Log Record
MWMS AI Agent Failure Handling And Escalation Protocol
MWMS AI Agent Failure Log Record
MWMS Brain Routing Rule
MWMS Brain To Brain Request Protocol
MWMS Supabase Event Schema
MWMS Deep Search Quality And Observability Framework
MWMS Source Visibility And Evidence Display Standard
MWMS Independent Model Review And Rescue Routing Framework
MWMS External Knowledge Engine And Reasoning Agent Separation Framework
AIBS Brain Blueprint
This framework adds the governed intelligence delivery and distribution layer to the MWMS AI Agent Operations Core.
Drift Protection
This framework protects MWMS from:
distributing raw research without synthesis
treating summaries as decision-ready outputs
creating documentation without source grounding
mixing checked findings with interpretation
presenting recommendations as decisions
sending reports without validation
publishing dashboard items without review
sending M unclear developer handoffs
saving MCR pages without source-of-truth discipline
automating email distribution too early
sending client reports without approval
distributing outputs with no owner or next action
hiding source quality from readers
hiding contradictions and missing information
turning weak reports into recurring noise
creating outputs that are never reviewed for usefulness
allowing distribution to bypass permission checks
treating delivery as complete when no outcome was created
Drift Signals
Watch for:
“Just summarise the sources.”
“Put all the links at the end.”
“The report looks professional.”
“We can leave out the conflicting evidence.”
“The reader does not need to see the uncertainty.”
“The recommendation is basically the decision.”
“The AI researched it, so it is verified.”
“We can send it now and check it later.”
“The dashboard needs more content.”
“M will work out what it means.”
“The client does not need the source detail.”
“The executive summary is enough.”
“Keep the raw research out because it makes the conclusion weaker.”
Rule
When these drift signals appear, return to request clarity, evidence, verification, finding and interpretation separation, validation, approval, and routing discipline.
Architectural Intent
The architectural intent of the MWMS Research Synthesis Documentation And Distribution Framework is to make MWMS intelligence deliverable, trustworthy, explainable, and actionable.
MWMS will continue to absorb, analyse, document, and generate large amounts of intelligence.
The value is not in generating more output.
The value is in moving the right output through a governed delivery pipeline so it reaches the right destination safely.
The long-term goal is that every important MWMS deliverable can answer:
What was requested?
Who requested it?
What decision must be supported?
What is the purpose?
What source supports it?
Was the original source preserved?
Was research completed?
What evidence was extracted?
What evidence supports the finding?
What evidence challenges it?
What remains unknown?
What findings were verified?
What interpretation was made?
What recommendation was produced?
What documentation format was used?
Was the correct schema applied?
Has the output been validated?
What type of distribution is this?
Who approved it?
Where is it going?
Who owns the next action?
What stop conditions apply?
What outcome should be reviewed?
When MWMS controls this pipeline, the system can move from AI output generation into governed intelligence delivery.
Final Standard
The MWMS final standard is:
No important research, analysis, report, recommendation, decision record, developer handoff, dashboard item, MCR page, email report, or client-facing deliverable should be distributed until its request, purpose, decision need, sources, evidence, verification status, checked findings, interpretation, recommendation, documentation format, validation status, authority, destination, owner, and next action are defined.
A valid MWMS research and distribution output must define:
original request
request owner
delivery purpose
decision required
output type
source material
original source preservation
source quality
research status
verification status
supporting evidence
challenging evidence
missing information
checked findings
interpretation
recommendation
synthesis summary
documentation format
schema or format
validation status
distribution type
distribution destination
permission requirement
human approval requirement
next-action owner
next action
stop conditions
logging requirement
outcome review requirement
delivery status
That is the MWMS Research Synthesis Documentation And Distribution standard.
MWMS System Change Log
Version: v1.1
Date: 2026-06-21
Author: HeadOffice
Change
Updated the MWMS Research Synthesis Documentation And Distribution Framework from v1.0 to v1.1 using the AI Automations by Jack material covering:
automated company research
client intelligence reporting
fact-checking workflows
source verification
meeting research preparation
multi-model research synthesis
evidence-backed reporting
source URL preservation
automated documentation
dashboard distribution
client-facing intelligence delivery
Expanded the original twelve-stage pipeline into a sixteen-stage pipeline:
• Define The Request And Delivery Purpose
• Define The Decision Or Output Need
• Identify Source Material
• Conduct Research Or Source Review
• Clean And Normalise Input
• Extract Evidence
• Verify Findings
• Separate Findings From Interpretation
• Synthesise Meaning
• Create Documentation
• Apply Schema And Format Rules
• Validate Output
• Approve Distribution
• Distribute Or Route
• Log Outcome
• Capture Learning And Feedback
Added new standards covering:
• original request preservation
• decision-focused research
• evidence records
• verification status
• checked findings
• findings versus interpretation separation
• recommendations versus decisions
• executive summary plus detailed evidence
• source links beside supported findings
• original source preservation
• contradiction visibility
• missing-information visibility
• raw research versus final output separation
• decision record distribution
• research archive distribution
Expanded the Research To Distribution Record Template to include:
• Original Request
• Request Owner
• Decision Required
• Original Source Preserved
• Verification Status
• Supporting Evidence
• Challenging Evidence
• Missing Information
• Checked Findings
• Interpretation
• Recommendation
Added a new Fact Check Research Distribution example.
Change Impact Declaration
This update materially strengthens the research-to-distribution pipeline without changing its primary ownership.
HeadOffice remains the framework owner.
Research Brain remains responsible for research and evidence quality.
Data Brain remains responsible for structured records and source integrity.
Individual Brains remain responsible for acting on intelligence within their authority.
The update does not authorise automatic external distribution, client delivery, dashboard publication, email sending, or developer work.
The update introduces stronger controls requiring:
• request clarity
• decision clarity
• source preservation
• evidence verification
• findings and interpretation separation
• contradiction visibility
• approval before material distribution
Pages Created
• None
Pages Updated
• MWMS Research Synthesis Documentation And Distribution Framework updated from v1.0 to v1.1
Pages Deprecated
• None
Standalone Pages Not Created
The following standalone pages were not created because their durable intelligence is governed within this updated framework:
• MWMS Automated Research Report Framework
• MWMS Client Intelligence Report Distribution Framework
• MWMS Evidence Synthesis Framework
• MWMS Fact Check Report Framework
• MWMS Research Documentation Framework
• MWMS Research Distribution Framework
• MWMS Executive Research Summary Framework
• MWMS Source Backed Recommendation Framework
Registries Requiring Update
• MCR Page Registry
• HeadOffice Page Registry
• Research Brain Page Registry where this framework is operationally referenced
• MCR Copy Map where the framework copy and version are recorded
• MWMS Course Absorption Decision Registry
Canon Version Update Required
No immediate HeadOffice Canon or Research Brain Canon version change is required unless either Canon directly records framework versions or contains research-distribution rules that conflict with v1.1.
The new request, evidence, verification, findings, interpretation, and distribution controls should be included during the next scheduled HeadOffice and Research Brain Canon alignment review.
Change Log Entry Required
Yes.
The v1.1 update must be recorded in:
• MWMS System Change Log
• MCR Page Registry change history where applicable
• HeadOffice Page Registry change history where applicable
• Research Brain Page Registry change history where applicable
• MWMS Course Absorption Decision Registry
Strategic Absorption Result
The AI Automations by Jack material concerning automated research, client intelligence reports, fact checking, evidence preservation, multi-model synthesis, source-backed documentation, and report distribution has been absorbed into the existing MWMS Research Synthesis Documentation And Distribution Framework.
The absorption preserves the durable intelligence-delivery architecture while rejecting:
• raw research being presented as a finished report
• source lists without claim-level relevance
• recommendations being presented as decisions
• polished summaries hiding uncertainty
• contradictory evidence being removed
• unsupported automated client distribution
• dashboard publication without validation
• automated email distribution before approval
The resulting v1.1 framework establishes that MWMS research outputs must be:
• request-led
• decision-focused
• source-preserving
• evidence-backed
• verification-aware
• contradiction-visible
• interpretation-separated
• recommendation-controlled
• schema-structured
• validated
• permissioned
• correctly routed
• outcome-reviewed
END OF FULL FILE OUTPUT