Article body
Full article
Whether enterprises can deliver AI analytics often depends on reusable metric definitions, bounded data access, and results that become reviewable assets. Hengshi’s products and capabilities can be combined around this chain: express business questions as metrics and analytical scopes, then deliver through dashboards, APIs, embedded pages, or engineering commands.
Natural language provides business users with a more direct analytics entry point. AI can shorten the work of understanding questions, retrieving data, and creating assets; enterprises remain responsible for metric definitions, authorization boundaries, and result review. This article follows actual product capabilities to explain how a single question can become a reusable analytics deliverable.
1 Ground business questions in reusable metrics
Hengshi distinguishes atomic metrics from business metrics. Atomic metrics hold aggregation definitions; business metrics add dimensions, constraints, timelines, and other settings to establish a clear analytical scenario. “Revenue” can be an atomic definition, whereas “monthly revenue from directly operated stores in East China” also requires a region, store scope, and dates. Human-created charts and Data Agent-assisted analysis should use the same definition.
Business metrics that share dimensions, timelines, and constraints can reference a metric grain within the same dataset to reduce repeated configuration. Changes to the grain synchronize configuration to referencing metrics. A grain currently supports only one dataset; business metrics in multi-table models must not be assumed to receive the same reuse behavior. Cross-table questions still require checks of data models, joins, and additional validation.
Topic domains organize metrics around business questions and support authorization and online/offline states. The same business metric may appear in multiple topic domains, but access to one topic domain does not automatically grant visibility in another. Topic authorization is linked to viewing permissions on the underlying data package, while visible rows remain constrained by data-package row permissions. Metric, topic, and data visibility need to be checked together, and each has its own role.
Metric names do not provide all the context. Knowledge management can supplement dataset purposes, implicit filters, synonyms, and mappings between terminology and fields or metrics. Relevant text can also be vectorized to improve semantic retrieval. This helps interpret questions without replacing metric definitions, data-quality checks, or business review.
2 Separate access boundaries instead of equating login with authorization
Enterprise analytics permissions span connections, application datasets, row and column rules, business topics, and integration identities. Data connections can have rules at connection, directory, and table levels; application datasets can have row and column permissions. Identity mapping and single sign-on establish who enters the system; resource and data authorization must still be completed.
Check downstream boundaries too. Row permissions on datasets A and B do not automatically propagate to dataset C created by joining A and B. C needs its own row permissions if its visible data must be controlled. Before launch, list the connections, data packages, topics, applications, and downstream datasets in use, then verify the fields and rows actually visible to each target role.
The platform grants tenants permission to use tenant resources; this does not replace user management inside the tenant’s own system. Embedded analytics also requires attention to synchronization of users, user groups, and functional permissions. Validate identity, functional permissions, connection permissions, and data permissions separately so that conversational analytics, dashboards, and embedded pages share explainable boundaries.
3 Deliver multiple analytics assets from one question
Data Agent can assist with on-demand analysis, metric creation, and dashboard generation. ChatBI can add conversation charts to dashboards, then adjust layouts, save, or continue exploration. This reduces the path from question to first draft while business users retain final judgment. Identical inputs do not always produce identical AI responses, and intelligent interpretation does not support complex reports or complex tables. Reliability depends on data preparation, analytical scope, and review.
The following examples illustrate delivery design. They do not define fixed fields, interface protocols, or industry templates. Every row assumes existing enterprise datasets, authorized scope, and confirmed metric definitions.
| Business question | Metrics and analytical scope | Delivery and integration | Acceptance artifacts |
|---|---|---|---|
| How are regions performing against quarterly sales targets? | Sales, targets, and attainment; region and date; confirmed timelines and filters | Regional comparisons, monthly trends, and filter explanations; tested and published aggregate APIs for integration; CLI for engineering asset changes | Metric definitions, scope, dashboard or exports, and business-review records |
| Which product line’s gross-margin changes need follow-up? | Confirmed gross-margin metrics, product line, and period; supplemented dataset knowledge where needed | Product-line trends and detail entry points; anomalies as investigation leads. Published detail or custom-query APIs for system consumption; CLI steps in a runbook | Definitions, datasets, question hypotheses, result scope, and review conclusions |
| How can users see authorized analytics inside a business system? | Application, users or groups, data-permission mode, and row/column rules | Published or embedded pages with filter-parameter meanings retained; page, JS SDK, or API according to whether full-page, frontend, or backend capabilities are reused | Role acceptance cases, embedded results, permission review, and rollback owner |
APIs are explicit delivery interfaces; a conversational result does not automatically become an API. The platform supports aggregate, detail, and custom-query APIs. They require scenario-specific testing and provide service after publication, with configurable authorization, rate limiting, or circuit breaking. External acceptance should inspect call scope, authentication, and returned results.
4 Engineering execution: give reviewable operations to the CLI
The public HENGSHI CLI command is hbi. Its product page groups data integration, HQL queries, dashboard generation, permissions, and operations into an execution surface for agents, with JSON, YAML, and Table output, accompanying skills, dry-run support, and SSE feedback for some changes. Implementation teams can preserve repeated steps as runbooks: read application, dataset, and asset state first, then adjust deliverables and submit them for human review.
The commands below are only a read-only entry-point example. They assume the CLI is installed and the corresponding authentication is configured. They are not a complete modeling or publication script and assume no enterprise-specific application name, dataset name, or HQL expression.
hbi --help
hbi auth status --output jsonBefore operations that change authorization, migrations, or assets, check subcommand help and applicable preview capabilities. The product page demonstrates --dry-run for inspecting authorization changes without applying them. Structured output and live feedback support review. The CLI is a delivered BI engineering interface; implementation teams remain responsible for command scope, permissions, and acceptance.
5 Combine products and delivery responsibilities by business scenario
Related products can work together as needed. The choice depends on the enterprise’s required analytics entry point, model location, and ownership of knowledge, processes, and quality.
| Product or capability | Principal delivery surface | Responsibility boundary to establish |
|---|---|---|
| Metric management and HENGSHI SENSE | Metrics, grains, topic domains, analytics, and visualization assets | Business and data teams own metric meaning, quality, authorization, and publication; the platform makes definitions easier to reuse. |
| AI analytics agents / Data Agent | Conversational analytics, assistance with metrics and dashboards, and intelligent reports | Users prepare data, terminology, and rules, then review generated results, complex scenarios, and final decisions. |
| HENGSHI BOX | A private-deployment option for ChatBI, local models, and agent automation | Local models incur no token charges when they do not call external APIs; total cost includes devices, software, and operations. Compliance requirements need deployment-specific assessment. |
| HENGSHI CLI | BI engineering terminal and skills / runbooks for agents | Implementation and operations teams define execution order, credentials, and approval points, then preview and review changes. |
| HENGSHI JARVIS | Consulting and enablement for agent knowledge, processes, and quality governance in software enterprises | Helps teams establish memory, routing, and knowledge operations; the project goals and implementation plan define the governance scope. |
Model and deployment strategies should follow the scenario. Hengshi supports cloud-provider and privately deployed models. Documentation states that results depend on the provider and does not guarantee effectiveness across all models. Data-sensitive scenarios seeking local inference can evaluate BOX. External-model integration requires explicit model capabilities, data scope, costs, and approval conditions.
6 Include reliability in the definition of analytics delivery
Sustainable AI analytics should answer four questions: what supports the result, who can see it, how it can be reviewed, and whether it can be reused. The starting point is an explainable metric definition and data scope; the middle is authorized conversational analytics, dashboards, embedded pages, or APIs; the endpoint is reviewable engineering work and business acceptance.
Capabilities can be combined as needed. Metric management reduces repeated definitions; Data Agent shortens the path to a first analytical draft; APIs and embedding serve business systems; the CLI standardizes engineering steps; and BOX or JARVIS addresses deployment and operational needs. Scaling depends on preserving definitions, permissions, delivery, and review as practices the team follows consistently.