## Problem `haf_stats_backend.account_content_daily` and `haf_stats_backend.network_content_daily` are both written by the same single comment-op scan in `process_content_stats`, and both claim to count created posts/comments per day. They **disagree**, and one of them is served to users. Found while reviewing !61 (the #42 double-count repair). It is **not** the #42 doubling and **not** caused by !61 — flagging separately so it does not scope-creep that MR. ## Evidence Comparing against an independent source of truth — `hivemind_app.hive_posts` (`depth = 0` → post, `depth > 0` → comment) — for 2023-07-01..10: | day | `account_content_daily` posts | `hive_posts` posts | ratio | `account_content_daily` comments | `hive_posts` comments | ratio | |---|---|---|---|---|---|---| | 2023-07-01 | 3,660 | 3,073 | 1.191 | 28,901 | 27,859 | 1.037 | | 2023-07-02 | 3,309 | 2,780 | 1.190 | 27,397 | 26,524 | 1.033 | | 2023-07-03 | 3,651 | 3,050 | 1.197 | 25,663 | 24,830 | 1.034 | | 2023-07-04 | 3,622 | 2,972 | 1.219 | 25,962 | 25,028 | 1.037 | | 2023-07-05 | 3,542 | 2,965 | 1.195 | 28,294 | 27,477 | 1.030 | | 2023-07-06 | 3,829 | 3,090 | 1.239 | 26,974 | 26,090 | 1.034 | | 2023-07-07 | 3,727 | 3,001 | 1.242 | 26,550 | 25,654 | 1.035 | | 2023-07-08 | 3,501 | 2,881 | 1.215 | 22,439 | 21,633 | 1.037 | | 2023-07-09 | 3,347 | 2,745 | 1.219 | 22,078 | 21,305 | 1.036 | | 2023-07-10 | 3,707 | 3,146 | 1.178 | 26,547 | 25,608 | 1.037 | A **stable ~19–24% excess on posts** and **~3–4% on comments**. The stability is what makes it interesting: it is a systematic offset, not noise and not a doubling (a doubling would be 2.000, as `network_content_daily` in fact is for the same days). For contrast, on the same days `network_content_daily` is **exactly 2.000×** `hive_posts` (the #42 bug), which means its *single-counted* value would land exactly on `hive_posts` — i.e. the network table agrees with Hivemind while the account table does not, despite coming from the same scan. ## Why it matters `account_content_daily` is read by the live endpoint **`get_account_content_stats`**. If the excess is a counting error, that endpoint over-reports every account's post count by roughly a fifth. ## Likely explanation (needs confirming, not assuming) Most plausibly **definitional**: haf_stats counts a *create* event and keeps it, whereas Hivemind **deletes** the row from `hive_posts` when a comment is deleted. So posts created and later deleted would be counted by haf_stats but absent from Hivemind. That would explain a positive, stable offset — and a larger one for posts than comments if posts are deleted more often. But that theory has a problem: it should apply equally to `network_content_daily`, which instead lines up exactly with Hivemind. Both tables are produced by the same `classified` CTE in the same scan, so a divergence between them is not obviously explicable and is worth understanding properly. ## Ask 1. Determine whether the ~19% excess is definitional (deleted posts, edits misclassified as creates, attribution differences) or a genuine counting bug. 2. Explain why `account_content_daily` and `network_content_daily` diverge at all, given they are written from the same classification in the same function. 3. If definitional, document it in the `get_account_content_stats` endpoint description so consumers do not treat it as comparable to Hivemind/`network_content_daily` figures. If it is a bug, fix it — and note the same repair-tooling questions as #42 apply. ## Related - #42 (the 2× `network_content_daily` double-count) and !61 (its repair) — separate defect, same table family. - Verified on testapi against Hivemind, 2026-07-14.