Feature request : First-class atom expiry: valid_until field, expired-atoms view, optional surfacing notification

[Sainin701]

Problem :

Knowledge doesn't age uniformly. Some atoms are eternal (biology basics,
durable frameworks). Others decay fast (platform-specific tactics,
time-bound market conditions, current events). There's no way to tell
Atomic "this atom is only valid until X date" and have the app do
anything with that information.

Example use case :

In fast-moving domains (performance marketing platform tactics, crypto
market conditions, current health research), I capture content that's
valid for a quarter or less. Today I tag these atoms with
valid-until/2026-06-22 as a convention, but:

• The app doesn't surface atoms whose expiry has passed
• I can't filter "show me all expired atoms"
• Nothing reminds me to review and refresh or archive

So my chat confidently cites a 2023 platform tactic as current
advice in 2026.

Proposal

Add an optional valid_until field on atoms (date, or auto-parsed from
a valid-until/YYYY-MM-DD tag for backward compat). Then:

1. An "Expiring soon / expired" view in the sidebar (atoms past
   valid_until, or within N days of it)
2. A filter on search/chat scope: valid_until:not-expired
3. Optional: include expired atoms in the daily briefing as a
   "needs review" section

[hiSandog]

How should expiry interact with synchronization when clients have clock skew or remain offline past valid_until? A useful design test would create, update, and delete an atom around the expiry boundary from two clients and verify the expired view converges deterministically. It would also help to clarify whether expiry is a visibility rule or a state transition persisted in history.

[Sainin701]

@hiSandog

I think it mostly goes away if expiry is a pure visibility rule, not a state transition. Nothing gets written at the boundary, valid_until is just a stored date, and “expired” is computed at query time (valid_until < now), so the expired view is just a filter.

So there’s nothing to converge, no client ever writes anything when an atom expires. Clock skew only shifts when an atom appears in the view by a few seconds, which is noise for expiry granularity measured in days. Offline clients just evaluate the filter locally and there’s no conflicting write to reconcile when they come back.

The only place a clock matters is the briefing section, and that’s server-generated anyway.