MWMS Advanced AI Capability Activation Registry

System: MWMS
Document Type: Registry
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Version: v1.1
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, AIBS Brain, Automation Brain, Product Brain, Research Brain, Prompt Vault, AI Operating Systems
Parent Page: HeadOffice
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR
Last Reviewed: 2026-06-01
Source / Origin: MWMS Advanced AI Capability Activation Registry v1.0 + AI Automations by Jack — Advanced Technology / AI-Powered Dashboards + RAG & Supabase Masterclass
MWMS Classification: Advanced AI Capability Registry / Deferred Capability Activation System / AIOS Future Capability Control Layer
Primary Brain: HeadOffice Brain
Supporting Brains: AIBS Brain, Automation Brain, Product Brain, Research Brain, Content Brain, Sales Brain, Customer Brain, Risk Brain, Compliance Brain, Data Brain, SIT Brain
Related Pages: MWMS Advanced AI Capability Stack Framework, MWMS Client AI Interface Selection Framework, MWMS AI Dashboard Capability Framework, MWMS Supabase RAG And Vector Memory Framework, MWMS AI Agent Operations Core, MWMS AI Agent Memory And Context Framework, MWMS AI Tool Permission And Access Framework, MWMS Automation Build Planning Framework, MWMS Automation Client Demo And Handover Framework, MWMS AI Operating System Architecture Framework, MWMS Context Engineering Framework, MWMS AI Automation Security And Risk Checklist, HeadOffice Kaizen Continuous Improvement Loop
Source Evidence: AI Automations by Jack — Advanced Technology Section introduced several future-facing AI capabilities including local model hosting, Custom GPTs, AI app builders, voice AI systems, chatbots, AI agent hierarchy, Chrome extensions, AI-powered dashboards, advanced n8n systems, and Supabase RAG workflows. The AI-Powered Dashboards lesson strengthened dashboards as a visible AIOS and client value layer, while the RAG & Supabase Masterclass strengthened Supabase vector memory, embeddings, reranking, Postgres chat memory, and n8n RAG workflows as future MWMS AIOS infrastructure.

Purpose

The purpose of the MWMS Advanced AI Capability Activation Registry is to prevent valuable advanced AI ideas from being forgotten, scattered, or loosely “parked” without a future activation path.

MWMS frequently absorbs course material, newsletters, frameworks, product ideas, tool signals, automation concepts, and future capability opportunities.

Some ideas are immediately useful.

Some deserve full MCR pages straight away.

Some are valuable but not ready for implementation yet.

The danger is that useful-but-not-now ideas can disappear.

This registry solves that problem by giving every valuable deferred capability a structured holding place.

The registry records:

what the capability is
why it matters
which Brain owns it
which Brains support it
current status
future activation trigger
likely MWMS use case
likely AIBS use case
required governance before use
risk level
whether a future full framework page is needed
what should happen next when the trigger appears

This is not a random idea list.

This is a governed activation system.

The v1.1 update adds two important changes from the completed Advanced Technology block:

AI-Powered Dashboards have moved from future concept into Active Strategic Capability / Framework Created because the MWMS AI Dashboard Capability Framework has now been created.
Supabase RAG / Vector Memory Systems has been added as a new active strategic capability because the MWMS Supabase RAG And Vector Memory Framework has now been created.

Core Doctrine

The MWMS doctrine is:

Useful ideas should not be forgotten, but they should not all be built immediately.

This registry exists to balance two risks.

The first risk is forgetting.

If MWMS parks useful ideas loosely, they may never be revisited.

The second risk is overbuilding.

If MWMS creates full systems too early, it wastes time, creates clutter, distracts M, and bloats the Blueprint.

The correct middle path is:

Register the capability now.
Define the activation trigger.
Build only when the trigger appears.

When a capability becomes strong enough to justify a full page, this registry must be updated so its status reflects the new reality.

Registry Function

This registry acts as the controlled holding layer for advanced AI capabilities that are valuable but not yet active.

Each capability should be classified as one of the following:

Active: currently being used or implemented
Active Strategic Capability: now recognised as strategically important and supported by a formal framework
Deferred: valuable but not currently needed
Backlog Priority: should be revisited soon when related work begins
Infrastructure Watch: monitor for future technical use
Commercial Opportunity: likely useful for future AIBS offer design
Prototype Candidate: useful for demos, proof-of-concepts, or M handoff mockups
Governance Required: potentially valuable but too risky without a dedicated framework
Framework Created: a full MCR framework now exists
Rejected: not suitable for MWMS at this time

Registry Entry Template

Each advanced AI capability should be captured using this structure.

Capability Name:
Capability Type:
Current Status:
Owning Brain:
Supporting Brains:
MWMS Use Case:
AIBS / Client Use Case:
Why It Matters:
Current Reason For Deferral Or Controlled Activation:
Future Activation Trigger:
Required Governance Before Use:
Risk Level:
Possible Future MCR Page / Current Framework:
Related Existing Pages:
Next Review Condition:
Notes:

Capability 1: Local Hosting / Local Models

Capability Name: Local Hosting / Local Models
Capability Type: Infrastructure / Private AI Model Layer
Current Status: Deferred / Infrastructure Watch
Owning Brain: Infrastructure Brain / HeadOffice Brain
Supporting Brains: AIBS Brain, Automation Brain, Data Brain, Risk Brain, Compliance Brain, Research Brain
Risk Level: Medium
Possible Future MCR Page: MWMS Local AI Hosting Decision Framework

Description

Local hosting means running AI models on local hardware or private infrastructure instead of relying only on cloud-hosted AI APIs.

This may include:

local model runners
open-source LLMs
locally hosted embeddings
private inference environments
future MWMS-managed model infrastructure

The course positioned local hosting as useful for:

privacy
no per-token API cost once running
offline availability
lower vendor dependence
no external rate limits
experimentation with open-source models
more direct control over model environment

MWMS Use Case

Local models may support:

internal experimentation
private document processing
high-volume low-risk summarization
offline AI workflows
low-cost bulk text processing
local testing before cloud deployment
fallback AI capability
future private MWMS inference layer

AIBS / Client Use Case

Local models may eventually support:

privacy-sensitive client systems
clients with data-control concerns
private AI assistant positioning
offline or internal-only business tools
regulated-industry prototypes
“private AIOS” offer positioning

Why It Matters

This matters because MWMS may eventually need more control over:

data privacy
cost exposure
vendor lock-in
API availability
client trust
internal experimentation
high-volume processing

It is not urgent now, but it could become strategically important later.

Current Reason For Deferral

Local hosting is not an immediate priority because:

current MWMS work depends more on structure than model hosting
OpenAI/Claude/Gemini cloud models are currently stronger and easier
local model setup could distract from core Brain and AIBS systems
M should not be diverted into infrastructure until there is a clear use case
local model quality, hardware needs, and maintenance burden need evaluation

Future Activation Trigger

Activate this capability when one or more of the following occurs:

MWMS needs high-volume low-cost internal processing
a client requires private AI processing
API costs become a major constraint
cloud model limits block a workflow
MWMS builds privacy-sensitive AIOS packages
Research Brain needs bulk local processing
AIBS needs “private AI” as a client offer
local models become strong enough for MWMS production use
a specific workflow can be tested locally without risking core systems

Required Governance Before Use

Before activation, MWMS must define:

model selection rule
hardware requirement
privacy rule
data storage rule
cost comparison
quality benchmark
fallback plan
client suitability rule
model licensing rule
update/maintenance rule
security boundary
what tasks local models are allowed to perform
what tasks require stronger cloud models

Registry Rule

Local hosting should not be treated as a current build task.

It should be monitored as a future infrastructure option.

Capability 2: Chrome Extensions / Browser Copilots

Capability Name: Chrome Extensions / Browser Copilots
Capability Type: Browser Interface / Data Capture / Workflow Trigger Layer
Current Status: Deferred / Backlog Priority
Owning Brain: Product Brain / Research Brain
Supporting Brains: Prompt Vault, Affiliate Brain, Content Brain, Research Brain, Automation Brain, Data Brain, Risk Brain, Compliance Brain
Risk Level: Medium to High
Possible Future MCR Page: MWMS Browser Copilot And Chrome Extension Framework

Description

Chrome extensions and browser copilots sit inside the browser and help capture, process, summarize, send, or route webpage data into MWMS workflows.

The course showed how browser extensions can capture page content and send it to n8n-style automations through webhooks.

This is directly relevant to future MWMS browser-side workflows.

MWMS Use Case

Chrome extensions may support:

Prompt Vault rebuild
Prompt Saver upgrade
webpage-to-Research-Brain capture
sales page capture for Affiliate Brain
YouTube transcript capture
ad library capture
competitor page analysis
content idea capture
course page capture
browser-to-MCR evidence collection
one-click “send to MWMS” workflows

AIBS / Client Use Case

Future client uses may include:

client research capture tools
sales team browser assistant
support knowledge capture
competitor monitoring assistant
website audit copilot
browser-side lead research assistant
AI workflow launcher from inside client browser

Why It Matters

This matters because a lot of MWMS research and affiliate work begins in the browser.

A browser copilot could dramatically speed up:

offer research
sales page analysis
prompt saving
evidence collection
content research
competitor tracking
Research Brain intake
Affiliate Brain intake

This is also connected to the already noted priority to rebuild the MWMS Prompt Vault / Prompt Saver.

Current Reason For Deferral

Chrome extension work is deferred because:

M has other active development priorities
browser extensions create data capture and privacy risks
Prompt Vault needs clearer scope before rebuild
extension permissions must be controlled
webhook destinations must be secured
browser-side capture can accidentally collect sensitive content
this needs a dedicated framework before build

Future Activation Trigger

Activate this capability when one or more of the following occurs:

MWMS begins Prompt Vault rebuild
MWMS begins Prompt Saver upgrade
Research Brain needs browser intake
Affiliate Brain needs sales page capture
Content Brain needs YouTube transcript capture
a browser-to-Brain workflow becomes a clear bottleneck
M is ready for Chrome extension work
a simple MVP can be defined with narrow permissions
a secure Supabase/n8n/Make destination is ready

Required Governance Before Use

Before activation, MWMS must define:

what page content may be captured
what page content must not be captured
whether logged-in pages are allowed
whether client data pages are allowed
destination workflow
webhook security
user confirmation step
storage rules
source tagging
prompt vault schema
extension permission boundaries
privacy warning
delete/correction process
internal-only versus client-facing use

Registry Rule

Chrome extension work should be treated as a future strategic backlog item, not a casual side build.

When activated, it should start with a narrow MVP tied to Prompt Vault or Research Brain intake.

Capability 3: Voice AI Systems

Capability Name: Voice AI Systems
Capability Type: Voice Interface / Customer Interaction / Client Service Layer
Current Status: Deferred / Commercial Opportunity / Governance Required
Owning Brain: AIBS Brain
Supporting Brains: Customer Brain, Sales Brain, Automation Brain, Risk Brain, Compliance Brain, Operations Brain, Product Brain
Risk Level: High
Possible Future MCR Page: MWMS Voice AI Governance Framework

Description

Voice AI systems allow users or customers to interact with AI through speech.

This may include:

website voice agents
phone-based inbound agents
outbound confirmation agents
AI receptionists
appointment confirmation agents
voice onboarding assistants
voice support agents
voice lead qualification agents

The course positioned voice AI as powerful because voice is fast, natural, and central to real business communication.

MWMS Use Case

Voice AI may support:

internal learning assistant
voice-based system navigation
voice summaries
spoken dashboard assistant
internal assistant for repetitive Q&A
voice demo prototypes for AIBS

AIBS / Client Use Case

Voice AI has strong future client potential.

Possible AIBS packages include:

AI receptionist
appointment confirmation agent
inbound FAQ voice assistant
lead qualification voice agent
customer onboarding voice assistant
missed-call follow-up agent
sales inquiry voice assistant
booking reminder voice agent

Why It Matters

Voice AI may become one of the most commercially attractive AIBS package areas because many small businesses struggle with:

missed calls
slow follow-up
repetitive phone questions
appointment no-shows
manual confirmations
low-quality first response
staff overload

Voice AI can create obvious client value if implemented carefully.

Current Reason For Deferral

Voice AI is deferred because it is high-risk.

It touches:

customers
calls
consent
brand trust
customer experience
compliance
personal data
sensitive questions
escalation
potential recording obligations

MWMS should not deploy voice AI without a dedicated governance standard.

Future Activation Trigger

Activate this capability when one or more of the following occurs:

AIBS begins client package design for service businesses
a clear AI receptionist use case appears
appointment confirmation becomes a client opportunity
Customer Brain requires voice interface planning
a safe internal voice prototype is needed
a small low-risk demo can be created
a client explicitly wants call-handling or voice support
MWMS has the support and monitoring process to manage it

Required Governance Before Use

Before activation, MWMS must define:

voice agent role
script boundaries
approved knowledge source
prohibited topics
human handoff path
escalation rules
consent and recording rules
call logging
privacy handling
client approval process
test cases
failure handling
monitoring
support ownership
claim restrictions
jurisdiction concerns
client-specific customization rules

Registry Rule

Voice AI should be treated as a strong commercial opportunity, but no customer-facing voice system should be deployed before governance, handoff, and compliance rules are defined.

Capability 4: AI App Builders / Build Any App In One Prompt

Capability Name: AI App Builders / Build Any App In One Prompt
Capability Type: Prototype Builder / Web App Generation / Product Validation Layer
Current Status: Deferred / Prototype System
Owning Brain: Product Brain
Supporting Brains: AIBS Brain, Automation Brain, UX Brain, Research Brain, Risk Brain, SIT Brain, M Development
Risk Level: Medium to High
Possible Future MCR Page: MWMS AI App Prototype Governance Standard

Description

AI app builders allow users to generate applications, dashboards, tools, and prototypes using prompts, screenshots, code references, UI references, and API instructions.

The course showed that these tools can rapidly create working prototypes and app-like experiences.

This capability is valuable for MWMS because it can help Martyn validate ideas before asking M or a developer to harden them.

MWMS Use Case

AI app builders may support:

internal tool prototypes
mock dashboards
AIBS proof-of-concept apps
client demo interfaces
M handoff visuals
Offer Evaluation micro-apps
AIOS launch review prototypes
Prompt Vault prototype
Research Brain interface mockups
Content Brain workflow demos
experimental lead magnet tools

AIBS / Client Use Case

Future client uses may include:

client demo apps
proof-of-concept interfaces
rapid workflow mockups
intake-to-report tools
client AIOS front-end prototypes
dashboards for value proof
lead qualification apps
simple internal client tools

Why It Matters

This matters because MWMS should not wait for full development every time it needs to test an idea.

AI app builders can help MWMS:

test concepts quickly
avoid overbuilding
show M what is wanted visually
validate user flows
demonstrate value to clients
explore product ideas cheaply
create early AIBS demos

Current Reason For Deferral

This is deferred because:

generated apps can be fragile
security may be weak
code quality may be poor
data handling may be unsafe
direct copying of apps/sites can create IP/trade dress risk
prototypes can be mistaken for production systems
M should not inherit messy prototype code without review
no prototype governance page exists yet

Future Activation Trigger

Activate this capability when one or more of the following occurs:

MWMS needs a fast internal demo
AIBS needs a proof-of-concept
M needs a visual prototype before building
a client-facing idea needs validation
a dashboard concept needs testing
a micro-app would reduce confusion
Product Brain needs to validate interface direction
UX Brain needs a prototype for testing
a low-risk workflow can be mocked safely

Required Governance Before Use

Before activation, MWMS must define:

prototype purpose
what is being tested
what data may be used
whether real user/client data is prohibited
whether public deployment is allowed
security review requirement
ownership of generated code
IP/copying boundaries
M handoff rules
testing standard
when prototype must be discarded
when prototype may be hardened
when SIT Brain reviews it
client demo disclaimer rules

Registry Rule

AI app builders should be used for prototypes, demos, and validation.

They should not be treated as production systems without hardening, testing, security review, and clear ownership.

Capability 5: Custom GPTs

Capability Name: Custom GPTs
Capability Type: Lightweight Assistant / Knowledge Tool / Prototype Interface
Current Status: Active For Low-Risk Use / Governed Prototype Layer
Owning Brain: Product Brain / HeadOffice Brain
Supporting Brains: AIBS Brain, Content Brain, Sales Brain, Customer Brain, Training Brain, Risk Brain
Risk Level: Low to Medium
Possible Future MCR Page: MWMS Custom GPT Usage Standard

Description

Custom GPTs allow MWMS to package instructions, knowledge, examples, and basic assistant behavior into a shareable ChatGPT-based helper.

They are useful for fast knowledge packaging and internal assistant prototypes.

MWMS Use Case

Custom GPTs may support:

internal training helpers
simple workflow assistants
prompt helpers
low-risk SOP assistants
content helper tools
offer research pre-checks
brand voice helpers
quick client demos
early Brain assistant prototypes

AIBS / Client Use Case

Custom GPTs may support:

low-cost client demo assistants
internal company knowledge helpers
lightweight training assistants
sales prep assistants
onboarding helper prototypes

Why It Matters

Custom GPTs are fast and accessible.

They can help MWMS test assistant concepts before building deeper AIOS infrastructure.

Current Reason For Limited Use

Custom GPTs are limited because they generally lack:

strong workflow control
Supabase event logs
fine-grained permissions
robust approval gates
client isolation
full AIOS architecture
deep automation control
high-trust auditability

Future Activation Trigger

Create a dedicated Custom GPT standard when:

MWMS begins making repeatable internal GPTs
AIBS needs client demo GPTs
Custom GPTs become part of training packages
users start relying on them operationally
client data is involved
GPT sharing rules become important

Required Governance Before Wider Use

MWMS must define:

when a Custom GPT is allowed
what knowledge may be uploaded
what client data is prohibited
sharing permissions
update process
source freshness rule
disclaimer rule
export/handover limits
when to replace GPT with proper AIOS component

Registry Rule

Custom GPTs are useful assistant prototypes.

They should not be mistaken for complete AI Operating Systems.

Capability 6: AI-Powered Dashboards

Capability Name: AI-Powered Dashboards
Capability Type: Reporting Interface / Client Value Proof / Operational Visibility Layer
Current Status: Active Strategic Capability / Framework Created
Owning Brain: HeadOffice Brain / Data Brain
Supporting Brains: AIBS Brain, Product Brain, Operations Brain, Automation Brain, Finance Brain, Experimentation Brain, Customer Brain, Risk Brain, Compliance Brain, SIT Brain
Risk Level: Medium
Current Framework: MWMS AI Dashboard Capability Framework

Description

AI-powered dashboards show structured data, intelligence, reports, tasks, metrics, summaries, action items, AI-generated insights, approval queues, and system status inside a visual interface.

The AI-Powered Dashboards lesson strengthened dashboards as a serious MWMS capability because dashboards solve the “magic box” visibility problem by making AI and automation work visible to clients and operators.

This capability has now moved from future concept into active strategic capability because the full MWMS AI Dashboard Capability Framework has been created.

MWMS Use Case

AI dashboards may support:

HeadOffice visibility
Brain performance reports
newsletter intelligence
task monitoring
experiment results
campaign reporting
course absorption progress
AI Employee performance
Kaizen scoreboard
AIOS system health
approval queues
automation status
MCR/system change tracking

AIBS / Client Use Case

Client dashboards may support:

AIOS value proof
weekly/monthly client reporting
support queue visibility
lead qualification summary
automation health
customer service insights
appointment performance
content output reporting
task/action reporting
client renewal proof

Why It Matters

Dashboards are central to trust and recurring revenue.

AIBS clients need to see:

what the AI system did
what value it created
what needs review
what improved
what actions remain
where risks appeared

Dashboards convert invisible automation into visible business value.

Current Reason For Active Strategic Status

This capability is no longer just deferred because:

the AI-Powered Dashboards lesson was strong and directly relevant
MWMS already uses HeadOffice dashboards
AIBS will need client-facing dashboards
dashboards are essential for value proof
dashboards are key to AIOS visibility
the full MWMS AI Dashboard Capability Framework now exists

Future Activation Trigger

Further implementation should activate when:

HeadOffice dashboard needs expansion
AIBS package reporting is designed
client value proof becomes required
Data Brain defines dashboard schema
Experimentation Brain needs live reporting
AI Employee performance metrics need display
Client AIOS dashboard template is required
dashboard actions need governance

Required Governance Before Use

MWMS must define:

source data
metric definitions
refresh cadence
confidence level
validation state
owner
action destination
stale data warning
client visibility rules
dashboard noise controls
permission levels
dashboard action logging
dashboard source-of-truth status

Registry Rule

AI dashboards are now a governed MWMS capability area.

They should prove value and support decisions, not become decoration or noise.

Capability 7: Advanced n8n Systems

Capability Name: Advanced n8n Systems
Capability Type: Automation Orchestration / Agentic Workflow / AIOS Execution Layer
Current Status: Active Learning / Future Implementation Layer
Owning Brain: Automation Brain
Supporting Brains: AIBS Brain, Data Brain, Operations Brain, Risk Brain, Compliance Brain, SIT Brain, HeadOffice Brain
Risk Level: Medium to High
Possible Future MCR Page: MWMS n8n Advanced Agentic Workflow Standard

Description

Advanced n8n systems can support AI agents, tools, memory, workflow execution, sub-workflows, data transformation, API calls, webhook triggers, RAG ingestion, vector retrieval, reranking, Postgres chat memory, and modular automation systems.

This capability is already highly relevant to MWMS because n8n is likely to become part of future AIOS and AIBS automation infrastructure.

The RAG & Supabase Masterclass strengthened this capability by showing that n8n can orchestrate:

document ingestion
Google Drive file triggers
Supabase vector storage
OpenAI embeddings
chunking
Cohere reranking
Postgres chat memory
AI agent tools
webhook front-end responses

MWMS Use Case

Advanced n8n may support:

Brain-to-Brain workflow automation
AI agent tool orchestration
sub-agent workflows
webhook-based intake
browser extension endpoints
chatbot backends
form-to-AI-to-database flows
client workflow automation
reporting pipelines
task routing
RAG ingestion
vector retrieval
Postgres chat memory
dashboard-backed AI workflows

AIBS / Client Use Case

Advanced n8n may support:

client AIOS workflow engines
AI receptionist backend workflows
lead qualification systems
client reporting pipelines
internal knowledge assistant tools
automation hubs
multi-step client workflows
RAG and memory integrations
client-specific knowledge assistants
chatbot/voice agent backend systems

Why It Matters

n8n is likely to be one of the most important orchestration tools for future MWMS systems because it supports deeper AI agent workflows, self-hosting possibilities, modular workflows, and advanced tool logic.

The Supabase RAG lesson makes n8n even more important because it can connect the interface layer, retrieval layer, memory layer, AI agent layer, and automation layer.

Current Reason For Controlled Implementation

Advanced n8n systems require control because they can create:

workflow complexity
credential risk
debugging difficulty
unclear ownership
duplicate automation logic
API cost exposure
external action risk
tool permission drift
exposed webhook risk
client memory leakage
wrong retrieval chain
poor observability

Future Activation Trigger

Activate deeper n8n implementation when:

MWMS needs agentic workflow orchestration
a Brain workflow requires sub-workflows
client AIOS delivery needs advanced automation
Make becomes too limited for a specific workflow
self-hosting becomes important
tool cost or control requires n8n
M has bandwidth for implementation
Automation Brain standards are ready
Supabase RAG enters technical build phase
chatbot or dashboard RAG backend is required

Required Governance Before Use

MWMS must define:

workflow owner
trigger
input schema
output schema
tool permission
credential handling
error handling
logging
testing process
sub-workflow contracts
human approval gates
client isolation
rollback process
webhook security
RAG source governance
memory retention rules

Registry Rule

Advanced n8n systems should be built only when the workflow requires orchestration depth beyond simple Make/Zapier-style automation.

For future MWMS RAG systems, n8n should be treated as a likely orchestration layer, not as a casual automation toy.

Capability 8: Chatbots

Capability Name: Chatbots
Capability Type: Conversational Interface / Support Layer / AIOS Interaction Layer
Current Status: Partially Activated Through Frameworks / Future Dedicated Governance Possible
Owning Brain: Customer Brain / AIBS Brain
Supporting Brains: Automation Brain, Data Brain, Risk Brain, Compliance Brain, Product Brain, Sales Brain, HeadOffice Brain
Risk Level: Medium to High
Possible Future MCR Page: MWMS Chatbot Memory And Handoff Standard

Description

Chatbots are text-based conversational interfaces.

The Advanced Technology section reinforced that chatbots become valuable when connected to:

memory
tools
RAG
business knowledge
databases
human handoff
workflow state
custom logic where needed

This capability has already been partially absorbed into:

MWMS Client AI Interface Selection Framework
MWMS AI Agent Memory And Context Framework v1.2
MWMS Supabase RAG And Vector Memory Framework

MWMS Use Case

Chatbots may support:

Brain Room assistant
internal knowledge assistant
course library assistant
prompt support assistant
sales script assistant
onboarding assistant
internal support triage
MCR lookup assistant
RAG-powered knowledge assistant

AIBS / Client Use Case

Client chatbot packages may include:

website FAQ chatbot
lead qualification chatbot
customer support triage bot
onboarding assistant
service recommendation bot
internal company knowledge assistant
sales inquiry assistant
RAG-powered support assistant

Why It Matters

Chatbots are one of the easiest AI interfaces for clients to understand.

They can also become risky quickly if they answer from stale knowledge, hallucinate, collect sensitive data, retrieve wrong-client knowledge, or fail to hand off.

Current Reason For Not Creating Dedicated Page Yet

A dedicated page may be needed later, but current chatbot principles have already been captured inside:

Client AI Interface Selection Framework
AI Agent Memory And Context Framework v1.2
AI Tool Permission And Access Framework
Supabase RAG And Vector Memory Framework

A separate page should wait until MWMS is actively designing a chatbot package or internal chatbot system.

Future Activation Trigger

Create a dedicated Chatbot Memory And Handoff Standard when:

MWMS builds a chatbot
AIBS designs a client chatbot offer
customer-facing chatbot deployment becomes real
chatbot memory/database design is needed
chatbot handoff workflow is needed
chatbot source visibility must be standardized
RAG-backed chatbot implementation begins

Required Governance Before Use

MWMS must define:

chatbot purpose
user type
approved knowledge
short-term memory
long-term memory
tool access
handoff triggers
escalation
logging
privacy/data rules
prohibited topics
update process
client-specific isolation
RAG source governance
no-answer fallback

Registry Rule

Chatbots should be treated as governed client or internal interfaces, not casual AI widgets.

Capability 9: Supabase RAG / Vector Memory Systems

Capability Name: Supabase RAG / Vector Memory Systems
Capability Type: Knowledge Retrieval Infrastructure / Vector Memory / AIOS Context Layer
Current Status: Active Strategic Capability / Framework Created
Owning Brain: Data Brain
Supporting Brains: HeadOffice Brain, AIBS Brain, Automation Brain, Research Brain, Product Brain, Operations Brain, Risk Brain, Compliance Brain, SIT Brain, Content Brain, Customer Brain
Risk Level: Medium to High
Current Framework: MWMS Supabase RAG And Vector Memory Framework

Description

Supabase RAG / Vector Memory Systems use Supabase as a structured database, vector store, metadata layer, and Postgres chat memory layer to retrieve relevant knowledge for AI Employees, chatbots, dashboards, voice agents, Brain Room, MCR lookup, and future client AIOS systems.

The RAG & Supabase Masterclass elevated this capability from future idea to active strategic capability.

This capability includes:

file ingestion
chunking
embeddings
Supabase vector store
metadata
retrieval
reranking
Postgres chat memory
n8n AI agent tools
webhook-connected front ends
client-specific knowledge bases
source-aware AI answers

MWMS Use Case

Supabase RAG may support:

MCR knowledge retrieval
Brain page retrieval
Brain Room AI replies
AI Manager context retrieval
AI Employee task context
Course Absorption anti-duplication
Newsletter Intelligence archive lookup
Research Brain knowledge base
Prompt Vault search
dashboard question answering
chatbot knowledge retrieval
source-backed report generation

AIBS / Client Use Case

Supabase RAG may support:

client knowledge assistants
client support chatbots
AI receptionist knowledge layer
internal company SOP assistant
client onboarding assistant
report explanation assistant
client AIOS dashboard Q&A
customer support knowledge base
private client RAG systems

Why It Matters

This matters because MWMS is becoming knowledge-heavy.

AI Employees cannot safely rely on memory alone.

RAG gives MWMS a structured way to:

store knowledge
retrieve relevant context
preserve source traceability
reduce context overload
improve chatbot quality
power AIOS systems
support client-specific knowledge bases
connect Supabase to the future AI workforce

This is one of the most important infrastructure directions for MWMS.

Current Reason For Active Strategic Status

This capability is now active strategic because:

Supabase is already core MWMS infrastructure
MWMS needs source-aware retrieval
MCR pages will eventually need AI retrieval
Brain systems need context control
client AIOS systems will need knowledge bases
chatbots and voice agents require approved knowledge
dashboards may need RAG explanation layers
the full MWMS Supabase RAG And Vector Memory Framework now exists

Future Activation Trigger

Implementation should activate when:

Brain Room needs source-aware AI replies
AI Manager needs context retrieval
MCR retrieval becomes a bottleneck
Course Absorption needs anti-duplication search
Research Brain needs internal retrieval
AIBS client knowledge assistant is designed
chatbot or voice agent needs approved knowledge
dashboard Q&A is required
Prompt Vault search is rebuilt
n8n RAG workflow becomes a build priority

Required Governance Before Use

MWMS must define:

source set
metadata schema
vector table design
chunking rules
embedding model
reranking rule
source authority tagging
freshness status
client isolation
sensitivity level
retrieval filters
logging
source visibility
update process
deletion/offboarding rules
webhook security
no-answer fallback
human review conditions

Registry Rule

Supabase RAG / Vector Memory is now a governed strategic MWMS infrastructure capability.

It should be treated as future AIOS backbone infrastructure, not casual chatbot memory.

Capability Review Cadence

This registry should be reviewed when:

a new Advanced Technology course section is absorbed
a newsletter introduces a relevant AI capability
MWMS starts a new Brain build
AIBS package design begins
M has development bandwidth
a client opportunity appears
a parked capability becomes a current bottleneck
HeadOffice identifies recurring need
a tool becomes cheaper, stronger, or more stable
risk/compliance conditions change
dashboard requirements expand
Supabase RAG requirements become active

Minimum recommended review:

during major course closeouts
during AIBS package planning
during Product Brain planning
during quarterly MWMS capability review

Capability Activation Process

When a deferred capability becomes relevant, MWMS should follow this activation process.

Step 1: Confirm Trigger

Identify which activation trigger has appeared.

Do not activate based on excitement alone.

Step 2: Reassess Value

Confirm the capability still matters.

Ask:

What problem does it solve now?
Which Brain needs it?
Is this still the best approach?
Has another tool replaced it?
Is the timing right?

Step 3: Reassess Risk

Check:

data risk
client risk
technical risk
security risk
cost risk
compliance risk
M workload risk
support burden

Step 4: Decide Output Type

Choose whether the capability needs:

no action
a small update to existing page
a full MCR framework page
a developer brief
a prototype
a test workflow
an AIBS package outline
a governance checklist

Step 5: Create Activation Brief

Before implementation, define:

scope
owner
supporting Brains
expected outcome
required standards
tool permissions
data rules
risk controls
success metric
next action

Step 6: Route Correctly

Send activation to the correct place:

Product Brain for product/prototype decisions
Automation Brain for workflow builds
AIBS Brain for client package design
Research Brain for investigation
Data Brain for schema/memory/data work
Risk/Compliance Brain for review
M only when development is actually ready

Activation Brief Template

Capability:
Activation Trigger:
Why Now:
Owning Brain:
Supporting Brains:
Target Use Case:
Internal / Client-Facing:
Current Problem Solved:
Minimum Useful Version:
Required Governance:
Tool / Data Access Needed:
Risk Level:
Human Review Required:
M Involvement Required: Yes / No
Future MCR Page Required: Yes / No
Prototype Required: Yes / No
Success Metric:
Next Action:

Registry Governance Rules

Rule 1: Deferred Does Not Mean Forgotten

A deferred capability remains visible in this registry until activated, rejected, merged, or replaced.

Rule 2: Trigger Before Build

No deferred capability should become active without a trigger.

Rule 3: One Capability Can Feed Multiple Brains

Some capabilities may support several Brains, but one Brain must own activation.

Rule 4: Do Not Send Everything To M

M should not receive development work until the capability has a clear brief, scope, trigger, and priority.

Rule 5: Governance Before Client Use

Any capability that touches clients, customers, public content, data, money, calls, browser capture, RAG, vector memory, dashboards, or live systems requires governance before deployment.

Rule 6: Prototype Before Production

Advanced capabilities should usually pass through prototype stage before becoming production systems.

Rule 7: Update This Registry After Decisions

If a capability is activated, rejected, merged, replaced, or has a framework created, this page must be updated.

Rule 8: Avoid Duplicate Pages

Before creating a new framework page, check whether the capability can be absorbed into an existing standard.

Rule 9: Commercial Potential Is Not Enough

A capability may look commercially valuable but still be deferred until MWMS can support delivery, risk, and maintenance.

Rule 10: Capability Must Serve A Constraint

Build only when the capability solves a real MWMS or client constraint.

Current Registry Summary

Capability	Status	Priority	Risk	Future Page / Current Framework
Local Hosting / Local Models	Deferred / Infrastructure Watch	Later	Medium	MWMS Local AI Hosting Decision Framework
Chrome Extensions / Browser Copilots	Deferred / Backlog Priority	Medium-High	Medium-High	MWMS Browser Copilot And Chrome Extension Framework
Voice AI Systems	Deferred / Commercial Opportunity / Governance Required	Medium	High	MWMS Voice AI Governance Framework
AI App Builders / One-Prompt Apps	Deferred / Prototype System	Medium	Medium-High	MWMS AI App Prototype Governance Standard
Custom GPTs	Active Low-Risk / Prototype Layer	Medium	Low-Medium	MWMS Custom GPT Usage Standard
AI-Powered Dashboards	Active Strategic Capability / Framework Created	High	Medium	MWMS AI Dashboard Capability Framework
Advanced n8n Systems	Active Learning / Future Implementation	High	Medium-High	MWMS n8n Advanced Agentic Workflow Standard
Chatbots	Partially Activated / Future Dedicated Page Possible	Medium-High	Medium-High	MWMS Chatbot Memory And Handoff Standard
Supabase RAG / Vector Memory Systems	Active Strategic Capability / Framework Created	High	Medium-High	MWMS Supabase RAG And Vector Memory Framework

Application To Course Absorption

During future course absorption, any valuable but not-now capability should be added to this registry instead of being loosely parked.

Course absorption should classify:

whether the idea is immediately useful
whether it deserves a full page now
whether it updates an existing page
whether it belongs in this registry
what trigger would activate it later

Course Absorption Rule

If a course idea is useful but not ready, register it with a trigger.

Do not simply say “park it.”

Application To Newsletter Intelligence

Newsletter Intelligence often surfaces new tools, trends, and capabilities.

Useful but not-now newsletter insights should be routed to this registry when they relate to future MWMS capability.

Examples:

new AI browser tools
new voice AI systems
new dashboard platforms
new local model infrastructure
new chatbot memory systems
new automation builders
new app generation tools
new RAG systems
new vector database tools
new dashboard builder platforms
new model hosting tools

Newsletter Rule

A newsletter insight that could become future MWMS capability should be registered, not forgotten.

Application To AIBS Brain

AIBS Brain should use this registry as a future package-development source.

The registry helps AIBS identify future offer ingredients, such as:

AI receptionist
client dashboard
internal knowledge assistant
lead qualification chatbot
browser research copilot
private AI system
rapid prototype app
advanced n8n workflow engine
Supabase RAG knowledge assistant
client AIOS dashboard
client support chatbot

AIBS Rule

AIBS should activate capabilities only when they can be turned into a clear client outcome, not just because the technology is impressive.

Application To Product Brain

Product Brain should use this registry to manage future MWMS product and interface ideas.

Product Brain should decide:

what deserves prototype
what deserves rejection
what should wait
what needs UX testing
what should become a full feature
what belongs in Prompt Vault
what belongs in HeadOffice
what belongs in client AIOS
what belongs in dashboard systems
what belongs in RAG-enabled interfaces

Product Rule

The registry should reduce product chaos by keeping ideas visible but controlled.

Application To Data Brain

Data Brain should use this registry for advanced data and memory capability planning.

Data Brain should track:

Supabase vector memory
RAG metadata
dashboard data sources
chat memory tables
client isolation
source freshness
retrieval filters
data quality
metric definitions
AIOS knowledge layers

Data Rule

Capabilities involving vector memory, dashboards, metrics, or source retrieval must have data governance before implementation.

Application To Automation Brain

Automation Brain should use this registry to identify which advanced capabilities require workflow orchestration.

Automation Brain should track:

n8n RAG workflows
document ingestion
webhook endpoints
dashboard action triggers
chatbot tool calls
Chrome extension workflows
voice AI workflow routing
approval automations
client AIOS execution paths

Automation Rule

Advanced capability becomes operational only when the workflow path is defined, logged, and governed.

Application To M Development

This registry does not authorize development work.

It creates future readiness.

Before M works on any listed capability, MWMS must create a separate developer brief.

That brief must define:

exact scope
current files/systems
expected outcome
what not to touch
test steps
risk controls
handoff instructions

Developer Boundary Rule

Registry entry does not equal development assignment.

M should only act when a capability has been formally activated and scoped.

Common Failure Modes

Failure Mode 1: Parked Means Forgotten

A useful idea is mentioned once and never revisited.

Correction:

Add it to this registry with a trigger.

Failure Mode 2: Everything Becomes A Page

Every idea becomes a full framework page too early.

Correction:

Use this registry to defer without losing the idea.

Failure Mode 3: Everything Goes To M

A capability becomes a development request before scope exists.

Correction:

Create activation brief first.

Failure Mode 4: Commercial Hype Overrides Readiness

A client-facing capability looks profitable but lacks governance.

Correction:

Require risk, compliance, support, and handoff review.

Failure Mode 5: Duplicate Capability Pages

Similar ideas create overlapping MCR pages.

Correction:

Check registry and existing pages before creating new pages.

Failure Mode 6: Trigger Is Too Vague

A capability is activated because it “might be useful.”

Correction:

Require a clear activation trigger.

Failure Mode 7: Registry Becomes Graveyard

Items are added but never reviewed.

Correction:

Review at course closeouts, AIBS planning, and quarterly capability reviews.

Failure Mode 8: Prototype Becomes Production

A quick AI app or workflow is treated as client-ready.

Correction:

Require SIT, security, governance, and ownership review before production.

Failure Mode 9: Framework Created But Registry Not Updated

A capability gets a full page, but the registry still lists it as deferred.

Correction:

Update capability status whenever a framework is created.

Failure Mode 10: Infrastructure Capability Treated As Casual Tool

RAG, vector memory, dashboards, or n8n workflows are treated as simple tools instead of system layers.

Correction:

Route to Data Brain, Automation Brain, Risk Brain, Compliance Brain, and SIT Brain before implementation.

Strategic Summary

The MWMS Advanced AI Capability Activation Registry gives future AI capability ideas a controlled home.

This v1.1 update reflects the completion of the Advanced Technology block and upgrades two important capability areas:

AI-Powered Dashboards are now an active strategic capability with a full framework created.
Supabase RAG / Vector Memory Systems has been added as an active strategic capability with a full framework created.

The current Advanced Technology block introduced several valuable future capabilities:

local models
browser copilots
voice AI
AI app builders
Custom GPTs
AI dashboards
advanced n8n systems
chatbots
Supabase RAG / vector memory

Some are already partly absorbed into frameworks.

Some now have full framework pages.

Some need future dedicated pages.

Some need governance before client use.

This registry ensures each capability has:

an owner
a status
a trigger
a risk level
a future page path
a use case
a review condition

This gives MWMS a better system than loose parking.

Final Standard

The final standard is:

Do not forget useful ideas.
Do not build them too early.
Register them.
Give them an owner.
Give them a trigger.
Give them a risk level.
Create full frameworks when the capability becomes strategically important.
Activate implementation only when the constraint appears.

This registry turns parked ideas into governed future capability.

Change Log

Version: v1.1
Date: 2026-06-01
Author: MWMS HeadOffice

Change:

Updated the MWMS Advanced AI Capability Activation Registry using the final two files from AI Automations by Jack — Advanced Technology block: AI-Powered Dashboards and RAG & Supabase Masterclass.

Updated AI-Powered Dashboards from:

Active Concept / Future Expansion

to:

Active Strategic Capability / Framework Created

because the MWMS AI Dashboard Capability Framework has now been created.

Added new capability entry:

Supabase RAG / Vector Memory Systems

with status:

Active Strategic Capability / Framework Created

and linked it to the newly created MWMS Supabase RAG And Vector Memory Framework.

Updated Advanced n8n Systems to include n8n + Supabase vector store + Postgres chat memory + reranking + webhook front-end connection as a major future implementation path.

Expanded Current Registry Summary to include Supabase RAG / Vector Memory Systems.

Added Data Brain and Automation Brain application sections.

Expanded Registry Governance Rules, Newsletter Intelligence application, AIBS Brain application, Product Brain application, common failure modes, Strategic Summary, and Final Standard to reflect dashboard and RAG/vector-memory capability activation.

Purpose of update:

To keep the registry accurate after creating dedicated frameworks for AI-powered dashboards and Supabase RAG/vector memory, ensuring these capabilities are no longer treated as loosely deferred ideas but as governed strategic MWMS capability areas.

Version: v1.0
Date: 2026-05-31
Author: MWMS HeadOffice

Change:

Created the MWMS Advanced AI Capability Activation Registry from the AI Automations by Jack — Advanced Technology Section.

This registry was created after identifying that valuable future capabilities should not be loosely parked because parked ideas may be forgotten.

Added structured registry entries for:

Local Hosting / Local Models
Chrome Extensions / Browser Copilots
Voice AI Systems
AI App Builders / Build Any App In One Prompt
Custom GPTs
AI-Powered Dashboards
Advanced n8n Systems
Chatbots

For each capability, defined current status, owning Brain, supporting Brains, MWMS use case, AIBS/client use case, why it matters, reason for deferral or controlled activation, future activation trigger, required governance, risk level, and possible future MCR page.

Added Registry Entry Template, Capability Review Cadence, Capability Activation Process, Activation Brief Template, Registry Governance Rules, Current Registry Summary, and application sections for Course Absorption, Newsletter Intelligence, AIBS Brain, Product Brain, and M Development.

Added common failure modes including parked means forgotten, everything becomes a page, everything goes to M, commercial hype overriding readiness, duplicate capability pages, vague triggers, registry becoming a graveyard, and prototype becoming production.

Aligned this registry with:

MWMS Advanced AI Capability Stack Framework
MWMS Client AI Interface Selection Framework
MWMS AI Agent Operations Core
MWMS AI Agent Memory And Context Framework
MWMS AI Tool Permission And Access Framework
MWMS AI Operating System Architecture Framework
MWMS Automation Build Planning Framework
MWMS Automation Client Demo And Handover Framework

Purpose of creation:

To create a governed activation system for valuable advanced AI capabilities that are useful to MWMS but not ready for immediate full implementation, ensuring they remain visible, owned, trigger-based, and ready for future activation.