Knowledge Base Content: What to Include and How to Write It

Useful knowledge base content answers questions people repeatedly need to resolve: what something means, how to do a task, what was agreed, and what to do when something fails. Start with a small set of verified answers rather than copying every document and conversation. The examples below show what to include and how to keep each kind of answer distinct.

Tools like fenbs give project rules, context notes, lessons, and references their own places in a shared work record. You can use the same distinction when drafting documents elsewhere. Keep the original evidence available so a polished summary never becomes the only support for an important claim.

Which content types should you start with?

Choose content by the question it answers. A procedure helps someone act; a reference note helps someone understand a fact. Combining everything into one meeting summary makes it harder to identify an instruction, check a source, or see that a choice is still awaiting approval.

For a hypothetical studio preparing a client handoff, those types might cover export requirements, packaging steps, missing-image checks, an approved delivery choice, and the last unfinished check. You do not need every type for every project. Write the answer someone needs next, then add another page when a real question exposes a gap.

What does a useful reference note look like?

A reference note states one dependable answer and shows where it came from. Write the answer first, then explain its scope. Google's technical writing guidance↗ (opens in a new tab) recommends defining the audience and scope and summarizing key points at the start; those habits work well for short project notes too.

Title: Approved delivery format
Answer: Use the format named in the approved project scope.
Applies to: Final client delivery for this project.
Source: Link to the approved scope, Delivery section.
Checked by: Project lead
Last checked: October 20, 2026
Open question: Does the client also need editable source files?

This example intentionally leaves an unanswered question visible. The note should not infer that a delivery requirement covers editable originals. When the source is unclear, link the evidence and ask the responsible person rather than allowing an assistant to turn a reasonable guess into a supposed requirement.

Keep selected reference links in one maintained location. In fenbs, Links and listings can preserve those references with status and dates; the working context overview explains how that record sits alongside project notes and decisions.

How should a procedure and a troubleshooting note differ?

A procedure describes the normal route to a result. State what the reader needs before starting, use actions in order, and finish with evidence of success. A screenshot or the phrase looks good is rarely enough when the task requires checking that a file opens, a message arrives, or a recipient can access a link.

Title: Prepare a client handoff folder
Before you start: Confirm the approved deliverables.
1. Add the approved final files to the shared folder.
2. Open each file using the expected application.
3. Check recipient access with the project lead.
Success check: The lead confirms the files and access.
Stop if: A deliverable or approval is missing.

A troubleshooting note begins with the observed failure. Separate things a reader can test from explanations they have not confirmed. This prevents the note from treating every missing image as the same problem or sending someone through a long list of unrelated changes.

Symptom: A linked image is missing from the exported file.
Check first: Is the image visible in the source document?
Then check: Is its linked source available?
Record: File name, export method, and exact result.
Stop and ask: If the approved source file cannot be found.
Resolution: Add only after the fix has been verified.

Use headings that describe the task or symptom. W3C guidance on headings↗ (opens in a new tab) explains how heading structure supports navigation, including assistive technology. That gives the reader a route through a long explanation without relying on visual styling alone.

How do you write a decision, a rule, and a lesson?

A decision records a choice someone made. A rule records an instruction that continues to apply within a stated scope. A lesson records what experience taught you. Keep these distinct so a failed attempt does not silently create a new policy and a temporary exception does not become a permanent instruction.

DECISION
Choice: Deliver the approved preview before editable originals.
Decider: Project owner
Reason: The preview is needed for the scheduled review.
Scope: This delivery only.

RULE
Instruction: A person approves changes to client deliverables.
Decider: Project owner
Scope: All work on this project.

LESSON
What happened: An old export was included in a review pack.
What we learned: Similar names made the current file unclear.
Next time: Check the approved source before packaging.

These are illustrative records, not policies for your business. Replace the choices with what your own responsible person actually decided. An assistant can draft the wording and record that choice; the wording itself cannot supply the missing approval.

What belongs in a glossary and a handoff?

A glossary defines the terms that otherwise cause repeated confusion. Include the preferred meaning, an example, and any nearby term people mix it up with. Avoid turning the glossary into another place to hide instructions. A definition explains what ready means; the procedure explains how to check readiness.

Term: Review pack
Meaning: The approved preview files and open review questions.
Example: The layout preview plus the unresolved copy choices.
Different from: The final delivery folder.

A handoff says what changed during the latest work and where the next session should start. Include what was checked and what remains uncertain. Save the durable answer in its proper note, then use the handoff to point to it rather than pasting another complete copy.

Completed: Added the approved previews to the review folder.
Checked: Each preview opens correctly.
Not checked: Recipient access.
Waiting on: Project lead to confirm the recipient list.
Start next: Check access after that confirmation.
References: Task and approved delivery decision.

How to do this with fenbs

1. Create a free account and add one active project to your kanban board.
2. Add a context note using the reference example. Include a precise source link and identify any unresolved question.
3. Record a person's approved choice in Decisions and rules, then add a lesson if the project has revealed a repeatable mistake.
4. Connect your supported assistant from Integrations. Ask it to read the project context and save a clear Where we left off record before stopping.

fenbs is free for one person, with no credit card, and is useful for the shared work these examples describe. It is not a document publishing system; keep long manuals or a public support center in a tool suited to those jobs.

How can you tell whether an example is ready to reuse?

Ask someone else to answer a real project question using the draft. Can they identify the current answer, open its source, and tell whether an approval is still missing? Test the procedure by following it, and check the handoff from the perspective of someone who did not attend the earlier conversation.

Choosing a system is a separate question: the guides to an AI knowledge base, internal knowledge base software, and a Confluence knowledge base cover those nearby choices. For this task, improve one answer until a colleague can use it confidently; the context engineering hub connects that habit to better AI starting context.