@clickzetta/cz-cli-darwin-arm64 0.5.16 → 0.5.18

package/bin/skills/lakehouse-doc-en/references/row-filter.md

@@ -0,0 +1,165 @@
+# Row-Level Security (Row Filter)
+> [Preview Release] This feature is currently in an invite-only preview stage. To use it, please contact our technical support team for assistance.
+
+## Overview
+
+Row-level security (Row Filter, also known as Row Access Policy) lets you bind a filter function that returns BOOLEAN to a table. The system automatically applies this function during queries and DML operations — only rows where the function returns `true` are visible to the current operation. It is commonly used for multi-tenant isolation and data permission control by user or role.
+
+Key characteristics of row filters:
+
+- Filter logic is encapsulated in a SQL function and can be reused across multiple tables.
+- The function can use security context functions such as `current_user()` and `current_roles()` to dynamically filter based on the current login identity.
+- Takes full effect for `SELECT`, `UPDATE`, `DELETE`, and aggregate queries.
+- `UPDATE` / `DELETE` only affects visible rows (those that pass the filter); invisible rows are unaffected.
+- Can be removed at any time via `ALTER TABLE ... DROP ROW FILTER` without affecting the underlying data.
+
+## Usage Steps
+
+### Step 1: Create a Filter Function
+
+A filter function is a SQL scalar function that returns `BOOLEAN` (see [CREATE FUNCTION(SQL)](create-sql-function.md)), with parameters corresponding to the columns in the table to be evaluated.
+
+The most typical use of row-level security is combining it with `current_user()` to filter by the current logged-in user — each user can only see rows that belong to them:
+
+```sql
+-- Each user can only see rows where the owner column equals their own login name
+CREATE FUNCTION my_schema.owner_only(owner STRING)
+RETURNS BOOLEAN
+AS owner = current_user();
+```
+
+You can also combine `current_roles()` (which returns an array of the current user's roles) to do role-based filtering:
+
+```sql
+-- The admin role can see all rows; other users can only see rows where region = 'east'
+CREATE FUNCTION my_schema.role_based(region STRING)
+RETURNS BOOLEAN
+AS array_contains(current_roles(), 'admin') OR region = 'east';
+```
+
+The filter condition can also be fixed logic unrelated to identity:
+
+```sql
+-- Only rows where region = 'east' are visible
+CREATE FUNCTION my_schema.only_east(region STRING)
+RETURNS BOOLEAN
+AS region = 'east';
+```
+
+The function can also accept multiple parameters to implement multi-column combined evaluation:
+
+```sql
+-- Only rows where region = 'east' AND amount >= 200 are visible
+CREATE FUNCTION my_schema.east_big(region STRING, amt INT)
+RETURNS BOOLEAN
+AS region = 'east' AND amt >= 200;
+```
+
+> The security context function `current_user()` returns the current logged-in username; `current_roles()` returns an array of the current user's roles (case-sensitive).
+
+### Step 2: Bind to a Table
+
+#### Bind at Table Creation
+
+```sql
+CREATE TABLE my_schema.docs (
+    id      INT,
+    owner   STRING,
+    content STRING
+) ROW FILTER my_schema.owner_only ON (owner);
+```
+
+#### Bind to an Existing Table
+
+```sql
+ALTER TABLE my_schema.docs SET ROW FILTER my_schema.owner_only ON (owner);
+```
+
+The columns listed in `ON (...)` are passed as arguments to the filter function in order. The column types and count must match the function definition.
+
+> It is recommended to use **schema-qualified names** when referencing filter functions (e.g., `my_schema.owner_only`). Without schema qualification, the system resolves based on the current schema, which may result in a `function not found` error.
+
+### Step 3: Verify the Binding
+
+```sql
+DESC EXTENDED my_schema.docs;
+```
+
+A `# Row Filter` section will appear at the end of the output:
+
+```
+# Row Filter
+Function           quick_start.my_schema.owner_only
+Bound Parameters   owner
+```
+
+## Behavior Examples
+
+Using `owner_only` (based on `current_user()`) as an example, assuming the current logged-in user is `alice`:
+
+```sql
+INSERT INTO my_schema.docs VALUES
+  (1, 'alice', 'alice doc'), (2, 'bob', 'bob doc'), (3, 'alice', 'another alice doc');
+
+-- alice queries: only returns rows where owner = 'alice'
+SELECT * FROM my_schema.docs ORDER BY id;
+-- 1 | alice | alice doc
+-- 3 | alice | another alice doc
+```
+
+The same SQL returns different data depending on who is logged in — when `bob` logs in, they only see the row with id=2. This is how row-level security dynamically filters by identity.
+
+Row filter effects on various operations:
+
+| Operation | Behavior |
+|-----------|----------|
+| `SELECT` | Returns only visible rows (rows where the filter function returns true) |
+| Aggregates (`COUNT`/`SUM`, etc.) | Only aggregates visible rows |
+| `UPDATE` | Only updates visible rows; invisible rows are unaffected |
+| `DELETE` | Only deletes visible rows; invisible rows are retained |
+
+For example, if `alice` executes `UPDATE my_schema.docs SET content = 'updated' WHERE id IN (1,2,3)`, only visible id=1 and id=3 are updated. Bob's id=2 is unaffected.
+
+## Multi-Column Filter Function Example
+
+```sql
+CREATE FUNCTION my_schema.east_big(region STRING, amt INT)
+RETURNS BOOLEAN
+AS region = 'east' AND amt >= 200;
+
+CREATE TABLE my_schema.o2 (id INT, region STRING, amt INT)
+ROW FILTER my_schema.east_big ON (region, amt);
+
+INSERT INTO my_schema.o2 VALUES (1,'east',100), (2,'east',300), (3,'west',300);
+
+SELECT * FROM my_schema.o2 ORDER BY id;
+-- 2 | east | 300   (only the row where region='east' AND amt>=200 is visible)
+```
+
+## Removing a Row Filter
+
+```sql
+ALTER TABLE my_schema.o2 DROP ROW FILTER;
+```
+
+After removal, all data in the table becomes visible again. The underlying data is not affected in any way.
+
+```sql
+SELECT * FROM my_schema.o2 ORDER BY id;
+-- 1 | east | 100
+-- 2 | east | 300
+-- 3 | west | 300
+```
+
+## Notes
+
+- The filter function must return `BOOLEAN`, and the column types and count in `ON (...)` must match the function parameters.
+- Use schema-qualified names when referencing filter functions to avoid resolution failures.
+- Row filters do not intercept data during writes (INSERT) — data is written to the underlying storage normally; visibility is only controlled during queries, updates, and deletes. If write-side constraints are also needed, combine with application-level logic.
+- A table can have one row filter bound at a time. To rebind, run `ALTER TABLE ... SET ROW FILTER` again; to remove, use `ALTER TABLE ... DROP ROW FILTER`.
+
+## References
+
+- [CREATE FUNCTION(SQL)](create-sql-function.md): SQL scalar function syntax used to create filter functions
+- [Column-Level Security (Dynamic Masking)](dynamic-mask.md): Column-level data protection, complementary to row-level security
+- [CREATE TABLE DDL Syntax](create-table-ddl.md)

package/bin/skills/lakehouse-doc-en/references/row_level_permission.md

@@ -1,41 +1,52 @@
 # Row-Level Permissions
 
+When multiple departments or roles share the same analysis domain, you may not want everyone to see the full dataset — a sales rep in the North China region should only see North China data, and a store manager should only see data for their own store. Row-level permissions let you define each user's visible data range without splitting data tables or creating multiple analysis domains.
+
 ## Feature Overview
 
-The row-level permissions feature is used to control the data scope that different users can access. By configuring permission rules, administrators can restrict users to only view data rows that meet specific conditions, ensuring data access security and isolation. For example, restricting a user to only view order data for "2022" and "2023".
+Row-level permissions work by configuring filter rules that restrict users to only the data rows that meet specified conditions. Once a rule takes effect, queries generated by the Agent automatically include the corresponding filter conditions, transparently to the user. For example, when both a North China user and a South China user ask "What are this year's orders?", the North China user sees only North China data and the South China user sees only South China data.
 
 ## Configuration Process
 
-| Step     | Demo                                                                                                   | Logic Description                                                                                                                                 |
-| -------- | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------ |
-| 0. Feature Entry   | ![](/.topwrite/assets/image_1776775841836.png =213)                                                    |                                                                                                                                      |
-| 1. Define Permission Rules | ![](/.topwrite/assets/image_1776136039447.png =198)                                                    | **Specify the data table and filter fields for the permission rule**
1. Enter the "Row-Level Permissions" page
2. Click the "+ Define New Row-Level Permission" button in the upper right corner
3. Fill in the permission name
4. Select the data table to control
5. Select the field for filtering
6. Save the rule |
-| 2. Configure Permission Scope | ![](/.topwrite/assets/image_1776136305692.png =215)![](/.topwrite/assets/image_1776136332684.png =207) | **Apply the permission rule to specific users and set their accessible data scope**
1. In the permission rule list, select the created rule
2. Add users to whom the rule should be applied
3. Set the accessible field values for each user
4. Save the configuration                       |
+| Step                          | Demo                                                                                                        | Logic Description                                                                                                                                                   |
+| ----------------------------- | ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 0. Feature entry              | ![](/.topwrite/assets/image_1780901235458.png =244)                                                         |                                                                                                                                                                     |
+| 1. Define permission rule     | ![](/.topwrite/assets/image_1780901267564.png =250)                                                         | **Specify the data table and filter field for the permission rule**1. Go to the "Row-Level Permissions" page4. Select the data table to control                     |
+| 2. Configure permission scope | ![](/.topwrite/assets/image_1780901703998.png =234)
![](/.topwrite/assets/image_1780901632107.png =231) | **Apply the permission rule to specific users and set their accessible data scope**1. In the permission rule list, select the created rule4. Save the configuration |
 
 ## Permission Effects
 
-| Scenario      | Data Visibility Scope         |
-| ------- | -------------- |
-| No row-level permission configured | Users can view all data in the data table |
-| Row-level permission configured | Users can only see data within the permission scope |
+| Scenario                           | Data Visibility Scope                               |
+| ---------------------------------- | --------------------------------------------------- |
+| No row-level permission configured | Users can view all data in the data table           |
+| Row-level permission configured    | Users can only see data within the permission scope |
 
 ### Example
 
-Taking the Hong Kong catering industry as an example:
+Taking the Hong Kong food and beverage industry as an example:
 
-* Before configuration: Users can view order data from 2018-2025
+* Before configuration: Users can view order data from 2018 to 2025
 
-* After configuration (accessible years set to "2022, 2023"): Users can only see order data for 2022 and 2023
-  ![](/.topwrite/assets/image_1776135526273.png =381)![](/.topwrite/assets/image_1776135559997.png =383)
+* :-: After configuration (accessible years set to "2022, 2023"): Users can only see order data for 2022 and 2023
+  ![](/.topwrite/assets/image_1780901812809.png =671)
 
 ## Notes
 
-1. It is recommended to use meaningful names for permission rules (e.g., "North China Region Data Permissions") for easier subsequent management
+1\. Use meaningful names for permission rules (e.g., "North China Region Data Permission") for easier management
+
+2\. After row-level permissions take effect, query results generated by the Agent are automatically filtered by the permission scope; users are unaware of the filtering
+
+3\. A user can be covered by multiple permission rules; verify that the combined data scope meets expectations
+
+4\. Permission rule changes take effect immediately; no restart or additional operations are required
 
-2. After row-level permissions take effect, query results generated by the Agent are automatically filtered by the permission scope
+5\. It is recommended to periodically review permission configurations to ensure consistency with business requirements
 
-3. A user can be covered by multiple permission rules. Please verify that the combined data scope across rules meets expectations
+## Related Documentation
 
-4. Permission rule modifications take effect immediately without requiring restarts or additional operations
+* [Answer Accuracy Improvement](answer-accuracy-improve.md) — Overall strategy for analysis domain partitioning and data isolation
+* [Metrics and Answer Builder](metrics_answer_build.md) — Relationship between metric configuration and row-level permissions
+* [Data Source Management](datagpt_data_source.md) — Data source configuration that row-level permissions depend on
+* [Conversational Data Analytics (Analytics Agent)](datagpt_introduction.md) — Return to feature overview
 
-5. It is recommended to regularly review permission configurations to ensure consistency with business requirements
+^

package/bin/skills/lakehouse-doc-en/references/scheduled_task.md

@@ -1,26 +1,28 @@
+# Scheduled Tasks
+
 ## Feature Overview
 
-The Scheduled Task feature allows users to create periodic data analysis tasks using natural language. The system will automatically execute analysis and push results at the scheduled time. It can be used for daily anomaly detection, business data monitoring, trend insights, and other scenarios, helping users automatically discover abnormal changes in data and provide analysis suggestions.
+The Scheduled Tasks feature allows users to create periodic data analysis tasks using natural language. The system will automatically execute analysis and push results at the scheduled time. It can be used for daily anomaly detection, business data monitoring, trend insights, and other scenarios, helping users automatically discover abnormal changes in data and receive analysis recommendations.
 
 ## Creating a Scheduled Task
 
 **Method 1: ASK AI Conversational Creation**
 
-| Step                        | Demo                                                | Content                                                                                                                                                                                                 |
-| --------------------------- | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| 1. User asks a question     | ![](/.topwrite/assets/image_1776758583558.png =257) | "Help me analyze whether yesterday's business data has any anomalies?"                                                                                                                |
-| 2. Auto-monitoring suggestion | ![](/.topwrite/assets/image_1776758640337.png =262) | The system recognizes the user's anomaly monitoring needs and proactively recommends at the end of the analysis result, e.g.: "If such anomalies can be detected earlier, it can help the operations team intervene faster. I can help you set up daily automatic detection. Once a store rating falls below 3.0 or negative reviews exceed 20, I will notify you immediately and automatically analyze the cause." |
-| 3. User confirms intent     | ![](/.topwrite/assets/image_1776758805383.png =258) | Reply "OK, set it up for me"                                                                                                                                                                             |
-| 4. Recommend monitoring metrics and configuration | ![](/.topwrite/assets/image_1776758857444.png =250) | Based on the metrics and data distribution the user cares about, provide suggestions: monitoring metrics (rating, negative review count, order volume, revenue), thresholds, execution frequency (daily at 09:00), push strategy (only push on anomalies), and ask the user to confirm execution time, notification email, and monitoring metric scope |
-| 5. User confirms configuration | ![](/.topwrite/assets/image_1776758918588.png =254) | Confirm or adjust monitoring metrics, execution time, notification email, etc.                                                                                                                           |
+| Step                                              | Demo                                                | Content                                                                                                                                                                                                                                                                                                                                                                                                              |
+| ------------------------------------------------- | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 1. User asks a question                           | ![](/.topwrite/assets/image_1780906950414.png =200) | "Help me analyze whether yesterday's business data has any anomalies?"                                                                                                                                                                                                                                                                                                                                               |
+| 2. Auto-monitoring suggestion                     | ![](/.topwrite/assets/image_1780907011715.png =261) | The system recognizes the user's anomaly monitoring intent and proactively recommends at the end of the analysis result, e.g.: "If such anomalies can be detected earlier, it can help the operations team intervene faster. I can help you set up daily automatic detection. Once a store rating falls below 3.0 or negative reviews exceed 20, I will notify you immediately and automatically analyze the cause." |
+| 3. User confirms intent                           | ![](/.topwrite/assets/image_1780906845499.png =126) | Reply "OK, set it up for me"                                                                                                                                                                                                                                                                                                                                                                                         |
+| 4. Recommend monitoring metrics and configuration | ![](/.topwrite/assets/image_1780906880578.png =255) | Based on the metrics and data distribution the user cares about, suggestions are provided: monitoring metrics (rating, negative review count, order volume, revenue), thresholds, execution frequency (daily at 09:00), push strategy (only push on anomalies), and the user is asked to confirm execution time, notification email, and monitoring metric scope                                                     |
+| 5. User confirms configuration                    | ![](/.topwrite/assets/image_1780906924308.png =176) | Confirm or adjust monitoring metrics, execution time, notification email, etc.                                                                                                                                                                                                                                                                                                                                       |
 
 **Method 2: Manual Creation**
 
-1. Enter the "Scheduled Tasks" page
+1\. Go to the "Scheduled Tasks" page
 
-2. Click the "+ Scheduled Task" button in the upper right corner
+2\. Click the "+ Scheduled Task" button in the upper right corner
 
-3. Describe the task requirements through conversation; you can specify the email address directly
+3\. Describe the task requirements through conversation; you can specify the email address directly
 
 ## Result Notification
 
@@ -28,27 +30,32 @@ The Scheduled Task feature allows users to create periodic data analysis tasks u
 
 * Enter the recipient email address in the task configuration
 * After the task execution is complete, the system will automatically send the analysis results to the specified email address
-  | Step 1: Email Notification                               | Step 2: Key Results Check                               | Step 3: View Full Analysis Process                        |
-  | -------------------------------------------------------- | ------------------------------------------------------- | --------------------------------------------------------- |
-  | ![](/.topwrite/assets/image_1776761334640.png =222)      | ![](/.topwrite/assets/image_1776761377358.png =182)     | ![](/.topwrite/assets/image_1776761407741.png =225)       |
 
 ### Manual Viewing
 
-* Enter the "Scheduled Tasks" page to view the task list
+* Go to the "Scheduled Tasks" page to view the task list
 * Click on a specific task to view historical execution records and analysis results
-  ![](/.topwrite/assets/image_1776163161997.png =768)
+  ![](/.topwrite/assets/image_1780907163189.png =557)
 
 ## Task Details Page
 
 * The task details page displays basic information and execution records:
-  ![](/.topwrite/assets/image_1776163215058.png =351)![](/.topwrite/assets/image_1776165685494.png =363)
+  ![](/.topwrite/assets/image_1780907206681.png =730)
 
 ## Notes
 
-1. Scheduled tasks are suitable for scenarios with high data update frequency (real-time or T+1). Scenarios with slower data updates (such as monthly reports) are not recommended for now.
+1\. Scheduled tasks are suitable for scenarios with high data update frequency (real-time or T+1); scenarios with slower data updates (e.g., monthly reports) are not recommended at this time
+
+2\. Ensure the email address entered is correct; otherwise, you will not receive push results
+
+3\. Task execution results are automatically generated by the Agent; it is recommended to manually verify key conclusions
+
+4\. You can enable or disable tasks in the task list at any time
 
-2. Ensure the email address entered is correct; otherwise, you will not receive the push results.
+## Related Documentation
 
-3. Task execution results are automatically generated by the Agent. It is recommended to manually verify key conclusions.
+* [Chart Auto-Refresh Settings](chart-auto-refresh-guide.md) — Automatically update dashboard chart data without manual triggers
+* [Answer Accuracy Improvement](answer-accuracy-improve.md) — Improve the accuracy of scheduled task analysis results
+* [Conversational Data Analytics (Analytics Agent)](datagpt_introduction.md) — Return to feature overview
 
-4. You can enable or disable tasks in the task list at any time.
+^

package/bin/skills/lakehouse-doc-en/references/security_overview.md

@@ -1,41 +1,119 @@
-# Singdata Lakehouse Security Features Overview
+# Security Features Overview
 
-Singdata Lakehouse is committed to creating a secure and reliable cloud environment for customers, ensuring that their accounts, information, business, and data receive enterprise-level security protection. To achieve this goal, Singdata Lakehouse employs multi-layered security measures covering architecture security, network security, access control, auditing and monitoring, and data encryption. Below is a detailed analysis of these security features.
+Singdata Lakehouse provides security capabilities across five layers — identity authentication, access control, network isolation, data protection, and backup & recovery — covering mainstream compliance scenarios from enterprise security baselines to Classified Protection Level 3 and industry-specific regulations.
 
-## 1. Architecture Security and Multi-Tenant Isolation
+## Security Capability Landscape
 
-Singdata Lakehouse is deployed in a public cloud environment, using a high-availability architecture to ensure service stability and reliability. By using multi-replica redundant storage and various protection technologies (such as host security, WAF, anti-DDoS, etc.), it ensures the security of the service architecture and infrastructure.
+| Security Layer | Core Capabilities | Problems Addressed |
+|----------------|-------------------|--------------------|
+| Identity Authentication | MFA multi-factor authentication, SSO single sign-on | Account takeover, password leaks |
+| Access Control | RBAC role system, fine-grained GRANT/REVOKE | Excessive privileges, unauthorized access |
+| Network Isolation | IP allowlist, Private Link, private storage BYOS | Public internet exposure, traffic egress |
+| Data Protection | Dynamic data masking, AES-256 storage encryption | Sensitive column leaks, static data exposure |
+| Backup & Recovery | Time Travel, RESTORE TABLE, UNDROP | Accidental deletion or modification |
 
-To achieve data and computing resource isolation between different tenants, Singdata Lakehouse performs data integrity and correctness checks at the data transmission layer, ensuring data integrity and tamper resistance.
+## Typical Compliance Scenarios and Feature Combinations
 
-![](.topwrite/assets/Security_System_en.png)
+### Enterprise Internal Security Baseline
 
-## 2. Network Security
+For teams just starting to build a data platform, prioritize the following three items:
 
-Singdata Lakehouse supports SSL/TLS encrypted transmission to ensure data security during transmission. Tenants can control the range of network addresses that can access their Lakehouse service instances by setting IP whitelist policies. For example, tenants can add their company's internal IP addresses to the whitelist to allow access only from these addresses.
+- Establish a role system and use RBAC instead of direct grants for centralized permission management → [Access Control](access-control-general.md)
+- Enable MFA on administrator accounts to prevent account compromise due to password leaks → [Identity Authentication](identity-auth.md)
+- Configure an IP allowlist (network policy) to restrict access to corporate network segments → [Network Policy](network_policy.md)
 
-## 3. Access Control
+### Classified Protection Level 3
 
-Singdata Lakehouse achieves further isolation of data and computing resources through workspaces. Only users who have joined a workspace can access the data and computing resources within it. Additionally, Singdata Lakehouse provides two authorization methods: ACL (Access Control List) and RBAC (Role-Based Access Control), allowing users to customize roles based on business needs and grant table-level granular permissions.
+Level 3 has explicit technical requirements across five control domains: identity verification, access control, security auditing, data confidentiality, and communication network security. The corresponding Lakehouse features are:
 
-For example, an administrator can create a workspace for data analysts and assign them the appropriate roles and permissions so that they can access and process specific data tables.
+| Control Domain | Lakehouse Feature | Reference |
+|----------------|-------------------|-----------|
+| Identity Verification (two-factor authentication) | MFA / SSO | [Identity Authentication](identity-auth.md) |
+| Access Control (least privilege) | RBAC + GRANT/REVOKE | [Access Control](access-control-general.md) |
+| Security Audit (operation records) | Job history query, operation logs | [Security Compliance Audit Guide](security_compliance_audit_guide.md) |
+| Data Transmission Confidentiality | SSL/TLS (enabled by default) | — |
+| Data Storage Confidentiality | AES-256 storage encryption | [Storage Encryption](storage_encryption.md) |
+| Communication Network Security | Private network connection (Private Link) | [Private Network Connection Overview](private-link-general.md) |
 
-## 4. Auditing and Monitoring
+### Finance, Healthcare, and Other Sensitive Industries
 
-Singdata Lakehouse records all operations on data, with these historical records being read-only and uneditable, and retained for up to 6 months. The platform also provides monitoring and alerting functions to help users promptly detect job anomalies, data anomalies, and other situations, and send notifications based on the severity of the alerts.
+Scenarios handling personal information and transaction data require additional data protection measures on top of the baseline:
 
-For example, when a job execution fails, the system will automatically send an alert notification to the administrator so that they can take timely measures to resolve the issue.
+- **Dynamic Data Masking**: Controls the visibility of sensitive columns such as phone numbers, ID numbers, and amounts by role, without touching the original data → [Dynamic Data Masking](dynamic-mask.md)
+- **Storage Encryption (Custom KMS)**: Uses your own KMS key (ARN) so that key lifecycle is under your control; currently supports Alibaba Cloud and AWS → [Storage Encryption](storage_encryption.md)
+- **Private Network Connection**: All data traffic stays on the internal network, never traversing the public internet → [Private Network Connection Overview](private-link-general.md)
+- **Private Storage BYOS**: Data is written to your own object storage bucket; Singdata Lakehouse holds no data copies → [Private Storage BYOS](bring_your_own_storage.md)
 
-## 5. Data Encryption
+### Data Disaster Recovery and Business Continuity
 
-Singdata Lakehouse encrypts sensitive data (such as account information) for storage, ensuring data security throughout its lifecycle. Users can further protect their data by configuring the data encryption feature. When the data encryption feature is enabled, data will remain encrypted throughout its lifecycle after being written to Lakehouse, and will only be decrypted when processed by the tenant's dedicated computing nodes.
+Scenarios that must meet RPO/RTO targets or guard against accidental operations:
 
-For example, when a company needs to store and process data involving personal privacy, it can enable the data encryption feature to ensure data security.
+- **Time Travel**: Retains 1 day of historical versions by default, configurable up to 90 days per table; supports querying historical snapshots at any point in time → [Backup and Recovery](data-recover.md)
+- **RESTORE TABLE**: Rolls back table data to a specified point in time to recover from accidental overwrites
+- **UNDROP TABLE**: Recovers a table after an accidental `DROP TABLE`
 
-## 6. Data Disaster Recovery and Restoration
+## Security Module Overview
 
-Singdata Lakehouse relies on the storage services of cloud service providers at the IaaS layer, built on a multi-replica, high-availability cloud infrastructure, providing extremely high service availability and data reliability. Additionally, the platform by default provides a 1-day data recovery feature, effectively reducing the risk of accidental data deletion or modification, and enhancing data integrity protection.
+### Access Control
 
-For example, in the event of accidental data deletion, users can use the time travel feature to restore data to any state within the past 7 days, thereby avoiding the risk of data loss.
+Supports both ACL (direct grants) and RBAC (role-based grants); RBAC is recommended. Assign permissions to roles, then grant roles to users. Permission changes only require modifying the role definition rather than updating each user individually. There is no superuser in the system; all operations require explicit authorization.
 
-In summary, Singdata Lakehouse provides a secure and reliable cloud environment for users through multi-layered security measures. Users can flexibly configure and use these security features according to their needs and scenarios to ensure the security of their business and data.
+- [Access Control Overview](access-control-general.md)
+- [Configure Access Control](access-control-configuration.md)
+- [Roles](roles.md) · [Metadata Objects and Privilege Points](meta-objects-and-privileges.md)
+- [Explanation of Permissions for Built-in Workspace-Level Roles](permissions-of-built-in-workspace-level-roles.md)
+- [User Authorization Getting Started Guide](user_permission_grand_guide.md)
+
+### Identity Authentication
+
+- **MFA**: Bind Google Authenticator; a dynamic verification code is required at login to prevent single-point password compromise
+- **SSO**: Integrate with enterprise IdPs (such as Okta, Azure AD) so the enterprise manages account creation, deactivation, and permission lifecycle centrally
+
+Reference: [Identity Authentication](identity-auth.md) · [Bind Google Authenticator (MFA)](using-google-authenticator.md) · [SSO Configuration](sso-configuration.md)
+
+### Network Isolation
+
+Three methods can be layered as needed, with increasing protection depth:
+
+| Method | Protection Scope | Applicable Scenario |
+|--------|------------------|---------------------|
+| Network Policy (IP allowlist) | Blocks access requests from unauthorized IPs | Restricting connections to corporate network segments |
+| Private Network Connection (Private Link) | Access via cloud provider internal network; traffic stays within the VPC | Production environments that prohibit public internet access |
+| Private Storage (BYOS) | Data written to your own object storage bucket | Data sovereignty requirements; data must not reside on third-party infrastructure |
+
+- [Private Network Connection Overview](private-link-general.md) · [Alibaba Cloud Private Network Connection Configuration](private_link.md)
+- [Private Storage BYOS](bring_your_own_storage.md) · [Alibaba Cloud BYOS Configuration](alicloud_byos_configuration.md) · [Tencent Cloud BYOS Configuration](byos_tencentcloud_configuration.md)
+
+### Dynamic Data Masking
+
+A masking function is bound to a column. At query time the system dynamically rewrites the returned values based on the current user's identity or role, while the original data is always stored in full. Applicable to sensitive columns such as phone numbers, ID numbers, bank card numbers, and salary amounts. Masking policies can be bound at table creation time or added to or removed from existing table columns.
+
+→ [Dynamic Data Masking](dynamic-mask.md)
+
+### Storage Encryption
+
+Enables AES-256 server-side encryption for data in newly created tables within a workspace. Two key modes are supported:
+
+- **Managed Encryption**: Uses managed keys from the cloud provider's object storage service; no additional configuration required
+- **Custom KMS Encryption**: Uses your own KMS key (ARN); the key lifecycle is under your control. Currently supports Alibaba Cloud and AWS
+
+> **Note**: Once encryption is enabled on a table, it cannot be reverted to an unencrypted state. Encryption only applies to tables created after it is enabled; existing tables are not affected.
+
+→ [Storage Encryption](storage_encryption.md)
+
+### Backup and Recovery
+
+Data protection is provided through the Time Travel mechanism:
+
+- Retains 1 day of historical versions by default; configurable up to 90 days per table
+- Historical data snapshots at any point in time within the retention window can be queried
+- `RESTORE TABLE` rolls the table back to a specified point in time, overwriting current data
+- `UNDROP TABLE` recovers a table after an accidental `DROP TABLE`
+
+→ [Backup and Recovery](data-recover.md)
+
+## Related Documentation
+
+- [Security and Compliance](data_security.md) — Navigate all security features by scenario
+- [Security Compliance Audit Guide](security_compliance_audit_guide.md)
+- [Permission System Inventory Best Practices](security-system-inventory-based-information-schema.md)

package/bin/skills/lakehouse-doc-en/references/set-command.md

@@ -52,7 +52,7 @@ SET schedule_job_queue_priority = 5;
 ```python
 from clickzetta import connect
 
-conn = connect(username='', password='', service='...', instance='...', workspace='...', schema='public', vcluster='default')
+conn = connect(username='', password='', service='...', instance='...', workspace='...', schema='public', vcluster='DEFAULT')
 my_param = {'hints': {'cz.sql.timezone': 'UTC+00'}}
 cursor = conn.cursor()
 cursor.execute("SELECT current_timestamp();", my_param)

package/bin/skills/lakehouse-doc-en/references/setup.md

@@ -1,37 +1,35 @@
 # Before You Begin
 
-Once your Singdata Lakehouse account has been set up, you can gain access to Singdata Lakehouse through any of the following means:
+Once your Singdata Lakehouse account has been set up, you can access Singdata Lakehouse through any of the following means:
 
-* [Singdata Lakehouse Studio](studio_manual.md), utilize the browser-based web interface to leverage our comprehensive integrated data development and management toolkit.
+* [Lakehouse Studio](studio_manual.md): Use the browser-based web interface with our comprehensive integrated data development and management toolkit.
+* [Data Agent](dataagent.md): A fully AI-interactive product built on top of Lakehouse + Studio, covering the full "development-operations-governance" lifecycle. It implements intelligent data platform upgrades with an Agentic AIOps philosophy, transforming data development from "people operating the platform" to "people directing Agents."
+* [CZ-CLI](cz-cli.md): An operations tool for command-line and AI Agents, encapsulating capabilities for SQL execution, Schema management, Studio task development, and task run inspection. It supports direct terminal operations and also allows AI Agents to assist with data warehouse development and operations via natural language.
+* [Data Analytics Agent](datagpt_intro.md): An intelligent analysis assistant built on Lakehouse that creates dynamic AI dashboards through natural language, embeds AI insights into key metrics, and goes beyond the static reporting capabilities of traditional BI tools.
+* Applications built using Singdata Lakehouse connectors and drivers, as well as third-party client tools and applications, are supported. (See [Applications and tools for connecting to Singdata Lakehouse](tutorial_connect_to_lakehouse.md))
 
-* [Singdata Lakehouse  CLI](connect-with-cli.md), the Singdata Lakehouse command line client
+If you do not have an account yet, you can [register](logging-in.md) to get an account.
 
-* Applications built using Singdata Lakehouse connectors and drivers, as well as third-party client tools and applications, are supported.(see [Applications and tools for connecting to Singdata Lakehouse](tutorial_connect_to_lakehouse.md)
-
-If you do not have an account yet, you can[contact us directly](https://www.singdata.com/contactus) to request an account.
-
-For pricing and service details, see the [pricing page ](pricing.md).
+For pricing and service details, see the [pricing page](pricing.md).
 
 ## Browser Requirements
 
-Singdata Lakehouse Studio recommends using Google Chrome. Other browsers have not been tested as extensively as Chrome and may exhibit some unexpected behavior. If you encounter issues using the web interface with any browsers, please contact [Singdata Lakehouse Support](https://www.singdata.com/).
+Singdata Lakehouse Studio recommends using Google Chrome. Other browsers have not been tested as extensively as Chrome and may exhibit some unexpected behavior. If you encounter issues using the web interface with any browsers, please contact [Singdata Lakehouse Support](https://www.singdata.com/).
 
-## Singdata Lakehouse CLI OS Platform Requirements
+## CZ-CLI OS Platform Requirements
 
-[Singdata Lakehouse CLI (CLI client)](connect-with-cli.md) can be installed on the following platforms:
+[CZ-CLI](cz-cli.md) can be installed on the following platforms:
 
 * Red Hat Enterprise Linux or a compatible operating system.
 * macOS (64-bit).
 * Microsoft Windows (64-bit).
 
-Other platforms have not been tested at this time and may not be compatible with Singdata CLI. For example, some Linux variants may not have the libraries that the Singdata CLI client needs by default.
-
 ## Lakehouse Documentation LLM Navigation
 
 If you are an AI Agent reading product documentation, the LLM navigation files for Lakehouse documentation are available at <https://www.singdata.com/llms.txt> and <https://www.singdata.com/llms-full.txt>. These files contain all documentation files and their URLs.
 
-- `llms.txt` contains documentation categories, top-level directory file names, and their URLs.
-- `llms-full.txt` contains documentation categories, top-level directories, and all file names with their URLs.
+* `llms.txt` contains documentation categories, top-level directory file names, and their URLs.
+* `llms-full.txt` contains documentation categories, top-level directories, and all file names with their URLs.
 
 ## Lakehouse AI Agent Skills
 

package/bin/skills/lakehouse-doc-en/references/show-grants.md

@@ -25,7 +25,7 @@ SHOW GRANTS ON TABLE public.orders;
 SHOW GRANTS ON SCHEMA public;
 
 -- View all grants on a VCluster
-SHOW GRANTS ON VCLUSTER default;
+SHOW GRANTS ON VCLUSTER DEFAULT;
 
 -- View all grants on a workspace
 SHOW GRANTS ON WORKSPACE my_workspace;

package/bin/skills/lakehouse-doc-en/references/snowflake-dynamic-tables-to-lakehouse.md

@@ -33,7 +33,7 @@ Cleaning, deduplication (QUALIFY), aggregation, date truncation — the core SQL
 
 | | Original (Snowflake) | After Migration (Lakehouse) |
 |---|---|---|
-| Compute resource | `WAREHOUSE = compute_wh` | `VCLUSTER default` |
+| Compute resource | `WAREHOUSE = compute_wh` | `VCLUSTER DEFAULT` |
 | Refresh strategy | `TARGET_LAG = '5 minutes'` | `REFRESH INTERVAL '5' MINUTE` |
 | Dependency propagation | `TARGET_LAG = 'DOWNSTREAM'` (auto cascade) | No such concept; each layer refreshes independently |
 | Manual refresh | `ALTER DYNAMIC TABLE ... REFRESH` | `REFRESH DYNAMIC TABLE ...` |
@@ -142,7 +142,7 @@ Lakehouse:
 ```sql
 CREATE OR REPLACE DYNAMIC TABLE bsg_dynamic_tables.bronze_orders
   REFRESH INTERVAL '5' MINUTE
-  VCLUSTER default
+  VCLUSTER DEFAULT
 AS
 SELECT ...
 ```

package/bin/skills/lakehouse-doc-en/references/spark-connector-summary.md

@@ -252,7 +252,7 @@ By reading data existing in the Lakehouse, use Spark ML to train a recommendatio
   * ```SQL
     create table sample_movie_data(user_id int,movie_id int,rating float);
     ```
-* Install Python package version greater than 3.6
+* Install Python package version 3.10 or above
 
 * Install Pyspark
 ```SQL

package/bin/skills/lakehouse-doc-en/references/sql_functions/context_functions/current_vcluster.md

@@ -33,6 +33,6 @@ USE VCLUSTER dev;
 SELECT current_vcluster();
 
 -- Switch back to the default computing cluster
-USE VCLUSTER default;
+USE VCLUSTER DEFAULT;
 SELECT current_vcluster();
 ```

package/bin/skills/lakehouse-doc-en/references/sso-configuration.md

@@ -67,7 +67,7 @@ After enabling SSO login, select **OAuth 2.0 / OIDC Protocol** in the right-side
 :-: ![](.topwrite/assets/image_1755162417316.png =695)
 
 ```
-https://uat-api.clickzetta.com/clickzetta-portal/sso/oidc/consume?u={code}
+https://api.clickzetta.com/clickzetta-portal/sso/oidc/consume?u={code}
 ```
 
 Use this callback URL to register the Lakehouse application in your IdP service and record the Client\_ID and other configuration values for later use.
@@ -126,7 +126,7 @@ After enabling SSO login, select **SAML 2.0 Protocol** in the right-side pop-up.
 :-: ![](.topwrite/assets/image_1755162706106.png =478)
 
 ```
-https://uat-api.clickzetta.com/clickzetta-portal/sso/saml/consume?u={code}
+https://api.clickzetta.com/clickzetta-portal/sso/saml/consume?u={code}
 ```
 
 Use this address to register the application in the IdP, and record and save the Entity ID and X.509 certificate returned by the IdP.