From Metric Definitions to AI Queries: How HENGSHI Turns Business Definitions into Executable Analytics Assets

Summary: A shared business definition must explain both how a number is calculated and the business conditions under which it should be used. HENGSHI connects calculation definitions, analysis configuration, publication, authorization and consumption through atomic metrics, business metrics, metric granularity and business topics. HQL and dataset knowledge management also provide understandable, executable business semantics for ChatBI and Data Agent. Using sales analysis as an example, this article explains metric reuse, interactive analysis and AI queries, along with implementation and acceptance methods for metric governance.

1. Why the Same Number Can Have Three Answers

At an operating review, finance, sales and operations all present “sales this month,” but their numbers differ. Finance uses revenue recognition dates, sales uses payment dates, and operations includes unfinished orders. All three reports may be calculated correctly. The problem is that one name conceals different business definitions, leaving users without a common basis for checking them.

Requiring every department to use a single “sales” metric does not solve this. Payment amount, net sales and recognized revenue serve different management purposes and should be distinguished. Consistent definitions mean interpreting the same business concept consistently under the same conditions, while making the boundaries between different concepts visible.

A metric fit for production analysis must answer several questions: What is being measured? Does the amount include tax? How are refunds handled? Which date field applies? Which business dimensions can break it down? Who can use it? How current is the data? A formula answers only some of these questions; the rest also determine whether a result can be understood correctly.

HENGSHI metric management places this information in maintainable analytical objects. Data teams maintain the underlying calculations, business teams define use cases, topic managers organize publication and authorization, and users query metrics in the metrics marketplace and analytical dashboards. Discussion moves from “a number in a screenshot” to a metric with a definition and business configuration.

2. Atomic Metrics and Business Metrics: Maintain Calculations and Context Separately

2.1 Atomic Metrics Capture Foundational Calculations

Atomic metrics define aggregate calculations using fields, parameters, user attributes and filtering operations. Teams can first define foundational measures such as sales amount, refund amount and order count, then organize calculations according to the actual data structure and HQL capabilities. The aim is to reduce repeated maintenance by allowing dashboards and analyses to reference existing definitions.

For example, if a company defines “net sales” as sales satisfying specified order-status conditions minus the corresponding refunds, it must also check refund attribution, duplicate records and join behavior. Subtracting one column from another does not by itself establish a business definition. Atomic metrics should rest on validated datasets and calculation logic.

Atomic metrics can be used as measures or filters in dashboard authoring and in metric analysis. Definitions can therefore become shared assets for analytical applications. Teams need not explain the underlying algorithm again for every chart, but must still check the metrics, data scope and filters actually referenced by each chart.

2.2 Business Metrics Establish the Analytical Context

Beyond the calculation definition, a business metric configures qualifying conditions, analysis dimensions, a time axis and path attribution. “Monthly net sales by store,” for example, must specify the store breakdown, the date field used as the time axis and the included orders. A date-type dimension is required to configure a time axis; an individual business metric can select one date field for that axis.

This configuration turns “an amount that can be calculated” into “a metric for business discussion.” Monthly sales based on payment dates and monthly revenue based on recognition dates can each have a clearly defined business metric, avoiding repeated changes of meaning within a single named object. Names and descriptions should reflect the distinction.

Path attribution links metrics that influence one another for joint analysis. It helps users organize an analytical path, but a configured relationship is not proof of causation. Changes in sales, customer traffic and average transaction value require interpretation using business context, data scope and analytical results. A preconfigured path must not be treated as an established operating conclusion.

2.3 Metric Granularity Reuses Common Analysis Configuration

When a group of metrics shares dimensions, a time axis and qualifying conditions, metric granularity can reuse this configuration. For example, sales amount, order count and refund amount may all need analysis by store and month, making centralized maintenance valuable. References also require checking affected metrics before changes, so one adjustment does not unexpectedly change several use cases.

Granularity reuse must respect dataset and model relationships. The availability of related fields depends on actual modeling relationships and the product version; fields from arbitrary datasets cannot be assumed to combine directly. Validate field sources, relationship directions and double-counting risks before deciding which settings can be shared and which need separate maintenance.

3. HQL: Moving Business Calculations Out of Repeated Chart Code

HQL is HENGSHI’s language for expressing analytical logic. It lets teams organize metric calculations within the platform and connect business definitions to underlying storage and computation. Business users need metric meanings and conditions of use; data developers must also ensure that expressions, data models and execution results agree.

Report maintenance makes this value clear. In traditional approaches, “net sales” logic often appears in multiple SQL queries and charts, each requiring updates when business rules change. Central definitions and references provide a basis for reducing repetition. Maintainers must still examine reference scope, data-source updates and comparability with historical analysis.

Function names alone cannot establish the correctness of complex analysis. Distinct counts require checking what is deduplicated; ratios require the numerator and denominator to use a consistent scope; cross-table calculations require checking whether joins multiply records; year-over-year and period-over-period comparisons require checking date ranges and missing periods. HQL capabilities, data modeling and business validation together establish an executable business definition.

Teams can maintain sample data and expected results for frequently used metrics. A sample containing normal orders, refunded orders, refunds across months and nulls can validate sales and net-sales calculations separately. These records explain why a definition is trustworthy and support regression checks after changes. Sample-based acceptance is an implementation method and should not be confused with an unverified built-in version rollback feature.

4. Business Topics Connect Maintenance, Publication and Authorization

As metric counts grow, a calculation list alone is insufficient. HENGSHI organizes metrics through business topics, which can contain metrics and subtopics. A metric can belong to multiple topics. Companies can organize content around operations, sales or supply chain so business users find analytical objects within familiar categories.

Metrics in topics support taking online, taking offline, removal and refresh. The metrics marketplace displays metrics associated with business topics and already online; users also need the corresponding topic permissions. Offline metrics are no longer available for normal viewing and use. Maintainers should check consumption impacts before changes rather than treating taking a metric offline as simply hiding a name in a list.

Business topics support authorization roles including managers, editors, viewers and tenant users. Placing one metric in multiple topics does not automatically share permissions among those topics. Companies must check authorization by user and business scope and confirm data-access boundaries, avoiding the assumption that metric visibility opens all underlying data.

In the metrics marketplace, users can view charts, definitions and upstream/downstream production relationships and enter metric-analysis dashboards. Publishing a metric therefore includes both a business explanation and an analytical entry point. Teams can check a number against its definition instead of comparing report values and guessing the source of differences.

Publication also needs organizational responsibilities. Assign definition owners and business approvers to key metrics, and check formulas, sample results, time semantics, permissions and descriptions before taking them online. Significant definition changes should retain their reasons, impact scope and acceptance records. These governance actions should connect to existing company processes; they must not all be presented as product features that execute automatically by default.

5. Preparing Understandable Semantics for ChatBI and Data Agent

5.1 A Metric’s Existence Does Not Mean AI Understands It

If a field is named “amt_01,” a metric “sales2” and its description is blank, natural-language queries may fail to match it accurately even when the formula is correct. HENGSHI’s data-preparation approach emphasizes clear dataset, field and atomic-metric names, with complete purpose descriptions. Distinguishing field names from metric names also reduces confusion between detail fields and aggregated results.

Dataset knowledge management can maintain business terms, synonyms, implicit rules and mappings to fields and metrics. A company can explain which metric “transaction value” means in a particular business domain, what dates constitute “last fiscal year,” or how a customer category is identified. Knowledge should specify its applicable context rather than forcing one department’s shorthand onto every business area.

Hiding fields irrelevant to the current analysis can reduce the Agent’s candidate set. Descriptions must keep pace with business changes: outdated refund rules, customer categories or organizational structures affect question interpretation. A stable semantic layer comes from continuously maintained business assets, rather than a one-time cleanup assumed to last forever.

5.2 From Interpreting a Question to Executing a Query

A question such as “How much did net sales at East China stores decline last month?” requires identifying the net-sales metric, month range, region condition and comparison baseline. “How much” may mean an absolute difference or a percentage decline; “last month” may mean a calendar month or a financial month. Where information is missing, a reasonable analysis should ask for clarification or explicitly state its assumptions.

After the question is interpreted, ChatBI or Data Agent can organize queries within available data and permissions and return analysis based on execution results. Metric definitions and business knowledge provide the basis for interpretation, while platform tools perform the actual calculations. Answers should distinguish retrieved results, applied conditions and inferred causes so users can check them.

Workflow: From a business question to a verifiable metric result

1. Business user → ChatBI / Data Agent: Ask a business question
2. ChatBI / Data Agent → Metric definitions and business knowledge: Retrieve metric meaning and analysis conditions
3. Metric definitions and business knowledge → ChatBI / Data Agent: Return applicable definitions and semantics
4. When conditions are ambiguous: ChatBI / Data Agent → Business user: Clarify time, scope or comparison baseline
5. When conditions are ambiguous: Business user → ChatBI / Data Agent: Confirm analysis conditions
6. ChatBI / Data Agent → Analysis execution tools: Organize a query within authorized scope
7. Analysis execution tools → ChatBI / Data Agent: Return actual calculation results
8. ChatBI / Data Agent → Business user: Present results, conditions and supporting explanations

The semantic layer reduces the burden of assembling business logic on the fly, but cannot guarantee accurate interpretation of every question. Missing metrics, undefined model relationships or incomplete knowledge require further data preparation and validation. Model capabilities, query execution and business definitions have separate responsibilities, and weaknesses in any layer can affect the answer.

6. An End-to-End Example: Reusable Store Sales Analysis

Suppose a chain wants to support an executive dashboard, regional managers’ self-service analysis and natural-language queries. First, organize order and refund data, confirm the meanings of order identifiers, payment dates, refund dates, stores and regions, and validate update frequency. This establishes a shared data foundation for subsequent numbers.

Second, define foundational measures and separately maintain sales amount, refund amount, order count and net-sales calculations. Business and finance teams must agree on attribution for refunds across months. If both rules are required, create distinct metrics instead of switching implicitly at query time. Use edge-case samples to check duplicate joins, nulls and canceled orders.

Third, establish business metrics and common analysis settings. Store operations select the required store, region and time axis; finance uses its own recognition definition. Reuse appropriate shared configurations through granularity, and maintain unsuitable ones separately. Reuse should reduce repeated work while preserving necessary business differences.

Fourth, publish into operations and sales topics and configure management and viewing permissions separately. Before taking metrics online, business owners check default charts, definitions and sample results. Then test visibility and usable scope with a regional manager’s account. An administrator’s ability to see data does not prove that an ordinary user can run the same query.

Fifth, describe business vocabulary such as “net sales,” “East China” and “financial month,” and test common questions with ChatBI and Data Agent. Include explicit wording, abbreviations, cross-period comparisons and questions with missing conditions. Check metric matching, time interpretation, actual queries and answers. When errors arise, identify whether knowledge, model relationships, permissions or execution is responsible before making a targeted correction.

7. Acceptance Criteria for a Metrics Platform

Acceptance should do more than count created metrics. Select real business questions and check definitions, publication, consumption and AI queries. This exposes both problems in metric assets and obstacles after those assets enter business workflows.

At the definition layer, check formulas, measured objects, time semantics and data sources, using edge-case samples to verify results. At publication, check topic organization, online/offline states and role permissions. At consumption, check dashboard references, dimensions and filters, confirming that calculations under identical query conditions can be reproduced. For AI, check terminology matching, ambiguity handling, query conditions and the evidence behind answers.

Definition changes also need records of their reasons, affected use cases and how old and new results can be compared. Metric lineage provides relationship clues; implementation teams must turn those clues into concrete checks. Seeing a lineage diagram does not prove that every consumer has automatically passed compatibility validation.

Metric alerts and KPI operations can build on this system, but thresholds, targets, trigger frequency and notification channels require confirmation against the version and project configuration. A technical article can explain their value; delivery must still follow actual capabilities and acceptance results, rather than promise that every rule works out of the box.

8. HENGSHI’s Perspective

HENGSHI’s perspective: Metric management connects calculation definitions, business configuration, publication, authorization and analytical consumption in one maintainable way of working. Through HQL, atomic and business metrics, business topics and semantic preparation for ChatBI and Data Agent, HENGSHI makes business definitions understandable to people and usable in actual analytical execution.

Companies can begin with one frequently used business domain, establish verifiable metrics and then expand across teams and AI use cases. Clearly defined metric assets with explicit boundaries and reproducible results continue to be useful as dashboards, query entry points and models evolve.