DOSSIER // CLASSIFIED // CORRECTIONS LOG // EVERY COMMITMENT TRACKED PUBLICLY // NEVER DELETED // A GALACTIC FEDERATION INTELLIGENCE OPERATION // DOSSIER // CLASSIFIED // CORRECTIONS LOG // EVERY COMMITMENT TRACKED PUBLICLY // NEVER DELETED // A GALACTIC FEDERATION INTELLIGENCE OPERATION //
⬡ FEDERATION DOCTRINE · CORRECTIONS
#001
IN PROGRESS

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
#002
IN PROGRESS

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
#003
SCHEDULED

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
#004
SCHEDULED

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
#005
ACTIVE COMMITMENT

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
#006
ACTIVE COMMITMENT

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
#007
MISSED

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
#008
MISSED

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
#009
SCHEDULED

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
#010
SHIPPED

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
#011
ACTIVE

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
▾ STATUS LEGEND
ACTIVEStanding commitment
IN PROGRESSCurrently executing
SCHEDULEDTarget date set
SHIPPEDDelivered, verifiable
MISSEDDeadline failed · correction logged
⬡ DOSSIER · A GALACTIC FEDERATION INTELLIGENCE OPERATION · RETURN TO BRIEFING