Choose a refresh policy for the rate your documentation changes

Classify sources by change pattern

Some documents change only with a release; others contain limits or procedures that can change between releases. List those patterns in the inventory. A weekly schedule may be unnecessary for stable conceptual material and insufficient for a time-sensitive operational instruction. The right policy depends on the consequences of stale guidance, not on a universal frequency suggested by a pricing tier or a comparison article.

Verify the current plan entitlement

Check whether the selected product and plan support the source type and refresh method you intend to use. SiteGPT’s public pricing differentiates refresh capabilities across plans; confirm the current details before choosing. A feature label does not establish the time between a source edit and a correct visible answer. Keep that delay as an observed property of your setup rather than a guaranteed product promise.

Add an event-driven check

For a known important release, make a targeted source and answer check part of the publishing checklist. This complements a routine refresh schedule without requiring a full evaluation every day. Record the exact changed passage and the question that depends on it. If the result is stale, investigate the update path rather than repeatedly requesting another refresh with no evidence of what failed.

Prefer a maintainable commitment

Choose a policy the team can actually operate and verify. A faster automated schedule still needs ownership of contradictions, failed imports and unexpected answers. If the source changes too quickly for the available process, narrow the assistant’s remit or direct readers to the authoritative live page. Do not present a calendar setting as proof of real-time accuracy.

• Record the required update interval separately from the observed interval and the vendor’s advertised feature so none is mistaken for another.