Why AI Weekly Reports Keep Getting Numbers Wrong: Root Cause Behind Grok Bot's Errors Despite Complete Materials

All the materials are provided, so why does the AI still get the weekly report wrong? In episode 16 of the Grok Bot series, Bilibili creator "马上花生" (Mashang Huasheng) recreates a typical office scenario using a simulated requirements progress table and a mock email: the progress table shows 8 items completed, but the email says 2 items are pending acceptance. How many items should the weekly report actually list? The root of the problem isn't whether the materials are sufficient—it's whether the status definitions and statistical criteria are aligned.

Core Conflict: Dev Done ≠ Acceptance Passed

The course designs a deliberately constructed contradictory scenario. The progress table lists 8 completed items, and the mock email updates 2 of them as still pending acceptance. If you simply do the math, 6 items accepted and 2 pending acceptance, the answer seems clear. But the creator points out that this "8-2=6" reasoning is itself a trap.

The key is: "Dev done" describes development status, while "acceptance" describes acceptance confirmation. Both sources can be simultaneously true—a task can be both in "development completed" status and in "pending acceptance confirmation" status. If you directly add these two numbers to get 16 items, or keep only one nice-looking completion number, both are misinterpretations of the status semantics.

The correct approach is to first return to the requirements document and look at the respective definitions of "dev done" and "acceptance," see which item changed, who confirmed it, and when. If the materials have no authoritative ordering or clear update relationship, it should be listed as a pending-confirmation question rather than letting the Bot pick a number arbitrarily.

In project management and software engineering, a task state machine is a model that defines the stages each task goes through from creation to closure and the allowed transitions. Common core states include: To Do, In Progress, Dev Done / Code Complete, Submitted for Testing, Under Acceptance, Accepted / Done, and Closed. The key point is that the state diagram is directed and cannot be arbitrarily merged: "Dev Done" and "Acceptance Passed" are two separate nodes, with testing submission, defect fixing, and acceptance review typically in between. Therefore, a task can simultaneously satisfy "development completed" and "pending acceptance confirmation"—the two are not mutually exclusive. Subtracting or adding the two sets of numbers essentially treats two different nodes in the state machine as the same counting criterion, which produces "double counting" or "undercounting" in statistics. Understanding the state machine model makes it clear why returning to the original definitions and confirming who can drive state transitions (usually the acceptor, not the developer) is a prerequisite step for avoiding errors in weekly report numbers.

Reconciliation Isn't Subtraction: Three Prerequisites

The creator emphasizes that "reconciliation" is far more than subtraction. Before confirming whether two sets of numbers are consistent, three conditions must be verified:

No duplicate records. Whether the same task appears twice in the progress table and email, causing double counting.

Consistent status definitions. Whether "complete" in the progress table and "completed" in the email mean the same thing, or belong to the development stage and acceptance stage respectively.

Genuinely the same statistical scope. Whether the time nodes, task granularity, and statistical units of the two sources are consistent. The course specifically stipulates that statistics are cut off at 18:00 Shanghai time on October 13, with task items as the statistical unit; new information after that node must be noted separately and cannot be mixed into this round of statistics.

The course also deliberately creates a more difficult situation: one pending-acceptance item lacks an owner, and another lacks an expected acceptance date. During reconciliation, a "pending confirmation issue list" should be written—asking who is responsible and when it will be confirmed—rather than reusing last week's names or inventing a deadline. Missing fields don't prevent delivering the confirmable parts first; as long as known, inferred, and undecided items are separated, readers can clearly judge.

Statistical criteria (metric definition) refer to the complete rules followed when a number is counted, including: statistical object (which tasks are included), time window (cutoff moment), granularity (by task item, subtask, or work hours), unit, data source priority, and deduplication rules. When the same thing doesn't match across two sets of materials, it's often not that the data itself is wrong, but that the criteria differ—for example, the progress table is filed by "dev completion date" while the email is updated by "acceptance confirmation date," so their time baselines are naturally inconsistent. The general approach to resolving criteria conflicts is to first establish a "single source of truth": clarify which material has authority over which field, then align time, granularity, and deduplication rules item by item. If alignment is still impossible, the discrepancy should be logged as a pending-confirmation item rather than letting the AI choose the "better-looking" number. This methodology also applies to financial report reconciliation, data warehouse construction, OKR reviews, and similar scenarios.

Artifact Boundaries: Drafts Stay as Drafts, Don't Commit on Others' Behalf

This lesson draws clear boundaries in task rule design. The source and pending-confirmation columns don't modify originals, don't send drafts or calendar invitations; what's delivered is a CSV table and reconciliation weekly report, not an Excel formula file. The course didn't generate a workbook, so it doesn't call it a "verified Excel file."

Every artifact must be openable, important facts must be traceable back to material sections, and gaps must remain in their corresponding positions. The appearance of a file card is only the beginning of delivery; the actual content must be checked, not just whether a download link exists.

The stopping point for drafts is equally critical. Writing an email doesn't equal having given a send instruction. The course reference didn't actually return a card or send record, so the file is explicitly called "Teacher Reference," without fabricating a delivered screenshot. If the recipient is unknown, mark it as pending confirmation; check tone, facts, and dates before deciding whether to send.

Human-in-the-loop refers to a mechanism where automated processes must be confirmed by a human before continuing at key nodes. In AI office scenarios, it manifests as the separation of "generation" and "sending": AI can draft emails, generate tables, and prepare calendar invitations, but actions that actually trigger sending, write to shared systems, or make external commitments require explicit human authorization. This is because sending-type actions have irreversibility and agency responsibility—once sent, they represent the organization's formal external commitment, and the cost of error is far higher than in the draft stage. Therefore, when designing AI workflows, operations should be divided into reversible (read, edit, save-as) and irreversible (send, delete, write, invite) categories, with the latter always having a confirmation gate. At the same time, AI should not fabricate status evidence such as "delivered" or "confirmed"; gaps should be retained in corresponding fields for human completion. This principle is not only a technical specification but also a responsibility boundary: draft errors are borne by humans, while mis-send consequences are borne by the authorizer.

Permissions and Authorization: Practice Without Opening a Real Email Account

The creator specifically notes that public attachment exercises don't require opening real email permissions. The course only uses self-authored requirements progress tables and mock emails, without connecting to real email or calendars.

But the course also provides authorization rules for real tasks: after selecting a connector, a position/role name must be configured; the role name doesn't automatically grant all email and calendar access permissions. Real tasks require first verifying identity authentication and read scope, validating with empty search markers, and continuing with writes, sends, or invitations based on specific authorization.

The core logic of this rule set is: source readable, criteria clear, gaps retained, artifacts verifiable, draft stopping point. Managing office tasks as an acceptance checklist allows both developers and office workers to judge exactly how far results have progressed.

The principle of least privilege requires that a system or account be granted only the minimum access scope necessary to complete the current task, not one bit more. In connector and Bot configuration scenarios, this means that even if a certain type of connector is selected, it doesn't automatically grant read-write access to all emails, calendars, and folders under that account. The correct process is: first confirm the identity authentication method (OAuth, service account, etc.), then specify read scopes item by item (e.g., read-only for certain labels, a specific shared calendar); write and send permissions are applied for and audited separately. Empty searches or irrelevant keyword searches can verify "what can actually be read right now," thereby discovering excessive or insufficient permissions. For public exercises, self-authored data is sufficient to complete the vast majority of methodology training without touching real accounts; only in real tasks is on-demand, scoped, time-limited granting needed, with revocation after task completion. This is both a security practice and compliant with data minimization requirements in data regulations (such as GDPR and personal information protection laws).

Reusable Methodology: Facts Change, Process Stays

If the owner or date is filled in, specify which item the new material replaces, revise the same artifact, and re-verify the affected numbers and criteria. Simply swapping the title date doesn't count as complete. If the next round lacks current materials, submit a missing-input statement—don't pass off this week's 6.2 as next week's results.

The methodology is reusable, but facts must be re-verified every time. In the next lesson, the creator plans to reuse the presenter role for themselves, others, or the team, distinguishing differences between copying templates and team Bots—the methodology can carry over, but shared login scope and member permissions must still be re-verified.

One-line Summary

The root cause of AI weekly report errors isn't insufficient materials, but misaligned status definitions and statistical criteria.

Paragraph Summary

Through a Grok Bot course, the article recreates a typical AI weekly report scenario: the progress table shows 8 items dev-done while the email mentions 2 pending acceptance. Directly subtracting to get 6 or adding to get 16 are both misreadings. The creator points out that dev done and acceptance passed are two independent nodes in a state machine, and a single task can satisfy both simultaneously. Therefore, one must first return to requirement definitions to confirm semantics, then verify three prerequisites—no duplicate records, consistent status definitions, and identical statistical scope. Missing fields during reconciliation should go into a pending-confirmation list rather than reusing last week's names or inventing deadlines. Artifact boundaries are equally critical: drafts stay as drafts, don't commit completion dates on others' behalf, and don't fabricate delivered records; public exercises need no real email permissions, while real tasks require first verifying identity authentication and read scope. The methodology is reusable, but facts must be re-verified each time.