Document Type: Standard
Status: Canon
Version: v1.0
Authority: HeadOffice
Applies To: All Supabase databases, schemas, tables, columns, views, functions, triggers, and API endpoints used within MWMS
Parent: MWMS Supabase Task Schema Standard
Last Reviewed: 2026-04-22
Purpose
MWMS Supabase Naming Standard defines the required naming structure used across Supabase schemas supporting MWMS Brain communication, task lineage, signal logging, and governance traceability.
Consistent naming ensures:
• stable cross-brain routing
• predictable WordPress integration
• consistent query behaviour
• reduced schema drift
• easier debugging and maintenance
• clear lineage visibility
• compatibility with automation layers
• compatibility with AI executor logic
Inconsistent naming introduces structural instability and increases implementation risk.
Naming discipline ensures MWMS remains scalable and auditable as the ecosystem expands.
Scope
This standard applies to:
• Supabase tables
• columns
• foreign keys
• indexes
• views
• triggers
• stored procedures
• API routes generated from Supabase
• join tables
• signal storage tables
• task system tables
• lineage reference fields
This standard governs naming structure only.
It does not define:
• table logic
• RLS policy logic
• SQL performance optimisation rules
• automation behaviour
• Brain authority rules
Those remain governed by:
MWMS Supabase Task Schema Standard
MWMS Brain Connector Architecture
MWMS System Data Flow Map
Core Principle
Supabase naming must remain:
predictable
machine readable
human readable
structurally consistent
aligned with cross-brain routing logic
Naming must support traceable lineage across:
Brain Request → Task → Task Events → Output → Decision → Lesson
If naming reduces traceability, it violates MWMS structure discipline.
Global Naming Rules
Character Rules
Allowed:
lowercase letters
numbers
underscores
Not allowed:
spaces
hyphens
camelCase
PascalCase
special characters
Correct:
mwms_brain_requests
affiliate_offer_intel
research_signal_log
Incorrect:
MWMSBrainRequests
affiliate-offer-intel
ResearchSignals
offerIntel
Case Format
All Supabase identifiers must use:
snake_case
Example:
created_at
request_id
signal_confidence
Pluralisation Rule
Tables should generally use plural nouns.
Examples:
mwms_tasks
mwms_task_events
affiliate_offers
research_signals
Singular allowed when representing:
configuration
state object
system singleton
Examples:
system_config
schema_version
Prefix Rules
MWMS System Tables
Core system tables must use:
mwms_
Examples:
mwms_brain_requests
mwms_tasks
mwms_task_events
mwms_task_artifacts
mwms_decision_records
mwms_lessons_learned
Required for canonical task lineage.
Brain-Specific Tables
Brain-specific tables should use:
brain prefix structure:
affiliate_
research_
experimentation_
finance_
headoffice_
sit_
data_
Examples:
affiliate_offer_intel
affiliate_opportunity_queue
research_signal_log
research_source_registry
experimentation_test_registry
finance_capital_decisions
headoffice_signal_views
Join Tables
Join tables should use:
alphabetical order where possible.
Example:
affiliate_research_links
experiment_finance_dependencies
Column Naming Rules
Primary Keys
All primary keys must use:
id
Type:
uuid
Example:
id uuid primary key
Foreign Keys
Foreign keys must reference the parent table name.
Format:
{parent_table}_id
Examples:
request_id
task_id
offer_id
experiment_id
decision_id
Timestamp Fields
Standard timestamp fields:
created_at
updated_at
Use:
timestamptz
Optional:
processed_at
completed_at
reviewed_at
Status Fields
Status fields must use:
status
Values should be lowercase text.
Examples:
new
queued
running
completed
failed
blocked
escalated
JSON Fields
JSON fields must use:
_json suffix
Examples:
meta_json
payload_json
result_json
Type:
jsonb
Boolean Fields
Boolean fields should begin with:
is_
has_
requires_
Examples:
is_active
has_dependency
requires_review
Confidence Fields
Confidence indicators should use:
confidence_level
Examples:
signal_confidence_level
evidence_confidence_level
Request Lineage Naming Rules
Cross-brain lineage fields must remain consistent.
Standard lineage fields:
origin_brain
target_brain
primary_brain
supporting_brains
request_type
signal_type
confidence_level
priority
outcome_type
review_owner
Aligned with connector architecture requirements.
View Naming Rules
Views should use:
_v suffix
Examples:
affiliate_offer_summary_v
research_signal_density_v
finance_capital_exposure_v
Views must not mimic table naming exactly.
Suffix ensures query clarity.
Function Naming Rules
Functions should begin with:
fn_
Examples:
fn_calculate_signal_strength
fn_assign_opportunity_stage
fn_generate_request_payload
Index Naming Rules
Indexes should use:
idx_
Examples:
idx_tasks_status
idx_requests_created_at
idx_signals_confidence
Enum Naming Rules (if used)
Enums should use:
enum_
Examples:
enum_signal_type
enum_request_status
Relationship Naming Discipline
Relationship naming must remain predictable for WordPress integration.
Example mapping:
Supabase field:
offer_id
WordPress PHP variable:
$offer_id
Consistency reduces integration complexity.
Alignment With PHP Structure
PHP naming should remain compatible with Supabase naming.
Example:
Supabase:
affiliate_offer_intel
PHP function:
mwms_affiliate_offer_intel_fetch()
Supports modular architecture discipline.
Drift Protection
The system must prevent:
mixed casing conventions
synonym drift across tables
duplicate naming patterns
renaming without governance visibility
schema aliasing breaking lineage
inconsistent foreign key naming
table names inconsistent with Brain naming structure
Naming drift creates:
routing failure
broken joins
reduced auditability
inconsistent dashboards
Naming discipline protects system integrity.
Architectural Intent
MWMS Supabase Naming Standard exists to ensure all data structures remain:
traceable
consistent
automation-ready
connector-compatible
stable across environments
Naming consistency ensures:
Brain communication remains reliable
WordPress integration remains predictable
task lineage remains auditable
future automation remains compatible
Stable naming supports scalable system intelligence.
Relationship to Other Standards
This standard complements:
MWMS Supabase Task Schema Standard
MWMS Brain Connector Architecture
MWMS Standard Cross Brain Flow
MWMS PHP Build & Modularity Standard
MWMS System Data Flow Map
Final Rule
If naming prevents clear lineage between:
request
task
signal
decision
learning
the schema is not MWMS compliant.
Naming clarity protects system clarity.
Change Log
Version: v1.0
Date: 2026-04-22
Author: HeadOffice
Initial creation of MWMS Supabase Naming Standard defining canonical naming structure for Supabase schema objects across MWMS ecosystem.
Establishes snake_case discipline, lineage-safe naming patterns, Brain-prefix structure, and compatibility alignment with MWMS PHP modular architecture.