A strange weekly report? Check the data before explaining the business

The weekly fulfillment report arrives with a red number. Before asking why performance slipped, the operations lead needs a more basic answer: does this week measure the same thing as last week, with equally complete inputs?

An Agent can assemble the checks and expose the affected rows. The team still owns the metric definition, the threshold and the decision to investigate. A polished explanation cannot substitute for those inputs.

Freeze a small measurement contract

Consider a fictional fulfillment team using two authorized CSV exports: orders and shipment events. These are illustrative inputs, not a Buda customer result or an executed experiment. The team defines an overdue order as an order whose promised dispatch deadline has passed without a dispatch event by the weekly cutoff. The denominator is all orders whose promised deadline falls inside the reporting window, including orders not yet dispatched. Cancellations are excluded only under the team's written rule.

Use two adjacent seven-day windows, Monday 00:00 through the following Monday 00:00, end exclusive, in the same stated timezone. Record the cutoff, export timestamp, source coverage, order ID, promised deadline and dispatch timestamp. A download date is not a business date. A missing dispatch event is not automatically evidence of lateness if the shipment export is incomplete.

Three inputs that deserve different responses

For A, report the missing interval and affected order IDs. Leave the missing measure null, not zero. Preserve the last complete report with its original date; do not label it current. A partial result may be useful if its covered interval and denominator are explicit, but it is not the full-week comparison.

For B, the underlying refund events may all be correct while the comparison is wrong. Keep this separate from the overdue-order measure. Ask the metric owner which attribution rule applies, record the answer and recalculate. An Agent must not silently select whichever definition produces the tidier story.

For C, suppose the fictional exports contain 20 overdue orders out of 200 eligible orders this week, versus 8 out of 200 last week. That is 10% versus 4%: an increase of 6 percentage points and 12 orders. If the team's illustrative investigation rule is an increase of at least 5 percentage points with at least 10 additional overdue orders, this case passes both conditions. This is a proposed team rule, not an industry benchmark or an AI-generated default.

Build an exception record, not a causal story

Use one row per exception: exception ID, class, affected metric, source file and row IDs, definition version, observed value, comparison, threshold, unanswered question, supplied owner role, next check and state. If no owner was supplied, write unassigned. Separate observations from hypotheses.

For C, “12 more overdue orders” is an observation. “A carrier outage caused the increase” is a hypothesis until shipment-level evidence supports it. Separate regional and device totals cannot establish a regional-device causal chain. An Agent should propose the cross-cut to check, not invent the answer.

A decision-ready summary puts the confirmed deviation, the missing-source warning and the owner decision first. Keep the source rows and arithmetic directly accessible. A quiet week may have no verified business exception while still having an unresolved source gap.

Preserve the checks before adding a schedule

In operations workflow you can build with Buda, keep the metric contract, authorized input copies, dated report and exception table in Drive. Drive and memory provide persistent files; the method still needs explicit instructions about which versions to read. A file name alone is not an access-control policy.

Start with a manual run on a redacted historical week. Ask the Agent to produce the three-case classification, arithmetic and unresolved questions without sending alerts or changing records. Save a reusable method as a Skill only after review; suitable Skills can be searched and installed in Buda AI's Marketplace. Read the Skill before installing it. Skills and automations let a tested procedure be reused or scheduled, but do not establish that every source connector or approval workflow is configured.

Unlike integrating parallel deliverables, this check is about the validity of each recurring comparison, not merging agent outputs. Preserve report v1, then issue v2 after the delayed export arrives, recording what changed and which exceptions were rechecked.

Practical questions

Who chooses the threshold?

The accountable operations owner. Record the business reason, percentage-point rule and minimum absolute count before running the check. Where no rule exists, show observations and request a decision rather than marking a guessed threshold as approved.

What changes when late data arrives?

Keep the old report, replace the incomplete input with a separately versioned export and rerun affected measures plus the completeness check. Close the source-gap row only after the expected interval is present; a new business exception may then emerge.

What if there are very few orders?

Always show numerator and denominator. One out of five is 20%, but it is one order; apply a team-approved minimum-count condition and inspect the records before escalating a percentage alone.

A useful first test is to deliberately withhold a source interval, change a definition and inject a threshold-crossing sample. These are suggested tests, not reported results. Review whether each reaches the right branch before deciding to schedule the report.