MWMS MCR

MWMS Messy Input Normalization Record

System: MWMS
Document Type: Operational Template
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, MWMS Brain, Brain Room, AI Manager, AI Employee Router, Task Executor Systems, Newsletter Intelligence, Course Absorption System, Opportunity System, AI Business Systems Brain
Parent Page: HeadOffice
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR

Purpose

The purpose of this document is to define the MWMS Messy Input Normalization Record.

This record is the practical operating template used when MWMS receives messy, incomplete, noisy, unstructured, duplicated, badly formatted, or unclear source material.

MWMS receives input from many places:

  • course transcripts
  • PDFs
  • newsletters
  • screenshots
  • Brain Room messages
  • developer notes
  • sales pages
  • affiliate offer pages
  • Supabase records
  • WordPress page lists
  • Google Sheets
  • Make.com outputs
  • pasted notes
  • research sources
  • future client documents

Not all input is ready for analysis.

If messy input goes directly into AI processing, MWMS risks:

  • weak summaries
  • wrong Brain routing
  • bad decisions
  • duplicate pages
  • poor course absorption
  • dashboard noise
  • vague developer instructions
  • unsupported offer decisions
  • unreliable automation
  • future client workflow errors

This record ensures raw input is cleaned, structured, classified, validated, and routed before serious AI work begins.

This is the practical daily-use version of the MWMS Messy Input Normalization Framework.

Scope

This record applies whenever MWMS needs to prepare messy input before it becomes:

  • an Agentic Work Unit
  • a course absorption report
  • a newsletter intelligence item
  • a Brain Room task
  • an offer evaluation
  • a research request
  • a developer support request
  • a dashboard item
  • a routed action
  • an MCR page draft
  • a future AIBS client workflow item

This record can be used manually first.

Later, parts of this record may become fields inside Brain Room, AI Manager, Supabase records, Newsletter Intelligence, Course Absorption workflows, task screens, validation queues, or future AIBS client systems.

Core Definition

A Messy Input Normalization Record is a structured record that converts raw source material into clean, usable MWMS input.

It captures:

  • what came in
  • where it came from
  • what type of input it is
  • whether it is complete
  • what noise was removed
  • what useful content was extracted
  • what structure was applied
  • which Brain owns it
  • what risks exist
  • whether it is safe to analyze
  • where it should go next

This record does not replace analysis.

It prepares input for better analysis.

Core Principle

The core principle of this record is:

Dirty input creates dirty intelligence.

MWMS must not treat messy input as reliable intelligence.

The input must first be normalized.

Normalization means:

capture → extract → clean → structure → classify → validate → route

Only after this process should the input move into deeper analysis, reporting, decision-making, automation, or MCR page creation.

Messy Input Normalization Record Template

1. Input Title

Field:
Input Title:

Purpose:
Gives the input a clear name.

Examples:

  • Mastering Claude Lesson Transcript Block
  • Newsletter Signal From AI Tool Update
  • Brain Room Message About Task Routing
  • Affiliate Offer Sales Page Intake
  • WordPress Page List Duplicate Check
  • Developer Screenshot From HeadOffice Dashboard
  • Client Operations Document Intake

Rule:
The title should make the source understandable at a glance.

2. Source Type

Field:
Source Type:

Recommended Values:

  • Course Transcript
  • Course PDF
  • Course HTML
  • Newsletter
  • Email
  • Screenshot
  • Brain Room Message
  • Developer Note
  • WordPress Page List
  • Supabase Row
  • Google Sheet Row
  • Affiliate Offer Page
  • Sales Page
  • Research Source
  • Finance Data
  • Experiment Result
  • Dashboard Item
  • Client Document
  • Pasted Text
  • Other

Rule:
The source type determines how the input should be cleaned and routed.

3. Source Name

Field:
Source Name:

Purpose:
Records the name of the file, page, email, screenshot, message, or source.

Examples:

  • Mastering Claude Cowork And AI Agent Automation
  • Techpresso Newsletter
  • Affiliate Brain Page List
  • Offer Sales Page
  • Brain Room Thread
  • Screenshot From WordPress Pages
  • Supabase Newsletter Intelligence Row

Rule:
The source name should be clear enough that the input can be found later.

4. Source Reference

Field:
Source Reference:

Purpose:
Captures a more exact reference where available.

Examples:

  • file name
  • lesson title
  • email subject
  • screenshot filename
  • WordPress page title
  • Supabase record ID
  • Google Sheet row
  • date/time received
  • dashboard row
  • URL if approved
  • Brain Room thread ID

Rule:
Use this field when the source may need to be checked later.

5. Date Received

Field:
Date Received:

Purpose:
Records when the input entered MWMS.

Format:
YYYY-MM-DD

Rule:
Date matters for freshness, audit trail, and avoiding stale context.

6. Originating System Or Brain

Field:
Originating System Or Brain:

Purpose:
Identifies where the input entered MWMS.

Examples:

  • HeadOffice Brain
  • Brain Room
  • Course Absorption System
  • Newsletter Intelligence
  • Affiliate Brain
  • Research Brain
  • Experimentation Brain
  • Finance Brain
  • Content Brain
  • Ads Brain
  • Dev Console
  • Opportunity System
  • MCR
  • AI Business Systems Brain
  • External Client Source

Rule:
Origin shows where the input came from. It does not always determine ownership.

7. Original Format

Field:
Original Format:

Recommended Values:

  • TXT
  • PDF
  • HTML
  • Screenshot
  • Email Body
  • Newsletter Body
  • CSV
  • Spreadsheet
  • WordPress Page List
  • Supabase Row
  • JSON
  • Transcript
  • SRT
  • Pasted Text
  • Web Page
  • Unknown

Rule:
Format affects extraction quality and cleanup needs.

8. Input Completeness

Field:
Input Completeness:

Recommended Values:

  • Complete
  • Mostly Complete
  • Partial
  • Incomplete
  • Unclear
  • Corrupted
  • Source Expired
  • Needs Reupload

Check:

  • Is the full source available?
  • Is any section missing?
  • Is the file expired?
  • Is the screenshot partial?
  • Is the transcript cut off?
  • Is the email body truncated?
  • Is the page list complete enough?
  • Is the data current?

Rule:
Do not treat partial input as complete.

9. Input Quality Level

Field:
Input Quality Level:

Recommended Values:

  • Clean
  • Mildly Messy
  • Messy
  • Very Messy
  • High Risk Messy
  • Not Usable Yet

Examples:

Clean:

  • well-structured document with clear headings

Mildly Messy:

  • small formatting issues

Messy:

  • copied web text, newsletter clutter, repeated text

Very Messy:

  • broken transcript, mixed sections, missing context

High Risk Messy:

  • developer/code/client/finance/compliance input with uncertainty

Not Usable Yet:

  • too incomplete to analyze safely

Rule:
Input quality controls whether the workflow can proceed.

10. Noise Detected

Field:
Noise Detected:

Purpose:
Identifies clutter that should be ignored or cleaned.

Examples:

  • newsletter footer
  • unsubscribe text
  • repeated navigation
  • tracking links
  • ads
  • sponsored blocks
  • course platform boilerplate
  • timestamps
  • repeated transcript fragments
  • broken formatting
  • unrelated page content
  • HTML noise
  • copied menu text
  • duplicated sections
  • filler text
  • irrelevant examples
  • vendor hype
  • old content
  • unclear metadata

Rule:
Noise should be removed without destroying useful meaning.

11. Useful Content Extracted

Field:
Useful Content Extracted:

Purpose:
Summarizes the useful material pulled from the input.

Examples:

  • core course framework
  • practical workflow rule
  • AI Employee concept
  • newsletter business signal
  • tool intelligence
  • compliance warning
  • affiliate offer details
  • market signal
  • developer issue
  • WordPress page status
  • finance assumption
  • experiment learning
  • client workflow requirement

Rule:
Extraction should identify what is actually useful, not summarize everything.

12. Content To Ignore

Field:
Content To Ignore:

Purpose:
Identifies material that should not influence the analysis.

Examples:

  • generic AI hype
  • sales fluff
  • old tool promotion
  • duplicated course intro
  • irrelevant examples
  • vendor claims without evidence
  • newsletter ads
  • platform boilerplate
  • unrelated text
  • outdated instructions
  • repeated transcript fragments
  • content outside MWMS scope

Rule:
Explicitly naming what to ignore prevents weak input from polluting the output.

13. Cleaned Input Summary

Field:
Cleaned Input Summary:

Purpose:
Provides a short cleaned summary of the input after noise removal.

Should Include:

  • what the input is about
  • the useful signal
  • the main topic
  • what is relevant to MWMS
  • what should happen next if obvious

Rule:
This should be short and practical, not a full analysis.

14. Key Extracted Elements

Field:
Key Extracted Elements:

Purpose:
Lists the structured pieces pulled from the input.

Possible Elements:

  • concepts
  • frameworks
  • rules
  • workflows
  • claims
  • data points
  • fields
  • page titles
  • risks
  • decisions
  • tool names
  • Brain names
  • user instructions
  • developer notes
  • action items
  • missing details

Rule:
Extracted elements should be specific enough to route.

15. Known Gaps

Field:
Known Gaps:

Purpose:
Identifies what is missing or uncertain.

Examples:

  • source file expired
  • full transcript missing
  • only screenshot available
  • current WordPress state not confirmed
  • page parent unclear
  • offer payout missing
  • finance data missing
  • source date unknown
  • tool access not confirmed
  • M’s current state unknown
  • duplicate page comparison incomplete
  • current web verification required

Rule:
Gaps must be stated before deeper analysis.

16. Assumptions Made

Field:
Assumptions Made:

Purpose:
Records any assumptions used during normalization.

Examples:

  • assuming page title matches MCR naming rules
  • assuming source belongs to Course Absorption
  • assuming parent should be HeadOffice
  • assuming input is latest version
  • assuming screenshot reflects current state
  • assuming newsletter body is complete

Rule:
Assumptions must not be presented as facts.

17. Input Classification

Field:
Input Classification:

Recommended Values:

  • Course Absorption Input
  • Newsletter Intelligence Input
  • Brain Room Task Input
  • Offer Evaluation Input
  • Research Input
  • Finance Input
  • Experimentation Input
  • Developer Support Input
  • MCR Page Input
  • Dashboard Review Input
  • Validation Input
  • Handoff Input
  • Client Workflow Input
  • Parking Input
  • Archive Input

Rule:
Classification determines the next workflow.

18. Owning Brain

Field:
Owning Brain:

Purpose:
Identifies which Brain owns the normalized input.

Examples:

  • HeadOffice Brain
  • Affiliate Brain
  • Research Brain
  • Experimentation Brain
  • Finance Brain
  • Content Brain
  • Ads Brain
  • Sales Brain
  • Conversion Brain
  • Operations Brain
  • AI Business Systems Brain

Rule:
No important input should move forward without Brain ownership.

19. Supporting Brains

Field:
Supporting Brains:

Purpose:
Lists other Brains affected by the input.

Examples:

For offer evaluation:

  • Research Brain
  • Ads Brain
  • Finance Brain
  • Experimentation Brain
  • HeadOffice Brain

For course absorption:

  • HeadOffice Brain
  • AI Business Systems Brain
  • Operations Brain
  • relevant specialist Brain

For newsletter:

  • Ads Brain
  • Content Brain
  • Affiliate Brain
  • Research Brain
  • Finance Brain

Rule:
Cross-Brain impact should be identified early.

20. Risk Level

Field:
Risk Level:

Recommended Values:

  • Low
  • Medium
  • High
  • Critical

High-Risk Inputs Include:

  • developer files
  • live system screenshots
  • Supabase records
  • finance data
  • paid traffic decisions
  • compliance-sensitive material
  • public content
  • client-facing documents
  • MCR canon updates
  • incomplete source used for major decisions

Rule:
Risk determines validation and human review.

21. Priority

Field:
Priority:

Recommended Values:

  • Critical
  • High
  • Medium
  • Low
  • Parking Lot

Rule:
Priority should be based on business importance, not excitement.

22. Required AI Employee

Field:
Required AI Employee:

Examples:

  • Course Absorption Agent
  • Newsletter Signal Extraction Agent
  • Brain Room Task Builder Agent
  • Offer Evaluation Agent
  • Research Evidence Collection Agent
  • Finance Break Even Analysis Agent
  • HeadOffice Validation Agent
  • Developer Support Agent
  • Handoff Agent
  • Reporting Agent
  • AIBS Client Reporting Agent

Rule:
The normalized input should be sent to the right role, not generic AI.

23. Recommended Workflow

Field:
Recommended Workflow:

Examples:

  • Course Absorption Pipeline
  • Newsletter Intelligence Pipeline
  • Brain Room Task Creation Pipeline
  • Offer Evaluation Pipeline
  • Research Workflow
  • Finance Review Workflow
  • Developer Support Pipeline
  • MCR Page Creation Pipeline
  • Validation Workflow
  • Handoff Workflow
  • AIBS Client Workflow

Rule:
Normalization should identify the next workflow path.

24. Validation Requirement

Field:
Validation Requirement:

Recommended Values:

  • Light Validation
  • Structured Validation
  • Operational Validation
  • High Risk Validation
  • Critical Validation

Rule:
The validation level must match the risk and destination.

25. Human Review Required

Field:
Human Review Required: Yes / No

Human Review Required For:

  • MCR canon
  • developer instructions
  • live systems
  • Supabase writes
  • WordPress changes
  • finance
  • compliance
  • paid traffic
  • public content
  • client-facing outputs
  • high-risk automation
  • uncertain source quality

Rule:
When in doubt, require human review.

26. Safe To Analyze

Field:
Safe To Analyze: Yes / No / With Caution

Purpose:
Determines whether the cleaned input can move into analysis.

Use:

Yes:

  • input is complete enough and risk is controlled

With Caution:

  • usable but gaps or assumptions exist

No:

  • too incomplete, risky, or unclear

Rule:
Do not send weak input into serious analysis.

27. Next Destination

Field:
Next Destination:

Examples:

  • Agentic Work Unit
  • Course Absorption Agent
  • Newsletter Queue Review
  • Offer Evaluation Agent
  • Research Brain
  • Finance Brain
  • Developer Support Agent
  • HeadOffice Validation
  • MCR Page Draft
  • Brain Room Task Builder
  • Handoff Package
  • Parking System
  • Archive
  • Human Review Queue
  • AIBS Client Review

Rule:
Normalized input must have a destination.

28. Recommended Action

Field:
Recommended Action:

Recommended Values:

  • Analyze
  • Create Agentic Work Unit
  • Route To Brain
  • Validate
  • Request More Input
  • Reupload Source
  • Clean Again
  • Merge With Existing Page
  • Park
  • Reject
  • Archive
  • Escalate
  • Create Full Page Output
  • Prepare Developer Handoff
  • Create Report

Rule:
The record should tell MWMS what to do next.

29. Logging Required

Field:
Logging Required: Yes / No

Logging Required For:

  • important course absorption
  • newsletter intelligence
  • offer evaluation
  • developer handoffs
  • validation failures
  • high-risk inputs
  • MCR page creation
  • cross-Brain routing
  • client-facing workflows

Rule:
Important input normalization should leave a trace.

30. Learning Capture Required

Field:
Learning Capture Required: Yes / No

Learning Examples:

  • new messy input pattern found
  • repeated source issue found
  • new cleanup rule needed
  • new validation rule needed
  • new routing rule needed
  • new course absorption filter needed
  • new developer evidence rule needed
  • new newsletter noise pattern found

Rule:
If the input reveals a reusable improvement, capture it.

Quick Use Version

Use this shorter form for daily manual work.

Input Title:
Source Type:
Source Name:
Source Reference:
Date Received:
Originating System Or Brain:
Original Format:
Input Completeness:
Input Quality Level:
Noise Detected:
Useful Content Extracted:
Content To Ignore:
Cleaned Input Summary:
Key Extracted Elements:
Known Gaps:
Assumptions Made:
Input Classification:
Owning Brain:
Supporting Brains:
Risk Level:
Priority:
Required AI Employee:
Recommended Workflow:
Validation Requirement:
Human Review Required:
Safe To Analyze:
Next Destination:
Recommended Action:
Logging Required:
Learning Capture Required:

Example 1: Course Transcript Normalization Record

Input Title:
Mastering Claude Course Lesson Transcript Intake

Source Type:
Course Transcript

Source Name:
Mastering Claude Cowork And AI Agent Automation

Source Reference:
Lesson transcript block

Date Received:
2026-05-15

Originating System Or Brain:
Course Absorption System

Original Format:
Transcript / TXT

Input Completeness:
Mostly Complete

Input Quality Level:
Messy

Noise Detected:
timestamps, repeated phrases, course platform clutter, spoken-language fragments

Useful Content Extracted:
AI agent workflow principles, task decomposition, validation gates, role separation, handoff rules

Content To Ignore:
tool hype, casual filler, repeated intro material

Cleaned Input Summary:
The lesson contains strong concepts for converting AI work into structured agentic workflows.

Key Extracted Elements:
AI Employee roles, workflow stages, validation requirements, reporting outputs, handoff logic

Known Gaps:
Exact transcript source may need reupload if source-checking is required later.

Assumptions Made:
Assuming extracted course block is complete enough for MCR page drafting.

Input Classification:
Course Absorption Input

Owning Brain:
HeadOffice Brain

Supporting Brains:
AI Business Systems Brain, Operations Brain, Brain Room

Risk Level:
Medium

Priority:
High

Required AI Employee:
Course Absorption Agent

Recommended Workflow:
Course Absorption Pipeline

Validation Requirement:
Operational Validation

Human Review Required:
Yes

Safe To Analyze:
With Caution

Next Destination:
Course Absorption Agent

Recommended Action:
Extract system value and create page output if justified.

Logging Required:
Yes if absorbed

Learning Capture Required:
Yes

Example 2: Newsletter Normalization Record

Input Title:
AI Newsletter Business Signal Intake

Source Type:
Newsletter

Source Name:
AI Newsletter

Source Reference:
Email subject and date

Date Received:
YYYY-MM-DD

Originating System Or Brain:
Newsletter Intelligence

Original Format:
Email Body

Input Completeness:
Complete / Mostly Complete

Input Quality Level:
Messy

Noise Detected:
ads, sponsor blocks, unsubscribe footer, repeated links, generic news

Useful Content Extracted:
business-relevant AI tool update, platform shift, compliance signal, monetization opportunity, market trend

Content To Ignore:
generic product hype, irrelevant AI news, sponsor fluff

Cleaned Input Summary:
Newsletter contains one or more signals that may matter to MWMS business operations.

Key Extracted Elements:
tool name, market trend, affected Brain, recommended action, urgency

Known Gaps:
Current verification may be needed if action affects tools, policy, paid traffic, or compliance.

Assumptions Made:
Assuming email body extraction is complete.

Input Classification:
Newsletter Intelligence Input

Owning Brain:
HeadOffice Brain

Supporting Brains:
Depends on signal

Risk Level:
Medium

Priority:
Based on signal value

Required AI Employee:
Newsletter Signal Extraction Agent

Recommended Workflow:
Newsletter Intelligence Pipeline

Validation Requirement:
Operational Validation

Human Review Required:
Yes before downstream action

Safe To Analyze:
Yes / With Caution

Next Destination:
Newsletter Queue Review

Recommended Action:
Extract signal, classify Brain, route or park.

Logging Required:
Yes

Learning Capture Required:
Yes if repeated pattern appears

Example 3: Brain Room Message Normalization Record

Input Title:
Brain Room Task Request Intake

Source Type:
Brain Room Message

Source Name:
Brain Room Thread

Source Reference:
Thread and timestamp

Date Received:
YYYY-MM-DD

Originating System Or Brain:
Brain Room

Original Format:
Message

Input Completeness:
Partial / Mostly Complete

Input Quality Level:
Mildly Messy

Noise Detected:
mixed topics, shorthand, emotional context, incomplete instruction

Useful Content Extracted:
task request, decision need, system concern, developer issue, workflow idea

Content To Ignore:
non-actionable chat unless relevant to context

Cleaned Input Summary:
Message contains a request that may need to become structured work.

Key Extracted Elements:
request type, owning Brain, possible AI Employee, risk level, next action

Known Gaps:
May need clarification if multiple tasks are mixed.

Assumptions Made:
Assuming message belongs to current active workflow unless stated otherwise.

Input Classification:
Brain Room Task Input

Owning Brain:
Determined by classification

Supporting Brains:
HeadOffice Brain if cross-system

Risk Level:
Variable

Priority:
Based on request

Required AI Employee:
Brain Room Task Builder Agent

Recommended Workflow:
Brain Room Task Creation Pipeline

Validation Requirement:
Structured or Operational Validation

Human Review Required:
Yes for medium/high-risk tasks

Safe To Analyze:
With Caution

Next Destination:
Agentic Work Unit

Recommended Action:
Convert message into structured task or park if unclear.

Logging Required:
Yes if task created

Learning Capture Required:
If repeated request pattern appears

Example 4: Developer Screenshot Normalization Record

Input Title:
Developer Screenshot Intake For M Support

Source Type:
Screenshot

Source Name:
WordPress Admin Screenshot

Source Reference:
Screenshot file and related user instruction

Date Received:
YYYY-MM-DD

Originating System Or Brain:
HeadOffice / Dev Console / Brain Room

Original Format:
Image / Screenshot

Input Completeness:
Partial

Input Quality Level:
High Risk Messy

Noise Detected:
visual clutter, partial screen, missing file context, possible hidden state

Useful Content Extracted:
visible page, visible error, visible parent, visible status, visible system issue

Content To Ignore:
anything not visible or not confirmed

Cleaned Input Summary:
Screenshot provides evidence of current visible system state but may not show full context.

Key Extracted Elements:
site area, screen title, visible error/status, page parent, date, relevant buttons or fields

Known Gaps:
File contents, database state, or hidden settings may be missing.

Assumptions Made:
Only visible evidence should be trusted.

Input Classification:
Developer Support Input

Owning Brain:
HeadOffice Brain

Supporting Brains:
Operations Brain / Dev Console where relevant

Risk Level:
High

Priority:
Based on build impact

Required AI Employee:
Developer Support Agent

Recommended Workflow:
Developer Support Pipeline

Validation Requirement:
High Risk Validation

Human Review Required:
Yes

Safe To Analyze:
With Caution

Next Destination:
Developer Support Agent

Recommended Action:
Prepare exact instruction only if enough evidence exists. Request file or screenshot if not.

Logging Required:
Yes for meaningful dev changes

Learning Capture Required:
If new save point or developer rule is created

Example 5: Affiliate Offer Page Normalization Record

Input Title:
Affiliate Offer Sales Page Intake

Source Type:
Affiliate Offer Page

Source Name:
Offer Name

Source Reference:
Network, URL, vendor page, or source note

Date Received:
YYYY-MM-DD

Originating System Or Brain:
Affiliate Brain / Newsletter Intelligence / Research Brain

Original Format:
Web Page / Pasted Text

Input Completeness:
Partial / Mostly Complete

Input Quality Level:
Messy

Noise Detected:
vendor hype, scarcity claims, testimonials, bonuses, unsupported performance claims

Useful Content Extracted:
offer promise, niche, target audience, mechanism, funnel type, claims, proof, pricing/payout if available

Content To Ignore:
unsupported claims, hype, vague income promises, unverified testimonials

Cleaned Input Summary:
Offer page provides initial data for evaluation but requires evidence separation.

Key Extracted Elements:
offer name, network, payout, niche, promise, mechanism, compliance risk, traffic fit

Known Gaps:
EPC, refund rate, conversion rate, vendor reliability, current network metrics may need verification.

Assumptions Made:
Vendor claims are not treated as evidence.

Input Classification:
Offer Evaluation Input

Owning Brain:
Affiliate Brain

Supporting Brains:
Research Brain, Ads Brain, Finance Brain, Experimentation Brain, HeadOffice Brain

Risk Level:
High

Priority:
Based on revenue potential

Required AI Employee:
Offer Evaluation Agent

Recommended Workflow:
Offer Evaluation Pipeline

Validation Requirement:
High Risk Validation

Human Review Required:
Yes

Safe To Analyze:
With Caution

Next Destination:
Offer Evaluation Agent

Recommended Action:
Evaluate, verify current data where required, then reject, park, request research, or send to Finance/Experimentation.

Logging Required:
Yes

Learning Capture Required:
Yes

Normalization Quality Checklist

Before sending normalized input into analysis, check:

  1. Is the input title clear?
  2. Is the source type identified?
  3. Is the source name recorded?
  4. Is the source reference included where needed?
  5. Is the date received known?
  6. Is the originating system or Brain known?
  7. Is the original format known?
  8. Is input completeness checked?
  9. Is input quality level assigned?
  10. Is noise identified?
  11. Is useful content extracted?
  12. Is content to ignore identified?
  13. Is a cleaned input summary included?
  14. Are key extracted elements listed?
  15. Are known gaps stated?
  16. Are assumptions marked?
  17. Is input classification assigned?
  18. Is owning Brain clear?
  19. Are supporting Brains listed where needed?
  20. Is risk level assigned?
  21. Is required AI Employee identified?
  22. Is recommended workflow clear?
  23. Is validation requirement assigned?
  24. Is human review requirement clear?
  25. Is the input safe to analyze?
  26. Is next destination clear?
  27. Is recommended action specific?
  28. Is logging required?
  29. Is learning capture required?
  30. Should more input be requested before analysis?

If several of these are unclear, the input is not ready.

Normalization Decision States

After normalization, assign one decision state.

Safe To Analyze

Input is clean enough and complete enough for the next workflow.

Analyze With Caution

Input can proceed, but gaps or assumptions must remain visible.

Needs More Input

Input is not complete enough.

Request missing file, screenshot, transcript, data, or confirmation.

Clean Again

Input is too noisy and needs further cleanup.

Route To Correct Brain

Input belongs somewhere else and should be routed before analysis.

Park

Input may be useful later but should not move now.

Reject

Input is too weak, irrelevant, duplicated, or unsafe to use.

Escalate

Input affects high-risk areas and requires HeadOffice, Martyn, M, compliance, finance, or specialist review.

Application Rules

Course Absorption Rule

Course inputs must be normalized before absorption.

Do not absorb course material just because it is available.

Normalize first, then decide whether it improves MWMS.

Newsletter Rule

Newsletters must be separated into signal and noise.

Generic AI news should not become dashboard intelligence.

Brain Room Rule

Brain Room messages must be converted into structured work when they matter.

Do not let important decisions or tasks disappear into chat.

Developer Rule

Developer inputs must be anchored to visible evidence, file contents, or confirmed current state.

Memory alone is not enough.

If M has to guess, the normalization failed.

Offer Evaluation Rule

Vendor claims must be separated from evidence.

Do not let sales page hype become offer truth.

Client Workflow Rule

Future client input must be isolated, permissioned, and purpose-limited.

Do not mix client contexts.

Common Normalization Failure Modes

Normalization has failed if:

  1. Raw input is analyzed before cleaning.
  2. Noise is treated as signal.
  3. Vendor claims are treated as facts.
  4. Old memory is treated as current evidence.
  5. The source is not traceable.
  6. Missing input is ignored.
  7. Assumptions are not marked.
  8. Brain ownership is unclear.
  9. Risk level is missing.
  10. Developer evidence is incomplete.
  11. Course content is absorbed without value filtering.
  12. Newsletter content creates dashboard noise.
  13. A Brain Room message becomes a vague task.
  14. Client input is mixed with another client or workflow.
  15. Input is routed without validation.

Any of these signs require revision, re-cleaning, parking, or escalation.

Manual Use Rule

This record should be used manually before it becomes technical infrastructure.

Manual use helps MWMS learn:

  • which input fields matter most
  • which input types are most common
  • which noise patterns repeat
  • which workflows need better cleanup
  • which AI Employees need stronger context
  • which records may later become Supabase fields
  • which normalization steps are too heavy
  • which inputs should be rejected early

Manual proof comes before automation.

Future Plugin Or UI Relevance

This record may later become:

  • input intake form
  • Brain Room message normalization panel
  • Newsletter Intelligence preprocessing record
  • Course Absorption intake record
  • Offer Evaluation intake screen
  • Developer Support evidence record
  • AIBS client input intake record
  • Supabase normalization table
  • AI Manager context preparation screen

Possible future fields:

  • normalization_id
  • input_title
  • source_type
  • source_name
  • source_reference
  • date_received
  • originating_system
  • original_format
  • input_completeness
  • input_quality_level
  • noise_detected
  • useful_content_extracted
  • content_to_ignore
  • cleaned_summary
  • extracted_elements
  • known_gaps
  • assumptions_made
  • input_classification
  • owning_brain
  • supporting_brains
  • risk_level
  • priority
  • required_ai_employee
  • recommended_workflow
  • validation_requirement
  • human_review_required
  • safe_to_analyze
  • next_destination
  • recommended_action
  • logging_required
  • learning_required
  • created_at
  • updated_at

No technical build is authorized by this record alone.

Governance Role

HeadOffice owns the MWMS Messy Input Normalization Record.

HeadOffice is responsible for:

  • deciding when normalization is required
  • protecting MWMS from dirty input
  • ensuring source and gaps are clear
  • preventing weak input from becoming operational intelligence
  • protecting MCR from poor course absorption
  • protecting dashboards from newsletter noise
  • protecting M from vague developer evidence
  • protecting future AIBS clients from unsafe input handling
  • deciding when this record is ready for operational copy or plugin/UI transformation

Individual Brains may use simplified versions for their own workflows, but they must not bypass normalization for high-risk inputs.

Relationship To Other MWMS Standards

This record supports and must align with:

  • MWMS Messy Input Normalization Framework
  • MWMS AI Agent Operations Core
  • MWMS Agentic Work Unit Standard
  • MWMS Agentic Work Unit Template
  • MWMS AI Workflow Pipeline Standard
  • MWMS AI Workflow Pipeline Checklist
  • MWMS AI Output Validation Standard
  • MWMS AI Output Validation Checklist
  • MWMS AI Employee Role Card Standard
  • MWMS AI Employee Role Card Template
  • MWMS Agentic Reporting Standard
  • MWMS AI Employee Handoff Protocol
  • MWMS AI Employee Handoff Package Template
  • MWMS AI Agent Failure Handling And Escalation Protocol
  • MWMS AI Agent Outcome Measurement Framework
  • MWMS AI Agent Memory And Context Framework
  • MWMS AI Tool Permission And Access Framework
  • MWMS Brain Routing Rule
  • MWMS Brain To Brain Request Protocol
  • MWMS Supabase Event Schema
  • AI Business Systems Brain Blueprint

This record is the practical application of the MWMS Messy Input Normalization Framework.

Drift Protection

This record protects MWMS from the following forms of drift:

  1. Treating raw input as clean intelligence
  2. Summarizing before cleaning
  3. Allowing noisy newsletters into dashboards
  4. Absorbing weak course material
  5. Treating vendor claims as evidence
  6. Creating developer instructions from incomplete screenshots
  7. Routing vague Brain Room messages into live workflows
  8. Losing source origin
  9. Ignoring missing data
  10. Letting old memory override current evidence
  11. Confusing input cleanup with final validation
  12. Creating tasks from incomplete context
  13. Mixing source material with assumptions
  14. Automating input processing before cleanup patterns are understood
  15. Letting poor input create poor AI output

Any important input that has not been normalized should be treated as raw material only.

Architectural Intent

The architectural intent of the MWMS Messy Input Normalization Record is to protect the quality of intelligence entering MWMS.

MWMS will only be as strong as the input it processes.

As the system grows, more information will enter from more sources.

Without normalization, the system becomes noisy.

With normalization, MWMS can turn raw information into usable intelligence, structured tasks, better reports, safer decisions, and stronger automation.

The long-term goal is that every meaningful input can answer:

  • What came in?
  • Where did it come from?
  • Is it complete?
  • Is it clean?
  • What noise was removed?
  • What useful content was extracted?
  • What should be ignored?
  • What gaps remain?
  • What assumptions exist?
  • Which Brain owns it?
  • What workflow should handle it?
  • Is it safe to analyze?
  • Where should it go next?

When MWMS can answer those questions, messy information becomes controlled intelligence.

Change Log

v1.0 — Initial Draft

Created the MWMS Messy Input Normalization Record as the practical operational template for converting raw, messy, incomplete, noisy, duplicated, or unstructured input into clean, classified, validated, and routable MWMS intelligence.

This record operationalizes the MWMS Messy Input Normalization Framework and supports Course Absorption, Newsletter Intelligence, Brain Room, Offer Evaluation, Research, Developer Support, MCR page creation, dashboard review, and future AIBS client workflows.