How to Build a Knowledge Base for AI Content That Sounds Like Your Business

A knowledge base for AI content is a folder of short, typed files that a model reads before it writes, where every entry says what kind of sentence it is, who owns it, when it expires and who may publish it. This guide covers how to build a knowledge base for AI content that way: what goes in it, the nine files, the six fields on every entry, and the rules that stop an opinion being published as a fact. It ends with the cold-draft test, which proves the base sounds like the company before any automation depends on it.

How to build a knowledge base for AI content, and what it is not

You build a knowledge base for AI content by sorting what the business knows into a small set of files by type, and by giving every entry six fields: an id, a type, an owner, a source, a review-by date and a permission level. The second half is the part most attempts skip, and it decides whether the drafts can be trusted. A folder of documents tells a model what has been said. A typed base tells it what is true, what is only believed, what has gone stale and what must never leave the building.

It is not a document dump. Uploading the sales deck, the website and years of proposals feels like giving the model everything, and it can make drafts worse: a 2023 study titled Large Language Models Can Be Easily Distracted by Irrelevant Context found performance dropped sharply when unrelated material was included. Anthropic's engineering note on effective context engineering for AI agents describes the goal as the smallest set of high-signal tokens that gets the result you want. It is the same reason we take apart pasting everything into a chat tool in can you just use ChatGPT for content.

It is not a vector store either. Retrieval tools find passages; they do not decide what a passage means. A search that returns the right paragraph still cannot tell the model whether that paragraph is current or confidential. Anthropic's write-up of contextual retrieval adds that a knowledge base under about 200,000 tokens can simply go into the prompt whole, and most small businesses fit inside that.

Nor is it a voice file, which is one of the nine files. How a sentence travels from a sales call to a published post is covered in how business knowledge becomes automated content, and choosing what the business should be known for is how to identify your knowledge pillars; both sit in our business knowledge guides. The question here is narrower: what the folder looks like on the day a model first opens it.

What goes in a content knowledge base

What goes in a content knowledge base is everything the business already says well, taken from the places it already says it, and nothing written fresh for the occasion. The table lists the usual sources. Each of those is a source, not an entry. The work is taking out the part a model can use and writing it down once, in the file its type belongs to.

The table runs one way on purpose. A source can feed two files, but an entry lives in exactly one, so anyone maintaining the base knows where to change it. Keep the sources too, in a folder the model does not read, so every source field points at something a person can open. Most businesses find the same few explanations in dozens of places with small differences; pick the best wording once and let the others go.

Customer language earns its own file because a business rarely writes it down and a model needs it most. The company calls it onboarding; the customer calls it the first month where nothing works. One wording per idea also helps any tool that retrieves rather than reads.

An AI content knowledge base as nine files, and six fields on every entry

An AI content knowledge base works best as nine plain-text files that share one format for every entry, so the model and the people who maintain it can read any file the same way. The nine are an index, facts, positions, evidence, examples, language, offer, do-not-say and voice. The index is the map: it says what each file holds, the order the model reads them in, and which file wins when two disagree. Every other file is a list of entries, and every entry carries the same six fields before its text.

The six fields are the whole taxonomy. The id is a short, stable name, so a draft can say which entry it used. The type repeats the file's name, so the entry keeps its meaning when copied. The owner is a named person who can confirm the entry or retire it. The source says where it came from, the review-by date says when it stops being trusted without a second look, and the permission level says who may publish it. A single entry in the facts file might read like this:

• id: fact-support-hours
• type: fact
• owner: the head of service
• source: the current service agreement, section on support
• review-by: the end of next quarter
• permission: public
• text: Support calls are answered by a person during business hours, and out-of-hours calls go to the engineer on call.

The fixed order matters more than the tool. Anthropic's prompting best practices for Claude recommend tagging each kind of content so the model can tell instructions, context and examples apart, and labelled fields do the same job. Read order matters too, which is why the index lists do-not-say and voice first: those two shape every sentence, so the model meets them before anything else. The files can sit under any subject structure; ours is the knowledge architecture framework.

Any tool that reads files can use the base. Claude Code loads standing instructions from a CLAUDE.md memory file, so one line there telling it to read the index first is a working setup. Anthropic's help page on what Claude projects are describes uploading documents to a project's knowledge base, which works too. The format is what carries across. What else that instruction file should hold is covered in our guide to how to write a CLAUDE.md file.

Facts and opinions are two file types with opposite rules

Facts and opinions belong in separate files because a model must treat them in opposite ways: a fact may be stated plainly, and an opinion must always be said as someone's view. A fact could be checked and found wrong, such as what a service includes or how quickly support answers. An opinion is something the business argues, such as that most small firms buy the wrong thing first. The failure is a draft that writes the founder's opinion in the voice of a fact, which reads as confident until a reader disagrees and the company has nothing to point to.

So the rules differ. A fact needs a source a person can open and a review-by date, and it is stated without hedging. A position needs an owner and the reason they hold it, and the draft frames it as advice the business gives. Evidence sits between the two: a case note or published figure that may be stated as fact only when its source and its permission both allow. Anthropic's guide to reducing hallucinations in Claude suggests telling a model to use only the documents it was given and to drop any claim it cannot back with a quote, and a typed base makes that workable, because the model can see which file a line came from.

Keep the two files honest with one question: if a customer pushed back on this sentence, would we show them a document or explain our reasoning? A document means a fact; reasoning means a position; a sentence that needs both is two entries. The one-line claim format we describe for turning business knowledge into content fits inside the facts file unchanged.

The do-not-say file, and an AI style guide for a business

The do-not-say file is a list of business rules a draft must never break, and it is a different thing from the banned words in a voice guide. Banned words are taste: a phrase the founder dislikes. Do-not-say rules are risk: a guarantee the contract does not give, a result the company cannot prove, a competitor named in a comparison, a service the business does not sell, a client named without written agreement, a claim the sector's regulator would not allow. Breaking the second kind can cost a client or a contract.

Write each rule as an entry with the same six fields and a reason, because a model that knows why a rule exists applies it to cases the rule did not name. "Never promise an uptime figure" is weaker than "never promise any figure the service agreement does not state", which also covers response and recovery times. List the services the business does not offer here too, or a model asked about a neighbouring service will describe it as if the company sold it.

An AI style guide for a business is the voice file, and it describes how the company sounds, which is often not how the founder sounds. The company page, the service pages and the proposals usually need a steadier, plural voice that a new hire could also write in. A founder's personal file is a different job, covered in the LinkedIn voice reference. The company file is a short description of the register, the words the company uses and avoids, and examples drawn from the examples file.

Examples carry more of the voice than any description. Anthropic's guidance on using examples effectively calls them one of the most reliable ways to steer tone and structure, and suggests three to five that mirror the real task and vary enough that the model does not copy one pattern. So every entry in the examples file carries one line on what makes the piece right, and the model learns the reason as well as the shape.

Permissions and review dates: who may publish each entry, and when it expires

Every entry carries one of four permission levels and a review-by date, because a base that a model can read freely will sooner or later be quoted freely. The four levels are public, which may be published as written; anonymised, which may be used once names and identifying detail are removed; background, which the model may use to understand a subject but must never state; and never, which is a rule in the do-not-say file rather than material in the base. Client work starts at background and moves to public only when the client agrees in writing.

The permission belongs on the entry, not on the file, because one case note can hold a public result and a confidential detail in the same paragraph; split it into two entries if the parts need different levels. The Model Context Protocol, which many AI tools use to read outside data, says the same in its own terms: its specification for MCP resources lets a server mark who a resource is for and when it was last modified, and says access controls should be implemented for sensitive resources.

A review-by date turns a stale entry into a scheduled chore instead of a published mistake. Facts about prices, dates, staff, tools and vendor terms change fastest and get the shortest windows. Positions change slowly and can be reviewed once or twice a year, and examples are rechecked when the offer changes. Schema.org's expires property defines the same idea for published work, the date content is no longer useful or available, which is a good question to ask of every fact.

Expired entries drop out of drafting until their owner confirms them again. That one rule does a lot to keep automated content accurate, because the entry nobody has looked at in a year is the one most likely to be wrong and least likely to be noticed. The same review-by logic, applied to every part of the system rather than to the base alone, is how you keep a content operating system from going stale.

The cold-draft test: proving the base sounds like your business

The cold-draft test proves a knowledge base works by giving a model only the base and three briefs, then having the owner mark every sentence of the drafts as ours, not ours, wrong or not allowed. Cold means nothing else goes in: no chat history, no pasted website, no extra notes. If the drafts sound like the business with only the base to go on, the base is doing the work. If they do not, the marks say which file is at fault.

Each mark points at a file. Not ours is a voice or examples problem: the facts are right and it still sounds like somebody else. Wrong is a facts problem, a missing entry or one past its review date. Not allowed is a permissions or do-not-say problem, and the most important of the four, because it would have reached a reader. A sentence with no entry behind it is the other common finding, and the fix is an instruction in the index to leave a marked gap rather than fill it.

Choose the three briefs to stretch the base in different directions: one that leans on facts, one on the founder's positions, and one that comes close to a client story, which tests permissions in a way a calm brief never will.

Run the test again whenever a file changes in a way that matters, and always before an automated workflow starts drafting from the base. This is where the base becomes the knowledge layer of a Content OS: every workflow that researches, drafts or repurposes reads from it, so a base that fails makes all of them wrong in the same way. It is why the base comes first when you build a content operating system from scratch.

A managed IT firm's first cold draft, and the three files that fixed it

Here is the test run once, on a twelve-person managed IT services firm; it is an illustration, not a client, but every failure in it is a common one. The firm looks after small offices' computers, networks, backups and security. Its founder wanted posts for the LinkedIn company page and articles for the website, drafted in Claude Code from a base built out of proposals, support tickets, case notes and the founder's recorded explanations. It had all nine files, but not the six fields on every entry, because most of it had been pasted in from older documents.

The briefs were a post on what an office should do when its main software reaches the vendor's end of support, a post on whether a small office needs a second firewall, and an article on recovering from ransomware. Claude Code was told to read the index, then the files it named, and nothing else. The founder marked every sentence. Three sentences failed, each differently.

The first draft gave an end-of-support date for a widely used accounting package. The date had been right when someone copied it from the vendor's notice, and the vendor had since extended it; the entry had no review-by date, so nothing flagged it. The fix was in the facts file: every vendor date got the shortest review window, an owner and a source pointing at the vendor's own page. That sentence was marked wrong.

The second draft said, as a plain statement, that small offices do not need a second firewall. That is the founder's view, argued well on sales calls, but it depends on how an office is set up, and it had landed in the facts file because nobody asked whether it was a fact. The fix was in the positions file: the line moved there with the founder as owner and the reasoning beside it, and the redraft said it as the advice the firm gives. That sentence was marked not ours, because it was more certain than the firm is.

The third draft named a client in its opening paragraph, a dental practice the firm had helped after an incident, with enough detail that anyone in town would know who it was. The case note had been imported from an internal record with no permission level, so the model treated it as public, and the practice had never agreed to be named. The fix was in the evidence file: the note was split into an anonymised entry and a background entry, and a do-not-say rule now says no client is named unless their evidence entry is public. That sentence was marked not allowed.

The base now feeds a small n8n workflow too. n8n's Schedule Trigger node starts it every Monday, and its Read/Write Files from Disk node reads the knowledge folder, so it can send each owner the entries whose review-by date has passed. On n8n Cloud that node reaches only one home directory and its storage is not permanent, so a team there keeps the folder in cloud storage, as n8n's documentation advises.

What is automated, what stays human, and what the base costs

The model and the workflow can draft from the base, check entries against their review dates, flag a sentence with no entry behind it and send the expiry lists on time; the people who hold the knowledge still decide what is true, what the business believes and what may be published. It is the line we draw in what to automate in your content, applied to the base itself. A model can draft entries from a source, but the owner confirms each entry's type and permission, because those are judgements about the business.

The cost is mostly time from the people who know things, and most of it arrives at the start. The founder writes or records the positions, because nobody else can. Whoever runs delivery confirms the facts and the client permissions, and someone close to sales pulls out the customer language. After that, the steady cost is the expiry review, a short list each month for each owner, and a cold-draft test whenever a file changes. A base nobody reviews is cheaper for a few months and then expensive all at once.

There is a cost in saying no as well: the best client story under an agreement, the comparison with a competitor, the promise the sales team makes out loud. Leaving those out is the price of drafts that can be trusted. If you would rather have the base built and tested for you, even our smallest setup, the Single-Platform System, starts with a knowledge and voice reference sized for that one platform, a second platform added later becomes the Two-Platform System and shares the same base, and what a content automation specialist builds covers the rest of the system around it.

Frequently asked questions

What is the difference between a knowledge base for AI content and a brand voice guide?

A brand voice guide is one file inside the knowledge base, and it covers only how the company sounds. The knowledge base also holds what is true, what the business believes, the evidence behind its claims, its customers' words, its offer and the rules it must never break, each with an owner, a review date and a permission level. A model with only a voice guide writes in the right tone about things it has to guess.

How much has to be in the knowledge base before the first cold-draft test?

Enough to answer three briefs without guessing, which is usually far less than people expect. A short voice file, three to five approved examples, the do-not-say rules and the facts and positions those three briefs touch are enough to run the test. The marks then show which file to write next.

Can we keep the knowledge base in a vector database instead of plain files?

Yes, but keep the typed entries as the source and treat the database as a way of searching them. A vector database finds passages that look relevant; it does not know which of them is an opinion, which has expired or which is confidential. If each stored chunk is one entry with its six fields attached, retrieval keeps those answers, and a small business may not need retrieval at all.

Who should own the entries in a small business?

The person who would be asked if a customer challenged the sentence. Positions belong to the founder or whoever argues them, facts about the service belong to whoever runs delivery, client evidence belongs to whoever holds the client relationship, and the do-not-say rules belong to whoever answers for contracts. Every entry needs a name, or nobody confirms it when its date comes round.

How often should a content knowledge base be reviewed?

Each entry is reviewed on its own date, not the base all at once. Facts about prices, dates, staff, tools and vendors get the shortest windows, positions can wait six months or a year, and examples are rechecked whenever the offer changes. A weekly workflow listing each owner's expired entries keeps that small.

Should a client case study go in the knowledge base if the client has not agreed to be named?

Yes, as background or anonymised, never as public. The model can still learn what the firm did and in what order, and it can tell the story without names or identifying detail, which is often all a post needs. The entry moves to public only when the client agrees in writing, and a do-not-say rule stops any client being named while their evidence entry sits at a lower level.

Where to start

Pick the file your drafts get wrong most often, usually facts or positions, and write ten entries for it with all six fields filled in. Add a short voice file, three to five examples and the rules the business must never break. Give a model only those, three briefs and an instruction to leave a marked gap rather than guess, and mark every sentence it writes. The marks will tell you which file to write next.

Keep reading

• How business knowledge becomes automated content — what happens to an entry after it is written: the path from a sales call to a published post, and back again when a fact changes.
• The knowledge architecture framework — the subject structure the nine files sit under, so the base grows by topic rather than by accident.
• How to automate LinkedIn content without sounding like AI — the founder's own voice reference, the personal counterpart to the company voice file here.