MWMS Advanced AI Capability Activation Registry

System: MWMS
Document Type: Registry
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Version: v1.0
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-05-31
Source / Origin: AI Automations by Jack — Advanced Technology Section
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 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, and advanced n8n systems. The first absorption pass created the MWMS Advanced AI Capability Stack Framework and MWMS Client AI Interface Selection Framework, but several valuable capabilities require a governed activation registry so they are not forgotten before full implementation.

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.

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.

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
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
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:
Future Activation Trigger:
Required Governance Before Use:
Risk Level:
Possible Future MCR Page:
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 tools such as local model runners, open-source LLMs, locally hosted embeddings, private inference environments, or 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 Dashboards

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

Description

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

The Advanced Technology section flagged AI-powered dashboards as a future-facing capability.

MWMS is already moving in this direction through HeadOffice Dashboard, Newsletter Intelligence, Task List, Queue Review, Routed Actions, and future Brain dashboards.

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

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

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

Current Reason For Controlled Expansion

Dashboards can easily become noisy if:

data quality is weak
metrics are undefined
AI summaries are unvalidated
stale data appears current
users are overloaded
dashboard items do not connect to action

Future Activation Trigger

Expand this capability when:

HeadOffice dashboard stabilizes further
AIBS package reporting is designed
client value proof becomes required
Data Brain defines dashboard standards
Experimentation Brain needs live reporting
AI Employee performance metrics need display

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

Registry Rule

AI dashboards should prove value and support decisions.

They should 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, 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.

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

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

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.

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

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

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

Registry Rule

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

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 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

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

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, 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

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

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

Registry Rule

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

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

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, 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, or replaced, 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
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	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 Dashboards	Active Concept / Future Expansion	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

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

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

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

Product Rule

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

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.

Strategic Summary

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

This solves the problem of useful ideas being forgotten without forcing MWMS to build every idea immediately.

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

Some are already partly absorbed into frameworks.

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.
Activate them only when the constraint appears.

This registry turns parked ideas into governed future capability.

Change Log

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.