DOSSIER — PUBLIC CORRECTIONS LOG Canonical plain-text export · dossiertrack.co/corrections This file is a verbatim text export of every entry in the log as published. Its SHA-256 is anchored to the Bitcoin blockchain via OpenTimestamps. The accompanying .ots proof lets anyone confirm this exact text existed on the date shown, without trusting us. Entries are append-only and are never edited or deleted. If a future export omits or alters anything below, this proof makes that visible. ====================================================================== ENTRY #001 DATE: 2026-05-13 STATUS: ON TRACK Real-time convergence alerts launch May 19, 2026 Dossier's full pipeline — Helius WebSocket capture, token enrichment, convergence detection, and Telegram alert dispatch — will be operational and serving the beta cohort by May 19, 2026. The detector is already running in production; this commitment is about the public launch to operatives on the waitlist. STATUS · Pipeline live in production · cohort onboarding starts on launch date ---------------------------------------------------------------------- ENTRY #002 DATE: 2026-05-13 STATUS: ON TRACK Beta surveillance grid expands from 8 to 40 wallets before launch The beta launch cohort will surveil 40 curated wallets, expanded from the original 8 used for system validation. Selection methodology: Kolscan daily + weekly leaderboards, filtered for memecoin specialization, 30-day positive PnL, and absence of obvious insider or wash patterns. The full wallet list and selection rationale will be published as a public document before paid tiers activate (see #004). STATUS · Curation in progress · target completion 5.18.26 ---------------------------------------------------------------------- ENTRY #003 DATE: 2026-05-13 STATUS: ON TRACK Operative tier billing live within 30 days of beta launch Paid tiers (Operative at $29/mo, Handler at $99/mo) will be live and accepting payment within 30 days of the May 19 beta launch — target on or before June 18, 2026. The free Operative-Beta tier (6 months free for the first 50 verified operators) remains active regardless. No card collection during the beta intake — all access at the beta tier is genuinely free until conversion windows open. STATUS · Target date · 6.18.26 ---------------------------------------------------------------------- ENTRY #004 DATE: 2026-05-13 STATUS: ON TRACK Wallet selection methodology published as a public document before paid tiers activate Before any operator pays for Dossier, the full wallet selection and scoring methodology will be published as a public document at dossiertrack.co/methodology. The document will cover: data sources, candidate filtering criteria, scoring formula, removal triggers, governance process for cohort expansion, and the exact wallet addresses currently being surveilled. This mirrors the Federation's lending-spec pattern — design before code, methodology before payment. STATUS · Drafting · target publication before #003 ---------------------------------------------------------------------- ENTRY #005 DATE: 2026-05-13 STATUS: ON TRACK Dossier operates under the Galactic Federation research framework Dossier is the intelligence arm of the Galactic Federation of Finance. Methodology is developed under Admiral Zoran Voss and the Federation research desk. Dossier is an independent product (own pricing, own roadmap, own brand), but every commitment made by Dossier operates under the same transparency principles as the parent — public specs before code, append-only corrections log, no inflated stats, no hidden authorities. If Dossier ever departs from Federation doctrine, that departure will be logged here as a numbered correction. The relationship is not marketing; it is operational structure. STATUS · Permanent · structural commitment ---------------------------------------------------------------------- ENTRY #006 DATE: 2026-05-14 STATUS: ON TRACK Dossier revenue feeds Galactic Federation liquidity — staged, on-chain, quarterly Dossier exists inside the Galactic Federation. So does its revenue. A staged, public, on-chain percentage of Dossier's net revenue is committed permanently to $GFOF liquidity on Raydium — not to marketing, not to a side wallet, not to anyone's pocket. The percentage scales with Dossier's ability to sustain itself. Phase 1 · Beta (now through ~Aug 2026). Dossier is free. No revenue, no contribution. Focus is product-market fit. Phase 2 · Paid launch through first $5K MRR. 25% of net revenue deployed quarterly into $GFOF/SOL liquidity on Raydium. "Net revenue" is defined as gross subscription revenue minus Stripe fees, refunds/chargebacks, and direct infrastructure costs (Railway, Helius API, domain). The math is published every quarter alongside the on-chain transaction. Phase 3 · $5K MRR sustained for two consecutive quarters. Contribution steps up to 50% of net revenue, same quarterly cadence, same LP-injection mechanism. The "two consecutive quarters" trigger exists so that a single lucky month doesn't lock Dossier into a higher commitment than the business can sustain. Mechanism. Dossier Stripe payouts → dedicated on-chain treasury wallet → quarterly conversion to $GFOF → addition to Raydium $GFOF/SOL liquidity pool. LP receipt held permanently by the Dossier Treasury — not burned, not withdrawn, not redirected. Every quarterly injection is reported here as an appended note to this entry with the transaction signature. Dossier Treasury Wallet: G1MLNThNPE8hcZQfNTcjZGEDaSx1otutcNScLazBc92Y Publicly auditable on Solscan. Stripe payouts swept here at the end of each calendar month. Zero outflows except quarterly LP injections to Raydium and direct infrastructure reimbursement. Why this commitment exists. Most token projects can't answer the question "where does real revenue go?" because there is no real revenue. Dossier has a real product with real subscribers. Making the answer public, mechanical, and on-chain removes ambiguity. If the Federation ever wants to know whether the intelligence arm is paying its share, the answer is a Solscan link. STATUS · Phase 1 active · Phase 2 activates with paid tier launch · Mirrored on GFOF Corrections Log ---------------------------------------------------------------------- ENTRY #007 DATE: 2026-05-28 STATUS: DISCLOSURE Real-time alerts went silent from May 19 to May 26 — Postgres connection bug, now fixed Dossier launched on schedule on May 19, 2026 (see #001). Alerts fired correctly for roughly 36 hours after launch. Then a Postgres connection bug in the wallet monitor caused it to crash and restart in a loop. Because the process kept restarting, the service appeared "online" on the Railway dashboard, but it was not actually capturing wallet activity. No new convergences entered the database, and therefore no Telegram alerts fired. The system was effectively dead from approximately May 19, 11:00 PM CT through May 26, 5:43 PM CT — roughly seven days. During that window, the live ticker on this site continued to scroll older entries, and the 24-hour counter eventually fell to zero. Both were accurate. Neither was investigated quickly enough. Root cause. The four backend services that talk to Postgres were using a single persistent connection per service, with no automatic reconnect when that connection was dropped. Railway's internal networking closes idle TCP connections after a period of inactivity, which surfaced as ECONNRESET errors that the services were not handling. Each service exited on the unhandled error and was restarted by Railway, only to fail the same way again. The wallet monitor was the visible symptom; the other services were silently vulnerable to the same failure. Fix. All four services (wallet monitor, main detector, Handler detector, public API) were rewritten on May 28, 2026 to use a connection pool with built-in reconnect, TCP keepalive on the underlying socket, and a non-fatal error handler that logs and recovers rather than exiting the process. The change is a connection-handling fix only — no detection rules, wallet cohort, or alert formats were modified. What is in place to prevent recurrence. The connection pool will transparently replace a dropped connection rather than crashing. Pool-level error events are logged but do not exit the process. The probe-on-boot pattern surfaces any database reachability issue immediately in the deploy logs rather than at the first user-visible failure. A separate follow-up will add automatic reconnect logic on the Helius WebSocket as well, addressing the other class of silent-death failure that this incident exposed. What this correction does not cover. Dossier's monitoring was not strong enough to detect that the alert pipeline had stopped producing output for a week. That is a separate failure of operational diligence, and the lack of proactive uptime alerting is the underlying reason this took seven days to surface. Strengthening that is on the internal workplan, but no specific commitment is being made here — when one is, it will be logged as its own entry. STATUS · Outage May 19–26 · Root cause identified · Fix deployed May 28, 2026 17:43 CT ---------------------------------------------------------------------- ENTRY #008 DATE: 2026-06-06 STATUS: DISCLOSURE Second alert pipeline outage from May 30 to June 5 — WebSocket connection bug, now fixed The Dossier alert pipeline went silent again from approximately the evening of May 30 (CT) through the morning of June 5. Both Telegram channels — Dossier Signals and Dossier Handler Signals — received no alerts during that window. This is the second multi-day outage in two weeks, following the May 19–26 outage logged in #007. What happened. The wallet monitor's connection to our data provider (a long-lived WebSocket feed delivering Solana transaction events) stopped receiving data and never recovered. The Node process stayed alive, the Railway dashboard kept showing the service as "online," but no new trades were being recorded. Telegram alerts cannot fire on data that was never captured. Root cause. Infrastructure log retention on the current tier had rolled over by the time the issue was discovered, so there is no definitive log from the moment the connection dropped. The failure pattern matches a class of issue commonly called "silent connection death" — the underlying network connection drops, the local process keeps believing it is still connected, but no data flows. The wallet monitor service had no logic to detect this state or to automatically reconnect when it occurred. This is a different bug from #007. The May 19 outage was a database connection issue, which was fixed on May 28 with auto-reconnecting database pooling. The May 30 outage was a WebSocket connection issue, which that fix did not address. Two parallel failure modes in the same service. The first fix did what it was designed to do; it just was not enough on its own. Fix. The wallet monitor was restarted on June 5 to recover the system. That brought it back online but did not fix the underlying cause. On June 6, an auto-reconnecting WebSocket layer was deployed with a heartbeat-based detector for silent connection death. The service now automatically reconnects on any disconnect (with exponential backoff), re-subscribes to all watched wallets on reconnect, and forces a fresh connection if it receives no data or heartbeat response within a configured window. The structural failure mode behind both #007 and #008 — silent connection failure with no auto-recovery — is now closed. What this means in plain terms. The product was effectively offline for a substantial portion of the post-beta-launch period. Subscribers received no alerts during that time. The site dashboard continued to display historical data, which made "live" framing misleading. No promise is being made here that no other outages will occur — there are other ways a service can fail. The commitment is narrower and verifiable: every connection-class failure that produces silent downtime will get a corrections entry with root cause and fix, on the same week it is discovered. STATUS · Outage May 30–June 5 · Recovered June 5 (restart) · Structural fix deployed June 6, 2026 10:15 AM CT ---------------------------------------------------------------------- ENTRY #009 DATE: 2026-06-07 STATUS: ON TRACK Retiring the in-character narrator from Dossier's product voice Dossier's site previously used a fictional narrator — Admiral Zoran Voss (see #005). With the v0.5 site, the product no longer speaks through an in-character persona. Doctrine and research are attributed to the Galactic Federation of Finance as an institution; the methodology, status, and homepage state things plainly, in the product's own operational voice. Why. Dossier's credibility rests on plain, verifiable claims about real on-chain activity — a public corrections log, no committed numbers without a spec, no hype. An in-character narrator voicing the product sits in tension with that. Boundary. A fictional character may still appear in Dossier's marketing and social channels as clearly-labeled flavor. It does not represent the product's leadership, and it does not voice performance claims — those live only in the corrections log and forecast record, with verifiable backing. STATUS · Decided June 7, 2026 · effective with the v0.5 site ---------------------------------------------------------------------- ENTRY #010 DATE: 2026-06-07 STATUS: KEPT Beta surveillance grid shipped at 38 wallets, not the 40 projected in #002 In #002 we projected a beta cohort of 40 curated wallets. The grid shipped at 38. This entry reconciles that number rather than leaving #002's projection unaddressed. Why. During curation, two of the projected wallets failed verification — on closer inspection they were dead or suspect (no genuine recent on-chain activity, or patterns that didn't survive scrutiny). Rather than pad the roster back to a round 40 with entries that didn't clear the bar, the beta launched with the 38 that did. The count reflects what passed verification, not a target we forced. STATUS · Shipped · Beta v2 cohort = 38 wallets · reconciles #002 ---------------------------------------------------------------------- ENTRY #011 DATE: 2026-06-17 STATUS: ON TRACK Scored Forecast Record launched — first baseline logged and two self-bootstrap forecasts put on the record We launched the Scored Forecast Record — a public, append-only log where Dossier states falsifiable predictions in advance and scores its own accuracy after the fact. The first logging session is complete. The point is plain: a smart-money detector should be willing to be graded, on the record, before the outcome is known. The baseline. We established a qualified-holder baseline for $GFOF of 42 organic wallets, measured at a 0.01% supply floor, excluding five structural wallets — the Moonshot bonding curve and four Streamflow dev-lock contracts — that are not organic demand. This is the measurement basis the first forecasts resolve against, stated up front so the resolution criteria can't be moved later. The first two forecasts. FCST-S-00001-H7 and FCST-S-00001-H30, made 2026-06-17, resolving on or about 2026-06-24 and 2026-07-17. They are explicitly labeled SELF-BOOTSTRAP: they exist to seed the scoring methodology and are not convergence signals, trade calls, or product claims. Probability is hard-pinned at p=0.50 by design in this phase (so the Brier score sits at 0.25 until there is enough resolved history); the model only earns a calibrated probability later, once forecasts have actually resolved. Honest gap. The two forecast hashes are recorded in the append-only event log, but their OpenTimestamps Bitcoin anchoring — and the public commit of the event-log file itself — is still pending; that step needs the build environment and will be completed and noted here. Until then the integrity guarantee rests on the published hashes, not yet on the Bitcoin anchor. STATUS · Active · Scored Forecast Record live · baseline = 42 organic wallets · FCST-S-00001-H7 / H30 pending resolution (2026-06-24 / 2026-07-17) · OTS anchor pending ---------------------------------------------------------------------- ENTRY #012 DATE: 2026-06-27 STATUS: ON TRACK Status taxonomy unified with the Federation corrections log; keep-rate stats now auto-calculated This log previously used five overlapping status labels (IN PROGRESS, SCHEDULED, ACTIVE, SHIPPED, MISSED). They have been consolidated to the same disciplined vocabulary the Federation corrections log uses: ON TRACK (a commitment in force or in flight), KEPT (delivered), and MISSED (failed). Two accountability logs speaking different status languages is a small credibility seam; closing it while the log is still short was the cheap, honest fix. What changed, precisely. Only status labels were normalized — IN PROGRESS / SCHEDULED / ACTIVE became ON TRACK, and SHIPPED became KEPT. No entry text, date, id, or outcome was altered. This entry exists because changing a visible label on a past public entry is itself a change the log should record, even when the underlying facts are untouched. Also added. A keep-rate summary, total/ON TRACK/KEPT/MISSED tallies, live search, and status filters — all computed from the entries on this page at load time, so the figures cannot drift from the log. ---------------------------------------------------------------------- ENTRY #013 DATE: 2026-06-27 STATUS: ON TRACK Signal-forecast calibration locked and published; momentum confound disclosed and pre-registered for testing The calibration plan for Dossier signal forecasts is now locked and published as a public spec at dossiertrack.co/forecast-spec. Three parameters are fixed, each as method + provisional value + recalibration trigger: the qualifying floor F = 0.01% of circulating supply, the broadening threshold of +15% at the H7 and H30 horizons, and a mechanically-selected control universe of eligible-but-no-signal tokens. None is a final number; each is provisional under the no-committed-numbers rule until the data supports it. The disclosure that matters. Convergence signals often fire on tokens already in motion, so a Phase 1 control that compares signal tokens against all eligible tokens cannot separate predictive skill from pre-existing momentum. Phase 1 results are therefore labeled suggestive, not isolated skill — stated plainly on the spec page rather than left for someone else to point out. The commitment. We commit, in advance, to a Phase 2 control matched on holder velocity (which holds momentum roughly constant), and to publishing that matched result on the record regardless of how it breaks — including if it shrinks or eliminates the measured edge. This entry exists so that pre-commitment is on the record and cannot be quietly dropped later. ---------------------------------------------------------------------- ENTRY #014 DATE: 2026-07-07 STATUS: DISCLOSURE A Helius API key was found hardcoded in a leftover file; rotated and the file deleted During a security audit of the Dossier backend we found a Helius API key hardcoded in plaintext in a leftover file (an early learning script that was never part of the running service). All production code correctly reads credentials from environment variables; this one file predated that discipline and was missed. The repository’s secret-ignore rules were otherwise correct, so no environment file or other credential was exposed. Impact. The exposed key was a Helius RPC key (read access to public Solana chain data). It could not move funds, access user data, or touch any wallet — Dossier holds no custody and stores no user secrets. The realistic worst case was consumption of our request quota by a third party. We have no evidence the key was used by anyone else. What we did. Rotated the key immediately (the exposed key is now dead), re-applied access settings to the replacement, and deleted the leftover scripts from the repository. We log this even though it was low-impact and caught before any known misuse — which is exactly the kind of event a project is tempted not to disclose. That temptation is the reason to disclose it. ---------------------------------------------------------------------- ENTRY #015 DATE: 2026-07-08 STATUS: DISCLOSURE Rotating the exposed key (#014) took down the wallet monitor that was quietly using it; our own telemetry caught it The key rotated in #014 turned out to also be the live credential the production wallet monitor was using. Rotating it killed the monitor’s authentication: its WebSocket to Helius began returning 401 (unauthorized) on every reconnect attempt, and new trades stopped being ingested. The interruption lasted roughly one day, until we identified the cause. How it was caught. Our own status telemetry. The status page flipped to DEGRADED and stated plainly that the pipeline was online but the data feed was interrupted — new trades were not being ingested until it reconnected. This is the instrumentation we built after #007 and #008 specifically so a running process can never mask a stalled feed. It worked as designed: the failure was visible and honestly labeled, not hidden behind a green light. Impact. Convergence detection paused during the interruption — the monitor could not see new trades, so no new signals could fire for that window. No user funds, custody, or data were involved. The gap is in ingestion coverage for the affected period, which we disclose here rather than pretend continuity we did not have. What we did, and the process change. Updated the monitor to the current live key; ingestion resumed and status returned to LIVE. We then swept all backend services and confirmed every one is on the same live key. Going forward, a key rotation includes updating the credential everywhere it is used — code, deployment variables, and any local files — as a single checklist. #014 and this entry are the same event from two sides: rotating an exposed key without updating the service that depended on it. ---------------------------------------------------------------------- ENTRY #016 DATE: 2026-07-28 STATUS: DISCLOSURE Ingestion was dead for five days, and the detector kept alerting on frozen data the entire time Dossier captured no wallet activity between 2026-07-22 18:32 CDT and 2026-07-27 13:41 CDT — four days and nineteen hours. The Helius WebSocket that feeds the wallet monitor was refused on every connection attempt, roughly once a minute, for the whole period. Every backend process stayed up and reported healthy throughout, because every process was healthy. The feed was not. The detector did not stop. It scans on a rolling 24-hour lookback using the time a trade was recorded, not the time it happened on chain. When ingestion stopped, the trades table froze — and the detector kept scanning the same frozen rows every sixty seconds, kept finding convergences inside them, and kept alerting. 190 distinct stale convergences were alerted on, and alerting continued until 13:40:45 on 27 July — one minute before the feed recovered. Not for the first day of the outage. For all of it. Those alerts described wallets that had “just bought” using data that was in some cases days old, with nothing in the message indicating it was stale. Against our own stated claim, they were not late. They were wrong. Anyone who acted on a Dossier alert between 22 and 27 July was acting on a snapshot of a market that had stopped being observed. On the raw message count. The database records 1,242 alert messages sent in that window. We are publishing 190 as the number of stale convergences because the gap between those figures is a separate defect, disclosed in #017. Reporting 1,242 here would count that bug twice. Root cause of the outage. Helius rejected the WebSocket upgrade with 401 Unauthorized (-32401) on every attempt, refused at their edge before reaching their origin. The same API key, from the same container, at the same moment, authenticated successfully over ordinary HTTPS and returned a healthy response — a test we ran from inside the running process specifically to separate the two cases. The key was not revoked, expired, restricted or out of credits, and the plan was active throughout. Issuing a new key and swapping it in restored the feed immediately, with no other change. We do not know why the original key was accepted for one protocol and refused for another, and we would rather say so than publish a tidy explanation we cannot support. The question is open with the provider. Fix. Both detector tiers now check feed freshness before every scan. If the newest trade in the database is more than twenty minutes old, the scan is skipped entirely, the reason is logged, and the paused state is written into the heartbeat so it appears on /status rather than looking like an idle-but-healthy detector. A failure to read freshness also skips the scan: missing an alert is recoverable, sending a false one is not. Data that is simply gone. The wallet monitor subscribes to a live stream with no historical replay. The trades never captured during those five days cannot be backfilled and no attempt will be made to reconstruct them. Any convergence that occurred in that window was missed and stays missed. Two smaller things found while diagnosing, disclosed for completeness. A latent bug in the wallet monitor’s subscription bookkeeping could, under the right collision, have attributed one wallet’s trades to another or dropped a wallet’s stream silently; it has been closed, and unmapped events now log loudly instead of vanishing. Separately, a change made during this diagnosis to capture the rejection detail introduced a crash that took the wallet monitor down for several minutes and stopped its heartbeat with it — briefly making the outage less visible on this site rather than more. It was fixed the same hour, and the process now survives socket-layer errors instead of exiting on them. What this entry does not fix. Our telemetry worked. The status page showed DEGRADED, refused to claim uptime it could not verify, and correctly separated process health from feed health — a running process never masked a dead feed. What failed is that nobody looked for five days. The instrumentation reports honestly to anyone who visits the page; it does not tell us. That gap is the real finding here, and no commitment is being made about it in this entry. When one is, it will be logged as its own entry with a date attached. STATUS · Outage 22–27 Jul · Feed restored 2026-07-27 · Freshness gate live on both tiers · 190 stale convergences alerted · Provider cause unexplained ---------------------------------------------------------------------- ENTRY #017 DATE: 2026-07-28 STATUS: DISCLOSURE More than half of every alert we have ever sent was a duplicate of one sent minutes earlier Auditing our own database after the outage, we measured what we had actually been sending. Over a normal, healthy eight-day period — 15 to 22 July — Dossier sent 7,825 alerts covering 2,113 distinct tokens. 4,238 of those messages repeated a token already alerted within the previous five minutes. That is roughly 978 messages a day, over half of them re-sends of a call already delivered. This was not caused by the outage. It has been happening in normal operation for the entire beta, to every operator. Cause. Every convergence is stored with a uniqueness key of token, wallet set and first-buy time, which is supposed to make a repeat impossible. The detector rescans every sixty seconds across a rolling window; as that window slides forward, the earliest qualifying buy changes, which changes the key, which reads as a brand-new convergence. The premium handler tier already carried a six-hour cooldown per token that suppressed this. The main tier had no cooldown at all. The protection existed and had simply never been applied where most of the volume was. Against our own description. This site says “one signal when curated wallets independently move on the same token in a tight window. Convergence, not a feed.” A thousand messages a day, half of them repeats, is a feed. The claim was not aspirational marketing that ran ahead of the build — it was a straightforward description of what we believed the system did, and we had never checked. Fix. The handler tier’s cooldown has been ported to the main detector: one alert per token per six-hour window, regardless of how many times a scan re-finds it. The convergence row is still recorded, so detection history stays complete — only the duplicate message is suppressed, and the scan log now reports how many were held back. Alert volume fell roughly 74% with no change whatsoever to what is detected. Deployed and verified live on 2026-07-28. Every operator in the beta experienced this. If Dossier felt noisy to you, it was, and the reason was ours. Nobody reported it, which is worth noting: we found this by auditing our own database rather than by being told, and a system that only reveals its faults when someone complains will keep faults that nobody bothers to complain about. STATUS · Chronic since beta start · Fixed and deployed 2026-07-28 · Alert volume down ~74% · Detection unchanged ---------------------------------------------------------------------- ENTRY #018 DATE: 2026-07-28 STATUS: DISCLOSURE Our published 6-hour convergence window is about thirty-six times wider than the events it catches. We picked it by intuition and never checked. Dossier has always described itself as detecting wallets that bought the same token “within the same 6-hour window”. While auditing the alert stream we measured, for the first time, how long our convergences actually take. Across 9,723 convergences over fourteen days: Median span 4.2 minutes. Seventy percent complete within fifteen minutes. Eighty-three percent within an hour. The ninety-ninth percentile is 315 minutes — which is to say our published window was calibrated, accidentally, to the outermost one percent of events. Real convergences in our cohort are near-simultaneous. That fits what one would expect: wallets reacting to the same trigger within minutes, not independently arriving at the same token over an afternoon. The extra five hours and fifty minutes were not catching additional signal. They were admitting coincidence, and coincidence is precisely what this product claims to filter out. A related measurement. Above a three-wallet threshold the window stops mattering almost entirely — three wallets agreeing inside fifteen minutes and three agreeing inside a full hour differ by about three events a day out of eighty-four. Three wallets agreeing is intrinsically near-simultaneous. The wallet threshold, not the window, is what actually governs how selective the product is, and we had the loosest possible setting on it. No change has been made yet, deliberately. Altering the window or the wallet threshold changes the published definition of the product, and our practice is to publish a specification for comment before shipping a change of that kind rather than quietly adjusting a constant and updating the copy afterwards. That specification is being written. Until it is published and this entry is superseded, the site continues to describe the 6-hour window because that is what the system currently does. The transferable lesson, since this log is meant to be useful. The 6-hour figure was chosen early, by judgement, and then repeated in every description of the product for months without anyone running a single query against it. It was not wrong through carelessness in the code. It was wrong because it was never measured. If you are building something that filters, measure the width of your filter against the thing you are filtering for, and do it before you write it on your homepage. STATUS · Measured 2026-07-28 · Median span 4.2 min vs 6h published · Specification pending · No change shipped yet ----------------------------------------------------------------------