docs: Migrate Cube AI/BI docs

Author: igorlukanin

docs/pages/_meta.js

@@ -21,14 +21,19 @@ module.exports = {
   //     toc: false,
   //   },
   // },
-  docs: {
-    // type: "page",
-    title: "[Demo] MDX Components",
-    display: "hidden",
+  // docs: {
+  //   // type: "page",
+  //   title: "[Demo] MDX Components",
+  //   display: "hidden",
+  // },
+
+  cube: {
+    type: "page",
+    title: "Cube",
   },
 
   product: {
     type: "page",
-    title: "Documentation",
+    title: "Cube Core",
   },
 };

docs/pages/cube/_meta.js

@@ -0,0 +1,7 @@
+module.exports = {
+  introduction: "Introduction",
+  workbooks: "Workbooks",
+  administration: "Administration",
+  embed: "Embed & API",
+  changelog: "Product Updates",
+};

docs/pages/cube/administration/_meta.js

@@ -0,0 +1,8 @@
+module.exports = {
+  ai: "AI",
+  "user-attributes": "User Attributes",
+  "roles-and-permissions": "Roles & Permissions",
+  "spaces-agents-models": "Spaces, Agents, Models",
+  "agent-rules": "Agent Rules",
+  "memory-isolation": "Agent Memories",
+};

docs/pages/cube/administration/agent-rules.mdx

@@ -0,0 +1,158 @@
+# Agent Rules
+
+_Understanding Agent Rules configuration and behavior in Cube._
+
+Agent Rules in Cube provide a powerful way to customize and control how AI agents behave within specific spaces. Rules act as contextual instructions that guide agents' responses and analysis, ensuring consistent behavior aligned with your business logic and domain expertise.
+
+## Rule Types
+
+### Always Rules
+
+**Always Rules** are automatically applied to every agent interaction within the space, regardless of the specific query or context.
+
+**Use Cases:**
+- Fundamental business definitions and context
+- Consistent calculation methods
+- Default analysis approaches
+- Domain-specific terminology
+
+**Example Always Rules:**
+```
+Sales efficiency is deal size divided by sales cycle length
+```
+
+```
+When analyzing customer data, always consider seasonality patterns from our retail business
+```
+
+```
+Revenue should be calculated using our standard GAAP accounting principles
+```
+
+### Agent Requested Rules
+
+**Agent Requested** rules are conditionally applied when the agent determines they are relevant to the current query or analysis. The agent intelligently selects which rules to use based on the context.
+
+**Use Cases:**
+- Specialized analysis techniques
+- Context-specific guidance
+- Advanced calculation methods
+- Scenario-specific instructions
+
+**Example Agent Requested Rules:**
+```
+If you asked to analyze sales efficiency start with correlation to WSE
+```
+
+```
+For customer segmentation analysis, use RFM methodology (Recency, Frequency, Monetary)
+```
+
+```
+When analyzing marketing performance, compare against industry benchmarks where available
+```
+
+## Best Practices
+
+### Rule Hierarchy and Organization
+
+- **Start with Always rules** for fundamental business context
+- **Use Agent Requested rules** for specialized scenarios
+- **Keep rules specific and actionable** rather than vague
+- **Test rules** with actual queries to ensure they work as expected
+
+### Writing Effective Rules
+
+✅ **Good Rule Examples:**
+- "Customer churn rate should be calculated as customers lost / total customers at start of period"
+- "When analyzing quarterly performance, always compare against same quarter previous year"
+- "For financial analysis, use our fiscal year starting in October"
+
+❌ **Poor Rule Examples:**
+- "Be helpful" (too vague)
+- "Always be accurate" (redundant)
+- "Consider all factors" (too broad)
+
+### Domain-Specific Rules
+
+**E-commerce Example:**
+```
+Always Rule: "Customer lifetime value equals average order value × purchase frequency × customer lifespan"
+Agent Requested: "For cart abandonment analysis, segment by device type and traffic source"
+```
+
+**SaaS Example:**
+```
+Always Rule: "MRR growth rate should exclude one-time charges and setup fees"
+Agent Requested: "When analyzing churn, differentiate between voluntary and involuntary churn"
+```
+
+### Contextual Guidance
+
+Rules should provide context that agents might not inherently understand about your business:
+
+```
+Always Rule: "Our peak season is Q4, with 40% of annual revenue typically occurring in December"
+Agent Requested: "For inventory analysis, consider our 6-week lead time for international suppliers"
+```
+
+## Rule Conflicts and Resolution
+
+### How Cube Handles Conflicting Rules
+
+Based on the rule configuration system, when multiple rules could apply to the same query, the conflict resolution strategy would likely include:
+
+1. **Rule type hierarchy** (specific behavior needs verification)
+2. **Rule specificity** - more specific rules typically override general ones
+3. **Rule order** - the system may consider rule creation order or explicit priority
+4. **Agent decision-making** for complementary vs conflicting guidance
+
+### Example Conflict Scenarios
+
+**Scenario 1: Direct Contradiction**
+```
+Rule A (Always): "Revenue recognition follows monthly billing cycles"
+Rule B (Always): "Revenue should be recognized quarterly"
+
+Resolution: The agent will flag this conflict and may ask for clarification
+```
+
+**Scenario 2: Complementary Rules**
+```
+Rule A (Always): "Sales efficiency is deal size divided by sales cycle length"
+Rule B (Agent Requested): "When analyzing sales efficiency, include pipeline velocity metrics"
+
+Resolution: Both rules work together - B provides additional context to A
+```
+
+**Scenario 3: Specificity Override**
+```
+Rule A (Always): "Use standard deviation for all variance calculations"
+Rule B (Agent Requested): "For customer behavior analysis, use median absolute deviation instead of standard deviation"
+
+Resolution: Rule B takes precedence for customer behavior queries due to higher specificity
+```
+
+### Best Practices for Avoiding Conflicts
+
+1. **Review existing rules** before adding new ones
+2. **Use specific triggers** in Agent Requested rules
+3. **Test rule combinations** with sample queries
+4. **Document rule intentions** clearly
+5. **Regular rule audits** to identify and resolve conflicts
+
+## Current Limitations
+
+### Current State: Space-Level Rules Only, Always Rules Only
+
+- Rules are currently configured at the **Space level**
+- All agents within a space inherit the same set of rules
+- Individual agent customization is not yet available
+
+## Getting Started
+
+1. **Assess Your Use Case**: Identify the key business context and calculations your agents need to understand
+2. **Start Simple**: Begin with 2-3 Always rules covering your most important business definitions
+3. **Add Specificity**: Implement Agent Requested rules for specialized scenarios
+4. **Test and Iterate**: Use real queries to validate rule effectiveness
+5. **Scale Gradually**: Add more rules based on actual usage patterns and feedback

docs/pages/cube/administration/ai.mdx

@@ -0,0 +1,16 @@
+# AI
+
+_AI features and administration in Cube._
+
+## Chats History
+
+Admins can access users chat history through <Btn>Admin → Chats History</Btn>. It's possible to search specific chats by the first message content or chat UUID.
+
+<video
+  autoPlay
+  muted
+  loop
+  playsInline
+  className="w-full aspect-video rounded-xl"
+  src="https://ucarecdn.com/c0a5f8ac-9c3c-41d7-80c3-95f533476ad4/"
+></video> 

docs/pages/cube/administration/memory-isolation.mdx

@@ -0,0 +1,47 @@
+# Agent Memories
+
+_Learn how Cube enforces memory isolation across tenants, spaces, and users._
+
+Memory in Cube allows Agents to learn from and recall past interactions, user preferences, and contextual information. When users interact with Agents, relevant information is stored as memories that can be retrieved in future conversations, enabling more personalized and context-aware responses. Memories help Agents understand user preferences, remember previous decisions, and provide continuity across sessions.
+
+Memories are scoped and enforced at the Tenant/Space boundary. Cube applies both application-layer and (optionally) infrastructure-layer isolation so one customer's end users cannot see another customer's memories.
+
+## How It Works
+
+### Space-Scoped Memories
+
+Cube memories are stored at the Space level. Agents only learn from and retrieve memories within the current Space, ensuring no cross-Space exposure by design. 
+
+### Tenant-Aware Security Context
+
+Every request carries a tenant-bound security context (JWT). Cube maps that context to an app/tenant ID and uses it across caching, orchestration, and query flows. This is the backbone of multi-tenancy isolation.
+
+### RBAC and Policy Guardrails
+
+Role-based access policies gate what entities and content are visible within a tenant. These same guardrails apply to what agents can read and write as memories.
+
+### Data Model and API Isolation
+
+Even when using the SQL API or custom views, hidden members and non-public entities remain inaccessible. Multitenancy configuration ensures queries and artifacts resolve only within the current tenant's scope.
+
+### Optional Infrastructure Isolation
+
+Many customers run in shared multi-tenant regions, but dedicated infrastructure and BYOC (Bring Your Own Cloud) variants are available. These provide stronger blast-radius isolation at the cluster, storage, and key-management levels.
+
+## Practical Implications
+
+- **Tenant Separation**: An end user in Customer A can only create and retrieve memories in Customer A's Spaces
+- **Cross-Tenant Protection**: Memories are not retrievable by Customer B's users or agents, because requests from B carry a different security context and resolve to different Space and tenant IDs
+- **Intra-Tenant Controls**: Even within a customer, RBAC and policies can further restrict which users or agents can contribute to or benefit from memories
+
+## Technical Implementation
+
+Cube ensures memory isolation through multiple layers of security controls:
+
+1. **Tenant Isolation**: Every request is scoped to a specific tenant via JWT and middleware
+2. **User Isolation**: Additional user-level filtering for user-mode memories
+3. **Automatic Filtering**: Database queries are automatically filtered by tenant using decorators
+4. **Vector Store Security**: All vector searches include tenant and user filters
+5. **Container Isolation**: Each tenant gets its own dependency injection container
+6. **JWT Security**: All security context comes from cryptographically signed JWT tokens
+7. **Memory Mode Controls**: Configurable memory isolation levels (user/space/disabled)

docs/pages/cube/administration/roles-and-permissions.mdx

@@ -0,0 +1,56 @@
+# Roles & Permissions
+
+_Understanding user roles and access control in Cube._
+
+Cube implements a role-based access control system with three main user roles: Admin, Developer, and User. Each role has specific permissions and access levels designed to support different responsibilities within the platform.
+
+## Deployment Structure
+
+- Database connections are managed through Semantic Model Deployments
+- Multiple Semantic Model Deployments can exist under one account
+- Roles can be either global (across all deployments) or deployment-specific
+- Admin role is always global
+
+## Role Permissions
+
+### Admin Role
+
+- Has highest level of privileges
+- Can manage semantic models
+- Can manage other users
+- Has access to admin section
+- Full query capabilities
+
+### Developer Role
+
+- Can create and edit semantic models
+- Can execute SQL queries against data sources
+- Can create and edit workbooks
+- Can create and edit data apps
+- No access to admin settings
+
+### User Role
+
+- Can query semantic models
+- Can create and edit workbooks
+- Can create and edit data apps
+- Can execute Semantic SQL queries
+- Cannot make changes to semantic models
+- Cannot query source data directly
+
+## Future Implementation
+
+A Viewer role is planned for future implementation with the following capabilities:
+
+- Use Analytics Chat with ability to query Semantic Views and existing reports
+- View (read-only) access to shared data apps
+
+## Agent Permissions
+
+Agents are connected to Semantic Model Deployments and inherit the permission level of the user they are operating under.
+
+## Typical Usage Scenarios
+
+- Users: Typically data consumers and analysts
+- Developers: Usually data stewards and data engineers
+- Admin: Typically assigned to data engineers managing the entire Cube instance