A filter meant to drop sponsored social-media posts used word-boundary patterns such as \bpartner\b and #[a-z0-9]*partner\b. Platform-mandated disclosure tags are often written with an underscore (#brandname_partner). In regex, _ is a word character, so there is no \b between "_" and "partner", and [a-z0-9]* stops at the underscore: the tag is never matched. On one brand, these posts grew from 21 % to 51 % of captions while the "sponsored share" stayed flat, so a paid campaign looked like organic growth.

When validating a social-media signal (per-entity mention growth year over year) with a "more distinct authors, not just more posts" robustness check, normalizing an entity's distinct-author count by the number of distinct authors who mentioned ANY entity looks natural but fails badly when the collection changed between periods. After a crawl that captured fewer posts per author, every entity lost roughly 44 % of its distinct authors while the pool of authors naming any entity barely moved (-5 %), so 86 % of genuinely rising entities failed the check.

A large scraped dataset (posts with timestamps and text, no author ID) has a structural break: after some date the crawler kept collecting only a subset of accounts (here, 8x fewer posts per week and a different country mix). Dividing by a weekly total fixes the volume but not the composition change. Entity-share metrics measured across the break are inflated or deflated by which accounts remained, and a growth ranking computed on that window selects artifacts. Comparing on an earlier, clean window avoids the break but loses the most recent period, which is often the one that matters.

Building a filter mask from a Python list with pa.array([bool(x) for x in found]) works until a batch is empty (e.g. every row was removed by an earlier date filter). pa.array([]) infers type null, and table.filter(null_array) raises ArrowNotImplementedError, crashing a long batch job deterministically on the same block every retry.

When ranking named entities (brands, products) by growth in social-media captions, two silent failure modes inflate or deflate results. (1) A pooled denominator ("captions naming any entity per week") is contaminated when one entity name is reused as a meme/spam hashtag: one name produced 1.2M captions in a single summer on unrelated funny videos, inflating the pool and making most other entities look like they grew. (2) Phrases that pass dictionary filters still mean something else in the scoring window: "on cloud" was 65% "on cloud 9" (a concert tour), "caesars" 78% a pizza chain, a surname became a politician in the news, a brand name was Honduran slang, a town name. Aggregate tests (unit tests, matcher diffs) do not catch these.

A word-bounded phrase matcher (Aho-Corasick or regex) over social-media captions misses brands glued into hashtags (#brandhaul, #brandsandals), plurals, curly apostrophes from phone keyboards (brand’s), unaccented spellings, and 3-letter names dropped by a minimum-length filter. The naive fixes (match any hashtag that starts with the brand, fold accents in captions) create large false-positive counts.

Ranking brands by "mentions per 10k videos" from a scraped social-media dump gave every brand a ×3–5 jump in the last weeks of the crawl and non-domestic brands ×10–30 year-over-year. The crawl's country mix and its late-period sampling changed (the share of domestic videos fell from ~87% to ~25% and the surviving domestic videos named a brand five times more often), so a per-video denominator inflated everyone at once and the ranking measured the crawler, not the brands.

Rebuilding an investor's full holdings history from SEC 13F-HR information tables (data.sec.gov submissions JSON -> filing folder index.json -> infotable XML) and comparing the reported value/share with a market close flags dozens of positions as "wrong ticker" when the mapping is actually fine. Three separate causes look identical: Yahoo closes are split-adjusted while 13F share counts are as reported at the time (so value/share is 2x, 4x, 20x the close after splits); some filers still report values in $ thousands after the 2023 switch to dollars (1000x); and CUSIP->ticker mapping through OpenFIGI returns renamed issuers (Facebook->Meta, Square->Block) that a naive name check rejects, while genuinely reused or dead CUSIPs slip through.

A "which holdings are below the investor's entry price" screen only gives today's status. It says nothing about when the stock first crossed under, how long it stayed, or whether it dipped and recovered. Building the time dimension runs into three data problems: deal days known only to the month, entry prices never disclosed (only "announced on day X"), and pre-IPO tranches with no quotes before listing.

Running N parallel workers that each hf_hub_download a ~10 GB file (local_dir mode) on a 16 GB machine: within ~40 seconds memory peaks at ~15 GB, the kernel OOM-kills one python worker, and because the workers were launched inside a tmux session under a systemd user scope, systemd marks the scope "Failed with result oom-kill" and tears down EVERYTHING in it — the launcher/driver included. Symptoms are deceptive: the per-worker logs show no traceback, the driver never logs a retry, network traffic simply freezes, and `ps` shows no python at all. It looks like a stall or a rate limit, not a crash.