Fleet token accounting: truthful top-X/N-hours report

Sub-tickets — 2/3 done

Activity

• wi-cli-venus created · 5w ago
• bin-venus-cc note · 1w ago
  SETTLE-FIRST QUESTION ANSWERED (pmmaster-evolutiva-cc, 2026-10-06 10:09 ART): is a single to:[] multi-recipient send distinguishable in the stored data from N sequential sends? SPLIT ANSWER - yes for an explicit array, NO for an ARO broadcast, and the flags that look like they encode it do not. READ-ONLY against /var/lib/llmmsg-srv/v2.sqlite (mode=ro), messages table, 145633 rows 2026-06-13..2026-10-06. 1. THERE IS NO SEND ID IN THE SCHEMA. Columns are id, ts, sender, recipient, body, origin_aro, kind, re, tag UNIQUE, plus expects_reply, retracted_at, session_id, bs_role, created_at, action_required, fanout, explicit_to, coach_retracted, requested_recipient, forward_path. One row per RECIPIENT, and nothing names the send. Everything below is reconstruction from a client-side naming convention, not a key. 2. AN EXPLICIT to:[] ARRAY IS DISTINGUISHABLE, by the TAG STEM. tag is UNIQUE, so N recipients cannot share one; the hub instead writes <sender>-<nonce>-<recipient> for N>1 and a bare <sender>-<nonce> for N=1. Stripping a trailing -<recipient> recovers the send. Measured reliability over the whole corpus: 16054 multi-row stems, of which ZERO span more than one sender and exactly ONE spans more than 0 seconds. Group-size distribution 2:7557, 3:4148, 4:2403, 5:707, up to 12. So grouping by stem is safe in practice. Verified against my own four sends today, including a 4-recipient array (ids 145350-145353, one nonce, four suffixes, identical ts) next to two single sends with distinct nonces and no suffix. 3. THE HEADLINE NUMBER: 145633 stored rows are 110979 sends, so 23.8% OF ALL STORED ROWS ARE FAN-OUT DUPLICATES of another row (24.9% over the last 24h: 5766 rows, 4329 sends, 970 multi-recipient). A raw count(*) per sender therefore over-counts array users by their recipient count and leaves light users untouched - pmmaster-evolutiva-cc's own 24h figures are 995 rows / 443 sends (2.25 rows per send) against audit-terra-ca's 400/354 (1.13). Ranking by rows_stored is a ranking of fan-out habit as much as of volume. ANY per-sender census MUST print both denominators. 4. AN ARO BROADCAST IS NOT RELIABLY RECOVERABLE, and this is the worse half. A single aro: broadcast can land as SEVERAL stems: scrp-syscheck-whey at ts 1791286388-9 wrote stem ...muwlnz0s6qwa with two suffixed rows (elazar-the-user-human-llmmsg-srv, nw-venus-cc) AND a separate bare-nonce row ...muwlnzsskfyi to nw-whey-cc one second later - one logical broadcast, two 'sends' by any stem-based count. Same shape at 1791279068 and 1791275518. So for aro: traffic the stem UNDER-groups, and no instrument in the schema distinguishes that split from two deliberate sequential sends. I deliberately do not quote a rate for how often this happens: the only way to group a broadcast is to bucket by sender+aro+time, and that bucketing is itself the guess being tested, so a percentage derived from it would be circular. The honest statement is the existence proof plus the absence of a key. 5. THE TWO FLAGS THAT LOOK LIKE THE ANSWER ARE NOT. fanout and explicit_to are BOTH 1 on a single-recipient array send and on a 4-recipient one alike, so neither encodes the arity; and both are 0 on every row before 2026-07-30 (45703 dm rows at 0/0), so for 2026-06-13..07-29 the tag shape is the ONLY route. A census that reads fanout as 'this was a broadcast' is reading a flag that cannot discriminate. CONSEQUENCE FOR THIS ROW AND FOR THE WAITING CONSUMER: monitor-llmmsgsrv-cc's census can be made truthful for to:[] traffic today by grouping on the tag stem and printing rows and sends side by side with the window served; it CANNOT be made truthful for aro: traffic without a send/broadcast id in the schema, which is a change to the hub and therefore coder-llmmsgsrv-cc's lane, not mine. That schema gap is the finding you suspected, one axis over from where you suspected it.
• bin-venus-cc note · 1w ago
  MESSAGE LEG DELIVERED as KPI-80 (pushed c800d15). Filed as a child, not as this row: KPI-66 is token accounting over fleet_tokens and its contract half KPI-68 is still gated on Elazar ratifying the store of record, so closing this epic on a hub-message tool would mark it done on work that never touched a token. The token half is untouched by today's work.