Shipped: content-block versioning in the KB
Every content block in your knowledge base now keeps an immutable version history. Drafts that cited a block stay tied to the exact text they cited, even after the block is edited.
Content-block versioning shipped this week. It does one thing, and the thing is load-bearing for everything else the knowledge base does.
What changed
Every content block in your KB now has an immutable version history. When a block is edited, the previous version isn’t overwritten — it’s preserved, with its own version ID, timestamp, and editor attribution. The current version is what surfaces in search and drafting by default. Earlier versions remain queryable by ID.
When a proposal cites a block, the citation pins to the version that existed at draft time. If the block is later edited, the proposal’s citation still resolves to the exact text the writer drafted from. A reviewer opening the proposal three months later sees the source the writer actually used, not whatever the source has become since.
Why this matters
Two practical reasons.
First, answer stability. A proposal in a 90-day evaluation window will outlive several KB edits in a healthy team. Without versioning, a sentence drafted from “version A” of a block can be edited mid-evaluation when the block updates to “version B” — and the citation now points at content that doesn’t match what the writer originally drew from. Versioning closes that gap. The cited block is the cited block, forever.
Second, audit. When a proposal makes a compliance claim and the underlying block is later corrected, a reviewer or a customer’s auditor can see what the team believed when they drafted, when the block changed, and who changed it. That’s not a feature anyone asks for in a sales call. It’s a feature people are very glad exists when it matters.
Sparrow Genie’s piece on RFP content libraries names the underlying problem in plain terms: most content-library failures trace to unclear ownership and stale content surfacing under a current-looking timestamp. Versioning isn’t the whole answer — block ownership, freshness signals, and review workflows are separate features — but versioning is the substrate the others depend on. Without it, the others have nothing to attach to.
What you’ll see in the UI
In the knowledge base, every block has a new “Versions” tab. Open it on any block to see the history — when it was created, every edit since, the diff between versions, and the editor who made each change. If a draft cited a previous version, the cited version is flagged in the history list.
In the drafting flow, citations now display the block version explicitly. A reviewer opening a draft sees not just “block 4f82” but “block 4f82, version 3, last edited March 14.” If the block has been updated since the draft was written, the reviewer sees a “newer version available” indicator with a one-click diff. Updating to the newer version is opt-in and audited.
What’s next
Two related features are in the queue: block-level approvals (a separate review state for KB content, distinct from draft review), and per-block source permissions (controlling which teams or roles can read which blocks). The second one ships in this changelog series before the end of the month.
Versioning runs on every existing block and every new block automatically. There’s nothing to enable.