Region And Feature Profiles
Region and compliance profiles should become first-class product architecture concepts. They describe product availability, public surface controls, and future
Region and compliance profiles should become first-class product architecture concepts. They describe product availability, public surface controls, and future enforcement boundaries.
Current phase: docs, manifest metadata, and static UI hints. Do not over-engineer backend packages today.
Profiles
export type RegionProfile = 'global' | 'cn-lite' | 'cn-platform'
export interface FeatureAvailability {
publicPublishing: boolean
publicProfiles: boolean
publicSpaces: boolean
publicComments: boolean
publicSearchUserContent: boolean
recommendations: boolean
thirdPartyAppSubmission: 'off' | 'review-only' | 'open'
momentsVisibility: 'private' | 'invite-only' | 'public'
}| Profile | Meaning | Current Status |
|---|---|---|
global | Default global product profile. | Primary product posture. |
cn-lite | Limited regional availability profile with public UGC disabled by default. | Documented planning profile. |
cn-platform | Future dedicated regional platform profile. | Reserved concept only. |
Future Enforcement Layers
UI-only hiding is not enough for production enforcement. Future implementation must align across:
- Frontend routes.
- App registry.
- Backend authorization.
- Database visibility fields.
- Object storage public URL generation.
- Search indexing.
- Sitemap and
noindexbehavior. - Analytics and audit logs.
Do Not Over-Engineer Today
The current useful step is to document the profiles, expose static Trust Center messaging, and make manifests ready for future metadata. Avoid creating a heavy compliance backend before public UGC, hosted billing, or region-specific operations require it.