engineeringMay 12, 2026· 3 min read

Five TTL policies: engineering the shelf life of truth

Answers age at different speeds — prices in days, math never. A single TTL knob can't express that, so Crowkis ships five policies plus version pinning and webhooks.

TTL design usually gets one integer and a shrug. But cached truth has genres: the Pythagorean theorem never expires, your pricing page expires on marketing's whim, 'today's status' expires at midnight, and policy answers expire exactly when the policy document revs. One number flattens all of that into a single wrong compromise.

In plain words: Math never expires; prices expire when marketing says so. Crowkis lets every answer carry the right expiry — and old answers fade out gracefully instead of failing suddenly.

Crowkis ships five TTL policies covering the genres — from never-expire through fixed windows to event-driven invalidation — assignable per entry and defaulted sensibly per intent class (temporal intents inherit short windows automatically). Version pinning ties entries to a document or config version; invalidation webhooks let your pricing pipeline or CMS kill affected entries the moment upstream truth changes.

the write-trust pipeline

Five stages score every write before it can ever be served.

The subtle layer is freshness decay inside confidence: an entry approaching staleness doesn't cliff from served-to-dead — its freshness signal sags, dragging the composite score toward the threshold, so borderline-old answers start losing to recomputation before they can mislead. Expiry becomes a gradient with a deadline, not a trap door.

The bottom line

Staleness is the failure mode users forgive least — a wrong price reads as a lie, not a bug. Engineering shelf life explicitly is what separates a cache you trust from a cache you audit.