Forge Academy: Knowledge Base Setup

A useful knowledge base makes it easy to tell what the business offers, which buyer a message addresses and what evidence supports the claim. Its quality depends on relationships and source discipline, not the amount of text collected. A large store of contradictory material can give the operator more work without giving the draft a clearer direction.

This lesson develops the structured knowledge used in Forge Nodes. It covers source selection, Node boundaries, buyer–pain–proof links and ongoing maintenance. Use the Getting Started lesson first if you need the initial creation sequence; here the goal is a knowledge base another operator can understand and maintain.

Choose source material before writing fields

Start with current, authorised business information. A service scope approved by the offer owner is a stronger basis for a promise than an old sales presentation. A documented example with permission to publish is more useful than an impressive anecdote with no record of its conditions.

Create a small source register outside Forge if needed. Record the source, owner, last verification date, permitted use and any restriction. This is a team maintenance practice, not a claim that Forge provides custom source-register fields or an automatic document-ingestion workflow.

Source	What it may support	What to resolve first
Current approved service scope	Deliverables, inclusions and exclusions	Whether it applies to the offer being marketed
Demonstrable product capability	A factual explanation of what the product does	Version, availability and the conditions needed to use it
Authorised case record	A specific customer result within its stated circumstances	Publication rights, exact wording and limitations
Sales or support notes	Candidate buyer questions and recurring concerns	Accuracy, relevance and removal of unnecessary personal information

Separate approved material from unresolved material. A useful question in a sales note can guide further investigation without becoming an asserted fact. Do not paste confidential correspondence into a public-facing knowledge item simply because it contains good language. The business-user responsibilities in Forge's Terms of Service include accuracy, review and rights.

Give each Node a coherent commercial boundary

A Node should describe something that can sustain a clear explanation: a product, service, case study or other focused subject. Ask whether its audiences, promise and evidence belong together. If a single description requires several unrelated offers and conflicting next steps, consider separating the subjects.

For an illustrative annual-report production business, “Annual report editorial coordination” can be one service Node. It includes collecting approved contributions, tracking responsibilities and preparing text for review. “Investor presentation design” may deserve a separate Node because the deliverable, buying situation and proof differ. This is a hypothetical example of knowledge design, not a claim about a Forge customer.

Do not create a new Node solely because you need another headline. Several buyer questions may belong to the same coherent offer. Equally, do not merge distinct services merely because the same team delivers them. Use the boundary that helps a reviewer identify which promise applies.

Choose the Node type that matches the subject. The documented product model uses type to influence writing. A case study should contain a defensible account of a specific case; choosing that type does not turn an unverified business claim into case evidence.

Write the offer fields so another person can explain them

Use a recognisable internal name and a factual description. State the value proposition in terms the buyer can understand, and describe a differentiator that can be supported. Include the relevant offer URL where appropriate. The official first-Node lesson sets out these basic inputs.

In the annual-report example, “coordinates approved written contributions and records the responsible reviewer” is more informative than “delivers effortless reporting excellence”. If the service does not perform financial audit or approve the underlying figures, make that boundary clear. The writing should be able to distinguish editorial coordination from responsibilities retained by the client.

Use concise information with enough context to prevent predictable misinterpretation. A short exclusion may be as important as a benefit. Save the factual offer before choosing objective or personality settings; voice can then express the positioning without changing its substance.

Link each pain to a buyer who experiences it

On the Node card, use the buyers count and Add Buyer to define a relevant role. The description should explain the decision or responsibility that makes the offer useful. “Finance reporting lead responsible for coordinating approved contributions” is more actionable than “business leaders”.

Use Add Pain through the pains count and select the corresponding buyer. Describe the problem in a way that identifies its consequence. For the finance lead, the problem might be discovering late that an important section has no agreed reviewer. For a communications lead, it might be inconsistent terminology across contributions. These are different concerns even when they occur in the same project.

A pain should not assume that every member of the audience has the problem. Write it as the situation your offer addresses. If the role or problem is only a hypothesis, retain that qualification in your team's source record and validate it through appropriate conversations or evidence.

Attach proof that supports the exact claim

Use the proofs count and Add Proof, select the relevant pain and enter the supporting information. The relationship matters: a specimen responsibility matrix can show how the service identifies a reviewer, while an approved terminology checklist can show how it supports consistent language.

Neither specimen proves that the service reduced a reporting cycle by a particular percentage. To make a result claim, you would need a verified result, its circumstances and permission to use it. Describe capabilities as capabilities, examples as examples and measured outcomes as measured outcomes.

Keep a claim's conditions close to its evidence. If a result applied to one project with a specific scope, preserve that scope when writing the proof. If a sample is illustrative, label it accordingly. The knowledge-to-marketing guide explains how these distinctions should survive the move into published content.

Use completeness as the beginning of validation

Forge's documented completeness indicator covers 7 factors: name, description, value proposition, differentiator, buyer, pain and proof. It helps reveal missing inputs. It does not independently check whether the entries are accurate, relevant or authorised.

After the presence check, ask a colleague to explain one complete relationship aloud: “This offer helps this buyer address this problem, and this evidence supports this specific claim.” If the sentence requires assumptions, repair the relationship. If the colleague cannot distinguish the service from another Node, revisit the boundaries.

Generate or write a small review draft using the intended surface and inspect how the knowledge is expressed. A consistent misunderstanding may reveal an ambiguous input. An isolated phrasing problem may need only an editorial correction. Use the Brand Voice Setup lesson for tone after the underlying meaning is stable.

Maintain knowledge when the business changes

Assign an owner to the offer and a review date in your team's register. Review sooner when there is a material change: a deliverable is removed, an offer ends, a capability changes, an evidence permission is withdrawn or the responsible person leaves. Do not assume that Forge automatically expires every claim or propagates corrections through already published content.

Update the affected Node information and review upcoming publishing activity. Check Content Plan for scheduled work and examine any draft that may depend on the old fact. If a claim is already live, decide with the responsible owner whether the destination content needs correction. The content governance guide covers those release responsibilities.

Retain a short change record outside the product where needed: what changed, why, who confirmed it and which planned content was checked. Use the Performance Loop lesson to evaluate evidence-driven refinements, while treating factual corrections as necessary regardless of engagement.

Open Forge and audit one Node from source to buyer, pain and proof. Your completion test is a coherent relationship, a verified source and a named maintenance owner. For help deciding the right boundaries for a complex offer, request a demo focused on knowledge-base setup. The Forge overview shows how this knowledge supports the complete marketing workflow.