Handing a Sales Daily Report to an Agent: From Metric Checks to Report Acceptance

A daily sales report may look like a few charts refreshed each morning. Before handing it to an Agent, however, the data team must answer three questions: should sales be counted by order date or payment date, on which day should refunds be recorded, and who may see regional details? Without agreed answers, a scheduled run simply delivers disagreements about definitions to more people on time.

Put the report’s business definitions into the platform first

For a report on “yesterday’s net sales by region,” the business owner needs to confirm the reporting period, refund treatment, and regional attribution. The data team then checks the sources, datasets, and metric calculations. HENGSHI SENSE supports data integration, modeling, metric management, and dashboard delivery. Teams can express basic calculations as atomic metrics, then configure qualifying conditions, analysis dimensions, and time axes in business metrics. The report consequently refers to metrics with explicit business meanings, giving later discussions a concrete definition to return to.

Beyond metric definitions, check when data updates, how late orders are handled, and what data each role may see. Reusable report numbers do not mean everyone should see the same details. Validate results with actual user permissions before publication.

Use samples to make “correct” specific

Before handing metrics to an Agent, calculate the results for a small set of known orders. The sample need not be large, but it should cover disputed boundaries: payments crossing midnight, partial refunds, canceled orders, regional reassignment, and delayed data. The business owner writes down expected figures first; the data team calculates results from the target dataset. Only after they agree should the definitions be used in the production report. Keeping reviewable orders and rules helps distinguish a data change from a definition change when numbers move later.

Acceptance check	Question the sample must answer	Evidence to retain on passing
Time basis	Which event time and time zone define yesterday?	Start and end times; details of orders crossing midnight
Amount basis	How do refunds, cancellations, and partial refunds affect the net amount?	Sample orders and manually expected values
Organizational basis	Does a region reflect attribution when the order was placed or current attribution?	Regional mapping version and reconciliation of totals
Visibility	Can a regional manager see another region’s details?	Dashboard checks under the actual role

“Yesterday” also needs a data cutoff. For a report run each morning, specify whether orders entered overnight belong to the current reporting period, and whether to wait, alert, or delay sending if source tables have not refreshed. Teams do not need to eliminate all late data, but recipients must know the report’s cutoff and which figures may change in a later run. Reports used for settlement can be named and accepted separately from operational daily reports, avoiding two purposes under one name.

Let the CLI perform defined actions

The public command entry point for HENGSHI CLI is hbi. It covers resource domains including application and dataset queries, HQL queries, dashboard configuration, and authorization, and can return structured results. After receiving a daily reporting task, an Agent should first inspect the target instance, application, and dataset, then verify the objects used by the queries and report. The following read-only checks are supported by the official documentation; the implementation team must confirm the actual IDs, fields, and expressions in the target instance.

hbi auth status --output json
hbi dataset list --app <app-id> --output json
hbi data-model query --app <app-id> --dataset <dataset-id> "SUM({amount})"

These commands do not decide how “net sales” should be calculated. The Agent calls confirmed capabilities in task order; HENGSHI SENSE executes queries and resource operations; business and data owners accept the definitions and conclusions. Before changes such as authorization, inspect the current state and use dry-run on commands that support it. Reading figures successfully is not permission to publish.

Build acceptance into the reporting process

Start by running one report manually: check metrics and time ranges, compare sample results, then open the final dashboard to inspect filters, charts, and permissions. Afterward, use the enterprise’s existing scheduler or Agent runtime to trigger repeated tasks, retaining command output and exception records. If data is stale, a query fails, or results deviate from expectations, the process should request review by the owner rather than continue sending a report that merely looks complete.

A handover can take the form of an acceptance card listing the dataset, metric names, reporting time zone, run time, target dashboard, and recipients. Attach expected results for a normal day’s data, one refund, and one order crossing midnight. The business owner confirms the rules represented by these samples, and the data team records the relevant queries and report locations. The Agent checks the same list on every run and returns changes to metric definitions or datasets to the owner for confirmation.

Define clear conditions for withholding delivery. If yesterday’s data has not finished updating, regional subtotals do not match the total, or a recipient sees a blank page, record the check, actual result, and time, and notify the responsible owner. Once resolved, rerun only the affected steps to avoid sending multiple versions. If the business permits sending an annotated report first, the business owner should define the conditions and wording in advance.

Acceptance records should trace back to a specific run: who confirmed the definition, which time range the query used, when the report was generated, and who closed an exception. At month-end, teams can distinguish changes caused by metric definitions, source data delays, or permission adjustments, and decide which checks should be automated next.

Turn failure handling into operating rules

An automatic run does not imply automatic delivery. After checking objects and running queries, the Agent should compare results against the acceptance card: is data fresh enough, do regional subtotals match the total, are key regions missing, and do recipients have access? The business owner sets thresholds in light of normal variation. Holiday sales can differ sharply from working-day sales, for example, so withholding every report on a period-over-period decline would create noise. Separate hard errors from anomalies that need explanation.

Read the task definition and confirmed metric definitions
Check data freshness, query results, dashboard, and recipient scope
For a hard error: record evidence, notify the owner, do not send
For an unexplained anomaly: attach an explanation request for business review
After approval: send the specified version and retain run time and acceptance results

A traceable report should show its version, reporting interval, and generation time. When a recipient says today’s numbers differ from yesterday’s view, compare the filters and permissions used in the two runs before checking for backfilled source data. Everyone need not repeat the entire query process. If a correction requires resending, the owner should state the reason in the new version so recipients know which result to use.

Expand to other regions or metrics once the process is stable. For each additional metric, reuse the same approach to samples, permissions, and withholding rules while confirming its business definition separately. Agents reduce mechanical work, but cannot accept definitions on behalf of business owners. The time saved comes from making routine checks repeatable and letting people focus on exceptions.

What a reviewable run record looks like

Suppose yesterday’s net sales must be sent to regional owners at 9 a.m. At 8:50 one morning, the Agent finds that the order source table has refreshed, while the refund table is still at the previous evening’s state. Record each source’s update time and query conditions, then give the data owner the specific exception “refund data has not reached the agreed cutoff,” rather than a generic task failure. After the owner confirms the refresh, rerun the query and compare samples. If the result changes, record the difference between old and new values.

Or suppose the East China subtotal differs from the overall table by RMB 500. The data team should locate the orders behind the difference, then inspect regional attribution and refund rules. If an upstream order was recently reassigned, record the adjustment time and mapping version used. The business owner can then decide whether to send the report and explain the change to recipients. This turns a verbal complaint about “wrong numbers” into a record that can be checked.

During the first week after launch, compare manual and Agent results in parallel. Reduce manual work after several runs whose differences can all be explained. If unclassified exceptions remain frequent, improve the samples and rules first. The decision to expand automation should depend on whether problems can be located and handled, not merely whether runs succeed.

When multiple analysis tasks share this process, HENGSHI JARVIS can provide consulting and enablement to help organize metric documentation, task routing, execution boundaries, and review requirements. It addresses how Agents collaborate using team knowledge and working rules. The actual data, metrics, and analysis assets remain jointly managed by HENGSHI SENSE and the organization using it.