status: Standard
Version: v1.0
Authority: MWMS HeadOffice
Applies To: All Supabase schemas, tables, columns, views, functions, triggers, indexes, constraints, policies, buckets, and scheduled jobs across MWMS
Parent: Governance
Last Reviewed: 2026-03-20
Purpose
This standard exists to enforce consistent naming across all Supabase infrastructure used by MWMS.
It prevents naming drift between sessions, tools, contributors, and Brains.
It ensures that database objects remain predictable, readable, auditable, and safe to maintain as MWMS expands.
This standard applies across all Brains.
This is not a task-only rule.
This is not an Affiliate-only rule.
This is the naming authority for all Supabase build work unless a narrower child standard explicitly governs a subsystem without contradicting this page.
Core Principle
Supabase object names are system infrastructure.
They must not change casually, stylistically, or session-by-session.
Naming must be stable, descriptive, and consistent across the whole ecosystem.
AI tools do not invent new naming patterns.
They must follow the existing standard.
Mandatory Global Rules
All Supabase object names must use:
- lowercase only
- snake_case only
- no spaces
- no hyphens
- no camelCase
- no PascalCase
Names must be descriptive, not clever.
Names must reflect system meaning, not temporary UI wording.
Names must not be renamed for preference alone.
Existing live names must remain stable unless a formal migration is approved.
Domain Prefix Rule
All major Supabase objects should begin with a domain, system, or Brain-aligned prefix where appropriate.
Examples:
- mwms_
- affiliate_
- ads_
- audience_
- research_
The prefix must reflect the owning system or bounded domain.
Do not create unrelated naming patterns inside the same domain.
Table Naming Rule
Tables must use lowercase snake_case.
Table names should be stable domain-led nouns.
Preferred pattern:
<domain>_<entity>
Examples:
- affiliate_offers
- affiliate_experiments
- audience_events
- mwms_tasks
Do not use page titles, UI labels, or vague generic names such as:
- data
- items
- stuff
- records
- temp_table
Do not create alternate names for an already-established entity.
If one canonical table exists, future work must reuse that naming pattern.
Column Naming Rule
Columns must use lowercase snake_case.
Column names should describe the stored field, not the UI label.
Standard shared fields should remain consistent wherever used:
- id
- created_at
- updated_at
- deleted_at
- status
- notes
- meta_json
Foreign key fields should use:
<referenced_entity>_id
Examples:
- offer_id
- task_id
- experiment_id
Do not mix alternate forms such as:
- offerId
- offerID
- id_offer
View Naming Rule
Views must use lowercase snake_case.
Views should clearly describe the read-model, rollup, summary, or derived purpose.
Preferred pattern:
<domain>_<subject>_<purpose>
Version suffixes may be used only where replacement is intentional.
Examples:
- mwms_task_event_rollup_clean_v1
- affiliate_offer_summary
- audience_state_current
Do not create vague names such as:
- final_view
- new_rollup
- better_version
Function / RPC Naming Rule
Functions must use lowercase snake_case.
Function names should begin with a verb and describe the action performed.
Preferred pattern:
<verb>_<subject>
or<domain>_<verb>_<subject>
Examples:
- derive_audience_state
- mwms_rollup_task_events
- archive_affiliate_offer
Do not use unclear abbreviations unless they are already canonically established.
Trigger Naming Rule
Triggers must use lowercase snake_case.
Preferred pattern:
trg_<table>__<event>_<purpose>
Examples:
- trg_affiliate_offers__before_update_stamp
- trg_audience_events__after_insert_validate
Constraint Naming Rule
Constraints must be explicitly named where practical.
Preferred patterns:
- primary key:
pk_<table> - foreign key:
fk_<from_table>__<to_table> - unique:
uq_<table>__<column_or_columns> - check:
chk_<table>__<rule>
Examples:
- pk_affiliate_offers
- fk_affiliate_offer_intel__affiliate_offers
- uq_audience_events__event_uuid
Index Naming Rule
Indexes must use lowercase snake_case.
Preferred pattern:
idx_<table>__<column_or_columns>
Examples:
- idx_affiliate_offers__status
- idx_audience_events__created_at
- idx_mwms_tasks__brain_status
RLS Policy Naming Rule
RLS policies must use lowercase snake_case.
Preferred pattern:
rls_<table>__<purpose>
Examples:
- rls_audience_events__append_only_insert
- rls_affiliate_offers__admin_read_write
Version Suffix Rule
Version suffixes may only be used when a genuine replacement or staged migration is required.
Allowed pattern:
_v2_v3
Do not use:
- _new
- _final
- _fixed
- _test
- _temp
A version suffix must have a migration reason and a change log entry.
Rename Control Rule
Live Supabase objects must not be renamed casually.
Any rename requires:
- explicit reason
- migration impact review
- consistency check against this standard
- entry in MWMS – System Change Log
No AI tool may rename existing Supabase objects for style preference alone.
Child Standard Rule
A narrower schema standard may exist for a subsystem, such as tasks or events.
That child standard may add specificity.
It may not contradict this standard.
If conflict appears, this standard remains upstream unless HeadOffice formally overrides it.
Enforcement Rule
For any session involving Supabase:
- this page must be treated as active authority
- naming must be checked before code or SQL is proposed
- AI tools must preserve existing canonical names
- drift must be rejected before implementation
Practical Outcome
This standard exists so that:
- Affiliate Brain does not invent its own database naming style
- Pro and Plus do not drift apart
- new schemas remain readable and maintainable
- future contributors can work safely across the whole MWMS system