romain-nicod Weekly watch
A briefing that a busy reader can act on. One PDF, no more than a page or two, where every item earns its place by changing what the reader should build, buy, or stop planning.
The discipline that makes it worth reading is subtractive: most of what happens in a week does not qualify, and the value is in what gets dropped.
Step 0: establish the watch
Ask before the first run, and store the answers in the corrections log at the bottom of this file so they are not asked again.
- What is the watch about? The market, technology or industry being followed.
- Who reads it, and in what capacity? This is the question that decides everything else. A person piloting a product, a person buying capacity, a person regulating a sector and a person writing code want four incompatible briefings. Name the capacity explicitly, and name the ones it is not.
- What are the standing sections? Two to four themes, in a fixed order, so the reader learns where to look.
- Where should the file go, and under what name?
- Any house style? Fonts, an accent colour, British or American English. Otherwise the document stays plain.
If the reader's capacity is not clear, ask again rather than guessing. Every wrong framing of this watch has come from assuming the reader wanted technique when they wanted market movement, or the reverse.
The materiality test
Apply it before the verification gate, because it drops more.
An item earns its place only if it moves a market position. Ask, in order:
- Does it shift what is possible to build, or what no longer needs building because someone now supplies it?
- Does it shift who supplies a layer of the stack, or where value is moving between layers?
- Does it change the cost, the licence, the jurisdiction or the dependency structure of a component a team would otherwise take for granted?
If all three answers are no, the item is out, however well sourced and however recent.
The default exclusions. These were each learned by publishing them once and watching them land flat. They hold unless the reader's capacity from step 0 makes one of them material.
- Nightly or per-commit builds of any project.
- Benchmark deltas, throughput and latency claims.
- Technique whose only result is a better number.
- Hardware. The component rarely changes a roadmap; the licence and the jurisdiction do.
- Regulation and supervisory expectation, unless the reader's capacity is regulatory.
- Minor releases from suppliers with no market position.
- Anything whose only interest is that it happened this week.
- Anything already widely circulated before the window. If it has been doing the rounds for a week, it is stale.
Reliably in scope, for most readers:
- A leading product changing licence, price or availability.
- A platform absorbing a layer teams used to build themselves.
- A supplier opening its platform to a rival, or a new entrant taking a layer.
- A structural constraint lifting or landing: retention, residency, licensing, export, supply.
- A change in how a major surface is funded or distributed.
The verification gate
No unverified content, ever. There is no "reported" or "unconfirmed" category in the document.
An item appears only if BOTH hold:
- An official primary source is confirmed live during this run: the actor's own release, blog, product page, documentation, changelog or repository release page. Aggregators and trade press are discovery tools, never the cited source.
- Its publication date is confirmed from that same official source. A date from secondary coverage does not qualify.
If either fails, the item is dropped without appearing anywhere in the document. Dropped candidates belong in the run summary, with the reason.
Never restate a supplier's claim as fact: attribute it. Never assert a characterisation the source does not make.
Window and carry-over
Default window: the seven days ending on the run day.
A verified item published before the window may be carried over if it is materially relevant and was under-covered. Show its true publication date and label it a carry-over. Rank by materiality rather than recency: a structural item from the prior week outranks a small item from inside the window. An item that was already widely covered is stale and stays out.
Harvest
Pass 1, press surfaces. The reader's curated source list, over the window.
Pass 1b, product surfaces, every run. Structural changes often ship quietly, outside press blogs. Check dated, non-press pages: release notes and "what's new" feeds, API and documentation changelogs, official repository release pages. High noise per unit of signal, so filter everything found here through the materiality test.
Pass 2, one light search per section. Catches new entrants. Still subject to both gates.
Then merge and deduplicate. One entry per announcement.
Per-item format
- A bold headline: date, actor, what.
- Exactly two sentences. The first says what was announced. The second says what it changes for the reader: what becomes buildable, what stops being worth building, which dependency or cost moves, which supplier position shifts.
- One official link. Two only when the announcement and its dated evidence sit on different official pages.
The second sentence is where the watch earns its keep. If it restates the first in other words, or only says the thing is interesting, rewrite it.
The document
- Title: the watch name and the week.
- First line: the week's single signal, one sentence, framed as a market movement. Look for the tension or the contrast in the week rather than writing a flat summary.
- The standing sections from step 0, in their fixed order, most material item first within each. Omit a section that has no qualifying item.
- Footer: the harvest window, the item count, any carry-over, and a line stating that every item was selected for its effect on a market position and drawn from an official primary source with a confirmed date. Check that the count matches the number of items.
- Save the file where the user asked in step 0, versioned, never overwriting a previous run. Give the path when done.
Run summary, in the conversation only
- Item count per section.
- What was checked for each standing section, naming the surfaces, so a gap is visible rather than silent.
- Candidates dropped, with the reason: failed materiality, failed verification, out of window, or stale.
- Judgement calls made without asking.
Corrections log
Every correction the reader gives goes here, in their words, on the run it is given. The point of the log is that they never have to repeat themselves, and a new correction that contradicts an old one replaces it rather than sitting beside it.
Start it empty. It fills up faster than expected, and after four or five runs it is the most valuable part of this file.
Frugality
Pass 1 is bounded by the source list, pass 1b by the entry points, pass 2 by one light search per section. Fetch a full page when it is needed to confirm a link, a date or a claim: date confirmation is never optional.
An honest light week is a light briefing. Padding a thin week is how a watch loses its reader.