What Gets Published, and When

NightWatch does not wait for you to come looking. Every day, on a fixed schedule, it writes things down and sends them out: a batch of research reports, three editorial briefs written in different market voices, and a short public post about how its own paper fund did overnight. This chapter explains where each of those comes from, what triggers it, and, just as important, what happens on the days the pipeline cannot produce a trustworthy number.

The short version: almost everything in this chapter runs on a timer, is written by a template rather than a language model, and is built to fail silently instead of publishing something wrong. If you remember one rule from this chapter, remember that one: on NightWatch, "no post today" is a designed outcome, not a bug.

The morning research pipeline

Every day the platform runs a full exchange scan at 09:00 KST. The morning research pipeline runs as part of a long-running daily marketing job: once the clock reaches the scheduled hour (09:00 KST), it kicks off the day's report run. When that moment arrives, it first waits up to 30 minutes for the morning scan to look fresh, and if the freshness check still fails after that window, it goes ahead anyway and works with whatever data it has rather than skipping the day entirely.

How many tokens get a report each day is controlled by a configurable target, currently set to 10, with a stated intent to scale that up to 20 over time. (A couple of other numbers exist elsewhere that are easy to confuse with the live target - an internal default of 20, and a manual, run-by-hand version of the same job that defaults to 30 - neither of those is what runs on the daily schedule.) So on a normal day, expect around ten reports, not thirty, with the ceiling controlled by that one setting.

Selection normally comes from something called the priority pool: a list of tokens already staged earlier in the day, ranked by a SQL query that scores each candidate by exchange count (times 10), whether it has a verified chain and contract address (plus 20), each social channel it has on Telegram, Twitter, or Discord (plus 5 each), and whether its data is fresher than 60 minutes old (plus 10). The top N by that score become the day's targets.

Only if that priority pool comes back completely empty does the pipeline fall back to a second selector, which scores tokens on a related but not identical formula:

(Note the on-chain weight is +20 in the priority-pool query above but +10 in this fallback selector; the two paths do not use identical math, which is worth knowing if you ever try to reconcile which score produced which pick.)

This fallback selector also draws from seven separate signal categories, each with its own hardcoded quota capping how many tokens from that category can be picked in a single run: grade change (quota 8), spread spike (5), depth crash (5), new entry (4), new exit (4), divergence (2), and high risk (2).

• Grade change scores as the size of the grade move (times 10) plus the token's 7-day average grade, so a big swing on a previously well-covered token ranks highest.
• Spread spike rewards a wide current spread combined with a low 7-day grade.
• Depth crash rewards a thin current order book combined with a low 7-day grade.
• New entry is a flat, high priority score (100) for tokens newly appearing on the platform's radar.
• New exit, divergence, and high risk each carry their own scoring logic and quota slot as well.

The point of walking through both formulas is this: which tokens get a report on a given day is not a person's editorial call made fresh each morning, it is arithmetic over data the platform already has, plus a fixed quota allocation someone set once in the code. That quota split (8 grade-change slots, 5 spread-spike slots, and so on) is itself a form of editorial choice, just one made in advance and baked into the code rather than decided fresh each day.

For each selected token, the pipeline generates:

• A Research V2 report, which does include charts (this is the deeper analyst-grade version, see the Cherry Store pricing for it below)
• A thumbnail image
• An archived database row, so the reports API can serve the report later. (A separate, older report renderer - V1 - still exists and is reachable on request from the reports API, though the morning pipeline itself only uses that older module for this archiving step, not for rendering.)
• A manifest file listing everything that was produced, which the distribution step reads next

What you'd notice if you looked for it: manifest generation and report generation are separate steps from distribution. If distribution fails, the reports still exist, they just have not been pushed anywhere yet.

Bulletin distribution: one live leg, three stubs

The distribution step reads the morning manifest and is built to be channel-agnostic: it is structured to fan a report out to Telegram, Twitter, Discord, and Medium alike, logging the outcome of each attempt.

In the running system today, only the Telegram leg is live. Twitter, Discord, and Medium distribution are not in this version. The underlying distribution step is already built to be channel-agnostic, so turning these on would not need new distribution code - what's missing is credential and account setup on each platform, which is why this is the smallest kind of gap: the plumbing exists, the taps are not connected.

If you are a partner or community manager expecting your token's community channel to get an automatic post on Twitter today, it will not. Only a Telegram-connected community channel receives the automated report and thumbnail right now.

Report Gallery and Report Viewer

Once reports exist, two pages let a human browse and open them:

• Report Gallery (/research/gallery) is a grid across nine exchanges: thumbnail, exchange/symbol, page count, language, and date. If nothing has been generated yet for the day, the empty state tells you to check back after the morning cycle. It does not show a fake placeholder grid.
• Report Viewer (/report/[id]) is the single-report page. It builds its own OpenGraph and Twitter card metadata dynamically from the report's actual grade, spread, depth, and volume numbers, so if you paste a report link into a chat app or social post, the preview card that renders shows real figures, not a generic site logo.

The curator desks: Haru, Andy, and EJ

Three named "desks" post a daily brief each, and all three are built the same way on purpose: a shared 4-beat structure (what happened, desk read, market structure, where to look next), composed entirely from live API pulls with zero calls to a language model. That is a deliberate cost-and-reliability decision, not a missing feature. A template that reads real numbers cannot hallucinate, and it costs nothing per run.

Two details worth knowing if you rely on these:

• The internal name is not the display name. Haru's Read is still stored under its original name from before the rename. The display name changed from "Liam" to "Haru" on 2026-07-21, but the underlying tables and files were never renamed, for stability. If you ever see "Liam" in a log line or a database table, that is Haru.
• EJ's sparkline resolution is approximate. The brief documents its own chart resolution as roughly 40 points per 24 hours and labels it as approximate rather than exact, a small, honestly disclosed limitation rather than a hidden one.

There was also a one-off: Haru's Read No. 1, a hand-written editorial (nicknamed internally after a market event) that overwrote the auto-composed brief for one specific date and posted a compact version to the public channel. It is marked legacy, a single publish rather than a recurring feature, and it is safe to re-run by date, but re-running it will re-post to Telegram unless that repost is specifically suppressed for the rerun.

Thusus Editorial Notes are a smaller, separate thing: a short set of notes written in Thusus's own voice (evidence-first, English). Updating a note always overwrites the previous text, so if the wording of a Thusus note changes, the old wording is not kept as history anywhere.

"NightWatch Live": the public channel

There is one public, outbound-only Telegram channel (internal chat ID -1003923634408) called NightWatch Live. No user interaction happens there; nobody replies to it, and nothing there is a support channel. It exists purely to receive two automated daily posts:

1. The daily paper-fund summary (posted 00:40 UTC): a plain-English recap of the Thusus paper-trading book's previous UTC day, a "day N" counter, yesterday's result, and all-time trade count/win-rate/total, with a link to the dashboard. This number is pulled live from GET /arb/thusus/book; nothing is precomputed by hand.
2. Haru's Read, cross-posted to the same channel on days that cross-post is enabled.

A rule worth internalizing: this is paper money, not your money. The daily post explicitly documents itself as reporting the simulated fund's results, not real capital. Do not read a good day on this channel as proof about anyone's real trading account.

The safety contract: silence over a wrong number

Both the daily channel post and Haru's Read are built so that any fetch failure, missing API token, or malformed data causes the post to be silently skipped rather than publish an empty or incorrect figure. "No post today" is expected behavior on a bad data day, not something that needs an incident report. If you notice NightWatch Live went quiet for a morning, the most likely explanation is that an upstream number looked wrong and the publisher correctly refused to guess.

On top of that automatic safety behavior, NightWatch staff also have a manual override: the daily channel post can be paused entirely, or run in a test mode that doesn't actually send to Telegram, without any code change.

Two Telegram bots, not one

A point worth flagging clearly is that NightWatch's alert system and its trading mini app are two separate Telegram integrations, and linking one does not link the other:

The alert bot and the trading mini app bot are two separate Telegram integrations; linking your account for grade-drop alerts does not also connect the trading mini app. To set up alerts, open /alerts - the page generates a one-time deep link and polls until your account shows as linked. If you've linked your Telegram account there expecting the trading mini app to also light up, that is not how these two flows relate: the mini app is opened separately, from its own chat menu inside Telegram.

Separately, note that even once you open the mini app's Markets, Positions, and Account tabs, order placement inside it is not in this version; planned for v1.1: you can browse the tabs, but orders do not go through yet. Chapter 5 (the account and wallet chapter) carries the fuller detail on this.

Observatory: the standing instrument decks

Separate from the daily-post cadence, three "Observatory" instance pages sit behind the curator desks as always-available instrument panels rather than one-off posts:

• Observatory: 24/7 Stocks and RWA (/observatory/24-7) is a market-clock view walking through Seoul, Taipei, Hong Kong, and New York, plus a live band of tokenized-rail prices (Samsung, SK Hynix, an EWY-tracking instrument) from an isolated data lane. Its own instance cards are honestly mixed in status: Tokenized Semiconductors is live, Tokenized AI is live-partial, and several others are labeled PLANNED directly on the card. Do not assume every card on this page trades; read the label on each one.
• Observatory: Semiconductors (/observatory/semiconductors) is the dedicated view of Samsung and SK Hynix trading as 24-hour perpetuals offshore ("night price"), plus a rail survey and pre-IPO section, layered with Haru's Read editorial voice.
• Observatory: Frontier desk (/observatory/frontier) has sections for AI Labs, Pre-IPO names, China-listed names, and "Big Scalers" (for example pre-IPO perps for names like OpenAI, SpaceX, and Anthropic on a partner venue, and a China chip name on HyperLiquid). This page currently has no dedicated curator or brief of its own; it is content without a home-page tab yet.

The embeddable liquidity widget

/embed/liquidity is a small (420 by 160 pixel), iframe-embeddable widget that a partner site can drop in to show live NightWatch liquidity data for one exchange/symbol pair. It takes exchange, symbol, theme, and pollMs as query parameters. This is the retail-sized version of the same publishing instinct as everything above: rather than making a partner build against the API from scratch, NightWatch hands them a page they can iframe. Chapter 18 covers the commercial side of who is expected to use this and how it connects to the partner program.

What you can do now

• Browse today's reports at /research/gallery. If it's empty, the morning cycle (09:00 KST scan, then report generation) may not have finished yet.
• Open a specific report at /report/[id]. The shared link will preview correctly with real grade/spread/depth numbers if you paste it elsewhere.
• Read the daily curator briefs on /observatory. Haru (cross-venue premium), Andy (tokenized semiconductors), and EJ (24/7 RWA) each post once a day.
• Connect the alert bot at /alerts if you want a DM the moment a tracked token's grade drops sharply. Remember this is a separate flow from the trading mini app, not the same login.
• Check the Observatory instance cards' status labels before assuming a market is tradeable. Several are marked PLANNED on the page itself.
• Do not expect your token's community to get an automatic Twitter, Discord, or Medium post yet. That's not in this version - only the Telegram distribution leg is live today.
• If NightWatch Live goes quiet for a day, that is not necessarily a problem. It may mean the publisher correctly declined to post a number it could not verify.