Blog · Tag
kb.
14 posts in this archive.
Block schema v3: merging KB blocks and evidence atoms
The schema change that let DDQ evidence live in the same store as proposal answers. What we split, what we merged, and the migration that took a week longer than we planned.
Reviewer feedback routing: comment to block to KB
How we close the loop from an inline comment on a draft paragraph to a versioned edit on the KB block that generated it. The routing is boring; the discipline it enforces is the whole game.
Win-loss, Part 4 of 5: closing the KB feedback loop
How a debrief finding becomes a block edit that ships into the next bid. The review cadence that makes it stick. The specific anti-patterns that break the loop.
Win-loss, Part 3 of 5: the five anti-patterns
Lessons logged and never applied. Themes that don't match answered questions. Five failure modes I see when a win-loss program looks healthy from the outside but isn't moving the win rate.
Linking debrief notes to the specific answer blocks that failed
How every debrief comment becomes a KB-block edit suggestion. The two-pass linker that walks from a free-text comment to the exact block that sourced the failed answer, with the SQL and the heuristics.
Shipped: keyboard-first KB search
A small thing that power users have been asking for since month three. Keyboard-first KB search with a reachable command palette, typed result filtering, and no mouse required to open, navigate, and act on a chunk.
Block reuse tracking: the metric that matters
Which KB blocks got used, in what proposals, and what they correlated with winning. How we instrument reuse, what the numbers told us, and where the signal turns into noise.
Turning a SOC 2 PDF into 140 KB blocks
The ingest, the extraction, the linking. A worked trace of how a SOC 2 Type II report becomes the set of KB blocks that DDQ answers cite — with the real pgvector row shape at the end.
Shipped: bulk edit for answer blocks, with undo
A real-world request we dragged our feet on for nine months. Bulk edit is now in the product, with version-aware undo and a confirmation flow that prevents the silent overwrite that made us nervous in the first place.
KB block versioning: the five-year commit history
How a KB block evolves across 18 proposals, three approvals, and one rollback. The data model behind block versioning, why we keep every prior version, and the queries that make it useful.
Shipped: answer-block tagging for win/loss cross-reference
A small change with a downstream payoff. Every answer block now carries tags for buyer, sector, theme, and outcome — wiring the foundation for the win/loss cross-reference work next month.
The answer provenance graph in the KB
Every block in the knowledge base tracks source, author, approver, and last-used-in. The provenance graph isn't bookkeeping — it's a product surface. Here's what it stores and what it powers.
Shipped: answer-block inheritance across projects
When you edit an approved KB block, in-flight proposals inherit the change without overwriting their local edits. Here's how the merge resolves and what we did about the conflict cases.
Shipped: content-block freshness scores
Every KB block now carries a freshness score that decays as the source ages, drifts from the company's current marketing language, or contradicts a more recent block. Stale citations get caught at draft time.
See the proposal workflow
Take the 5-minute tour, then start a trial workspace when you're ready to run a real pursuit against your own source material.