A drift scan is a work queue with a timestamp, not an inventory of current state

Claim

Never source a "what is stale" list from a prior drift report. Re-derive it from the newest verdict-bearing report per ticker, at the moment you need it.

What happened

Output/Portfolio/thesis-drift-2026-09-16.md listed 14 fired-trigger names and closed with:

Next: /analyze-from-before on the held + fired names, oldest first — FISV, NLCP, PANW, CRWD, DOCU.

That queue was then worked the same day. FISV, NLCP, PANW, CRWD and DOCU all have reports dated 2026-09-16. The drift scan did its job perfectly.

A portfolio-specific passage was removed from the public build.

Ticker	Reported	Actual (2026-09-16)
PANW	WATCH [6.5], unrefreshed	WATCH [7.0] — upgraded; CyberArk dilution drag reversed, FY26 FCF/share $5.38 vs $4.65 est
DOCU	HOLD [6.0], unrefreshed	HOLD [6.5] — upgraded; IAM hit 15.1% of ARR, clearing its own named ≥15% upgrade test

Why it is a trap rather than mere carelessness

The inversion is the point: a drift report is most misleading about the names that were handled fastest. A name flagged on the 16th and analysed on the 16th looks identically stale in that file to one flagged on the 16th and still untouched. The document has no way to record its own resolution, because it was written before the resolution existed.

It also feels like a legitimate source — it is a generated report, recently dated, in Output/, about exactly this question. Every heuristic for "is this a good source" passes.

The rule

1. Fired-trigger and staleness state is derived, never stored. Compute it at read time from the newest verdict-bearing report per ticker (kb.py find <TICKER> returns reports newest-first for exactly this reason).
2. Treat /thesis-drift output as a to-do list. Its value expires the moment its queue is worked. When citing one, cite it as "the queue as of DATE" and check what has been done since.
3. The tell is an unexplained upgrade. If a name is supposedly stale but its numbers look better than the file you are holding, you are probably holding a superseded file.
4. Same failure family as [[pitfall-kb-find-never-searched-the-reports]] — the current state existed under Output/, and the report was written without consulting it.

What would falsify this

A drift report that records resolution status per row (e.g. re-reading the ticker's newest report at render time and marking rows resolved). That would make the document safe to cite later — and is the obvious fix if this recurs. Until then the rule stands.

History

A portfolio-specific passage was removed from the public build.