Document Type: Operating Framework
Authority Level: MCR Source Of Truth
Status: Active
Version: v1.1
Primary Location: MCR
Future Operational Destination: Data Brain, Research Brain, AIBS Brain, Client Intelligence Systems, Automation Brain, HeadOffice Brain, Compliance Brain, Risk Brain
Parent Page: Data Brain
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: AI Automations by Jack AI Native Entrepreneur Architecture And Tool Decision Block and Client Intelligence, RAG, Email Memory, Dashboard, Research, Website Scraping, Browser Copilot, and Personalised Communication Block
MWMS Classification: RAG Framework / Knowledge Base Infrastructure Framework / Client Memory Framework / Living Relationship Intelligence Framework / Vector Memory Standard / Source Based AI Retrieval Standard
Primary Brain: Data Brain
Supporting Brains: Research Brain, AIBS Brain, Automation Brain, HeadOffice Brain, Compliance Brain, Risk Brain, Sales Brain, Content Brain, Product Brain, UX Brain, Prompting Framework
Related Pages: MWMS Supabase RAG And Vector Memory Framework, MWMS Client Intelligence And Business Memory Automation Framework, MWMS AIBS Automation Audit And Opportunity Mapping Framework, MWMS Automation Architecture And Tool Selection Framework, MWMS Source Visibility And Evidence Display Standard, MWMS AI Observability Metadata Standard, MWMS AI Automation Security And Risk Checklist, MWMS Prompt Architecture And Automation Output Reliability Framework, MWMS Client Intelligence Report Automation Framework, MWMS Client Communication Automation Framework, MWMS AI Assisted Outreach And Sales Follow Up Automation Framework
Purpose
The purpose of the MWMS RAG Knowledge Base And Client Memory Infrastructure Framework is to define how MWMS creates reliable, source based knowledge systems that allow AI Employees, client assistants, diagnostic systems, report generators, support agents, voice agents, communication systems, and business intelligence tools to answer and act from approved knowledge rather than generic model memory.
This framework exists because many MWMS systems will need to work from:
uploaded documents
client files
website content
SOPs
sales decks
case studies
training materials
FAQs
call transcripts
emails
meeting notes
Google Drive files
internal MCR pages
business knowledge bases
client intelligence records
research documents
course transcripts
support histories
customer feedback
product documentation
CRM records
onboarding answers
campaign history
customer interaction history
relationship history
sales activity
client preferences
changing client circumstances
business events
approved behavioural signals
The core purpose is:
To help MWMS build RAG and knowledge base systems that retrieve the right information, preserve source context, avoid stale knowledge, reduce hallucination, protect client data, create useful business memory, and maintain living relationship intelligence that improves future communication and service delivery.
Core Doctrine
The MWMS doctrine is:
AI should answer from approved knowledge when the task depends on business facts.
Generic AI is useful for general thinking.
But client systems, internal Brains, business reports, support agents, AIBS diagnostics, sales systems, and personalised communication systems need grounded memory.
A good RAG and client memory system allows AI to:
search approved sources
retrieve relevant context
answer from business-specific material
avoid pretending to know what is missing
cite or reference source material where needed
update when documents or circumstances change
remove outdated knowledge
keep client memory separate
preserve confidence and source metadata
support better diagnosis and decision-making
support accurate personalisation
remember relevant relationship context
distinguish enduring facts from temporary campaign context
detect when new information conflicts with old information
record when and how important information was learned
support communication without exposing private information inappropriately
The key doctrine is:
Memory without source control becomes misinformation.
Personalisation without identity and privacy control becomes risk.
Strategic Importance
This framework is strategically important because RAG and client memory are infrastructure foundations for the MWMS ecosystem.
It supports:
AIBS client memory
AIBS Brain
Research Brain
Data Brain
HeadOffice Brain
Content Brain
Sales Brain
Client Intelligence reports
knowledge based chatbots
WhatsApp assistants
AI voice agents
internal support assistants
proposal assistants
business diagnostic tools
client onboarding systems
prompt vault retrieval
MCR page retrieval
course absorption intelligence
future AI Employee memory
relationship intelligence
context-aware outreach
client-specific reports
customer lifecycle communication
account management
client retention systems
business event monitoring
personalised support
memory-backed sales follow-up
The AI Native Entrepreneur RAG material showed a practical pattern where documents are placed into a Google Drive folder, processed into database records, embedded into a vector searchable structure, moved into a processed folder, and later deleted from memory when placed into a delete folder.
The later client intelligence material expanded this pattern by showing that client memory must also include continuously changing information such as:
new emails
meeting outcomes
updated customer goals
support interactions
sales history
campaign responses
community activity
CRM changes
new business facts
changing preferences
relationship events
This matters because a knowledge base is not only about adding information.
It must support:
processing
storage
retrieval
source metadata
deletion
freshness
confidence
governance
identity separation
fact history
relationship continuity
contradiction resolution
contextual communication
human review
The strategic upgrade is:
MWMS should not build AI assistants that merely sound smart.
MWMS should build AI assistants that know:
where their answers came from
which person or organisation the information belongs to
when the information was learned
whether the information is still current
whether the information may be used
how confidently it should be applied
Definition
RAG means retrieval augmented generation.
In MWMS terms, RAG means:
The AI retrieves relevant approved knowledge before it answers, drafts, recommends, communicates, or acts.
Knowledge base means an organised collection of approved information that AI systems are allowed to search.
Embedding means converting text into numerical form so similar ideas can be retrieved by meaning rather than only exact keywords.
Vector memory means stored embedded knowledge that can be searched semantically.
Client memory means approved business-specific and relationship-specific knowledge about a client that can be retrieved for diagnostics, reports, support, sales, communication, account management, and automation.
Living client memory means client knowledge that can be updated as new verified interactions and business events occur.
Relationship intelligence means approved context about the history, goals, preferences, commitments, concerns, and interactions between MWMS and a client or customer.
Source metadata means information attached to each stored record so MWMS knows where it came from, when it was captured, who approved it, what client or person it belongs to, and how reliable it is.
Temporal metadata means information explaining when a fact became valid, when it was learned, when it was reviewed, and whether it has expired or been replaced.
Campaign context means temporary instructions or facts used for a specific communication or campaign that should not automatically become permanent client memory.
MWMS Definition
The MWMS RAG Knowledge Base And Client Memory Infrastructure Framework is:
Data Brain’s standard for creating, maintaining, retrieving, updating, deleting, and governing source based AI knowledge and relationship memory systems so MWMS Brains and AI Employees can answer and communicate from approved business context instead of unsupported general model assumptions.
Scope
This framework applies to:
RAG systems
vector memory systems
Supabase vector systems
Pinecone style memory systems
client knowledge bases
living client memory systems
relationship intelligence systems
internal MWMS knowledge bases
document upload pipelines
Google Drive based knowledge intake
MCR page retrieval
business memory automation
client support assistants
voice agent knowledge bases
WhatsApp assistant memory
website chatbot memory
proposal generation memory
report generation memory
content generation from approved sources
AI employee memory
prompt vault retrieval
client intelligence systems
AIBS diagnostic systems
customer lifecycle communication systems
context-aware sales follow-up
personalised outreach systems
CRM-connected memory
meeting and email memory ingestion
campaign personalisation systems
This framework does not provide development instructions.
It defines the operating rules for safe RAG infrastructure, business memory, relationship intelligence, and knowledge governance.
Core Principle
The core principle is:
Retrieval is only useful when the source is trusted, current, relevant, identity-matched, and allowed.
A RAG or client memory system is not automatically reliable.
It can still fail if:
poor documents are uploaded
old documents are not removed
sources are not tagged
client data is mixed
customer identities are confused
private information is exposed
retrieval pulls the wrong chunk
AI overstates retrieved context
metadata is missing
deletion is not handled
human review is skipped
source confidence is unknown
temporary campaign information becomes permanent memory
new information conflicts with older information
one client’s communication uses another client’s facts
personalisation reveals information the recipient did not expect to be used
Rule
RAG and client memory must be treated as governed infrastructure, not a magic memory folder.
The MWMS RAG Knowledge Base And Client Memory Model
Every MWMS RAG and client memory system should be designed across sixteen layers:
Knowledge Purpose Layer
Identity And Entity Layer
Source Intake Layer
Permission And Sensitivity Layer
Knowledge Classification Layer
Chunking And Processing Layer
Embedding And Vector Layer
Metadata And Source Layer
Storage And Database Layer
Retrieval And Ranking Layer
Context Assembly Layer
Answer And Communication Generation Layer
Contradiction And Temporal Change Layer
Deletion And Freshness Layer
Observability And Testing Layer
Governance And Improvement Layer
- Knowledge Purpose Layer
Every RAG or client memory system must start with a purpose.
Do not build a knowledge base just because documents or customer data exist.
Purpose Questions
Ask:
what will this knowledge base answer
what communication will it support
who will use it
which Brain owns it
is it internal or client-facing
is it for support
is it for diagnostics
is it for reports
is it for content
is it for sales
is it for voice agents
is it for employee training
is it for client intelligence
is it for relationship management
is it for personalised communication
what decision or workflow does it improve
what information should never be used
Valid Purpose Examples
Use RAG and client memory to:
answer customer questions
answer team questions
support AI voice agents
support WhatsApp assistants
create client reports
generate business diagnostics
draft proposals
retrieve SOPs
search training materials
support course absorption
support research synthesis
support content creation from approved sources
support internal Brain memory
personalise client follow-up
remember approved client goals
maintain service continuity
support account management
use verified interaction history in future communications
identify changing customer needs
Weak Purpose Examples
Avoid:
“store everything”
“make AI smarter”
“dump all client files in”
“upload every email”
“build a second brain without structure”
“let the AI figure it out”
“we might need it later”
“personalise everything possible”
“remember every detail forever”
Rule
No RAG or client memory system should be created without a defined knowledge and operational purpose.
- Identity And Entity Layer
Every knowledge record must belong to a clearly identified entity.
Entity Types
Possible entities include:
MWMS
Brain
client organisation
prospect organisation
customer
employee
supplier
partner
campaign
project
product
offer
service
meeting
conversation
document
Identity Keys
Possible stable identity keys include:
client ID
customer ID
CRM record ID
verified email address
organisation ID
project ID
account ID
source ID
document hash
conversation ID
Identity Rules
The system must:
use stable identifiers
avoid relying only on names
prevent duplicate identities
detect identity conflicts
separate people from organisations
separate organisations with similar names
preserve source-to-entity linkage
avoid mixing client memories
avoid inferring identity from weak signals alone
Rule
Every memory record must know who or what it belongs to.
Client Isolation Standard
Client isolation must exist at:
source level
record level
chunk level
vector level
query level
output level
access level
log level
One client’s information must not be available to another client’s retrieval process.
Cross-client learning may use anonymised patterns where authorised.
Raw client-specific information must remain isolated.
- Source Intake Layer
The quality of the RAG system depends on source quality.
Source Types
Sources may include:
PDFs
Google Docs
Word documents
spreadsheets
website pages
service pages
sales decks
case studies
SOPs
training documents
FAQs
product documentation
onboarding files
call transcripts
meeting notes
email exports
individual emails
chat transcripts
support tickets
review data
social content
newsletter content
MCR pages
course transcripts
client reports
competitor pages
public articles
approved internal notes
CRM records
form submissions
calendar outcomes
community activity
client-provided preferences
sales interactions
support interactions
communication responses
Source Intake Questions
Ask:
what is the source
who owns it
who approved it
which entity it belongs to
is it current
is it complete
is it accurate
is it sensitive
does it belong to a client
does it belong to a person
does it need redaction
does it need summarising first
is it worth storing
should it be temporary or long term
does it need deletion later
is it an explicit fact or an inference
is it campaign context or durable memory
Source Folder Pattern
A simple source intake system may use:
To Add folder
Added or Processed folder
Delete folder
Error folder
Review Needed folder
The course example used a Google Drive style intake where documents placed into a To Add folder were processed into the database and then moved into an Added folder so the operator could visually see that the files had been processed.
Rule
Every source must enter through a controlled intake path.
Continuous Intake Standard
Living client memory may receive ongoing inputs.
These inputs may include:
new emails
meeting transcripts
support tickets
form updates
CRM changes
purchase history
campaign responses
account manager notes
client approvals
business announcements
website changes
Continuous intake must not mean uncontrolled intake.
Each incoming record must pass:
identity matching
permission checks
relevance checks
sensitivity checks
source classification
memory classification
deduplication
conflict checking
- Permission And Sensitivity Layer
RAG and client memory systems can expose sensitive information if poorly governed.
Permission Types
Sources may be:
public
internal MWMS approved
client approved
client confidential
customer sensitive
employee sensitive
regulated
temporary processing only
excluded from AI use
approved for internal use only
approved for external communication
approved for analysis but not quotation
Sensitivity Levels
Use:
Level 1 Public
Public website, public article, public marketing content.
Level 2 Internal
MWMS internal frameworks, non-sensitive SOPs, course notes.
Level 3 Client Confidential
Client sales decks, internal SOPs, private business documents.
Level 4 Customer Sensitive
Customer records, support conversations, emails, personal data.
Level 5 Restricted
Health, legal, financial, employee, payment, identity, or highly sensitive records.
Permission Questions
Ask:
are we allowed to process this source
are we allowed to store this source
are we allowed to use it in AI output
are we allowed to use it in personalised communication
are we allowed to expose answers to staff
are we allowed to expose answers to customers
does the client know this is being used
is AI processing approved
should the source be redacted
should it be excluded from retrieval
who can access the memory
how long may it be retained
should the information be visible in generated communication
Rule
Private data must not enter RAG or client memory without permission and sensitivity labelling.
Personalisation Privacy Rule
A fact being available does not mean it should be used in communication.
Before using memory in a message, the system must ask:
is the fact relevant
is the fact accurate
is the fact current
is its use expected
could its use feel intrusive
could it reveal private information
could it expose internal notes
could it damage trust
could it create discrimination or unfair treatment
Rule
Personalisation must be useful, appropriate, and proportionate.
- Knowledge Classification Layer
Every stored record should be classified by the kind of knowledge it represents.
Knowledge Classes
Use:
Verified Organisational Fact
Approved information about a company, product, service, offer, policy, or process.
Verified Client Fact
Approved information about a client organisation.
Verified Individual Fact
Approved information about an identified person.
Relationship Fact
An approved fact about the history or state of the relationship.
Preference
A stated preference that may influence communication or delivery.
Goal
A stated desired outcome.
Constraint
A stated limitation, risk, boundary, or requirement.
Commitment
A promise, agreement, or assigned obligation.
Interaction Record
Evidence that an interaction occurred.
Behavioural Signal
An observed action that may be relevant but requires cautious interpretation.
Inference
A conclusion derived from evidence but not directly stated.
Temporary Context
Information relevant only to a current campaign, meeting, or task.
Expired Fact
Information no longer considered current.
Disputed Fact
Information contradicted by another source.
Prohibited Memory
Information that must not be stored or used.
Rule
Facts, preferences, signals, and inferences must not be treated as the same thing.
Durable Memory Rule
A record should become durable memory only when:
it has a clear purpose
it is linked to the correct identity
it is sufficiently reliable
retention is justified
future use is appropriate
it is not merely temporary campaign context
- Chunking And Processing Layer
Documents and interactions must be processed into useful pieces.
Poor chunking creates poor retrieval.
Processing Steps
Processing may include:
file detection
text extraction
OCR only when necessary
cleaning
splitting into chunks
preserving headings
preserving document title
preserving page or section reference
preserving speaker identity
preserving timestamps
tagging
summarising
metadata creation
entity linking
memory classification
embedding
storage
processed file movement
Chunking Questions
Ask:
how large should each chunk be
should chunks overlap
are headings preserved
is page reference preserved
are speaker and timestamp preserved
are tables handled correctly
are images or diagrams important
is the text clean
are repeated headers removed
are irrelevant sections excluded
should the document be summarised first
should the interaction be split by topic
should facts be extracted into separate records
Chunk Quality Rules
Good chunks should:
contain one coherent idea
preserve enough context
include source identity
include entity identity
avoid being too long
avoid being too short
retain useful headings
retain meaningful timestamps where relevant
allow retrieval by meaning
support accurate answering
Rule
Chunking should preserve meaning, not just split text mechanically.
Interaction Processing Standard
Emails, meetings, and support conversations may require both:
the original interaction record
structured memory extracted from that interaction
The original interaction should not automatically be replaced by the extracted memory.
Important extracted facts should retain a link to the source interaction.
- Embedding And Vector Layer
Embedding converts text into searchable meaning.
The RAG material explained embeddings as numerical representations that allow the system to find the right drawer of information when a user asks a question.
Embedding Questions
Ask:
which embedding model is used
what dimension is required
what language support is needed
what cost applies
what database stores the vector
can vectors be deleted
can vectors be updated
is metadata stored with the vector
is the embedding model suitable for the content
does the vector belong to the correct client namespace
Vector Store Options
Possible vector stores include:
Supabase vector
Pinecone
other vector databases
managed RAG platforms
internal MWMS future vector infrastructure
Rule
Embeddings are not the answer.
They are the retrieval map.
Vector Isolation Rule
Where client data is stored in vector memory, the system must use strong isolation through:
separate namespaces
mandatory client filters
row-level controls
separate stores where necessary
access-controlled queries
retrieval testing
- Metadata And Source Layer
Metadata is what makes memory governable.
Without metadata, RAG becomes a black box.
Required Metadata Fields
Each knowledge record should include:
Client Or Brain:
Entity ID:
Entity Type:
Source Name:
Source Type:
Source URL Or Location:
Document Title:
Section Or Page:
Source Interaction ID:
Date Captured:
Date Learned:
Valid From:
Valid Until:
Last Reviewed:
Permission Level:
Sensitivity Level:
Knowledge Class:
Topic:
Tags:
Owner:
Source Confidence:
Retention Rule:
Version:
Hash Or Source ID:
Processed Status:
Deletion Status:
Human Verified:
Useful Metadata Fields
Optional fields:
department
workflow area
customer journey stage
offer
service
audience
document category
language
country
compliance flag
stale after date
replaced by source
source priority
campaign ID
project ID
relationship stage
communication suitability
fact status
contradiction status
inference confidence
Metadata Use Cases
Metadata allows MWMS to:
retrieve only one client’s information
retrieve only one person’s information
filter by topic
exclude sensitive sources
remove outdated documents
delete all chunks from one file
preserve source confidence
route outputs to the correct Brain
separate facts from assumptions
track stale knowledge
separate temporary context from durable memory
identify replaced facts
trace personalisation decisions
Rule
Every chunk and memory record must know where it came from, who it belongs to, and whether it may be used.
- Storage And Database Layer
The RAG system needs clear storage decisions.
Storage Types
Use:
source file storage
extracted text storage
chunk storage
vector storage
metadata storage
client fact storage
relationship event storage
chat history storage
query log storage
output log storage
deletion log storage
review status storage
conflict history storage
communication influence log
Database Options
Use:
Supabase
Pinecone
WordPress database
Google Drive
Airtable
Google Sheets
custom database
future MWMS memory infrastructure
Storage Questions
Ask:
where are original files stored
where are chunks stored
where are embeddings stored
where is metadata stored
where are client facts stored
where is interaction history stored
where is chat history stored
where are outputs logged
where are delete requests logged
is storage client separated
is access controlled
can data be exported
can data be deleted
can facts be versioned
can conflicts be preserved
Rule
The original source, extracted knowledge, embedding, metadata, identity, and fact history must not become disconnected.
- Retrieval And Ranking Layer
Retrieval is where RAG and client memory succeed or fail.
Retrieval Questions
Ask:
what question is being asked
what task is being performed
which person or client is involved
what source set should be searched
what client or Brain should be searched
what sources should be excluded
how many chunks should be retrieved
should metadata filters be applied
should recent sources rank higher
should verified sources rank higher
should direct statements outrank inference
should temporary context be included
should low-confidence sources be excluded
should the answer include source references
should the AI say when nothing relevant is found
Retrieval Filters
Use filters such as:
client
entity
Brain
source type
knowledge class
topic
date
validity period
permission level
sensitivity level
source confidence
document status
verified status
retention status
campaign
project
relationship stage
Retrieval Failure Examples
Failures include:
wrong client retrieved
wrong person retrieved
old document retrieved
irrelevant chunk retrieved
sensitive source retrieved
temporary context treated as permanent
too many chunks retrieved
too few chunks retrieved
AI answers from general knowledge instead of source
AI invents missing details
outdated preference is used
disputed fact is presented as confirmed
Rule
Retrieval must be filtered by identity and context, not only similarity.
Retrieval Priority Standard
Where sources conflict, priority should generally favour:
current approved source
direct explicit statement
authoritative source
human-verified record
recent valid record
high-confidence source
relevant client-specific source
Lower-priority sources should not silently override higher-priority sources.
- Context Assembly Layer
Retrieved information must be assembled before generation.
Context Sets
The system may assemble separate context sets for:
organisational knowledge
client organisation knowledge
individual customer knowledge
relationship history
current campaign context
current conversation context
recent events
approved offer information
task instructions
The system should not blend these sets without clear labels.
Context Assembly Pattern
A strong context assembly may include:
Task Or Campaign Intent
What the system is currently trying to do.
Organisational Truth
Approved business information relevant to the task.
Client Organisation Context
Relevant facts about the client organisation.
Individual Context
Approved information about the person.
Relationship Context
Relevant prior interactions, commitments, and outcomes.
Current Event Context
Recent changes or events relevant to the task.
Restrictions
Information that must not be used or exposed.
Rule
Company knowledge, customer memory, and temporary campaign instructions must remain distinguishable.
- Answer And Communication Generation Layer
The AI must answer and communicate from retrieved knowledge responsibly.
Answering Rules
The AI should:
answer from retrieved context
identify when context is missing
avoid unsupported claims
avoid overconfidence
preserve source distinction
include citations or source references where required
separate fact from interpretation
ask for more information when needed
recommend human review for high-risk outputs
avoid exposing sensitive information unnecessarily
Communication Rules
When generating personalised communication, the AI should:
use relevant approved context
avoid unnecessary personal details
avoid revealing internal notes
avoid pretending to remember facts that were not retrieved
avoid using disputed or stale information
avoid over-personalisation
preserve campaign intent
follow approved brand voice
record which facts influenced the message where required
support draft-first review for sensitive communication
Answer Types
RAG and memory outputs may include:
direct answer
summary
report section
proposal draft
support reply
customer reply
internal note
content draft
sales call prep
diagnostic finding
opportunity recommendation
personalised outreach
account update
client follow-up
renewal communication
Rule
If retrieved context does not support the answer or communication, the AI must not pretend that it does.
Personalisation Standard
Personalisation quality should be judged by:
accuracy
relevance
timeliness
appropriateness
usefulness
privacy
trust
business value
Conversion alone is not a sufficient measure of personalisation quality.
- Contradiction And Temporal Change Layer
Client memory changes over time.
The system must handle new facts that conflict with older facts.
Examples
A client changes their preferred communication channel.
A customer changes role or company.
A client’s budget changes.
A previous objection is resolved.
A product is discontinued.
A deadline is extended.
A business goal changes.
A person corrects information previously supplied.
Contradiction Process
When a conflict is detected:
identify the conflicting records
compare source authority
compare dates
compare confidence
check whether the facts may both be valid for different periods
mark the old record as replaced, disputed, or expired
preserve history where justified
route material conflicts for human review
Rule
New information must not silently overwrite important historical facts.
Temporal Fact Standard
Each changing fact should support:
date learned
valid from
valid until
current status
replaced by
review date
source reference
Fact Status Values
Use:
Current
Historical
Expired
Replaced
Disputed
Unverified
Review Needed
Rule
Client memory must distinguish what is true now from what used to be true.
- Deletion And Freshness Layer
RAG systems must remove or replace old information.
The RAG file showed that deleting the original file from a folder is not enough.
The corresponding stored database records must also be deleted or retired.
Deletion Reasons
Delete or retire knowledge when:
document is outdated
client revokes permission
source is wrong
source is replaced
customer data should not be stored
retention period ends
privacy request is received
duplicate data exists
test data is no longer needed
project is closed
relationship ends
information is no longer relevant
memory was incorrectly assigned
Freshness Questions
Ask:
when was this source captured
when was this fact learned
is it still current
has the business changed
has the customer changed
has pricing changed
has the offer changed
has the SOP changed
has the website changed
has the source been superseded
should this be reprocessed
should old chunks be removed
should the fact become historical
Deletion Standard
Deletion should remove or retire:
original file if required
extracted text
chunk records
embeddings
metadata records
client fact records
relationship memory where required
related source references where required
access to the deleted source
Deletion should preserve only what is legally and operationally justified, such as:
deletion log
who deleted it
why it was deleted
date deleted
source ID or hash
audit note where needed
Rule
A RAG or client memory system without deletion control becomes dangerous over time.
Memory Review Standard
Different memory types require different review frequencies.
Examples:
pricing and offers require frequent review
client role and contact information require periodic review
legal and compliance information require controlled review
historical meeting records may remain unchanged
temporary campaign context should expire quickly
- Observability And Testing Layer
RAG and client memory systems must be tested.
Test Questions
Ask:
does the system retrieve the right source
does it retrieve the correct client
does it retrieve the correct individual
does it ignore wrong sources
does it answer only from context
does it say when it does not know
does it handle deleted sources
does it handle updated sources
does it separate clients
does it preserve sensitive boundaries
does it log retrieved chunks
does it handle poor questions
does it handle contradictory sources
does it hallucinate
does it avoid intrusive personalisation
does it distinguish campaign context from durable memory
Observability Fields
Track:
User Query:
Task Type:
Client ID:
Entity ID:
Retrieved Source IDs:
Retrieved Chunks:
Retrieved Fact IDs:
Source Confidence:
Context Sets Used:
Answer Generated:
Communication Generated:
Facts Influencing Output:
Model Used:
Prompt Version:
Human Review Needed:
Accepted Or Corrected:
Error:
Date:
Rule
If MWMS cannot see what the system retrieved and used, MWMS cannot trust the output.
Personalisation Audit Standard
For high-value or sensitive communications, the system should be able to show:
which client record was used
which facts influenced the message
which source supported each fact
whether any fact was inferred
whether the information was current
whether the message was approved
- Governance And Improvement Layer
RAG and client memory systems need ongoing governance.
Governance Questions
Ask:
who owns the knowledge base
who owns client memory
who can add sources
who can create durable memory
who can delete sources
who approves private sources
who reviews stale information
who checks hallucination risk
who maintains metadata
who resolves identity conflicts
who resolves contradictory facts
who monitors failures
who handles client deletion requests
who decides when memory becomes production grade
who approves memory use in communication
Improvement Inputs
Improve the system using:
failed queries
bad retrieval examples
human corrections
user feedback
stale source reviews
new documents
updated prompts
better metadata
better chunking
better filters
better source confidence scoring
client corrections
communication responses
support outcomes
relationship changes
Rule
A knowledge base or memory system must be maintained or it becomes a liability.
Knowledge Base Types
MWMS may create several types of RAG and memory systems.
Type 1: Internal MWMS Knowledge Base
Purpose:
retrieve MCR standards
support course absorption
support AI Employees
support HeadOffice decisions
support internal strategy
Primary users:
Martyn
M
AI Employees
future MWMS operators
Risk level:
medium, depending on source content
Type 2: AIBS Client Knowledge Base
Purpose:
support client diagnostics
answer business questions
generate reports
map opportunities
support proposals
Primary users:
AIBS Brain
Client Intelligence systems
Sales Brain
client facing reports
Risk level:
medium to high
Type 3: Living Client Memory System
Purpose:
maintain approved client and relationship context over time
support contextual communication
support account management
support service continuity
support personalised follow-up
support lifecycle decisions
Primary users:
AIBS Brain
Sales Brain
Client Communication systems
HeadOffice
account management systems
Risk level:
high
Type 4: Customer Support Knowledge Base
Purpose:
answer customer questions
support chatbots
support WhatsApp assistants
support voice agents
reduce support workload
Primary users:
customer service AI
support staff
customers
Risk level:
high if customer facing
Type 5: Sales And Proposal Knowledge Base
Purpose:
retrieve case studies
retrieve offer details
retrieve pricing logic
retrieve objections
support proposal drafting
Primary users:
Sales Brain
AIBS Brain
proposal assistants
Risk level:
medium
Type 6: Content Knowledge Base
Purpose:
retrieve approved content
preserve brand voice
repurpose source material
create educational assets
support AI visibility
Primary users:
Content Brain
Social Media Brain
Affiliate Brain
AIBS Brain
Risk level:
medium
Type 7: Voice Agent Knowledge Base
Purpose:
give voice agents business knowledge
answer caller questions
route calls
qualify leads
support appointment booking
Primary users:
AI voice agents
Sales Brain
AIBS Brain
local business systems
Risk level:
high because output is live conversation
RAG And Client Memory Intake Checklist
Before adding a knowledge source or memory record, confirm:
Source
source name
source type
source owner
source location
source date
source purpose
source quality
source status
Entity
client ID
person ID
organisation ID
relationship to MWMS
identity confidence
duplicate identity check
Permission
public or private
client approval
AI processing approval
storage approval
communication use approval
allowed users
excluded users
retention rule
Sensitivity
personal data
customer data
staff data
confidential business data
regulated data
public data
internal data
Knowledge Classification
verified fact
preference
goal
constraint
commitment
interaction
behavioural signal
inference
temporary context
expired fact
prohibited memory
Processing
extract method
chunking rule
metadata fields
topic tags
source confidence
stale after date
deletion rule
Rule
No source should enter RAG or client memory without metadata, identity, permission, and purpose review.
Knowledge Record Standard
Each stored knowledge record should include:
Record ID:
Client Or Brain:
Entity ID:
Entity Type:
Source ID:
Source Name:
Source Type:
Document Title:
Chunk Text Or Fact:
Embedding:
Knowledge Class:
Topic:
Tags:
Permission Level:
Sensitivity Level:
Communication Use Allowed:
Source Confidence:
Inference Confidence:
Date Captured:
Date Learned:
Valid From:
Valid Until:
Last Reviewed:
Stale After:
Retention Rule:
Hash Or File ID:
Status: Current / Historical / Stale / Replaced / Disputed / Deleted / Review Needed
Human Verified: Yes / No
Replaced By:
Contradiction Status:
Rule
A knowledge record must be traceable, filterable, identity-matched, time-aware, and deletable.
Source Confidence Standard
RAG and client memory systems must label source confidence.
High Confidence Sources
Examples:
official client documents
current approved SOPs
signed proposals
current service pages
current product documentation
verified call transcripts
approved MCR pages
client supplied training material
explicit verified customer statements
approved CRM records
Medium Confidence Sources
Examples:
public website pages
social posts
public reviews
old but still useful reports
staff notes
informal meeting summaries
competitor pages
unverified interaction summaries
Low Confidence Sources
Examples:
unverified AI summaries
copied notes with no source
outdated pages
incomplete transcripts
unclear third-party content
rough workshop notes
unapproved scraped content
behavioural assumptions
Rule
Low-confidence sources should not drive high-confidence recommendations or personalised communication without human review.
Retrieval Safety Standard
Before using retrieved context, the system should check:
client match
individual match
Brain match
source confidence
permission level
sensitivity level
freshness
validity period
relevance
contradiction
knowledge class
communication suitability
output risk
human review requirement
Rule
The system should retrieve the best allowed context, not merely the closest semantic match.
RAG Answering Standard
When answering from RAG, the AI should follow this pattern:
Understand the user question.
Identify the correct client, person, Brain, or entity.
Retrieve relevant approved context.
Separate organisational, client, relationship, and temporary task context.
Check whether context is sufficient.
Check whether important facts conflict.
Answer from the retrieved context.
State uncertainty when context is weak.
Avoid unsupported general claims.
Include source reference where required.
Recommend human review when output is high risk.
Log retrieval and output.
Rule
RAG answers must be source-led and identity-safe.
Client Memory Communication Standard
When generating communication from client memory, the system should:
identify the communication objective
identify the recipient
retrieve only relevant client and relationship context
retrieve approved organisational truth
exclude prohibited or sensitive memory
check freshness and contradiction status
draft the message using approved voice rules
avoid over-personalisation
record important memory used
route for human approval where required
store the resulting interaction according to retention rules
evaluate whether the interaction creates new durable memory
Rule
Communication generation and memory updating are separate controlled stages.
Document Add Process
A standard document add process should include:
File placed into approved intake location.
Automation detects new file.
File identity and ownership are established.
File text is extracted.
Text is cleaned.
Text is split into chunks.
Metadata is added.
Embeddings are created.
Records are stored.
Original file is moved to processed folder.
Processing log is created.
Errors are routed to review.
Rule
The operator should be able to see whether a file has been processed successfully.
Interaction Memory Add Process
A standard email, meeting, or support memory process should include:
Interaction is captured through an approved source.
Participants and entities are identified.
Permission and sensitivity are checked.
Original interaction is stored or referenced.
Potential facts, commitments, preferences, goals, and constraints are extracted.
Each proposed memory is classified.
Confidence and source evidence are assigned.
Duplicate and contradiction checks are performed.
Temporary context is separated from durable memory.
Human review occurs where required.
Approved memory is stored.
The interaction and memory records are linked.
Rule
Not every sentence in a conversation should become durable memory.
Document Delete Process
A standard document delete process should include:
File or source ID is marked for deletion.
System identifies related stored chunks.
System identifies matching source hash or file ID.
Related vectors and records are deleted or retired.
Original file is removed or archived where required.
Deletion log is created.
Retrieval tests confirm deleted content is no longer used.
Rule
Deleting a file from storage is not enough if its chunks remain in vector memory.
Client Memory Correction Process
When a client or authorised operator corrects information:
identify the affected record
verify the correct identity
record the correction source
mark the old fact as replaced or disputed
store the corrected fact
preserve necessary audit history
update embeddings and retrieval status
test that the old fact is no longer treated as current
Rule
Corrections must change future retrieval behaviour.
Chat History Standard
Some RAG and client memory systems may store chat history.
Chat History Uses
Chat history can support:
better follow-up answers
user context
support review
client intelligence
content ideas
product improvement
common question analysis
frustration detection
sales insight
report generation
relationship continuity
Chat History Risks
Risks include:
storing personal data
storing sensitive questions
unclear retention
client confidentiality
customer privacy
using chat history without consent
treating casual statements as permanent facts
cross-user contamination
Rule
Chat history should be stored only when it has a clear purpose, identity link, and retention rule.
Hallucination Protection Standard
RAG reduces hallucination but does not eliminate it.
Protection Rules
Use:
source-only answering prompts
no context, no answer rule
uncertainty statements
source confidence labels
human review
retrieval logs
output validation
answer quality testing
stale source warnings
conflicting source warnings
identity filters
fact-status checks
Required Instruction
Important RAG systems should include a rule such as:
If the retrieved context does not contain the answer, say that the knowledge base does not currently contain enough information.
Rule
RAG systems must be designed to admit missing knowledge.
Client Facing RAG Standard
Client-facing RAG systems need stronger controls.
Client Facing Requirements
Required:
approved source list
sensitivity review
user access control
client isolation
answer boundaries
fallback message
human escalation
audit log
retrieval log
delete process
privacy note
testing
client approval
Rule
A client-facing knowledge assistant must be safer than an internal research assistant.
Living Client Memory Standard
Living client memory systems require:
stable client identity
stable person identity
approved intake sources
temporal metadata
durable versus temporary classification
fact versus inference separation
contradiction handling
client isolation
privacy controls
communication-use controls
correction process
deletion process
auditability
Rule
Living memory must improve service continuity without becoming uncontrolled surveillance.
Voice Agent RAG Standard
Voice agents using RAG need extra caution because answers happen live.
Voice Agent Requirements
Use:
short retrieved context
low latency retrieval
verified knowledge base
identity confirmation where personal information is involved
fallback to human
disclosure rules
call logging
post-call analysis
answer boundaries
appointment or routing limits
no unsupported claims
Rule
Voice agents must not improvise beyond approved knowledge when answering business-specific questions.
AIBS Diagnostic RAG Standard
AIBS can use RAG to support client diagnostics.
Diagnostic Uses
Use RAG to retrieve:
client SOPs
sales decks
service descriptions
customer feedback
reviews
call notes
meeting notes
workflow documents
prior reports
competitor findings
Diagnostic Rules
The system should:
preserve source evidence
separate fact from inference
highlight missing data
support opportunity mapping
support first project selection
require human review before proposal
Rule
AIBS diagnostic RAG should support recommendations, not blindly make them.
RAG And Client Memory Quality Scorecard
Score each system out of 100.
Score Categories
Knowledge Purpose Clarity: 8
Identity And Client Isolation: 10
Source Quality: 8
Permission Safety: 10
Metadata Completeness: 8
Knowledge Classification: 8
Chunk Quality: 6
Retrieval Accuracy: 10
Temporal And Contradiction Control: 8
Freshness And Deletion Control: 8
Answer And Communication Grounding: 8
Observability And Governance: 8
Interpretation
85–100: Strong production-ready system subject to approved use
70–84: Good system with minor improvements
55–69: Internal use only with human review
40–54: Too weak for client use
Below 40: Do not use yet
Rule
Client-facing and personalised communication systems require high scores and strong isolation testing.
RAG Build Readiness Checklist
Before building a RAG or client memory system, confirm:
Purpose
use case defined
owner defined
user defined
output type defined
communication use defined
success metric defined
Identity
client ID defined
person ID defined
entity matching method defined
duplicate handling defined
client isolation defined
Sources
source list defined
source permission confirmed
sensitivity reviewed
source confidence assigned
source update pattern understood
temporary versus durable memory rule defined
Data
database selected
metadata fields defined
client separation defined
retention rule defined
deletion process defined
fact status defined
contradiction process defined
AI
embedding model selected
retrieval method defined
prompt rules defined
no context no answer rule added
human review points defined
personalisation boundaries defined
Security
access control planned
API keys protected
private data boundaries defined
user permissions defined
audit logs planned
Testing
retrieval tests planned
deletion tests planned
stale data tests planned
hallucination tests planned
client boundary tests planned
identity tests planned
contradiction tests planned
personalisation privacy tests planned
Rule
Do not build RAG or client memory until source, identity, permission, and memory-use rules are clear.
Application To Data Brain
Data Brain owns this framework.
Data Brain should define:
schemas
metadata fields
source IDs
entity IDs
vector storage rules
retention rules
deletion rules
source confidence
knowledge classes
fact statuses
client separation
retrieval filters
temporal fields
contradiction fields
observability fields
Data Brain Rule
RAG is data infrastructure first and AI output second.
Client memory is identity-governed data infrastructure before it is personalisation.
Application To Research Brain
Research Brain should use RAG to preserve and retrieve research evidence.
Research Brain can use RAG for:
source libraries
competitor knowledge
market research
course notes
trend archives
newsletter intelligence
evidence retrieval
insight synthesis
Research Brain Rule
Research RAG must preserve source visibility and confidence.
Application To AIBS Brain
AIBS Brain should use RAG for client memory and diagnostics.
AIBS can use RAG to:
understand client documents
support business audits
create client reports
power assistants
support proposals
retrieve SOPs
support staff knowledge
identify value leaks
maintain approved client context
support relationship continuity
AIBS Rule
Client memory must be permission-safe, source-led, identity-matched, time-aware, and separate by client.
Application To Automation Brain
Automation Brain should build the processing and retrieval workflows only after governance is clear.
Automation Brain should manage:
intake workflows
identity matching workflows
processing workflows
embeddings
storage
deletion
retrieval
logs
error routing
review queues
conflict routing
memory update workflows
Automation Brain Rule
RAG automation must include deletion, identity isolation, contradiction handling, and error handling, not only upload.
Application To Compliance And Risk Brain
Compliance and Risk Brain should review RAG and client memory systems for:
private data
customer data
sensitive documents
AI processing permission
communication-use permission
retention
deletion rights
client separation
identity accuracy
data exposure
hallucination risk
source confidence
client-facing output
intrusive personalisation
Compliance Rule
A RAG or client memory system that stores client data is a governance responsibility, not a toy.
Application To Content Brain
Content Brain may use RAG to create source-led content.
Content Brain can retrieve:
approved brand voice
approved offers
approved claims
approved FAQs
approved case studies
approved research
content source libraries
Content Brain Rule
Content generated from RAG still requires claim and source review.
Application To Sales Brain
Sales Brain may use RAG and client memory for proposals and follow-up.
Sales Brain can retrieve:
case studies
client notes
sales decks
objections
pricing logic
prior proposals
diagnostic findings
offer scope
approved client goals
relationship history
current commitments
Sales Brain Rule
RAG can draft sales material and contextual follow-up, but humans approve claims, price, scope, and sensitive personalisation.
Application To Client Communication Systems
Client Communication systems may use approved memory to:
personalise onboarding
support service updates
draft follow-up
maintain relationship continuity
reference approved commitments
adapt communication to current needs
Client Communication Rule
A communication system must not use memory merely because it is available.
It must use memory because it is relevant, accurate, current, appropriate, and allowed.
Application To HeadOffice Brain
HeadOffice should approve major memory systems.
HeadOffice should ask:
does this memory system support MWMS strategy
is it safe
who owns it
who maintains it
what data enters it
what data is excluded
is it internal or client-facing
does it use personal data
does it support communication
does it need M
does it deserve build priority
HeadOffice Rule
Not every knowledge base or client memory system deserves infrastructure.
What Not To Do
Do not:
dump all documents into memory without purpose
upload all emails without review
mix client data
mix customer identities
skip permission review
store sensitive data unnecessarily
rely on old documents
forget deletion workflows
retrieve without metadata filters
answer from low-confidence sources as if certain
let AI invent missing context
create client-facing RAG without testing
use RAG as an excuse to avoid human review
store chat history without purpose
expose service role keys
treat embeddings as understandable business records
build complex RAG before proving the use case
turn temporary campaign context into permanent memory
treat behavioural signals as facts
silently overwrite conflicting facts
use private memory in communication without relevance and appropriateness checks
assume more personalisation is always better
Rule
A messy knowledge base creates confident wrong answers.
An uncontrolled client memory system creates confident and potentially intrusive communication.
Deferred Update And Parking Lot Section
This page creates later update needs.
Later Update 1: MWMS Supabase RAG And Vector Memory Framework
Add:
broader client memory governance
entity identity fields
source confidence scoring
deletion workflow requirements
stale document handling
client-facing RAG readiness score
no context no answer rule
source metadata requirements
temporal fact fields
contradiction status
client memory isolation
Later Update 2: MWMS Client Intelligence And Business Memory Automation Framework
Add:
RAG as client memory infrastructure
living relationship intelligence
document add and delete lifecycle
interaction memory lifecycle
source confidence labels
vector memory retrieval
chat history governance
source freshness review
identity matching
durable versus temporary memory
fact correction and contradiction handling
Later Update 3: MWMS Source Visibility And Evidence Display Standard
Add:
retrieved source IDs
chunk source references
fact versus inference separation
evidence-backed answers
confidence labels
missing source warning
memory source visibility
fact validity date
Later Update 4: MWMS AI Observability Metadata Standard
Add:
retrieved chunk IDs
retrieved fact IDs
retrieval score
source ID
entity ID
client ID
vector store name
embedding model
prompt version
answer grounded flag
communication grounded flag
no context flag
human review flag
facts influencing output
Later Update 5: MWMS AI Automation Security And Risk Checklist
Add:
vector memory privacy risk
client memory separation
identity matching failure
source permission review
deletion request handling
service role key caution
private file ingestion controls
chat history retention rules
personalisation privacy risk
cross-client memory leakage
Later Update 6: MWMS AIBS Automation Audit And Opportunity Mapping Framework
Add:
audit documents as RAG sources
client diagnostic memory
opportunity map retrieval
report evidence retrieval
business knowledge base as audit deliverable
living client context as an audit input
Later Update 7: MWMS AI Voice Agent Design Testing And Governance Framework
Add:
voice agent knowledge base rules
identity confirmation
live answer boundaries
retrieved context limits
fallback when knowledge missing
post-call retrieval review
client memory privacy
Later Update 8: MWMS Prompt Architecture And Automation Output Reliability Framework
Add:
RAG answering prompt rules
source-only response instructions
no context no answer instruction
retrieved context formatting
citation and uncertainty handling
separate company, client, relationship, and campaign context
Later Update 9: MWMS Client Communication Automation Framework
Add:
living client memory retrieval
business truth plus client context assembly
communication suitability controls
personalisation influence logging
temporary campaign context separation
draft-first review for sensitive communication
Later Update 10: MWMS AI Assisted Outreach And Sales Follow Up Automation Framework
Add:
client-state-aware follow-up
trigger event personalisation
memory freshness checks
one-to-many campaigns with one-to-one contextual output
response-to-memory update loop
personalisation suppression when evidence is inadequate
Future AI Employee Ideas
These AI Employee ideas are parked candidates only.
RAG Knowledge Base Architect
Primary Brain: Data Brain / Research Brain
Status: Parked Candidate
Purpose: Designs RAG knowledge base structure, source intake, metadata, chunking, retrieval, deletion, and governance standards.
Source Intake Controller
Primary Brain: Data Brain / Compliance Brain
Status: Parked Candidate
Purpose: Reviews sources before they enter memory and assigns permission level, sensitivity level, topic, confidence, and retention rules.
Client Identity Resolver
Primary Brain: Data Brain / AIBS Brain
Status: Parked Candidate
Purpose: Matches incoming records to the correct client, organisation, customer, project, or relationship identity.
Vector Memory Curator
Primary Brain: Data Brain
Status: Parked Candidate
Purpose: Maintains vector memory, removes stale records, checks duplicates, validates metadata, and protects source quality.
Retrieval Quality Tester
Primary Brain: Research Brain / Data Brain
Status: Parked Candidate
Purpose: Tests whether RAG systems retrieve correct, current, allowed, identity-matched, and relevant context.
Knowledge Deletion Steward
Primary Brain: Data Brain / Risk Brain
Status: Parked Candidate
Purpose: Ensures deleted or replaced sources are removed from files, records, embeddings, and retrieval paths.
Source Confidence Analyst
Primary Brain: Research Brain
Status: Parked Candidate
Purpose: Scores source reliability and decides whether information can support answers, reports, proposals, communication, or client-facing recommendations.
RAG Answer Quality Reviewer
Primary Brain: Prompting Framework / Research Brain
Status: Parked Candidate
Purpose: Reviews RAG outputs for source grounding, uncertainty handling, hallucination risk, and answer usefulness.
Client Memory Privacy Reviewer
Primary Brain: Compliance Brain / Risk Brain
Status: Parked Candidate
Purpose: Reviews client memory systems for privacy, data separation, sensitive content, retention, personalisation appropriateness, and deletion obligations.
Client Memory Curator
Primary Brain: Data Brain / AIBS Brain
Status: Parked Candidate
Purpose: Maintains living client memory, reviews changing facts, separates durable memory from temporary context, and resolves stale or disputed information.
Memory Conflict Resolver
Primary Brain: Data Brain / HeadOffice Brain
Status: Parked Candidate
Purpose: Reviews contradictory client and organisational records and determines which information remains current.
Personalisation Safety Reviewer
Primary Brain: Compliance Brain / Sales Brain / Client Communication Systems
Status: Parked Candidate
Purpose: Reviews whether client memory use in outbound communication is relevant, appropriate, accurate, and non-intrusive.
Drift Protection
This framework protects MWMS from:
ungoverned memory systems
stale knowledge
source confusion
mixed client data
identity confusion
unsupported AI answers
poor retrieval
missing metadata
forgotten deletion
overconfidence
private data exposure
chat history misuse
source-free reports
AI voice agents making things up
client assistants answering beyond approved knowledge
dumping documents into vector memory without purpose
treating RAG as magic
temporary context becoming permanent memory
outdated preferences influencing communication
behavioural signals being treated as facts
cross-client personalisation leakage
intrusive personalisation
silent contradiction overwrites
Drift Signals
Watch for:
“Just upload everything.”
“Upload every email.”
“The AI will find what it needs.”
“We do not need metadata.”
“We can identify the client from their name.”
“We can delete the file manually later.”
“The old document is probably still fine.”
“No need to separate clients.”
“The chatbot sounds accurate.”
“We do not need source references.”
“Let it answer from general knowledge.”
“We can add deletion later.”
“The client will not care where the answer came from.”
“The voice agent can improvise.”
“Let’s store all chat history just in case.”
“The more personal the email, the better.”
“The AI can decide what should be remembered.”
“The new fact can just replace the old one.”
“It is only an inference, but it is probably correct.”
Rule
When these drift signals appear, return to purpose, identity, source permission, knowledge classification, metadata, deletion, and answer grounding.
Strategic Summary
The AI Automations by Jack RAG and client intelligence material reinforced a core MWMS lesson:
Useful AI memory is not created by simply uploading documents or storing every interaction.
It is created by:
controlled source intake
correct identity matching
clean processing
meaningful metadata
reliable retrieval
temporal fact management
contradiction handling
deletion control
governed answer generation
appropriate communication use
RAG is essential for MWMS because future AI Employees and client systems must work from real business context.
Living client memory is also strategically valuable because future client communication and service systems should not treat every interaction as isolated.
But RAG and client memory are risky when poorly governed.
This framework establishes the discipline needed for MWMS to use source-based knowledge and relationship memory safely across internal Brains, AIBS client systems, support agents, voice agents, reports, sales systems, communication systems, and productised AIOS modules.
The strategic upgrade is:
MWMS memory must be source-led, identity-safe, permission-safe, current, retrievable, time-aware, correctable, deletable, observable, and appropriate for the task in which it is used.
Final Standard
The MWMS final standard is:
No MWMS RAG, knowledge base, client memory, voice agent memory, support assistant, business intelligence memory system, or memory-backed communication system should be used until its purpose, identity model, source list, permission level, sensitivity level, knowledge classification, metadata, chunking, storage, retrieval rules, context assembly, answer boundaries, communication-use boundaries, contradiction process, deletion process, freshness review, observability, and human review requirements are defined.
A valid MWMS RAG and client memory system must define:
purpose
owner
user
entity types
identity keys
client isolation
source list
permission rules
sensitivity levels
knowledge classes
durable versus temporary memory
source confidence
chunking method
embedding model
vector store
metadata fields
temporal fields
storage location
retrieval filters
context assembly rules
answer rules
personalisation rules
no context no answer rule
contradiction process
correction process
deletion process
stale source review
chat history rules
observability fields
human review points
governance owner
That is the MWMS RAG Knowledge Base And Client Memory Infrastructure standard.
MWMS System Change Log
Version: v1.1
Date: 2026-06-21
Author: HeadOffice
Change
Updated the MWMS RAG Knowledge Base And Client Memory Infrastructure Framework from v1.0 to v1.1 using the later AI Automations by Jack material covering client intelligence systems, RAG email memory, personalised communication, CRM context, meeting history, continuously updated business memory, and relationship-aware automation.
Expanded the framework from a primarily document and vector retrieval standard into a combined source-based knowledge infrastructure and living client memory standard.
Added the following major operating layers:
• Identity And Entity Layer
• Knowledge Classification Layer
• Context Assembly Layer
• Contradiction And Temporal Change Layer
Expanded the original twelve-layer model into a sixteen-layer RAG and client memory model.
Added new operating standards covering:
• stable client and customer identity
• client isolation across source, record, vector, query, access, output, and log layers
• living client memory
• relationship intelligence
• temporal facts
• durable memory versus temporary campaign context
• fact, preference, goal, constraint, commitment, signal, and inference classification
• continuous interaction intake
• email, meeting, support, CRM, and campaign memory
• client memory correction
• contradiction handling
• fact validity periods
• communication-use permission
• personalisation privacy
• context-aware communication
• traceability of facts influencing generated messages
• over-personalisation prevention
• memory-backed sales and client follow-up
• interaction-to-memory approval workflow
Updated the metadata and knowledge record standards to include:
• Entity ID
• Entity Type
• Source Interaction ID
• Date Learned
• Valid From
• Valid Until
• Knowledge Class
• Communication Use Allowed
• Inference Confidence
• Fact Status
• Replaced By
• Contradiction Status
Added new knowledge base type:
• Living Client Memory System
Added new Future AI Employee parked candidates:
• Client Identity Resolver
• Client Memory Curator
• Memory Conflict Resolver
• Personalisation Safety Reviewer
Added later update requirements for:
• MWMS Client Communication Automation Framework
• MWMS AI Assisted Outreach And Sales Follow Up Automation Framework
Change Impact Declaration
This update materially expands the framework but does not change its primary ownership.
Data Brain remains the primary owner because RAG and client memory are data infrastructure before they become AI output or communication systems.
The update does not authorise unrestricted ingestion of emails, meetings, customer records, or behavioural activity.
The update introduces stronger controls requiring:
• defined purpose
• identity matching
• client separation
• permission review
• knowledge classification
• temporal metadata
• contradiction handling
• communication-use review
• deletion and correction controls
The update does not create permission for AI systems to expose private client memory, infer sensitive characteristics, or personalise communications merely because information is available.
Pages Created
• None
Pages Updated
• MWMS RAG Knowledge Base And Client Memory Infrastructure 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 now governed within this framework or belongs as updates to existing pages:
• MWMS Living Client Memory Framework
• MWMS Relationship Intelligence Framework
• MWMS Email Memory RAG Framework
• MWMS Customer Memory Vector Database Framework
• MWMS Personalised Client Context Retrieval Framework
• MWMS Client Identity And Memory Isolation Framework
• MWMS Temporal Client Fact Framework
• MWMS RAG Email Personalisation Framework
Registries Requiring Update
• MCR Page Registry
• Data Brain Page Registry
• MCR Copy Map where the Data Brain framework copy and version are recorded
Canon Version Update Required
No immediate Data Brain Canon version change is required unless the current Data Brain Canon directly records child framework versions or contains a narrower definition of client memory that conflicts with this update.
The updated framework should be included during the next scheduled Data 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
• Data Brain Page Registry change history where applicable
Strategic Absorption Result
The later AI Automations by Jack material concerning client intelligence, RAG email systems, continuous business memory, CRM-connected context, relationship-aware communication, and personalised campaign generation has been absorbed into the existing MWMS RAG Knowledge Base And Client Memory Infrastructure Framework.
The absorption preserves the useful architectural intelligence while rejecting:
• uncontrolled ingestion of all historical email
• permanent storage of irrelevant interactions
• identity matching based only on names
• cross-client memory mixing
• silent replacement of historical facts
• behavioural assumptions being treated as facts
• intrusive personalisation
• use of private memory merely because it is technically available
The resulting v1.1 framework establishes that MWMS client memory must be:
• source-led
• identity-safe
• permission-safe
• client-isolated
• knowledge-classified
• time-aware
• correctable
• conflict-aware
• retrievable
• deletable
• observable
• appropriate for its intended use
END OF FULL FILE OUTPUT