Signal freshness (TTL)

Signal freshness is the age of an identity signal at the moment it is used, and it often matters more than the signal's strength. A SIM-swap check performed during the request proves the line's current state; the same check from last night's batch file proves only what was true last night.

Freshness is expressed as a time-to-live: past the TTL, a signal should degrade to a no-answer rather than a weak yes. Systems that treat stale signals as valid quietly convert their strongest control into a false assurance.

A TTL is a policy statement, not a technical constant, and it should be derived from how fast the underlying fact can change. A SIM can change in minutes, so a swap check answered from last night's batch describes a world that may no longer exist; a credential's presence in a breach corpus changes on the timescale of publication, so a day-old answer is fine. Systems that apply one cache lifetime across every signal type are choosing a number for the convenience of the cache.

The failure this prevents is specific and quiet: a stale answer read as a current one. Degrading past the TTL to a no-answer rather than a weak yes forces the calling rule to decide what to do with the absence, which is the decision that was being skipped. Freshness also belongs in the record, so a decision reviewed months later can be re-derived from what was actually known at the time, which is what makes an attestation worth keeping and a trust signal worth distinguishing from a score.

Where a provider reports its own answer's age, that figure belongs in the response rather than in a log line, so the consuming rule can apply its own TTL instead of inheriting the provider's.

Treating freshness as a first-class field rather than an implementation detail is what makes the property auditable later.