About
How signals are picked
Where signals come from, how editors pick them, how priority is set, and what the site stores and what it does not.
Every signal here has been through an editor; anything that has not is labelled where it appears. This page follows a piece of news in the order it enters the site. The site itself is written in Chinese; this English edition translates the interface, not the content.
Where signals come from
Signals come from a fixed set of outside sources, of four kinds:
- RSS
- Atom
- GitHub Release
- Official blog pages
They are imported once a day. A new item first enters the candidate pool; at that point it is not a signal yet.
The publisher is the organisation behind an announcement — big tech, startup, research lab, open-source community or media — and the source is the feed it came through. Every signal page names the publisher type, so you can tell a vendor announcement from an open-source release or a research result.
All publishers and sources →Pre-release versions (version numbers with rc, beta and the like), an announcement the site has already published, and “hacked by …” titles left by defaced web pages. These three are rejected automatically; every other candidate waits for an editor. An item with a title and no summary is not rejected automatically.
How editors pick
Deduplicate. When the same news arrives from several sources, the editor picks one as the main entry and hangs the rest under it as further sources.
Draft. Candidates worth publishing become drafts; the rest are marked as seen or rejected.
Explain. The editor writes why it matters, who should care, what background it needs and how to learn more, and links it to the related skills and knowledge.
Check. A missing title, summary, body, source link or date blocks publication until it is fixed; too few links or incomplete explanations are warnings — it can be published, but the editor has to see them.
Publish. Once the checks pass it becomes a signal. Briefings are generated from published signals, adjusted by an editor, then published.
In the editors’ workspace a model suggests what to do with each candidate (publish, mark as seen, or reject). It only suggests; it never changes a candidate’s state, and the editor decides.
Priority bands
The editor marks each signal critical, important or signal. That decides the band; time since publication can only move a signal down, never up.
- Critical: always in this band
- Important: for 30 days after publication
The first part of a briefing.
- Important: once 30 days have passed
- Signal: always in this band
The second part of a briefing.
- No summary or body, or an invalid source link or date
Lands here whatever its importance; briefings leave it out by default.
When the record itself has a serious problem, it goes no higher than Worth tracking, even if marked critical.
The bands do not come from a combined score, and they are the same for every reader. An earlier version banded signals by how complete their records were; measured, it put all 31 signals in the same band, so it was replaced by the rules above.
“Following” only filters by the topics you follow and says which topic matched. It does not change the band, or the order anyone else sees.
Why the news is “gathered automatically, not picked by an editor”
All news shows the candidates imported in the last 7 days, with only a title, a shortened summary, the source, the date and topic tags. No editor has picked them, so every place they appear says so.
Rejected items, placeholders from failed imports and the secondary copies of duplicates are left out. Candidates no editor has handled yet do appear, until an editor handles them. So the mix of sources in the news follows how often each one publishes, not how good it is: before an editor gets to them, daily media outlets make up most of it.
News items already published as signals link to the signal page. Curated signals and briefings contain only what editors published.
Eight relations between signals, skills and knowledge
The site holds three kinds of entry: a signal is something new that happened, a skill is an ability that helps you evaluate and use new technology, and knowledge is a lasting concept you need to understand them. Every relation between entries carries a type and a note saying why they are connected.
Grew out of the other; built on top of it.
Makes use of the other.
Explains what the other is, or why it works that way.
You need the other before this one. The only one of the eight with a direction; the “Read these first” list on skill and knowledge pages is built from it.
Read on from this one.
A later release of the same product line. A signal page’s release line is built from it alone.
Gives evidence for the other.
Related, but none of the above. About 5% of all relations.
Every AI feature is marked “not reviewed”
Compare two technologies
On a signal page, pick another published signal and get what they share, how they differ and when to use each.
Explain at your level
Pick beginner, intermediate or advanced and get an explanation at that depth.
Learning path
Using the skills and knowledge linked to the signal as material, it drafts learning steps and self-checks.
Ask the radar
Answers only from the site’s published signals, skills and knowledge, citing each claim; when the site has nothing relevant, the answer says so first.
A model writes these on the spot, without an editor’s review, and the result always carries “AI-generated, not reviewed by an editor, for reference only”. The first three are cached, so the same request is not generated twice. The answers are written in Chinese.
“Similar meaning” in search and “Similar signals” on a signal page use a vector model that runs on the server itself and calls no outside service; the latter is marked “matched by content, not picked by an editor”. Bands, briefings and news are not decided by AI.
Ask the radar →What the site stores, and what it does not
- There are no accounts and nothing to sign in to.
- The topics you follow, what you have read or saved for later, which signals you had seen on your last visit (for the “New” stamps), the light or dark theme and the shortcut switch are kept only in your browser’s local storage; the server does not know them. The one exception is the new-signal alert below, and only if you turn it on.
- “Close to what you read” on the home page and under Read later is worked out in your browser; the read and saved marks and followed topics it uses are not sent to the server for it (followed topics reach the server only if you turn on alerts, see the note below). Once you have marks, the browser downloads one recommendation file that is the same for everyone — the published signals’ vectors and public card fields. The request carries none of your marks; it only says that this browser has some reading history.
- For each signal you save for later, this browser keeps a copy of the page so it opens offline. To find those pages it downloads a list of every published signal’s address, the same for everyone, so the server does not learn which ones you saved.
- To move to another device, carry your follows and reading marks over with a follow code or reading code; both are exported and imported entirely in the browser.
- Everyone gets the same pages; any personalisation happens in your browser.
Alerts are off by default. When you turn them on under “Following”, the server stores one record: the push address your browser’s push service gave this browser (Chrome and Edge use Google’s, Firefox uses Mozilla’s, Safari uses Apple’s), two keys used to encrypt notifications, the topics you follow, and when it was created. It does not store your address, your browser model, or anything about what you read. If you later change your followed topics on any page, the record’s topics change with them.
Notifications are encrypted on the server and delivered to your browser through the push service, which cannot read them and only knows that a message went to this browser. Alerts go out only when an editor sends them by hand, and each signal is sent once.
To delete it: turn alerts off under “Following”, or unfollow every topic, and the record is deleted on the server at once. If you revoke the site’s notification permission in your browser settings, the push service tells the server on the next send that the address is gone, and the record is deleted then. The data on this machine is backed up once a day and the newest 14 backups are kept, so a backup taken before you turned alerts off still holds the record until it is replaced, usually about 14 days.
The questions you type into Ask the radar, and the comparisons, explanations and learning paths you request on a signal page, go to the server and on to the model provider that generates the answer. The site does not keep your questions.
To limit how often requests can be made, the server counts them per address in process memory; nothing is written to a file, and a restart clears it.
The whole site is served through Cloudflare, which sees your address.