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.
This week we shipped answer-block inheritance across in-flight proposals.
The behavior change: when an approved knowledge-base block is edited, every active proposal that references that block surfaces the change as an inherited update — visible in the proposal’s review pane, applied automatically to the draft, but never silently overwriting a local edit a writer has already made. The status badge tells you which mode the block is in: inherited from KB v3, locally edited (KB v3 inheritance available), or locally edited (KB v4 inheritance available — review).
Three cases the merge has to handle.
Case 1: clean inheritance. The proposal references the block at version 2 and has no local edits. The KB block is updated to version 3. The proposal’s draft updates to version 3. The badge shows inherited from KB v3. No reviewer action required. This is the most common case.
Case 2: local edit, no upstream conflict. The proposal references the block at version 2 and a writer has edited it locally to fit the buyer’s vocabulary. The KB block is updated to version 3, but the upstream edit is in a different paragraph than the local edit. The system applies the upstream edit and preserves the local one. The badge shows locally edited, KB v3 partial-inherit applied. Reviewer can click to see exactly which lines came from KB and which are local.
Case 3: local edit, upstream conflict. Same as Case 2, but the upstream edit and the local edit touch the same paragraph. The system does not merge automatically. The proposal stays at version 2 with the local edit intact. A KB v3 inheritance available — review badge appears, and the reviewer can open a diff pane to choose: keep local, take upstream, or hand-merge. We refused to silently auto-resolve this case because the wrong choice ships fabrications into the proposal.
Two operational notes.
The inheritance signal flows on a write to KB, not on a read from the proposal. We don’t poll. When a KB block is edited and approved, the system enumerates the proposals that reference the previous version and writes inheritance status into each one. The proposal pane reflects it on the next reviewer load. Latency on the propagate step is sub-second for proposals under 200 blocks.
Provenance is preserved across inheritance. The block’s source pointer, version, and author chain stay attached to the inherited copy. A proposal at inherited from KB v3 shows the same citation footer as a proposal at KB v3 — the inheritance does not strip provenance.
This builds on block versioning and the diff view we shipped earlier in the year, and refines the Knowledge Base governance surface — owners, edit history, retire-without-breaking-history. The next piece is the freshness signal: when a block goes stale (no review in 90+ days, or upstream documentation changed), the proposal pane will surface that even before the inheritance event. That’s in flight.
Docs: see the Knowledge Base → Inheritance section of the product docs for the full state diagram and a reviewer walkthrough.