Shipped: KB block freshness alerts in review
Stale KB content now flags itself before a reviewer touches it. The freshness signal sits inline on every drafted answer that cites a block past its refresh date.
Stale KB content now flags itself in the review UI. Every drafted answer carries a freshness signal next to its citation. Reviewers see “this block was last verified 14 months ago” inline, before they sign off on the answer. The relevant page is /platform/knowledge-base; this post is the engineering note.
What landed
Three things, in order.
Per-block refresh windows. Every KB block has a configurable refresh window. SOC 2 attestations get 12 months. Insurance certificates get 12 months. Pricing-related blocks get 6 months. Generic policy blocks get 24 months. Owners can override per block.
Freshness states. Each block sits in one of four states:
- Current — verified within the refresh window. Green dot.
- Aging — past 75% of the refresh window. Yellow dot.
- Stale — past the refresh window. Red dot.
- Expired — past 150% of the window. Red dot, plus the block is excluded from drafting until refreshed.
Inline rendering. On any drafted answer, the citation chip carries the block’s freshness state. A reviewer doesn’t have to leave the proposal to see whether the source is current. Hover surfaces the last-verified date and the refresh window.
What this maps to
Sparrow’s research on content library best practices and Shelf’s post on outdated knowledge bases name the same failure: KBs decay silently, the AI on top of them surfaces stale content, and the reviewer either catches the staleness late or doesn’t catch it at all.
The pattern is recoverable but only if the staleness signal lives where the reviewer is. We’ve shipped staleness signals in the KB admin UI for months — they were not enough. Reviewers don’t open the admin UI during proposal review. The signal has to be inline on the drafted answer at the moment of approval.
How owners set windows
A block’s refresh window is editable from the block detail page. Defaults are set per category:
- Compliance attestations (SOC, ISO, FedRAMP) — 12 months. The audits are annual; the answers age with the audits.
- Insurance — 12 months, aligned with policy renewals.
- Financial — 12 months for audited statements; 90 days for cash-position blocks.
- Pricing — 6 months. Pricing changes faster than other content.
- Privacy / data residency — 12 months. Tied to annual privacy reviews.
- Generic policy — 24 months. Slow-moving.
- Product / capability — 6 months. Roadmap and feature drift.
Defaults can be overridden per block. The override is logged for audit.
What expires looks like
When a block crosses 150% of its refresh window — say, 18 months for a 12-month SOC block — it transitions to Expired. The drafting engine excludes Expired blocks from retrieval until they’re refreshed. A reviewer who hits the Expired state sees a refusal at draft time, not a stale answer at review time.
This is the stricter mode. It’s on by default for compliance and insurance blocks; off by default for generic policy. Customers can change the policy globally or per category.
Where to find it
The freshness chip is rendered automatically next to every citation. No settings change required. Existing customers see the chip on their next draft session.
Block-level refresh windows live in the block detail page. The KB admin UI surfaces an aggregate view of every block’s freshness state, sortable by category and owner.
Documentation: /platform/knowledge-base under Freshness.
What’s next
A planned follow-up: scheduled refresh nudges. Today, the system flags staleness; the owner has to act. The next ship is a Slack or email nudge to the block owner X days before a block expires, with a one-click “still current, extend by N months” action. Targeting later this quarter.