Suppose a user reviews NVDA at 8:00 AM, reads three stories, opens one SEC filing, and returns at 2:00 PM. A conventional feed can simply show the latest page again. The user must mentally reconstruct what was already there.
“Since I last checked” changes the unit of value. Instead of another feed, the product answers a narrower question: which evidence items in the current result have not been seen by this device before?
The local checkpoint
The current implementation stores one encrypted checkpoint per ticker in the same device-local IndexedDB environment used by Ticker Watch. The checkpoint contains the ticker, the time of the successful check, and identifiers for evidence already seen.
The checkpoint is encrypted with AES-GCM using the existing device-local Ticker Watch key. The billing service does not receive the checkpoint. The public market gateway does not receive the checkpoint. Billing is asked only whether the account has the entitlement for the feature.
Evidence identity matters
A delta feature is only as good as its idea of identity. If the same story is represented differently on every request, the product will repeatedly tell the user that an old story is new.
Ticker Watch prefers a stable HTTPS source URL when available. When a source URL is unavailable, it falls back to normalized descriptive material such as title and date. News items and SEC filings use separate namespaces so a filing and an article cannot collide merely because they have similar text.
This is intentionally pragmatic rather than magical. News providers can republish, rewrite, or change URLs. A robust production research-memory layer should continue improving canonicalization and provider-specific identity handling as source coverage grows.
Why remember keys instead of full articles?
The local checkpoint does not need to become a duplicate archive of every article body. For the purpose of deciding “seen before or not,” compact evidence keys are enough. The current design caps remembered keys per ticker to avoid unbounded local growth.
| Checkpoint field | Purpose | Where readable |
|---|---|---|
| Ticker | Scopes the checkpoint | Trusted browser while decrypted |
| checkedAt | Explains the comparison point | Trusted browser while decrypted |
| Seen news keys | Prevent old stories from being re-labeled as new | Trusted browser while decrypted |
| Seen filing keys | Track newly surfaced SEC evidence separately | Trusted browser while decrypted |
Entitlement is separate from memory
One architectural temptation is to store premium state in the same backend that verifies subscriptions. We deliberately separate those concerns. The account service can answer, “Is this feature enabled?” without becoming the owner of the research checkpoint.
That gives us a cleaner privacy boundary:
- Billing service: identity, subscription state, entitlement.
- Market gateway: selected ticker and public evidence retrieval.
- Trusted browser: encrypted checkpoint and delta comparison.
This separation also limits the consequences of a compromise. A billing database should not automatically become a detailed record of the companies a user repeatedly checks.
Why device-local first?
Cross-device continuity sounds obviously better, but it introduces hard questions: which device checkpoint wins, how are concurrent updates merged, how are research-memory keys transferred, and how do we preserve the rule that the relay should not read them?
The first version therefore makes a conservative promise: the checkpoint is private to this device. If the user checks NVDA on a laptop and later opens a phone, those devices currently maintain separate “last checked” histories.
That limitation is visible in the product rather than hidden. We would rather ship a smaller privacy boundary we can explain than imply cross-device continuity before the cryptographic and conflict semantics are ready.
Failure modes we care about
Provider churn
A source may alter URLs or article metadata. That can cause a previously read item to appear new. Canonical source identity is an ongoing engineering problem.
Incomplete current evidence
“No new items” means no unseen items in the evidence currently returned. It does not prove that nothing happened anywhere in the market.
Compromised endpoint
AES-GCM protects stored checkpoint data from a relay or casual storage inspection. It does not protect against malware or a hostile extension observing the checkpoint after the trusted browser decrypts it.
Baseline reset
If the local checkpoint is deleted, corrupted, or intentionally reset, the next successful check becomes a new baseline. The system should not silently reconstruct history it no longer has.
Why this is a paid feature
We want the underlying evidence to remain useful in the free product. The user can still load a ticker, inspect news, open SEC filings, follow sources, and generate single-ticker audio. What Plus adds here is continuity: the software remembers the research work already completed and reduces repeated reading.
That is a healthier monetization boundary than withholding the primary source itself.
What this means for investors
The user benefit is simple: after a baseline exists, a refresh can focus attention on newly surfaced evidence. Instead of asking, “Which of these seven cards did I already read?” the product can say, “Two stories and one filing are new to this device’s research memory.”
Next: interpretation without prediction
Once the product knows which evidence is new, the next problem is prioritization. Not every headline matters equally, but ranking evidence creates a dangerous temptation to turn research context into a stock-price prediction. The next article explains the boundary.