A Valis Work Rule structurally forbidding databases from being nested inside other database rows. Rationale Nested databases break the Meta Database governance model, creating State Management Overhead. Specific risks include: 1. Loss of Governance: Nested DBs are invisible to the Meta Database, preventing tracking of ownership, lifecycle status, and standard views (breaking the Agreements system). 2. Permission Rigidity: Permissions cascade from the parent row, making it impossible to secure a private database inside a public container (e.g., a restricted "Management" channel nested inside a public "Discord Synced Channels" parent). 3. Navigation Friction: Deeply nested databases are difficult to find in the sidebar or Quick Find. Operational Rule The Mandate: All databases must be registered as top-level entries in the Meta Database. Nesting databases inside rows is strictly forbidden. Implementation Strategies To adhere to this mandate without cluttering the Meta Database: Preferred Strategy (Unified Database): Consolidate similar datasets (e.g., "Discord Archive") into a single database using Select/Relation properties. Principle: Aligns with Radical Simplicity (minimizing artifacts) and ensures Fully Governed data (lifecycle, ownership, views). Scalability: Since Notion handles millions of rows, creating separate databases for performance is unnecessary. Nuance: Only split into multiple databases (e.g., "Public" vs "Private") if permission requirements differ drastically. Fallback Strategy (Flat Registration): If distinct databases are strictly required, register each one as a top-level row in the Meta Database (rather than nesting them). Why: This ensures every database remains visible to admin systems and agents, even if it creates more items to manage. Clarifications This rule applies to the Database Object itself (the source of truth). You can still display Linked Views of databases inside pages or other database rows for convenience, provided the original database lives at the top level. This rule originated when Telnent (Head of Engineering) proposed a structure for Discord knowledge management: creating a parent "Discord Channels" database, and nesting a separate database for each channel inside its corresponding row. While this implies a clean hierarchy, it creates "ghost" databases invisible to the Meta Database.
A Valis Work Rule structurally forbidding databases from being nested inside other database rows.
Rationale
Nested databases break the Meta Database governance model, creating State Management Overhead. Specific risks include:
- Loss of Governance: Nested DBs are invisible to the Meta Database, preventing tracking of ownership, lifecycle status, and standard views (breaking the Agreements system).
- Permission Rigidity: Permissions cascade from the parent row, making it impossible to secure a private database inside a public container (e.g., a restricted "Management" channel nested inside a public "Discord Synced Channels" parent).
- Navigation Friction: Deeply nested databases are difficult to find in the sidebar or Quick Find.
Operational Rule
The Mandate: All databases must be registered as top-level entries in the Meta Database. Nesting databases inside rows is strictly forbidden.
Implementation Strategies
To adhere to this mandate without cluttering the Meta Database:
- Preferred Strategy (Unified Database): Consolidate similar datasets (e.g., "Discord Archive") into a single database using Select/Relation properties.
- Principle: Aligns with Radical Simplicity (minimizing artifacts) and ensures Fully Governed data (lifecycle, ownership, views).
- Scalability: Since Notion handles millions of rows, creating separate databases for performance is unnecessary.
- Nuance: Only split into multiple databases (e.g., "Public" vs "Private") if permission requirements differ drastically.
- Fallback Strategy (Flat Registration): If distinct databases are strictly required, register each one as a top-level row in the Meta Database (rather than nesting them).
- Why: This ensures every database remains visible to admin systems and agents, even if it creates more items to manage.
Clarifications
This rule applies to the Database Object itself (the source of truth). You can still display Linked Views of databases inside pages or other database rows for convenience, provided the original database lives at the top level.
This rule originated when Telnent (Head of Engineering) proposed a structure for Discord knowledge management: creating a parent "Discord Channels" database, and nesting a separate database for each channel inside its corresponding row. While this implies a clean hierarchy, it creates "ghost" databases invisible to the Meta Database.