Advice Has a Timestamp

An option derived from a network snapshot decays as the network or the intent changes. Options should remember the state they came from, say when they need re-evaluation, and never overwrite what was advised before.

Wellzai2 min read

"This route is no longer preferred because its financing assumption is no longer supported."

That sentence appears in Wellzai's Intent Path model as an example of what an interface should be able to say. It is modest, and it carries an idea most software ignores: advice is derived from a particular state of the world, and it ages.

In Wellzai's exploration design, an outcome option is derived from a network snapshot, so it has freshness. Every discovery run records the state it ran against: a checkpoint, the identities and revisions it saw, the time and the query. If the network moves materially beyond that point, the exploration can be marked as needing re-evaluation. If the person changes what they want, everything derived from the old intent, from the desired outcome and its requirements to the gap assessment and the options, is invalidated or flagged rather than quietly left in place. New evidence, a candidate that disappears, a new constraint or new timing can all invalidate a strategy. And nothing is overwritten. A new exploration becomes a new run linked to the old one, so the earlier advice stays available to explain what changed.

The implication is that an option should carry its own conditions of validity, the way a measurement carries its date. Reordering a list without explanation is not honest about change; naming the assumption that failed is.

These are specifications for Wellzai's exploration and path reasoning, not yet a running system, and they do not settle the deeper question either. Some advice may decay in hours; some may hold for a season. How long is a piece of advice good for? Should a system decide when advice expires, or only notice when the facts it rested on have moved?