System: MWMS
Document Type: Operating Framework
Authority Level: MCR Source Of Truth
Status: Active
Version: v1.5
Primary Location: MCR
Future Operational Destination: Product Brain, AIBS Brain, Automation Brain, UX Brain, Data Brain, Sales Brain, Client Delivery Systems, HeadOffice Brain
Parent Page: Product Brain
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR
Last Reviewed: 2026-07-26
Source / Origin: MWMS AI App Builder And Productized Interface Framework v1.4 plus Perry Belcher Bigfoot Blueprint Workshop directory, structured data interface, utility-first product, claimed listing, data enrichment, directory flywheel, marketplace progression, SaaS progression, data licensing and monetisation intelligence
MWMS Classification: AI App Builder Framework / Productized Interface Framework / MVP Interface Standard / Client Portal And Dashboard Packaging Framework / Browser Copilot Framework / Embedded AI Interface Standard / Automation To Product Interface Standard / Multimodal Intake Standard / Personal Interaction History Standard / Directory And Structured Data Interface Standard / Data Utility Product Framework
Primary Brain: Product Brain
Supporting Brains: AIBS Brain, Automation Brain, UX Brain, Data Brain, Sales Brain, Compliance Brain, Risk Brain, Finance Brain, HeadOffice Brain, Prompting Framework, Experimentation Brain, Content Brain, Research Brain, Search Intelligence Brain, Partnership Brain, Affiliate Brain
Related MWMS Standards
MWMS AI Agent Operations Core
MWMS AI Agent Orchestration Framework
MWMS AI Agent Memory And Context Framework
MWMS AI Multi Agent Role Design Framework
MWMS AI Tool Permission And Access Framework
MWMS AI Automation Security And Risk Checklist
MWMS AI Output Validation Standard
MWMS AI Output Validation Checklist
MWMS AI Observability Metadata Standard
MWMS AI Usage And Cost Visibility Standard
MWMS AI Workflow Pipeline Standard
MWMS AI Workflow Pipeline Checklist
MWMS AI Ambiguity And Partial Failure Containment Framework
MWMS Client Context Isolation And Privacy Boundary Standard
MWMS Dashboard First Client AIOS Offer Framework
MWMS Micro SaaS Productization And Access Control Framework
MWMS Productized AIOS Service Packaging And Scope Control Framework
MWMS Client Onboarding AIOS And Dashboard System Framework
MWMS Client Approval And Review Gate Protocol
MWMS Client Intelligence And Business Memory Automation Framework
MWMS Source Visibility And Evidence Display Standard
MWMS KPI Dashboard And Insight Summary Framework
MWMS Business Brain Copilot Architecture Framework
MWMS Prompt Architecture And Automation Output Reliability Framework
MWMS n8n Operating And Deployment Standard
Research Brain Market Analysis Method
Research Brain Competitor Analysis Framework
Data Brain Data Capture And Activation Framework
Content Brain Programmatic SEO Framework
MWMS AI Visibility And Answer Engine Authority Framework
Purpose
The purpose of the MWMS AI App Builder And Productized Interface Framework is to define how MWMS uses AI app builders, frontend builders, AI coding tools, databases, payment systems, dashboards, portals, browser extensions, embedded assistants, lightweight web applications, multimodal interfaces, directories, searchable catalogues and structured data products to turn automations and organised information into usable, sellable, understandable, controlled and professionally delivered products.
This framework exists because backend capability alone is not a complete product.
A webhook, Make scenario, n8n workflow, spreadsheet, Airtable base, Supabase database, API, dataset or AI workflow may create real value, but users often need:
a clear interface
a visible product boundary
a searchable or filterable view
a dashboard
a portal
a history screen
a submission screen
a comparison tool
a matching tool
a directory
a structured entity record
a status view
a decision utility
a payment or access layer
an understandable output
a support path
The strategic principle is:
Automations become more valuable when users can understand, access, control and see them.
Structured data becomes more valuable when users can search, compare, evaluate, claim, correct and act on it.
A productized interface must expose real operational value.
It must not disguise weak architecture with polished design.
Definition
AI App Builder
A tool that can create web applications, interfaces, dashboards, prototypes, portals or frontend experiences using natural language, AI coding, templates or assisted development.
Productized Interface
A user-facing or operator-facing interface that makes an automation, AIOS system, workflow, dataset or structured information asset easier to use, sell, demonstrate, govern and support.
MVP Interface
A minimum viable user-facing version of a product or system created to test real user interest, workflow usefulness, decision value or client value.
Client-Facing Interface
Any page, portal, dashboard, app, form, report screen or tool a client or customer can access.
Internal Interface
A tool used only by approved MWMS operators, Brains, AI Employees, Martyn, M or approved internal users.
Directory And Structured Data Interface
A searchable, filterable or navigable product interface that organises entities, places, products, providers, opportunities, resources or records into structured listings designed to support discovery, comparison, evaluation, connection or action.
Structured Entity Record
A controlled record representing one directory entity.
A structured entity record may include:
identity
category
location
attributes
services
pricing
availability
media
proof
reviews
source
verification
freshness
ownership
claim state
correction state
access level
commercial status
Decision Utility
A tool that helps a user make a specific decision through structured data, comparison, scoring, filtering, matching, calculation or guided interpretation.
Claimed Listing
A directory record whose authorised entity representative has completed an approved identity or ownership process and received permission to edit approved fields.
Enriched Listing
A record that contains materially useful information beyond the raw source record.
Marketplace
A system that enables buyers and sellers, requesters and providers, or other participant groups to transact, book, quote, apply, licence, purchase or exchange value.
MWMS Definition
The MWMS AI App Builder And Productized Interface Framework is:
Product Brain’s standard for deciding when and how MWMS should use AI app builders, frontend tools, AI coding tools, databases, interface layers, structured data products and directory systems to turn automations and information assets into usable MVPs, client portals, dashboards, productized AIOS modules, decision utilities, data products and Micro SaaS products while protecting reliability, security, source rights, scope, user experience, data quality and long-term maintainability.
Scope
This framework applies to:
internal operator tools
diagnostic tools
dashboards
approval interfaces
client portals
Micro SaaS tools
browser extensions
embedded assistants
conversational dashboards
multimodal submission systems
personal history systems
directories
catalogues
comparison tools
matching systems
entity record systems
claimed listing systems
decision utilities
data products
marketplaces
paid data access
API enabled products
productized automation interfaces
This framework governs:
product boundary
user journey
interface class
input and output contracts
data state
authentication
authorisation
payment and entitlement
multimodal intake
history
source lineage
structured data presentation
directory listing quality
claim and correction workflows
freshness
marketplace readiness
utility-first launch
productisation maturity
prototype and production boundaries
support
risk
maintainability
cross Brain handoff
This framework does not govern:
final business viability
final capital allocation
unrestricted autonomous publishing
unrestricted scraping
unrestricted data reuse
legal ownership of external data
regulated marketplace operation
financial approval
security approval
compliance approval
developer task assignment
production implementation without approved authority
Core Principle
The interface is not the system.
The interface is the controlled product layer through which the user interacts with the system.
A strong interface should make a strong system easier to use.
It should not make a weak system look finished.
Product Boundary Rule
Before an interface is built, define:
problem
user
desired outcome
input
output
workflow
data
state
permissions
history
support
commercial model
evidence
risk
what the interface does not do
No application should begin with:
“Build an app.”
It should begin with:
“What controlled user outcome must this interface make possible?”
Interface Value Test
A productized interface must improve at least one of the following:
access
clarity
speed
control
visibility
decision quality
workflow completion
evidence visibility
error reduction
reusability
commercial packaging
customer experience
data usefulness
If it does not improve a real outcome, the interface is unnecessary.
Interface Architecture
A controlled MWMS interface may contain:
Presentation Layer
Interaction Layer
Workflow Layer
Data And State Layer
Authentication And Authorisation Layer
Payment And Entitlement Layer
AI And Automation Layer
Evidence And Source Layer
History Layer
Logging And Observability Layer
Support And Escalation Layer
Presentation Layer
The presentation layer should show:
what the product does
what the user can do
what state the system is in
what information is required
what output is available
what evidence supports the output
what limitations apply
what next action is expected
Interaction Layer
Every visible action should have a known backend contract.
For each action define:
actor
permission
input
validation
processing route
AI use
deterministic use
human review
database write
file write
output
status change
logging
failure handling
retry handling
duplicate handling
Database And State Layer
The database should represent real operational state.
Possible states include:
draft
submitted
queued
processing
partially processed
awaiting review
approved
rejected
completed
failed
cancelled
archived
deleted
expired
payment required
access revoked
The database must distinguish:
user identity
client identity
tenant identity
submission identity
workflow identity
output identity
status
version
created time
updated time
review state
entitlement state
archive state
deletion state
The interface must not infer critical state only from what is visible on screen.
State must be represented in the controlled backend or authoritative database.
Authentication And Authorisation Layer
Authentication answers:
Who is the user?
Authorisation answers:
What is the user allowed to do?
Every interface requiring private, client-specific, paid or operational data must define both.
Authentication may include:
secure account login
approved single sign-on
restricted internal identity
time-limited access
approved token-based access
Authorisation must enforce:
user role
client or tenant relationship
record ownership
permitted actions
permitted fields
entitlement
approval authority
administrative authority
Server-side enforcement is required.
Frontend hiding is not sufficient authorisation.
Payment And Entitlement Layer
Where payment controls access, define:
payment provider
customer identity
product
plan
subscription status
entitlement status
activation event
renewal event
failed payment event
cancellation event
refund event
revocation event
grace period
manual override authority
Every protected request must validate current entitlement through an approved backend method.
Possession of a URL, interface, browser extension or stored key is not sufficient proof of entitlement.
Multimodal Intake Layer
MWMS product interfaces may accept:
text
structured fields
images
audio
voice notes
video
documents
spreadsheets
URLs
mixed-modality submissions
Each accepted modality must define:
business purpose
accepted type
accepted format
maximum size
maximum duration where relevant
required metadata
validation method
unsafe-file handling
privacy classification
storage destination
retention period
deletion method
processing route
failure response
human review requirement
Every accepted modality must serve the product outcome.
Multimodal Intake Contract
Each submission should record:
submission identifier
authenticated user identifier
client or tenant identifier
submission date and time
modality type
original filename
content type
file size
storage reference
checksum or duplicate signal where appropriate
processing status
validation status
privacy level
retention status
deletion status
consent status where required
The original input must remain distinguishable from AI interpretation and generated output.
Modality Processing Separation
The controlled pattern is:
User Submission
→ Identity And Permission Check
→ Input Validation
→ Modality Detection
→ Modality Specific Processing
→ Structured Extraction
→ Combined Reasoning
→ Output Generation
→ Output Validation
→ Storage
→ User Display
Different input types should not be passed blindly into one prompt.
Structured Extraction Layer
Before broad AI reasoning, raw input should be converted into structured observations.
Examples:
audio to transcript
image to observations
document to sections and fields
spreadsheet to validated rows
URL to approved source extract
mixed input to linked evidence packet
Observation, interpretation and recommendation must remain separate.
Personal Interaction History Model
Where users require history, the system should preserve:
submission
source
version
status
output
review
changes
replacement
archive state
ownership
access
time
History must be tenant-safe and user-specific.
User Specific Record Retrieval Contract
Every retrieval must enforce:
authenticated identity
record ownership
client or tenant relationship
field visibility
archive rules
deletion rules
entitlement
administrative override rules
Personal history must not rely on browser-only filtering.
Input To Output Traceability
Every output should be traceable to:
input
source
processing route
model or deterministic step
version
review
approval
change
final state
Multi Tool Product Interface
A product may contain multiple tools where they share:
one user
one product boundary
one data model
one entitlement model
one navigation structure
one support path
Unrelated tools must not be bundled merely to increase apparent value.
Error And Partial Processing States
The interface must show where:
processing failed
only part of the input succeeded
a modality failed
data is incomplete
evidence is missing
human review is required
an output is provisional
a retry is available
support is required
Partial success must not be displayed as complete success.
Directory And Structured Data Interface Layer
Directory Product Principle
A directory is not merely a collection of pages.
It is a productized structured data interface that helps a defined user discover, compare, evaluate, contact or act on a defined class of entities.
Directory Opportunity Definition
Before building a directory, define:
I am the directory of:
For:
The exact decision or task supported is:
The underlying data source is:
The value added beyond the raw data is:
The user action enabled is:
The listed entity benefit is:
The initial monetisation path is:
The future product progression is:
Directory Opportunity Qualification
A directory opportunity is stronger where:
information is fragmented
users repeatedly search for the same category
comparison is difficult
existing specialist resources are weak
users require trust or confidence
entities benefit from discoverability
data can be legally structured
enrichment creates material value
records can remain current
multiple monetisation paths exist
a clear user action follows discovery
A directory opportunity is weaker where:
the information is already complete and easy to use
there is no recurring decision
there is no meaningful enrichment
the data cannot be maintained
source rights are unclear
the entity class is too unstable
the interface creates no advantage over the source
the directory exists only to create pages
Specialist Authority Rule
A directory may focus narrowly where narrow scope creates greater relevance and usefulness.
Narrow positioning must be justified by:
user need
entity supply
decision value
data availability
commercial viability
Narrow naming or domain selection does not create authority by itself.
Authority must be earned through:
coverage
accuracy
freshness
usefulness
source integrity
participation
reliable decision support
Structured Entity Record Standard
Each directory entity should use a controlled schema.
Possible fields include:
entity identifier
entity name
entity type
category
subcategory
description
location
service area
contact method
website
features
attributes
services
products
pricing
availability
eligibility
certifications
media
proof
reviews
rating context
source
source licence
source captured date
last verified date
last updated date
verification state
claim state
owner identifier
correction state
commercial tier
sponsorship state
visibility state
archive state
removal state
The schema must be designed around the user’s decision.
Do not add fields merely because they are easy to generate.
Anti Thin Listing Rule
A directory listing must provide materially more value than the raw source record.
A listing may create added value through:
normalised data
comparison fields
decision-specific questions
clear attributes
structured summaries
maps
availability
verified information
current pricing where authorised
media
reviews where authorised
proof
filters
calculators
matching
related entities
source visibility
freshness
owner-verified details
community-contributed corrections
A listing is thin where it merely republishes:
name
address
phone number
website
generic generated description
Thin records must not be published at scale as if they are complete products.
Data Source And Rights Rule
Before data is imported, define:
source
owner
licence
permitted use
attribution requirement
commercial-use permission
redistribution permission
API terms
scraping restriction
retention
refresh rights
deletion obligation
correction path
privacy classification
Public availability does not automatically mean unrestricted reuse.
Data Provenance Record
Each imported or enriched field should be traceable where practical to:
source
source location
captured date
import method
transformation
AI enrichment
human correction
entity correction
confidence
last verification
Source fact and AI-generated interpretation must remain distinguishable.
Data Enrichment Pipeline
The controlled enrichment pattern is:
Define Entity Class
→ Define Schema
→ Locate Approved Sources
→ Verify Source Rights
→ Acquire Base Records
→ Normalise
→ Deduplicate
→ Validate
→ Identify Missing Fields
→ Enrich
→ Record Provenance
→ Run Anti Thin Review
→ Publish Controlled State
→ Monitor Freshness
→ Accept Corrections
→ Revalidate
AI Enrichment Rule
AI may assist with:
normalisation
classification
field extraction
summarisation
comparison
missing-field research
entity matching
duplicate detection
quality review
AI must not:
invent unavailable facts
create fake reviews
infer ownership
assign certification without evidence
claim verification without a check
create false availability
create false pricing
create unsupported rankings
hide source uncertainty
Enrichment Confidence States
Approved states include:
Source Verified
Entity Verified
Human Reviewed
Multi Source Supported
Single Source
AI Interpreted
Unverified
Contradicted
Stale
Deprecated
Listing Freshness Model
Each listing should have a freshness state.
Approved states include:
Current
Recently Verified
Due For Review
Stale
Entity Correction Pending
Source Conflict
Temporarily Unavailable
Archived
Removed
Freshness should be based on:
entity volatility
source reliability
last update
user reports
owner reports
commercial importance
regulatory importance
The interface should show freshness where it materially affects decisions.
Claimed Listing Workflow
The controlled claim pattern is:
Existing Listing
→ Claim Request
→ Identity Submission
→ Entity Relationship Verification
→ Approval Or Rejection
→ Permitted Field Access
→ Change Submission
→ Validation
→ Publication
→ Change History
A claimed listing must not give unrestricted authority over:
source evidence
independent reviews
compliance flags
historical records
paid placement disclosure
system-generated quality signals
other users’ data
Claimed Listing Permission Model
Possible permissions include:
edit contact details
edit opening hours
edit services
upload media
submit proof
respond to reviews
request correction
view listing analytics
purchase approved upgrades
manage authorised users
Claim status must be visible internally.
Verification status must not be sold as if it were independent quality certification.
Owner Submitted Correction Rule
Entity owners may submit corrections.
Corrections must record:
requester
relationship
field
previous value
new value
evidence
review state
reviewer
decision
publication time
Correction requests must not silently overwrite independent evidence.
User Submitted Correction Rule
Users may report:
incorrect information
closed entity
changed contact details
misleading claims
duplicate records
unsafe content
wrong category
stale information
User reports should enter review.
They must not directly rewrite authoritative records.
Review And Rating Governance
Where reviews are included, define:
review source
review ownership
display rights
moderation
verification
response rights
removal rules
fraud controls
disclosure
appeal process
MWMS must not:
copy reviews without permission
fabricate reviews
hide legitimate criticism for commercial reasons
sell suppression of negative reviews
misrepresent sponsored listings as independent rankings
Paid Placement Disclosure Rule
Paid listings, featured listings, sponsored results and premium placement must be visibly disclosed.
Commercial payment must not be represented as independent quality ranking.
Directory Search And Filter Standard
Search and filtering should support the actual user decision.
Possible controls include:
category
location
availability
price
service
feature
eligibility
rating
verification
distance
use case
audience type
delivery model
Filters should reflect reliable data.
Do not expose filters backed by incomplete or invented fields.
Comparison Interface
A comparison interface should:
show comparable fields
identify missing data
show source
show freshness
avoid false precision
avoid unsupported winners
allow user-relevant sorting
distinguish sponsored position
Matching Interface
A matching interface should define:
user input
eligibility
matching logic
ranking logic
commercial influence
confidence
fallback
manual review
explanation
Paid status must not secretly override relevance where the interface claims neutral matching.
Utility First Launch
A new directory or structured data product should normally prove usefulness before aggressive monetisation.
The initial product may provide:
free search
free comparison
free calculator
free matching
free reference data
free basic listings
free claim request
free correction request
Utility-first launch supports:
real usage
feedback
data improvement
sharing
trust
search discovery
product validation
entity participation
Utility-first does not mean uncontrolled free access forever.
The product should define the conditions for introducing:
paid listings
premium tools
lead generation
sponsorship
subscription
marketplace features
data access
API access
Directory Flywheel
The directory flywheel may operate as:
More Approved Listings
→ Greater Usefulness
→ More Users
→ More Searches And Actions
→ More Claims And Corrections
→ Better Data
→ Greater Entity Participation
→ More Useful Listings
The flywheel is not automatic.
It requires:
quality
coverage
freshness
trust
participation
clear value
reliable operation
ethical monetisation
Directory Defensibility
Possible defensibility sources include:
comprehensive data
specialist positioning
proprietary enrichment
first-party data
claimed listings
reviews
historical data
workflow integration
entity participation
user participation
comparison utility
matching logic
brand trust
distribution
API customers
marketplace liquidity
A domain name or a high page count is not a sufficient moat.
Directory Monetisation Boundary
A directory may support:
paid listings
enhanced listings
premium placement
sponsored search
programmatic advertising
lead generation
request-for-quote leads
bookings
reservations
newsletter sponsorships
hosted webinars
affiliate commissions
marketplace fees
job boards
data licensing
API access
training
tools
calculators
SaaS
membership
association services
Each monetisation method must define:
payer
beneficiary
value delivered
price basis
disclosure
tracking
refund rules
quality control
conflict of interest
support
data use
risk
Do not activate every monetisation model at launch.
Monetisation should be introduced where it does not destroy usefulness or trust.
Claim To Paid Upgrade Boundary
A claimed listing may be offered paid upgrades only where:
the entity receives genuine value
the upgrade is optional
the terms are clear
free access is not falsely degraded
sponsored placement is disclosed
verification is not sold as quality approval
analytics are accurate
cancellation is controlled
Directory To Marketplace Progression
A directory may progress toward a marketplace only after evidence of:
sufficient supply
sufficient demand
repeated user intent
participant reliability
transaction value
verification capability
support capacity
commercial viability
fraud controls
payment controls
dispute controls
legal readiness
The controlled progression is:
Directory
→ Claimed Listings
→ User Demand
→ Lead Exchange
→ Booking Or Quote Flow
→ Transaction Layer
→ Marketplace
Marketplace Readiness Record
Record:
supply count
active supply
demand volume
repeat demand
transaction intent
average transaction value
take-rate model
payment method
refund model
dispute path
fraud controls
verification
support
insurance or liability needs
regulatory review
go or no-go decision
Directory To SaaS Progression
A directory may progress toward SaaS where entities or users repeatedly need tools beyond discovery.
Possible tools include:
entity dashboard
lead inbox
listing management
analytics
review management
booking management
quote management
comparison export
workflow tools
data alerts
market intelligence
API access
team access
The controlled progression is:
Directory Utility
→ Repeated User Need
→ Tool Hypothesis
→ Manual Test
→ MVP Tool
→ Paid Entitlement
→ Usage Review
→ SaaS Product
Directory To Newsletter Progression
A directory may support a newsletter where it has a recurring reason to communicate:
new listings
market changes
opportunities
events
jobs
price changes
availability
research
alerts
industry updates
Newsletter growth must not rely on undisclosed email harvesting.
Consent and communication rules must be respected.
Directory To Association Or Membership Progression
A directory may support membership or association services where there is genuine participant value.
Possible benefits include:
standards
education
events
peer access
verified profiles
research
advocacy
tools
discounts
certification where legitimate
An association name alone does not create authority.
Authority requires:
members
governance
activity
standards
credible leadership
transparent purpose
real value
Data Licensing And API Readiness
A directory may expose governed data through:
reports
exports
licenced datasets
approved feeds
API access
Before data licensing, define:
ownership
source rights
field rights
commercial rights
personal data controls
customer use
rate limits
entitlement
versioning
refresh
accuracy disclaimer
support
revocation
audit
downstream redistribution
Data that MWMS does not have the right to redistribute must not be licensed.
Entity Dashboard Standard
A directory entity dashboard may show:
listing state
claim state
verification state
profile completeness
traffic
views
clicks
leads
bookings
reviews
corrections
freshness
subscription
entitlement
invoices
support
Analytics must be accurate and scoped.
The dashboard must not imply causality that cannot be supported.
Public, Paid And Restricted Access Tiers
Possible directory access tiers include:
Public
basic search and approved public records
Registered
saved lists
alerts
history
personalisation
Entity
claimed listing
approved editing
analytics
lead access
Paid User
advanced filters
exports
matching
alerts
premium tools
Data Customer
approved reports
licensed exports
API access
Administrator
governance
moderation
support
commercial control
Access must be enforced server-side.
Directory Risk And Governance
Directory-specific risks include:
source rights violations
privacy violations
stale records
false listings
duplicate entities
fake claims
fraudulent ownership
misleading paid placement
unsupported rankings
fabricated enrichment
copied reviews
review manipulation
false verification
unsafe providers
regulated category exposure
marketplace liability
data leakage
API abuse
undisclosed lead resale
uncontrolled email use
algorithmic bias
search manipulation
Each directory implementation must maintain:
source register
licence register
schema
provenance rules
claim process
correction process
review rules
commercial disclosure rules
freshness policy
removal process
incident process
privacy classification
support path
risk owner
Prototype And Production Boundary
A prototype may use:
temporary data
restricted users
manual review
limited automation
small-scale storage
manual entitlement
known constraints
sample listings
manual corrections
manual claim approval
A production product requires:
controlled architecture
stable data model
server-side access control
tested integrations
monitoring
logging
support path
backup
recovery
retention rules
security review
production payment handling
client isolation
user isolation
multimodal validation where applicable
history integrity
version control
rollback
source-rights review
data provenance
freshness process
claim controls
correction controls
commercial disclosure
removal process
Rule
Prototype quickly.
Productionize deliberately.
Interface Classes
Type 1: Internal Operator Interface
Purpose:
allow an MWMS operator or employee to control, review, monitor or correct a workflow
Examples:
task queues
approval screens
records interfaces
automation monitoring
AI Employee review
Best characteristics:
direct
functional
state visible
log aware
manually controllable
Type 2: Diagnostic Interface
Purpose:
collect business details
score opportunities
generate diagnostic output
support AIBS sales
Examples:
automation audit application
business memory intake
lead leakage checker
AIOS readiness assessment
Type 3: Dashboard Interface
Purpose:
show performance, value, system activity and required action
Examples:
review dashboard
lead flow dashboard
voice agent call dashboard
content production dashboard
client intelligence dashboard
Dashboards should distinguish:
activity
output
outcome
forecast
financial translation
The dashboard must not present activity counts as proof of business value without valid attribution.
Type 4: Approval Interface
Purpose:
review and approve AI or automation output
Examples:
content draft approval
outreach message approval
proposal review
AI report review
social posting approval
The interface must preserve:
source material
draft output
approval status
reviewer
review time
requested changes
final version
Type 5: Client Portal
Purpose:
allow clients to see reports, outputs, status, evidence, value and next actions
Examples:
AIBS client portal
audit report portal
project status portal
content assets portal
review system portal
Client portals require stronger:
authentication
client isolation
support
privacy
evidence display
status accuracy
Type 6: Micro SaaS Interface
Purpose:
let paid users access a defined tool or outcome
Examples:
content repurposer
proposal generator
review request system
lead magnet generator
document analyser
multimodal report generator
Micro SaaS interfaces require:
clear product boundary
payment entitlement
usage rules
support
history behaviour
access revocation
cost awareness
Type 7: Browser Extension Or Copilot
Purpose:
provide context-specific assistance inside an existing browser workflow
Examples:
LinkedIn response assistant
YouTube conversation assistant
page summariser
research helper
Browser interfaces must not hold unrestricted credentials, unrestricted business logic or source-of-truth authority.
Type 8: Embedded Assistant
Purpose:
provide bounded support, qualification, recommendation or knowledge access inside a website or portal
Embedded assistants require:
approved knowledge sources
clear scope
fallback
escalation
evidence where needed
protection against invented answers
Type 9: Conversational Dashboard
Purpose:
allow users to ask controlled questions about approved reports, metrics, records or operational data
The system must:
retrieve approved data
show evidence
respect permissions
distinguish source facts from interpretation
avoid unrestricted database access
Type 10: Multimodal Submission Interface
Purpose:
allow a user to submit text, images, audio, video, documents, URLs or mixed inputs and receive a controlled result
Examples:
field report application
inspection tool
image and voice report system
document and commentary analyser
progress tracking tool
Multimodal interfaces require:
modality contracts
file validation
source lineage
partial processing states
personal history
user-specific retrieval
privacy controls
Type 11: Personal History Interface
Purpose:
allow authorised users to view previous submissions, reports, outputs, progress and approved records
Personal history interfaces require:
record ownership
tenant-safe retrieval
version visibility
replacement state
archive behaviour
deletion behaviour
entitlement
support
Type 12: Directory And Structured Data Interface
Purpose:
allow users to discover, search, filter, compare, evaluate, claim, correct or act on governed structured entity records
Examples:
provider directory
product catalogue
event directory
industry database
resource directory
comparison site
location finder
market intelligence catalogue
job directory
opportunity directory
Directory interfaces require:
defined user decision
approved data sources
structured entity schema
anti-thin listing rules
provenance
freshness
claim controls
correction controls
commercial disclosure
search and filter integrity
support
removal process
Type 13: Comparison And Matching Interface
Purpose:
help users compare options or receive a bounded match based on declared criteria
Requirements:
comparable fields
missing-data handling
explainable logic
commercial influence disclosure
confidence
fallback
evidence
human support where material
Type 14: Marketplace Interface
Purpose:
allow approved participants to transact, quote, book, apply or exchange value
Marketplace interfaces require:
verified participants
payment controls
fraud controls
dispute handling
refund rules
support
commercial rules
liability review
regulatory review
transaction records
Type 15: Data Product And API Interface
Purpose:
provide approved users or systems access to governed structured data
Requirements:
source rights
licence
entitlement
rate limits
versioning
field definitions
refresh
audit
revocation
support
downstream-use controls
Self Service Client Experience Standard
A self-service interface may allow users to:
submit information
view status
view approved reports
see evidence
download outputs
approve work
submit requests
see next actions
view personal or company history
search records
save comparisons
claim listings
submit corrections
manage entitlements
Self-service must not remove the human support path.
The system should show when:
information is current
data is delayed
analysis is generated
human review is required
an issue has been escalated
processing is partial
access is restricted
an output has been replaced
a listing is stale
a claim is pending
a correction is under review
a result is sponsored
Rule
Self-service should improve visibility without transferring operational confusion to the user.
Interface Tool Selection
Tool selection should follow the problem and maturity level.
Possible tools include:
WordPress
Supabase
Airtable
Google Sheets
Make
n8n
Lovable
Bolt.New
Replit
Claude Code
Claude-generated HTML
Carrd
Chrome extensions
custom development
Stripe
Vercel
Tool Selection Questions
Ask:
what user experience is required
what data must persist
what level of security is required
what integrations are needed
what modalities are accepted
how files are stored
how history is retrieved
how many users are expected
is the product internal or external
does the code need to be exported
is version control required
is payment required
what maintenance capacity exists
does the interface need to survive the original builder
how many directory records are expected
how frequently records change
whether full-text search is required
whether location search is required
whether entity claims are required
whether marketplace progression is expected
whether API access is expected
Choose the lightest tool that meets the real requirements without creating unacceptable risk or lock-in.
Tool Agnostic Rule
MWMS does not absorb builder-specific workshop steps into Canon as permanent architecture.
Replit, WordPress, Supabase or any other platform may be used where appropriate.
The product boundary, data model, permissions, provenance, support and migration path must survive the choice of builder.
App Builder Dependency Rule
Review:
code ownership
exportability
hosting dependency
pricing dependency
database dependency
authentication dependency
platform limits
unsupported features
builder shutdown risk
migration path
file storage dependency
history portability
search scalability
record scalability
API portability
data exportability
The product should not become impossible to maintain because the original builder becomes unavailable.
Minimum Viable Interface
A minimum viable interface should include only what is required to validate:
the user
the problem
the workflow
the output
the decision value
the trust boundary
the commercial hypothesis
For a directory, the minimum viable interface may include:
one defined entity class
one controlled schema
one approved data source
one useful search or filter
one entity page
one correction route
one freshness indicator
one clear user action
one support path
one measurement plan
MVP does not mean:
uncontrolled
insecure
untraceable
misleading
thin
unsupported
Validation Before Expansion
Before adding features, validate:
users understand the product
users complete the core action
data is useful
records are accurate enough
search works
filters help decisions
users return
entities engage
support burden is manageable
monetisation does not damage value
risk remains acceptable
Feature Expansion Rule
A feature should be added only where it supports:
user outcome
commercial value
risk control
operational efficiency
data quality
supportability
retention
defensibility
Do not add:
marketplace
SaaS
association
API
AI assistant
complex dashboard
advanced payment
multiple monetisation systems
until the underlying need is proven.
Sales Demo Standard
A product demo should show:
problem
user
current friction
input
workflow
state
output
evidence
control
value
next action
For a directory, show:
what the user is trying to find
how the directory improves the decision
what fields are trustworthy
how records are updated
what action follows
what is sponsored
what support exists
Do not demonstrate only visual polish.
Productized Interface Pricing Logic
Pricing may consider:
user value
business outcome
access scope
number of users
number of records
workflow complexity
data cost
AI cost
support
integration
security
maintenance
entitlement
commercial risk
update frequency
marketplace operation
API volume
Do not price solely by:
number of screens
number of prompts
number of automation nodes
time spent in the app builder
Required Product Specification
Before production, record:
product name
problem
user
interface class
primary outcome
scope
exclusions
inputs
outputs
workflow
data
states
permissions
history
source
evidence
multimodal requirements
directory requirements where relevant
claim process where relevant
correction process where relevant
freshness where relevant
commercial model
entitlement
support
risk
acceptance criteria
test plan
rollback
what not to touch
Future AI Employee Roles
AI Product Interface Architect
Primary Brain: Product Brain
Status: Parked Candidate
Purpose: Defines interface class, product boundary, user journey, states and production requirements.
Multimodal Intake Architect
Primary Brain: Product Brain / Data Brain
Status: Parked Candidate
Purpose: Defines accepted modalities, processing separation, storage, lineage, failure states and privacy controls.
Personal Interaction History Architect
Primary Brain: Product Brain / Data Brain
Status: Parked Candidate
Purpose: Defines user-specific history, record ownership, version visibility, archive behaviour and tenant-safe retrieval.
Browser Copilot Product Designer
Primary Brain: Product Brain
Status: Parked Candidate
Purpose: Designs bounded browser-based assistance without exposing unrestricted logic or credentials.
Conversational Data Experience Designer
Primary Brain: Product Brain / Data Brain
Status: Parked Candidate
Purpose: Designs conversational access to dashboards, reports, catalogues and governed operational data.
Embedded Assistant Experience Designer
Primary Brain: Product Brain / UX Brain
Status: Parked Candidate
Purpose: Designs website assistants that provide bounded support, recommendations, qualification or diagnostic experiences.
Directory Product Architect
Primary Brain: Product Brain / Data Brain
Status: Parked Candidate
Purpose: Defines directory opportunity, user decision, entity schema, listing quality, data provenance, claim workflow, freshness, monetisation boundaries and product progression.
Structured Data Quality Reviewer
Primary Brain: Data Brain / Product Brain
Status: Parked Candidate
Purpose: Reviews source rights, schema quality, enrichment confidence, anti-thin compliance, duplication, provenance and freshness.
Marketplace Readiness Reviewer
Primary Brain: Product Brain / Risk Brain / Finance Brain
Status: Parked Candidate
Purpose: Evaluates supply, demand, transaction intent, payment, fraud, support, liability, economics and progression readiness.
Drift Protection
This framework protects MWMS from:
building apps for the sake of apps
confusing polished UI with real value
confusing visual completion with product completion
turning every automation into SaaS
launching prototypes as production
exposing private data through interfaces
weak access control
payment access mismatch
dashboard bloat
feature bloat
overbuilding MVPs
skipping user testing
burdening M with vague cleanup
creating client-facing systems without support paths
hiding backend fragility behind nice design
creating tools users do not understand
overusing builder-specific architecture
excessive browser permissions
exposed browser webhooks
conversational interfaces inventing answers
self-service systems with no human escalation
frontend-only user filtering
cross-client history exposure
accepting unsafe files
hiding partial multimodal failure
mixing source facts with AI interpretation
untraceable outputs
unstructured multi-tool products
creating directories only to generate pages
publishing thin listings
using public data without rights review
inventing directory enrichment
copying reviews without permission
selling verification as quality approval
undisclosed paid placement
allowing claims to overwrite independent evidence
publishing stale records without warning
launching marketplaces before readiness
licensing data MWMS does not control
turning every directory into SaaS
assuming a domain creates authority
assuming large page counts create a moat
treating AI-generated facts as verified
hiding commercial influence in ranking or matching
Drift Signals
Watch for:
“This would look cool as an app.”
“The interface is finished because it renders.”
“The builder says deployment succeeded, so verification is unnecessary.”
“Let’s make it SaaS.”
“Replit can do everything.”
“Lovable can build it quickly.”
“We do not need to test it.”
“The backend can come later.”
“We can add payment later.”
“Access control is not important yet.”
“The dashboard looks impressive.”
“The client will love the interface.”
“M can clean it up later.”
“Let’s launch the prototype.”
“We need more features before testing.”
“The UI looks professional, so it is ready.”
“AI generated the code, so it should work.”
“We can deploy directly from the builder.”
“We do not need GitHub yet.”
“Accessibility can come later.”
“Animation makes it feel premium.”
“We can just filter the table in the browser.”
“The user will only see their own records.”
“The upload worked, so the file is safe.”
“We can send all input types to one prompt.”
“The output looks complete.”
“The failed audio does not matter because the image worked.”
“We can add history later.”
“Let’s import every public record.”
“AI can fill in the missing facts.”
“More listings automatically means more authority.”
“We can monetise it immediately.”
“The entity paid, so it should rank first without disclosure.”
“The owner claimed the listing, so their version is now the truth.”
“We can copy the reviews.”
“The marketplace can come later.”
“The directory will rank automatically.”
“We can sell the data because it is public.”
Governance Boundaries
Product Brain owns:
product boundary
interface class
user journey
feature scope
product progression
product usefulness
interface acceptance criteria
Data Brain owns:
schema
provenance
data quality
source records
structured access
data retention
data correction architecture
data licensing controls
Research Brain owns:
market evidence
opportunity research
competitor structure
customer decision needs
research confidence
Search Intelligence Brain and Content Brain govern:
structured search discovery
answer-engine visibility
programmatic content boundaries
information gain
refresh strategy
AIBS Brain governs:
commercial system packaging
client delivery
service productisation
SaaS packaging where applicable
Partnership Brain and Sales Brain govern:
entity outreach
commercial partnerships
listing sales
claim communications
sponsorship sales
Finance Brain governs:
economic viability
pricing
margin
capital
marketplace economics
data product economics
Risk Brain and Compliance Brain govern:
source rights
privacy
regulated categories
fraud
claims
marketplace liability
consumer protection
commercial disclosure
HeadOffice retains authority over:
major product decisions
cross-Brain conflicts
investment
governance
strategic progression
high-risk activation
Developer Boundary
This framework does not authorise Product Brain to change M’s active build areas.
Before developer involvement, define:
problem
user
scope
workflow
data
interface class
states
permissions
history
multimodal requirements
directory requirements
source rights
claim rules
freshness
acceptance criteria
test requirements
what not to touch
The goal is to prevent vague cleanup work being handed to M.
Architectural Intent
The architectural intent of this framework is to ensure MWMS treats AI-generated interfaces, directories and structured data products as controlled product layers, not substitutes for real architecture.
The long-term MWMS standard is:
real problem
clear product boundary
known user
approved inputs
controlled processing
authoritative data
source rights
stable workflow
secure access
tenant-safe history
traceable output
visible state
validated result
useful structured data
freshness
claim integrity
commercial disclosure
support path
measured outcome
The interface should make a strong system easier to use.
It should not make a weak system look finished.
A directory should make fragmented information more useful.
It should not reproduce weak data at scale.
MWMS System Change Log
Version: v1.5
Date: 2026-07-26
Author: MWMS HeadOffice / Product Brain
Change
Updated the MWMS AI App Builder And Productized Interface Framework from v1.4 to v1.5 using the strongest non-duplicative directory, structured data product, utility-first product, claimed listing, data enrichment, directory flywheel, marketplace progression, SaaS progression, data licensing and monetisation intelligence absorbed from Perry Belcher Bigfoot Blueprint Workshop.
Added
Directory And Structured Data Interface definition
Structured Entity Record definition
Decision Utility definition
Claimed Listing definition
Enriched Listing definition
Marketplace definition
Directory And Structured Data Interface Layer
Directory Product Principle
Directory Opportunity Definition
Directory Opportunity Qualification
Specialist Authority Rule
Structured Entity Record Standard
Anti Thin Listing Rule
Data Source And Rights Rule
Data Provenance Record
Data Enrichment Pipeline
AI Enrichment Rule
Enrichment Confidence States
Listing Freshness Model
Claimed Listing Workflow
Claimed Listing Permission Model
Owner Submitted Correction Rule
User Submitted Correction Rule
Review And Rating Governance
Paid Placement Disclosure Rule
Directory Search And Filter Standard
Comparison Interface
Matching Interface
Utility First Launch
Directory Flywheel
Directory Defensibility
Directory Monetisation Boundary
Claim To Paid Upgrade Boundary
Directory To Marketplace Progression
Marketplace Readiness Record
Directory To SaaS Progression
Directory To Newsletter Progression
Directory To Association Or Membership Progression
Data Licensing And API Readiness
Entity Dashboard Standard
Public, Paid And Restricted Access Tiers
Directory Risk And Governance
Type 12 Directory And Structured Data Interface
Type 13 Comparison And Matching Interface
Type 14 Marketplace Interface
Type 15 Data Product And API Interface
Directory Product Architect
Structured Data Quality Reviewer
Marketplace Readiness Reviewer
expanded Tool Selection Questions
expanded Prototype And Production Boundary
expanded Minimum Viable Interface
expanded Required Product Specification
expanded Drift Protection
expanded Drift Signals
expanded Governance Boundaries
Clarified
directories are productized structured data interfaces rather than mass page-generation systems
specialist authority must be earned through usefulness, quality, coverage and freshness
every published listing must materially improve on the raw source
public availability does not equal unrestricted reuse
AI enrichment must remain distinguishable from verified source facts
claimed listings require identity, field-level permission and change history
owner corrections cannot silently overwrite independent evidence
reviews require source and display rights
paid placement must be disclosed
utility should normally be proven before aggressive monetisation
a directory flywheel is conditional on quality, freshness, participation and trust
a domain name and large page count are not defensibility
marketplaces require supply, demand, payment, fraud, support and risk readiness
directory-to-SaaS progression must follow repeated product need
data licensing requires ownership and redistribution rights
builder-specific workshop instructions do not become permanent MWMS Canon architecture
Pages Created
None
Pages Updated
MWMS AI App Builder And Productized Interface Framework
Pages Deprecated
None
Standalone Pages Not Created
The following standalone pages were not created because their durable intelligence is governed within this updated framework:
MWMS Directory Product Framework
MWMS Structured Entity Record Standard
MWMS Claimed Listing Workflow
MWMS Directory Flywheel Framework
MWMS Directory To Marketplace Progression Framework
MWMS Directory To SaaS Progression Framework
MWMS Directory Data Licensing Framework
MWMS Anti Thin Directory Standard
MWMS Utility First Directory Launch Framework
Registries Requiring Update
MCR Page Registry
Product Brain Page Registry
MCR Copy Map where the Product Brain framework copy and version are recorded
Required Registry Change
Update the existing MWMS AI App Builder And Productized Interface Framework entry from v1.4 to v1.5 and record the addition of directory and structured data interface architecture, entity schema, anti-thin listing controls, source rights and provenance, claimed listing and correction workflows, freshness, utility-first launch, directory flywheel, marketplace and SaaS progression, data licensing, directory monetisation boundaries and directory-specific governance.
Canon Version Update Required
No immediate Product Brain Canon version change is required unless the current Canon directly records framework versions or contains an interface classification that conflicts with this update.
Change Log Entry Required
Yes.
The v1.5 update must be recorded in:
MWMS System Change Log
MCR Page Registry change history where applicable
Product Brain Page Registry change history where applicable
Previous Version
Version: v1.4
Date: 2026-06-28
Author: HeadOffice
Change
Updated the MWMS AI App Builder And Productized Interface Framework from v1.3 to v1.4 using the AI Automations by Jack transcript block covering multimodal Micro SaaS applications, image and audio submission, user-specific record history, persistent client records, per-user output retrieval, multi-tool paid applications and productized interface delivery.
Added
Multimodal Intake Layer
Multimodal Intake Contract
Modality Processing Separation
Structured Extraction Layer
Combined Reasoning Layer
Personal Interaction History Model
Personal History Rules
User Specific Record Retrieval Contract
Input To Output Traceability
Multi Tool Product Interface
Error And Partial Processing States
Multimodal Submission Interface class
Personal History Interface class
END MWMS AI APP BUILDER AND PRODUCTIZED INTERFACE FRAMEWORK v1.5