RFP knowledge-base design for answers teams can defend

Knowledge model

Store a defensible claim, not a reusable-looking paragraph

A previous answer mixes several layers: facts about the company or product, interpretation of the buyer’s language, a selected level of detail, persuasive positioning and deal-specific commitments. Copying the paragraph reuses all layers whether or not they still apply. Instead, model a factual claim with its subject, predicate, value, scope and evidence. Attach approved explanatory fragments and caveats separately. The final response can then be composed for the new question without pretending that one paragraph is universal.

Granularity is a design judgment. “The platform supports encryption” is too broad to defend. A useful claim identifies the relevant data state, component, configuration, boundary and source. Splitting every sentence into isolated tokens is equally unhelpful because relationships disappear. Test the unit by asking whether an owner can approve it, a writer can understand its applicability and a change can identify the affected responses. Preserve bundles where several claims must travel together to avoid a misleading answer.

Governance

Make provenance and change propagation part of the data model

Each claim should point to the evidence that establishes it: an approved policy, product specification, controlled register, contract position or named expert decision. Store enough identity to recover the exact version used. Record the owner, approver, valid period and sensitivity. If the evidence is a live system, record the query or record identity and retrieval time. A link to a mutable homepage is not durable provenance. When no authoritative source exists, mark the gap instead of laundering confidence through polished prose.

Changes need dependency handling. A revised policy should identify which claims depend on it, which response fragments repeat them and which active submissions may be affected. Do not delete the previous state; retire it with reason and effective date so earlier releases remain explainable. Use review queues driven by material change and risk rather than an annual ritual applied equally to every sentence. A security claim tied to a changed architecture deserves immediate attention, while stable company history may need a lighter cadence.

• Keep exact source and version identity.
• Distinguish evidence from commentary and approval.
• Represent unknown and conflict as first-class states.
• Track dependencies from sources to claims and answer fragments.
• Retire with history rather than silently overwrite.

Retrieval

Filter for permission and applicability before ranking relevance

Vector similarity is useful for matching varied buyer language, but similarity is not permission or applicability. Resolve the authenticated user and exclude knowledge they cannot view. Apply hard filters for product edition, jurisdiction, valid date, confidentiality and other non-negotiable scope. Then combine lexical and semantic signals with question classification, evidence strength and recency. Return several compatible claim objects when a question is compound rather than selecting one paragraph because its wording looks closest.

The answer interface should reveal the retrieval path. Show which claims were used, their sources, scope and approval state. Surface competing evidence and missing coverage. Let the writer remove a claim without erasing the audit trail and add deal-specific material as a separate object. Exports need stable citations or references so provenance survives outside the application. If the target format cannot carry rich metadata, preserve it in the response record and provide a lightweight visible marker for reviewers.

• Enforce access and scope before semantic search.
• Retrieve evidence objects, not only answer text.
• Expose conflicts and insufficiency to the writer.
• Preserve provenance through editing and export.
• Never treat fluent synthesis as an authoritative source.

Quality

Evaluate whether the right evidence reaches the right answer

Create an evaluation set from real question families. Include paraphrases, abbreviations, negative questions, tables, compound requirements, multiple languages and requests for unavailable facts. Label the evidence that should be retrieved, what must not be used and what a safe unknown response looks like. Measure whether suitable material appears in the first results, but also whether the assembled answer is supported, complete and within scope. An apparently relevant result can still be unusable if it answers a nearby product or expired policy.

Use production edits as signals, not automatic truth. A writer may change tone, add buyer context, correct a fact or introduce an error. Classify the edit and send proposed knowledge changes to the relevant owner. Review frequently rejected retrievals and unanswered questions by family. Coverage can be improved by new evidence, better metadata, adjusted segmentation or a clearer product policy. This closes the loop while keeping approval authority separate from popularity.

• Test paraphrase, negation, compound and multilingual questions.
• Label both expected and prohibited evidence.
• Measure support and completeness after assembly.
• Classify writer edits before learning from them.
• Route knowledge changes to accountable owners.